Homematic shutters HmIP-BROLL always close when sending command "UP"

Definitely gonna have a look at it and provide more details, at least about HmIP-BROLL. Got to collect some information and test data first.

@grizzle: i just tried to implement your solution, but i fail miserable…

i always only get:
Configuration model ‘homematicproxy.rules’ is either empty or cannot be parsed correctly!

do i miss some addon or what do i need to make this “strange” rules syntax work… i am a bit lost :frowning:

Wait for the fix. Martin is close to a patch as I can read in the GitHub issue.

Sorry for keeping you waiting so long. I totally messed up my systems - two instances of OpenHAB and one Home Assistant did not work together very well. Came up to fix it all last weekend.
And now, @krikk, my rule does not work any more. So yes, patching the binding would be best.
As said above, I can try to fetch log data from the CCU and OpenHAB to compare them. But don’t expect anything before Sunday. :neutral_face:

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):

  1. Uninstall the binding in Paper UI resp. remove it from addons.cfg if you added it there
  2. Stop openHAB
  3. Clear the cache directory
  4. 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. :upside_down_face:

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… :wink:

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.

20200807_BROLL

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 :slight_smile: ).

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.