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
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.
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
Dirk
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.
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.
Thanks for the input.
So there´s another binding with this option beside the zwave binding
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
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.
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!
