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

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!

Guys, you probaply think I’m crazy.

Since this morning, the controles of our rollershutters are reversed now :smiley:
The setup is up und running for month. And the bug where the shutters move all the way down when setting the slider to 100 seems to be gone (this bug: Homematic shutters HmIP-BROLL always close when sending command "UP" - #13 by Knut1507)

So, you are probably thinking I made an update of OH, but thats not the case. I am still on 2.5.6.
Is it possible the Bindinig has been updated without me doing so?
There is something that may have caused it: I installed mariadb yesterday evening and I also installed the corresponding persistance Binding of it.

Thats the only reason I can think of.
Thank you for your input

Is there the possibility to insert this Workaround in the Binding description? There is it directly helpful to the most owner of a Rollershutter. On my oppinion Homematic IP is the favorite Home Automation System in DACH-area and should be fully supported by OpenHAB.

How sounds the idea to implement special devices where e. g. three points are included in one item. And this item is directly controllable like other items/points. I think there will be other special items/devices in other bindings which also needs a special handling to support.

@MHerbst Great Job you do with the Binding!

As far as I know, this workaround is no longer necessary if you are using a current version of the binding. Therefore it would not make sense.

How sounds the idea to implement special devices where e. g. three points are included in one item.

There are already 3 or 4 some special implementations within the binding (primarily display devices), but because of the large number of existing devices adding special implementation code to the binding is not possible. But I am already think about an option that would allow a user to influence the behaviour of the binding, e.g. suppress creation of unwanted channels or defining another type.

I have never heard that a binding would be updated this way. You can see the version of the binding in Paper UI. Maybe it happens because the current versions of all bindings are at 2.5.11 and if you install a binding via Paper UI maybe somthing more happened.

What is your suggestion to implement the BROLL and FROLL into OpenHAB? One item acting as three points cannot run without a script on my oppinion.

I don’t know these devices in detail, because I don’t own them. I have only got the data point documentation from EQ3 and it does not really gives you information about how everything exactly works.

So, I don’t know which data points you want to be combined. If you like, you can create an issue as enhancement request in the github repo with an exact description of how it should work in your opinion. It could be possible to include some special coding for these devices in the binding. But this could take some time.

Anyway, the most flexible solution would be to create a script.

Channel 3 is the command channel which is used to send the command to. Channel 4 contains the Level Information. Like 80% closed.
So if you map channel 3 to an item, one can control the rollershutter but never knows the Level. It only switches between 0 and 100.
So the current solution is to have an additional Script which pulls the Level Info from channel 4 and updates the item tied to Level 3.
Would be very convenient to have this in a singe item without the scripting.
In case you are in need of such a device i would volunteer to sponsor you one for better Analysis and Implementation.

Thanks for this information. I really don’t know why they make it so complicated and why they need that many data points …

I understand. This would definitely better.

In case you are in need of such a device i would volunteer to sponsor you one for better Analysis and Implementation.

Thanks for your offer, but I don’t want to implement more and more device-specific special cases in the binding (there are already some of them making the maintenance of the binding more and more expensive). I would prefer to enhance the binding in a way that allows a user to configure how the provided channels in OH should be derived from the data points: This could be done e.g… in a text format and maybe later editable in the new Main UI.

For the shutter devices I could image to a configuration entry that says: “define a OH channel that reads the current value from Level of Channel 4 and write to Level of Channel 3”.

On the device of Sebastian I can put a Bountysource on top. You will ask you why the guys are so interested in this silly device? I think it is the core device of the Homematic IP system next to the heating control device. Furthermore it should be said that much people have many items in place. I have myself 16 items for 16 windows installed. That is a huge amount to configure and setup.

I imagine that this category of a special item is not only for that FROLL or BROLL. Other Bindings must have this special devices/items too. So other users should also interested in scripted items.

Nope, channel 4 is for the actuation, channel 3 represents thr current level. At least for HmIP-BROLL.

HmIP devices (and HM too, AFAIR) let you run simple logic on the device itself. As for the BROLL, you have actuator channels 4, 5 and 6 which can all be set independently. You can program how the device calculates its behavior out of these three (e.g. AND, OR, MIN, MAX, SUM, Multiply). The CCU is not involved in that.
Therefore it is just mandatory to have a channel to reflect the calculated result.

Thank you for your reply.

According the the console:
233 │ Active │ 80 │ 2.5.11 │ openHAB Add-ons :: Bundles :: Homematic Binding

According to PaperUI -> Addons -> Bindings:
Homematic Binding - binding-homematic - 2.5.6

So just for my understanding, since I’m fairly new to OH: Currently it is not possible to use the HmIP-BROLL on OH out of the box the same way like a, say, dimmer, where you have a slider that allows you to set the desired level information and at the same time show the current level information?

If this is the case, where do I enter the code above and how do I adapt it to my setting?

Sorry if I’m asking very basic questions.

I’m using Channel 3 with Metadata “Autoupdate” which seems to work, but I’m new to all this as well and not done with testing yet.

It’s the key concept of how Homematic manages its channels and so they are exposed via API to third party systems like OH. Don’t expect to change that behaviour in near future or at all.
In OH, you have to “glue together” the two channels to use it like intended. That’s what the Jython script does. See here to learn more about scripts.
You’ll need three items as described here to get it working. Didn’t try with OH3 btw, but should work.

Disclaimer: I’m fairly new to OH (v.3.0.1), tried my luck now for three days straight, so I’m not asking my questions lighthearted ;). I’m still having problems getting my HmIP-BROLL to be controlled via an item that behaves similarly to a dimmer-slider.

