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

Hej there,

I have a similar issue but other homematic components:
CCU3 and Homematic IP Wired.
The Rollershutter actuator is called HmIPW-DRBL4.

These is my first rollershutter:

Dimmer		JA1_R1_Level	"Küchenfenster [%d %%]" 	{channel="homematic:HmIPW-DRBL4:XXX:YYY:2#LEVEL"}

Switch  	JA1_R1_Stop  	"Stop"  					{channel="homematic:HmIPW-DRBL4:XXX:YYY:2#STOP"}

Setting the dimmer to 0 will move the rollershutter all the way down. Thats fine.
Whereas setting the dimmer to 100 SHOULD move the rollershutter all the way up, but its going down instead as well.
Now setting the dimmer to 99 will move the rollershutter all the way up.

Is this problem related or should I start a new thread?

Thank you

Might be of interest -

1 Like

I discoverd the same behavior. I also found using a Dimmer item not so handy. Most use cases are 0 or 100. If you want a specific high it is easier to start a full move and stop at the needed position.
At least that was the case for me.

So i used the rollershutter item as a proxy item. A rule catches the commands (UP/DOWN/STOP) and send them to the correct channels (LEVEL and STOP). In this way i also could translate UP to 99 instead of 100 to go around this problem.

You can find my rules etc. in the allready linkt post.

1 Like

Awesome, thank you @rossko57 and @Knut1507

Thank you @philissimo for the script!

I have improved it a little bit to also have a STOP action.

homematicproxy.rules:

import org.eclipse.smarthome.model.script.ScriptServiceUtil

rule "Rolladen Status Update" // status update
when
    Member of rollStatus received update
then
    var name = triggeringItem.name
    name = name.replace('Status','') 

    var correspondingProxy = ScriptServiceUtil.getItemRegistry.getItem(name)

// I will later add some mappings here, where it will compansate the offset
// of the roller shutter when it allready touches the ground, but is not fully
// closed. Then  the Basic UI shows a half open roller shutter, if it is really
// half open 

    if(triggeringItem.state != correspondingProxy.state.toString){
        correspondingProxy.postUpdate(triggeringItem.state.toString)
    }
end

rule "Rolladen steuern" // control rollershutter
when
    Member of rollProxy received command
then
    var correspondingControll = ScriptServiceUtil.getItemRegistry.getItem(triggeringItem.name + "Control")
    var correspondingStop = ScriptServiceUtil.getItemRegistry.getItem(triggeringItem.name + "Stop")
// here the actual mapping happens
    switch(receivedCommand){
        case UP: {
            if(correspondingControll.state != "99"){
                correspondingControll.sendCommand("99")
            }
        }
        case DOWN:{
            if(correspondingControll.state != "1"){
                correspondingControll.sendCommand("1")
            }
        }
        case STOP:{
            if(correspondingControll.state != "STOP"){
                correspondingStop.sendCommand(ON)
            }
        }
//here I will add the same mapping logic for the offset
        default: {
            if(correspondingControll.state != receivedCommand){
                correspondingControll.sendCommand(receivedCommand)
            }
        }
    }
    
end

Example:
Proxy: freakingCoolRollershutter
Control: freakingCoolRollershutter Control
Stop: freakingCoolRollershutter Stop
Status: freakingCoolRollershutter Status

items:

Rollershutter   Bathroom_Shutter           "Rolladen  [%d %%]"                  <rollershutter>   (Bathroom, gShutter, rollProxy)                                   
Rollershutter   Bathroom_ShutterControl    "Rolladen"                                             (rollControl)                  ["Switchable"]                     {channel="homematic:HmIP-BBL:XXX:XXX:4#LEVEL"}
Rollershutter   Bathroom_ShutterStop       "Rolladen Stop [%d %%]"                                (rollControl)                                                     {channel="homematic:HmIP-BBL:XXX:XXX:4#STOP"}
Rollershutter   Bathroom_ShutterStatus     "Rolladen Status [%d %%]"                              (rollStatus)                                                      {channel="homematic:HmIP-BBL:XXX:XXX:3#LEVEL"}

Attention:
I’m using HmIP-FBL and HmIP-BBL. For both 0 and 100 are reversed.

Hi all together,

thanks to your implementations I managed to get this working, too. As I’m moving to JSR223 and prefer the idea of metadata over naming conventions for items. For anyone interested, I’ll share the concept.

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"]}

As can be seen from the channels, I have HmIP-BROLL devices. They didn’t seem to like using channel :4#STOP, but sending the stop command to :4#LEVEL works fine as well.

This leads to a rule to control the channel via the proxy item:

from core.rules import rule
from core.triggers import when
from core.metadata import get_key_value
from core.utils import getItemValue

@rule('Set upper level of roller shutter', description = 'HmIP and OH use reverse logic for rollershutters. Limit value to 1/99.9, control via HmIP-channel 4.')
@when('Member of HmIpBrollProxy received command')
def send_command(event):
  if (event.itemCommand == UP):
    level_item_name = str(get_key_value(event.itemName,'Proxy','LevelItem'))
    events.sendCommand(level_item_name, '1')
  elif (event.itemCommand == DOWN):
    level_item_name = str(get_key_value(event.itemName,'Proxy','LevelItem'))
    events.sendCommand(level_item_name, '99.9')
  elif (event.itemCommand == STOP):
    stop_item_name = str(get_key_value(event.itemName,'Proxy','LevelItem'))
    events.sendCommand(stop_item_name, 'STOP')
  else: 
    send_command.log.info("Unknown command")

When writing this, the idea came up to replace the upper value 1 with 0.1. Will try that out.

It seems to me, that the CCU/the API/Homematic binding has problems with boundary values 0 and 100. In the logs I see weired level values when going all the way up or down. To handle this, the part of the rule to proxy the level status replaces them with 0.1 or 99.9:

@rule('Convert roller shutter level', description = 'Converts HmIP level to OpenHAB conventions')
@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(min(99.9, max(0.1, float(str(event.itemState)))))))

This works like a charm and OH can display the level correctly (e.g. in Basic UI).

Further information:

Thanks again to @philissimo and @Knut1507, your concepts helped me developing this.

Hey guys,
thanks for your efforts on making this more convenient. Ideally this behavior should be solved within the binding, right?
There is a github issue (#6145) for the the behavior and @Mherbst was so kind taking a first look. Since I’m not 100% into detail about the concepts and how it should behave, could you help us and document in the ticket whats going wrong and what expected behavior should be?
Thanks much for your contribution on this issue to sort this.
Seb

I agree. The binding already tries it, but it maybe the current implementation is only correct for some devices. It seems that for some devices 100% means “window completely closed” and for others it means “completely open”. Unfortunately the data point documents from EQ3 ist not really helpful and therefore information about the behaviour of the different devices would help.

I have tried to file my issue as detailed as possible on GitHub. It would be really helpful if the Binding could be fixed and no workaround is required anymore. Please let me know, if you need more details.

1 Like

Thanks for your detailed information. As far as I can see your devices have not been detected as rollershutters/blinds. The “level” channel is a “Dimmer” but it should be a “Rollershutter”.

Maybe it is quite easy to solve.

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.