[homematic] Rollershutter values are inverted

Hi there,

i would like to discuss that openHAB and the homematic CCU are using different logics to represent the state of a rollershutter.


Open Closed
openHAB 0% 100%
CCU 100% 0%

Discussion with @rpwong from another thread.

While this would make some things easier it could break others when implementing something into the core of openHAB.

My point of view:
homematic is using 100% for open and 0% for closed and this should be the leading logic.
eQ3 as manufacturer uses this logic and openHAB or the binding should use the same logic.
Otherwise we´re having break between the two systems and users have to think in two worlds.

I know about the workarounds with proxy items and rules, but to be honest this makes it unnecessary complex.

There are already multiple threads around the community:

Even other values are inverted, like OPEN and CLOSED in this example:

Now we look to another binding that has rollershutters:

The zwave binding has the option [ config_invert_percent=true ] to invert values.
Note: This isn´t descripted in the docs :slight_smile:

The homekit binding also offers the option [inverted="true"] to invert values and describes this in the docs for rollershutters.

I already created an issue on Github and waiting for feedback from a maintainer.

What is your view on this?

kind regards

Hi @Bredmich!
Although I do find the openHAB value assignment (0% = open, 100% = closed) more logical than the one from Homematic CCU’s, I would agree in having the binding for Homematic to use the same logic and value assignment as in the CCU (in general, a binding should reflect the master system…).
Kind regards

1 Like

You’re not going to get openHAB’s internal sense of opened/closed changed. This is after all supposed to be abstract, and not reflect any real device.

You’ve made a case that Homematic binding has a deficiency, now you just need an interested developer.

That is nothing i proposed :wink:
I said that a change in the openHAB core would probably break other things.

I know that sometimes it´s about how many people are interested in something and that´s why i´m asking the community.

I have my openhab rollershutter connected with google home. Im am not sure but i think google internal handels the rollershutter like the CCU (open = 100% closed = 0%) BUT the way it is in openhab (0% = open, 100% = closed) is more logical to us so google translates this as i speak to it.
Means if i say “Open rollershutter office 10 %” i see that google send the vaule 90 to my openhab item.

So in an “human → google → CCU” communication all would be fine. With openhab in this chain i use rules to invert it back an forth. I would like if the binding would do this like google does but i would not like just the binding to be changed because this would change the presentation in openhab UI to the less logical representation.

In Homekit Binding an invert option exists.
I guess the same should be available in Homematic Binding - optional for the user.

Thanks for the input.
So there´s another binding with this option beside the zwave binding :slight_smile:

I´m not a developer so this guess could be completely wrong.
Shouldn´t it be relatively easy to implement the same logic that already applies to zwave and homekit into the homematic binding?

It is probably really not that complicated. I have already seen the issue, but have not yet had time to look into it more closely. For a clean solution, it will take some time, because the HM binding creates all things dynamically. This makes it a bit more complicated.


Thanks alot for your feedback Martin.
I don´t expect a quick solution and rather a reliable solution that will reduce the hassle of working with proxy items and inverting rules :slight_smile:

kind regards

That was me who suggested this, but it’s more that I think it would be good for items to have the built-in ability to either reverse logic or transform states without requiring proxy items and rules. But I’m not losing any sleep over it. :wink:

I think mating our abstract Items model to the quirks of real devices is very much the binding’s job.
There’s nothing to stop binding authors providing channels like rollershutter and invertedshutter. Or if some given technology actually specifies a convention, that should be hardwired into the binding.

For sure. I was just thinking that there are cases when users might want to do this with items due to the internal logic of their systems. But again, I don’t really care that much.

Have you tried to change the direction on the hardware itself?

I found my the openhab graphic was competely back the front, displayed closed when actually open… I found in the manual a key sequence to switch the motor direction and finally openhab icons matched the real world!