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

Same issue appeared with original CCU2 after upgrade from 2.45.6 to 2.47.12. I can also confirm that changing from “UP” to “1” helps as a workaround…

I have/had the same problem.

I wrote two ‘generic’ proxy rules which can handle all my seven shutters. The read/write problem could be solved as well, since you can only read out the status at one channel and control the shutter at another.

Therefore you need three items (proxy item, controll item, status item) for each rollershutter.

homematic.items:

//groups are needed for triggering the rules
Group rollProxy "Rolläden Proxy"
Group rollControl "Rolläden Bindings"
Group rollStatus "Rolläden Status"

//proxy
Rollershutter rollEssecke "Essecke [%d %%]" (rollProxy)
//control
Rollershutter rollEsseckeControl "Essecke Binding [%d %%]" (rollControl) ["Switchable"] {channel="homematic:HmIP-BROLL:[fancy:id]:4#LEVEL"} // channel 4
// status
Rollershutter rollEsseckeStatus "Essecke Status [%d %%]" (rollStatus) {channel="homematic:HmIP-BROLL:[fancy:id]:3#LEVEL"} // channel 3

In this code there is an naming convention for the items. All the names of the items for one rollershutter have to start with the name. The ‘status’ item musst end with an ‘Status’, the ‘control’ item musst end with ‘Control’. Keep in mind, that the string ‘Status’ must not appear more often in the name of the ‘status’ item, otherwise the assignment with this code base does not work.

Example:
Proxy: freakingCoolRollershutter
Control: freakingCoolRollershutterControl
Status: freakingCoolRollershutterStatus

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

// here the actual mapping happens
    switch(receivedCommand){
        case DOWN: {
            if(correspondingControll.state != "100"){
                correspondingControll.sendCommand("100")
            }
        }
        case UP:{
            if(correspondingControll.state != "1"){
                correspondingControll.sendCommand("1")
            }
        }
//here I will add the same mapping logic for the offset
        default: {
            if(correspondingControll.state != receivedCommand){
                correspondingControll.sendCommand(receivedCommand)
            }
        }
    }
    
end

default.sitemap:

Default item=rollEssecke label="Essecke"

I think that’s an easy and short way to solve that problem, without having to add two new rules for each roller shutter.

Kind reagards,
Phil

6 Likes

Hey all,
I came to this thread as my HmIP-BROLL were behaving the same way. Thanks to @philissimo I was able to also add the generic rule-based workaround.

The thing I’m wondering is that my RasperryMatic (3.47.18.20190918) works fine. I can send UP/DOWN/STOP quite fine through webgui and rollershutter behaves ok.
Only OH2 cannot send UP command. Thus seems to be something within OH or homematic addon.

Is there something I can help debugging to get this sorted? I would also have a spare BROLL device to troubleshoot/temporary share. Possibly @MHerbst or @gerrieg have an idea?

For reference: The corresponding github issue seems to be this one.
Thannks

Same problem here.

I clicked the arrow down button in the sitemap and everything worked as expected. Here’s the events.log:

2020-01-02 14:47:56.963 [ome.event.ItemCommandEvent] - Item ‘WZ_Rollladen_Hoehe’ received command DOWN
2020-01-02 14:47:56.967 [nt.ItemStatePredictedEvent] - WZ_Rollladen_Hoehe predicted to become DOWN
2020-01-02 14:47:57.004 [vent.ItemStateChangedEvent] - WZ_Rollladen_Hoehe changed from 1 to 100

Tried to open up again fails. Logs look similar:

2020-01-02 14:51:26.332 [ome.event.ItemCommandEvent] - Item ‘WZ_Rollladen_Hoehe’ received command UP
2020-01-02 14:51:26.338 [nt.ItemStatePredictedEvent] - WZ_Rollladen_Hoehe predicted to become UP
2020-01-02 14:51:26.363 [vent.ItemStateChangedEvent] - WZ_Rollladen_Hoehe changed from 100 to 0

I had to open up it via the CCU again. Cannot see any logs about that.

Hope, these logs can help solve the issue.

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?