Thanks for taking the time to answer David. From your answer it is clear that I have missed something even though I have tried to search and read all what I could find about this topic.
My confusion was that the MQTT output had changed from the older binding and I had found no info about this. In addition I saw UP, STOP, DOWN mentioned in the MQTT docs for the rollershutter item but I cannot find exactly where just now, today I just found this from https://www.openhab.org/addons/bindings/mqtt.generic/
Channel Type ârollershutterâ
â˘on: An optional string (like âOpenâ) that is recognized as UP state.
â˘off: An optional string (like âCloseâ) that is recognized as DOWN state.
â˘stop: An optional string (like âStopâ) that is recognized as STOP state.
I might have misunderstood from this that the commands published still were UP, DOWN, STOP but I think this was more clear from the reference I am unable to find today.
If the generally accepted output is 0, STOP, 100 and working for all I have no wish to propose any change or start a discussion about this.
Itâs difficult to determine what is ârightâ here.
The Rollershutter Item type accepts commands UP/DOWN , MOVE/STOP , and numeric 0-100 (for a target position). But thatâs just an abstract model.
(No, I donât know what MOVE is for. Maybe there are mechanisms that need a direction set first and then a separate âgoâ)
In the real world, there are rollers with no position control. Just UP/DOWN and probably STOP are needed - in whatever form the device needs.
Likewise I would expect there are rollers that only accept numeric target positions (to include 0 and 100). Maybe there are some that scale differently, 0 -255 say.
And various combinations most likely. Certainly there are also blinds that offer more than just these controls - slat / lamella positioning - but thatâs a bit outside the scope of our âstandard OH modelâ
The conclusion I guess is that you are likely to have to tailor or translate openHAB internal commands (and maybe ignore some of them) for any given real device.
Thatâs okay, we can do a lot with mapped or scripted transforms, and outbound transforms have been added to MQTT binding now thanks to @David_Graeff
But if that is the correct approach, you most likely would want the OH commands passed along to the transform as they are. Converting UP to 0 for example, leaves the transform unable to distinguish between those commands if they should need different actions.
If I were starting from scratch Iâd publish the standard commands just as they come, with provision for transform by MAP or JS as required.
Iâm not sure if that gives an option to âignoreâ any particular commands, or whether it woulld be up to the user not to send them
My rollershutters actually are homemade controllers for awnings. I programmed them to listen to UP, STOP, DOWN based on the v1.xx MQTT binding. They have no position control and it is easy to adopt them to anything the actual binding gives.
But instead of reprogramming controllers I selected to use a proxy item which listens to the actual commands/states and translates them to whatever is the current version. This works as well. Just for knowing how the outbound transforms work I may give them a try also.
I think the idea of publishing any commands just as they come is very good because it would most likely satisfy the requirements from a variety of brands all inventing their âown version of the wheelâ.
I think you should raise a Github issue for this. If it is decided that a change is sensible - because the availability of outbound transform no longer requires further fudging by the binding - now is the time to change it, before a 2.5 general release. It would be a breaking change for someone.
Hi Friends, mqtt items do not work when I upgrade M4 to 2.5.0. But it works if I drop it back to 2.4.0. What is the new version mqtt items do not work.
