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

Tags: #<Tag:0x00007f617edc7be8>

Hi,

I recently upgraded to piVCCU firmware version 3.47.15 (from 3.45.7) and I have some HmIP-BROLL shutter actuators. I use the proxy pattern to set the level of the actuators on channel 4 and receive the current level on channel 3. All was working fine before the upgrade.

Now the following problem occurs:
Whenever I try to open the shutters (sending command UP), the shutters actually go DOWN. Sending the command DOWN also results in a downward movement. So I have no way to open the shutters from my sitemap.
I have also some rules which set the level of the actuators to specific values like 80% or 20%. This works as expected, but apparently the manual upward motion is not working any more.

Here are the item definitions:

Rollershutter   Kueche_Rollo_Proxy         "Rollo [%d %%]"    <rollershutter>    (GF_Kitchen, gShutter)        ["Rollershutter"]
Rollershutter   Kueche_Rollo_Set           {channel="homematic:HmIP-BROLL:3014F711A061A7D8A9918DD6:00111A498BEEC4:4#LEVEL"}
Switch          Kueche_Rollo_Stop          {channel="homematic:HmIP-BROLL:3014F711A061A7D8A9918DD6:00111A498BEEC4:4#STOP"}
Rollershutter   Kueche_Rollo_Level         {channel="homematic:HmIP-BROLL:3014F711A061A7D8A9918DD6:00111A498BEEC4:3#LEVEL"}

and the proxy rules:

rule "Kueche Rollo 1"
when Item Kueche_Rollo_Proxy received command
then    if (receivedCommand == UP) {
        Kueche_Rollo_Set.sendCommand(UP)
        }
        if (receivedCommand == STOP) {
        Kueche_Rollo_Stop.sendCommand(ON)
        }
        if (receivedCommand == DOWN) {
        Kueche_Rollo_Set.sendCommand(DOWN)
        }
end


rule "Kueche Rollo 2"
when Item Kueche_Rollo_Level changed
then Kueche_Rollo_Proxy.postUpdate(Kueche_Rollo_Level.state)
end

The problem occurs on all my shutters. openHAB and the addons are on the stable 2.4.0 version.

I would be glad if someone could help me.

Kind regards,
André

1 Like

As a workaround, I changed the proxy rules so that the level of the shutter is set to 1 instead of UP, when the command UP is received from the proxy. 0 also does not work any more, it must be 1.

I suspect that something changed in the current CCU firmware because no other component was updated in my setup.

Hey,

i can confirm this behavior. After the last update of the homematic ccu the command UP no longer works.

Your workaround is fine and I recommend to use numeric commands instead of UP and DOWN everywhere in your code.

Kind regards

Hi,

I can confirm this behavior as well on HmIP-FBL shutter actuators.
I will try your suggested workaround tomorrow.

Kind regards,
Rubén

Hi,

I have the same issue after upgrading my RaspberryMatic to version 3.47.10. I have tried downgrading to 3.45.7 but the issue still persists. I will probably need to write some proxy code for the above mentioned workaround as well :frowning:

Cheers,
Chris

After downgrading RaspberryMatic to 3.45.7 the problem was still existing. I didn’t restart Openhab on the first try. After restarting Openhab the problem has now disappeared.

So it comes up by installing 3.47.10 and goes away by downgrading back to 3.45.7 and restarting Openhab afterwards as well.

Ich hab da mal ein Issue bei RaspberryMatic aufgemacht, wobei ich vermute, dass es eher in der Basis vccu zu finden ist, weil @Andre_Hessling ja geschrieben hat, dass es bei ihm auch mit piVCCU auftritt.

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.