Here’s what I tried based on Homematic shutters HmIP-BROLL always close when sending command "UP" - #16 by grizzle

  1. Manually create a group HmIpBrollProxy: So far so good.

  2. Manually create three items individually via Items → Add -> Add items from textual definition.

Rollershutter Dining_Rollershutter_Level “Level [%.0f %%]” (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”]}

Here’s where I encountered the first problems (I of course replaced the addresses of my device)

When using the proposed code it shows the following syntax error for the 1st and the 3rd item, always around the proxy-code.

Or did I try to include the code wrongly? Replacing the ’ 'with a " " (I thought “well maybe there’s a syntax change between OH2 and OH3?”) and putting a dummy name in between allowed me to create the three items, but this obviously would eventually cause problems down the road.

  1. I created the first rule (Rules → +)…

    … in a way that made sense to me to to house the code from the example:

  2. Same with the second rule:

That’s how far the instruction went. Not surprisingly, nothing works. :wink:

Now two questions which I now have:

  1. Is what I did above even remotely correct? I struggled with two things at the same time: 1) The code example being from OH2 and me not being sure whether it should also work with OH3 (at least I have no explanation for the syntax error) or me just not getting what to do with the code, and 2) at the same time me having 0 experience with OH3 with anything that’s outside of the “WebUI”-clickable-spere. So it’s hard for me to debug.
  2. Even if the above would be correct, how would I now create and link the slider to everything above? From what I can see I’m missing a crucial part here.

Btw: If I get this to work I’d offer to include a Beginner-proof step-by-step instruction here, since I believe that I’m not the only one who wants to get his HmIP-BROLL working with Alexa via OH3.

Thanks a lot in advance.

Sorry it took me so long to answer, but there are projects around the house keeping me busy. :man_mechanic:

I cannot exactly tell what’s the problem as I’m still on OH2 and so don’t know the error. It seems the parser doesn’t recognize the Metadata correctly. These are key concept of my approach.

I have a test instance of OH3 though. So I found a workaround to get the items into the system fully manually.

  1. Create the groups HmIpBrollProxy and HmIpBrollLevel
  2. Create the three rollershutter items where *_Level and *_Level_Status belong to the groups listed. You can do this by using the textual definition but removing the Proxy-Metadata.
  3. Open items 1 and 3, “Add metadata” accordingly. Custom namespace ist Proxy.
    Seems the syntax is some yaml now… :thinking:

Unfortunately I can’t test by now.

For the python part, maybe you have to add a script instead of a rule? (As said before, I’m not into the concepts of OH3 yet.)

Found out, it was one FROLL actor mailfunctioning, which caused so much trouble. When I commented the actor out, the rest of the actors in the items-list worked as it should.

original message:
Hi, did I missed something with the update to 2.5.12 for the homematic addon? All my Rollershutters are not working anymore. In the sitemap my Rollershutter group is empty and Default item=rollershutter is not showing.
my items:

Rollershutter SuedterasseMarkise_Level "Level [%.0f %%]" <rollershutter> (HmIpBrollProxy) {Proxy='' [LevelItem="SuedterasseMarkise_Level_Actuator"]}
Rollershutter SuedterasseMarkise_Level_Actuator  "Markise Südterasse [MAP(broll.map):%s]"   {channel="homematic:HmIP-BROLL:XXXX:YYYYY:4#LEVEL"}
Rollershutter SuedterasseMarkise_Level_Status      (HmIpBrollLevel)    {channel="homematic:HmIP-BROLL:XXXX:YYYY:3#LEVEL", Proxy='' [ProxyItem="SuedterasseMarkise_Level"]}




Default item=SuedterasseMarkise_Level_Actuator label="Markise Südterasse" icon="terrace"
Group item=gRollo label="Rollos" icon="blinds" 

I´m working with this rules:

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

Thanks a lot for every hint.

Here’s a solution Homeatic HmIP-BROLL & HmIP-FROLL - Get them to work in openHAB which worked great for my 9 HmIP-BROLLs with OH / Alexa.

Problem for me was not so much that the above didn’t work, I just lacked some context / “how-go-guideline/quickstart”, which @Bredmich was able to provide exceptionally.