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.
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…).
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.
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.
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.
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!