I have already uploaded a test jar:
After the installation please remove all BROLL things and create the again. The LEVEL channel(s) must be of type “Rollershutter”. Some more information can be found in this issue:
@MHerbst I strictly followed the instructions, but always end up with two versions of the HM binding running at a time. I also gave it a 2nd try with bundle:uninstall <id>.
openhab> bundle:list | grep Homematic
203 │ Active │ 80 │ 2.5.7.202007111710 │ openHAB Add-ons :: Bundles :: Homematic Binding
236 │ Active │ 80 │ 2.5.6 │ openHAB Add-ons :: Bundles :: Homematic Binding
I have some issues with OH “forgetting” items or the links, respectively. Re-editing the .items-File fixes this. But if there really two instances of the binding running with different versions, I cannot tell which one handles my things.
So the main question is: How can I stop OH behaving like that?
Normally the following steps should work (at leas for me):
- Uninstall the binding in Paper UI resp. remove it from addons.cfg if you added it there
- Stop openHAB
- Clear the cache directory
- Start openHAB again
You could also remove the binding from the addons folder first. The execute the steps above and make sure that no Homematic binding is active. Then copy the test version back to the addons folder and restart openHAB.
It works atm. And you know the saying about running systems. 
1 Like
Hi,
I had the same issues with HmIPW-DRBL4.
99 was ok. 100 was going down. Like 0.
Also the percentage in openhab was allways -1 to CCU.
Now I tried your actual testversion and it is working nearly perfectly! Thanks so far.
What problems do I still have:
My item is a Rollershutter and in Paper UI the channel is recognised as Rollershutter, now, too.
Rollershutter Rolladen_BueroM_Level “Rolladen Büro Markus[%d %%]” (gRollershutter) { channel=“homematic:HmIPW-DRBL4:CCU3:xxx:14#LEVEL”, autoupdate=“false” }
On the sitemap it is a “Default”, so the right buttons (Up, Stop, Down) are shown.
All the buttons are working fine, now!
Default item=Rolladen_BueroM_Level label=“Rolladen”
But:
The % of the Rollershutter is wrong updated after “STOP” (its updated to 100 or 0 not to the right %).
It is also not updated when using the buttons in the room…
It IS updated, if I use for example PostUpdate(27)
The readonly Status-Channel is updating right, but it is still a “Dimmer”.? The Read/Write-Channel does not:
Greetings
Markus
P.S. “New users can only put one image in a post”. I had to put everything in one picture…
If you send a command to this channel, the Level of this channel is set immediately to its target value. When sending a stop command, this level value does not change in Homematic. Your CCU reports the new level (the current level of your blinds/roller shutter) to another channel. In your case, that’d be channel 13.
So OH can never show the “real” level as it just does not know it from this channel the item is linked to.
To send commands to channel 14 and reflect the real level from channel 13, you could use a Proxy item.
Thank you @grizzle for the explanation.
I don’t have any of these Homematic devices so I can’t test it myself.
It is also not updated when using the buttons in the room…
That’s bad, I would have expected that the CCU would also send updated values to the LEVEL data point
The readonly Status-Channel is updating right, but it is still a “Dimmer”.? The Read/Write-Channel does not:
The binding derives the channel type from its name. Only for LEVEL a “Rollershutter” is used. In my opinion this is OK because the buttons won’t make sense for a read/only device.
Unfortunately Homematic uses the position values different from other Rollershutter devices and the definition within openHAB. In openHAB 0% means fully open, while on the CCU 0% means fully closed. Therefore the values are inverted for the “Rollershutter” type items. The STATUS channel is a dimmer and therefore the values appear inverted.
Currently the binding is very generic and tries to get all necessary information from HM channel and datapoint definitions. I have some first idea for enhancements to the binding that would allow to handle these complex HM devices better.
In the meantime, I would also recommend using proxy items.
Thank you for your fast reply. I checked it within the CCU and you are right. It is only reported to the channel 13…
Thank you for your fast reply, too!
That’s bad, I would have expected that the CCU would also send updated values to the LEVEL data point
I checked in the CCU again. Its send to the MAIN READONLY LEVEL (in this case 13) because 14-16 are LEVEL which can - for example - be added…
The binding derives the channel type from its name. Only for LEVEL a “Rollershutter” is used. In my opinion this is OK because the buttons won’t make sense for a read/only device.
This is a LEVEL, too, but it is recognised as “DIMMER”:
In the meantime, I would also recommend using proxy items.
I will give it a try… 
Thanks for the hint. Currently only LEVEL in channel “Blind Virtual Receiver” is defined as rollershutter. Will add LEVEL in “Blind Transmitter”, tool
1 Like
Updated the rules as @MHerbst changed the behavior of the binding:
from core.rules import rule
from core.triggers import when
from core.metadata import get_key_value
from core.utils import getItemValue
@rule('Proxying roller shutter commands', description = 'Pass proxy item commands to channel 4')
@when('Member of HmIpBrollProxy received command')
def send_command(event):
level_item_name = str(get_key_value(event.itemName,'Proxy','LevelItem'))
events.sendCommand(level_item_name, str(event.itemCommand))
@rule('Proxying HmIP-BROLL level', description = 'Send level channel 3 to Proxy item')
@when('Member of HmIpBrollLevel received update')
def main_update(event):
proxy_item_name = str(get_key_value(event.itemName,'Proxy','ProxyItem'))
events.postUpdate(ir.getItem(proxy_item_name), QuantityType(str(event.itemState)))
The item definitions stay the same:
Rollershutter Dining_Rollershutter_Level "Level [%.0f %%]" <rollershutter> (HmIpBrollProxy) {Proxy='' [LevelItem="Dining_Rollershutter_Level_Actuator"]}
Rollershutter Dining_Rollershutter_Level_Actuator {channel="homematic:HmIP-BROLL:XXX:YYY:4#LEVEL"}
Rollershutter Dining_Rollershutter_Level_Status (HmIpBrollLevel) {channel="homematic:HmIP-BROLL:XXX:YYY:3#LEVEL", Proxy='' [ProxyItem="Dining_Rollershutter_Level"]}
Icons in basic UI now reflect the real position. However, there’s a lag in time, as you have to wait until the Homematic CCU sends the new position.
@MHerbst Thank you for doing research on the problem.
In openHAB 0% means fully open, while on the CCU 0% means fully closed.
One hint from me:
For BROLL devices on CCU the standard value for fully open is 100%, but you can configure this value with a device parameter on CCU (BROLL firmware 1.6.2); e.g. I set this value to 0% to be consistent with openHAB.
Regards,
Andy
Yeah, I did this with one single BROLL as I installed it upside down. Ended up turning around the device mechanically, as it bothered me when doing programs or direct connections on the CCU.
It can work, but I’d not recommend to do so.
Thanks for the information. I will keep this in mind. Maybe I can make it more flexible in a next version. Now I am waiting for the current fixes to be reviewed and merged.
Thanks for this. It works now like I supposed it to do. (Es funktioniert nun wie ich es erwartet hätte 
).
1 Like
Do this rules also work for HmIP-FROLL ? I tried but they don´t work for me as my blinds only go down, not up. Also the first line of the rule " from core.rules import rule" is marked in red in Visual Studio Code. I followd this Instructions for installing the helper libraries https://openhab-scripters.github.io/openhab-helper-libraries/Getting%20Started/Installation.html (installation of rule addon, copying folder automation and so on). Do I miss something?
Thank you for any hint.
@el-repho Please check the channel type. If it is of type “Rollershutter” then UP/DOWN should work correctly. If you have created the thing before installing the new binding version, please delete the thing, run auto detection and create it anew. If after the re-creation the LEVEL channel is not of type “Rollershutter”, I can have a closer look.
Thanks for the quick reply. After deleting the thing and recreating I was able to controll HmIP-Broll as described here and HmIP-Froll with the commands up, down and stop. Unfortunately the level is showing “Err”. I will have a closer look to the homematic documentation this week and try some other channels. As far as I understand, I don´t have to change anything in the rule, but in the items definitions e.g. change the channel number.
I will post the output here unless somebody already has a solution for this.
Thank you for the great community and support!
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!