Right. I see now, the description text of the rules above are misleading, as they refer to channel 3 - which is true for BROLL devices, but not necessarily for others.
The idea is you have one item which represents the actor and one which reads back the current level from the CCU. You have to adjust the channels yourself according to the device used.
IMHO, the easiest way to find the correct channels is via the CCU UI. The status channel is described as “Statusmitteilung”. The actor channel differs - if I’m right, there are also differences between Homematic and Homematic IP. Your HmIP-FROLL should have some channel(s) named “Aktor”.
Describing Screenshot (HmIP-BBL) can bee seen here.
I can confirm, that the rule and the items definition also work for HmIP-FROLL. Even the channels are the same.
Status channel: 3
Actor channel: 4
The only difference is that HmIP-FROLL shows 0% when the blinds are up and HmIP-BROLL shows 100%. I prefer 0% for up and added map transformation to my Broll item.
Thanks for the great work! I really like this community!
So, you are probably thinking I made an update of OH, but thats not the case. I am still on 2.5.6.
Is it possible the Bindinig has been updated without me doing so?
There is something that may have caused it: I installed mariadb yesterday evening and I also installed the corresponding persistance Binding of it.
Thats the only reason I can think of.
Thank you for your input
Is there the possibility to insert this Workaround in the Binding description? There is it directly helpful to the most owner of a Rollershutter. On my oppinion Homematic IP is the favorite Home Automation System in DACH-area and should be fully supported by OpenHAB.
How sounds the idea to implement special devices where e. g. three points are included in one item. And this item is directly controllable like other items/points. I think there will be other special items/devices in other bindings which also needs a special handling to support.
As far as I know, this workaround is no longer necessary if you are using a current version of the binding. Therefore it would not make sense.
How sounds the idea to implement special devices where e. g. three points are included in one item.
There are already 3 or 4 some special implementations within the binding (primarily display devices), but because of the large number of existing devices adding special implementation code to the binding is not possible. But I am already think about an option that would allow a user to influence the behaviour of the binding, e.g. suppress creation of unwanted channels or defining another type.
I have never heard that a binding would be updated this way. You can see the version of the binding in Paper UI. Maybe it happens because the current versions of all bindings are at 2.5.11 and if you install a binding via Paper UI maybe somthing more happened.
I don’t know these devices in detail, because I don’t own them. I have only got the data point documentation from EQ3 and it does not really gives you information about how everything exactly works.
So, I don’t know which data points you want to be combined. If you like, you can create an issue as enhancement request in the github repo with an exact description of how it should work in your opinion. It could be possible to include some special coding for these devices in the binding. But this could take some time.
Anyway, the most flexible solution would be to create a script.
Channel 3 is the command channel which is used to send the command to. Channel 4 contains the Level Information. Like 80% closed.
So if you map channel 3 to an item, one can control the rollershutter but never knows the Level. It only switches between 0 and 100.
So the current solution is to have an additional Script which pulls the Level Info from channel 4 and updates the item tied to Level 3.
Would be very convenient to have this in a singe item without the scripting.
In case you are in need of such a device i would volunteer to sponsor you one for better Analysis and Implementation.
Thanks for this information. I really don’t know why they make it so complicated and why they need that many data points …
I understand. This would definitely better.
In case you are in need of such a device i would volunteer to sponsor you one for better Analysis and Implementation.
Thanks for your offer, but I don’t want to implement more and more device-specific special cases in the binding (there are already some of them making the maintenance of the binding more and more expensive). I would prefer to enhance the binding in a way that allows a user to configure how the provided channels in OH should be derived from the data points: This could be done e.g… in a text format and maybe later editable in the new Main UI.
For the shutter devices I could image to a configuration entry that says: “define a OH channel that reads the current value from Level of Channel 4 and write to Level of Channel 3”.
On the device of Sebastian I can put a Bountysource on top. You will ask you why the guys are so interested in this silly device? I think it is the core device of the Homematic IP system next to the heating control device. Furthermore it should be said that much people have many items in place. I have myself 16 items for 16 windows installed. That is a huge amount to configure and setup.
I imagine that this category of a special item is not only for that FROLL or BROLL. Other Bindings must have this special devices/items too. So other users should also interested in scripted items.
Nope, channel 4 is for the actuation, channel 3 represents thr current level. At least for HmIP-BROLL.
HmIP devices (and HM too, AFAIR) let you run simple logic on the device itself. As for the BROLL, you have actuator channels 4, 5 and 6 which can all be set independently. You can program how the device calculates its behavior out of these three (e.g. AND, OR, MIN, MAX, SUM, Multiply). The CCU is not involved in that.
Therefore it is just mandatory to have a channel to reflect the calculated result.
So just for my understanding, since I’m fairly new to OH: Currently it is not possible to use the HmIP-BROLL on OH out of the box the same way like a, say, dimmer, where you have a slider that allows you to set the desired level information and at the same time show the current level information?
If this is the case, where do I enter the code above and how do I adapt it to my setting?
It’s the key concept of how Homematic manages its channels and so they are exposed via API to third party systems like OH. Don’t expect to change that behaviour in near future or at all.
In OH, you have to “glue together” the two channels to use it like intended. That’s what the Jython script does. See here to learn more about scripts.
You’ll need three items as described here to get it working. Didn’t try with OH3 btw, but should work.
Disclaimer: I’m fairly new to OH (v.3.0.1), tried my luck now for three days straight, so I’m not asking my questions lighthearted ;). I’m still having problems getting my HmIP-BROLL to be controlled via an item that behaves similarly to a dimmer-slider.
Or did I try to include the code wrongly? Replacing the ’ 'with a " " (I thought “well maybe there’s a syntax change between OH2 and OH3?”) and putting a dummy name in between allowed me to create the three items, but this obviously would eventually cause problems down the road.
That’s how far the instruction went. Not surprisingly, nothing works.
Now two questions which I now have:
Is what I did above even remotely correct? I struggled with two things at the same time: 1) The code example being from OH2 and me not being sure whether it should also work with OH3 (at least I have no explanation for the syntax error) or me just not getting what to do with the code, and 2) at the same time me having 0 experience with OH3 with anything that’s outside of the “WebUI”-clickable-spere. So it’s hard for me to debug.
Even if the above would be correct, how would I now create and link the slider to everything above? From what I can see I’m missing a crucial part here.
Btw: If I get this to work I’d offer to include a Beginner-proof step-by-step instruction here, since I believe that I’m not the only one who wants to get his HmIP-BROLL working with Alexa via OH3.
Sorry it took me so long to answer, but there are projects around the house keeping me busy.
I cannot exactly tell what’s the problem as I’m still on OH2 and so don’t know the error. It seems the parser doesn’t recognize the Metadata correctly. These are key concept of my approach.
I have a test instance of OH3 though. So I found a workaround to get the items into the system fully manually.
Create the groups HmIpBrollProxy and HmIpBrollLevel
Create the three rollershutter items where *_Level and *_Level_Status belong to the groups listed. You can do this by using the textual definition but removing the Proxy-Metadata.
EDIT
Found out, it was one FROLL actor mailfunctioning, which caused so much trouble. When I commented the actor out, the rest of the actors in the items-list worked as it should.
original message:
Hi, did I missed something with the update to 2.5.12 for the homematic addon? All my Rollershutters are not working anymore. In the sitemap my Rollershutter group is empty and Default item=rollershutter is not showing.
my items:
Problem for me was not so much that the above didn’t work, I just lacked some context / “how-go-guideline/quickstart”, which @Bredmich was able to provide exceptionally.