So, I just tried the PaperUI color picker, tied to an MQTT Homie Color (RGB) item. Holy crap. Seriously??
I don’t know if this is an MQTT Homie Binding or a PaperUI issue.
I think I see what’s going on. HSV to RGB conversion is a lossy process – but the GUI code appears to be doing this lossy conversion for back and forth for every single movement. Not only that, it also has rounding errors.
That’s not good, because then you end up with insane behavior like this.
It would be that much better if the gui maintained its own set of HSV values, and only recalculated the HSV from the RGB if the RGB value changed due to being set from another source. Also, in the case of ambiguity (obviously 255,255,255 is saturation 0 but what’s the hue?) leave the unknown value as is! Don’t force hue to 0, that only has a one in 256 chance of being right.
Also, the scale is wrong – it won’t let you produce RGB level 255, the maximum it produces is 250.
Thought one : PaperUi is not a proper Ui, and provides value tweakers just for test purposes.
What’s it like in a real UI? (I wouldn’t be that surprised if it was somewhat similar.)
Thought two : to the binding, a command is a command and the source cannot be determined.
Thought three : bear in mind you probably have autoupdate at work as well, making its own guess about the outcome of a command and applying it to the state. I would not expect that to do anything unpleasant, but it is another factor.
Thought four : the binding won’t be making state updates except where the end device is involved. Which obviously may do its own internal translations, roundings, and limits. Needs careful unpicking of this lòop.
Yes, please use BasicUI, HABPanel, or HABot and see if it behaves the same. IMHO, PaperUI cannot be trusted. I believe the color picker in any of these can be configured to not send the commands until you release the button or at a fixed interval of changes. PaperUI has no such configruation.
Look at events.log and try to verify what the commands and updates are flowing back and forth. Are you getting commands back from the Homie device or updates?
This can also be confirmed by looking at events.log. You will see autoupdate predicting what the state should become in response to the command. If the device reports back and updates the Item with the actual new state, autoupdate should be set to false.
This is likely where the problem lies and it may be an untenable problem. For every command you are going from HSB → RGB → HSB. OH gets the command as an HSB, then it gets translated to an RGB. Then the device reports its new state back to OH as an RGB and OH converts the RGB back to an HSB. The errors will definitely add up pretty quickly in this scenario.
Not entirely correct. The UI only sends commands. It’s the binding or core OH code (in HSBType.java) that is doing the conversion. All PaperUI or any of the other UIs see is HSB.
Thanks guys. I will test it with BasicUI too. But, your replies (the fact that openHAB is HSV/HSB natively) as well as the fact that log items only refer to the HSV value, are telling me that the problem is probably in the MQTT homie binding.
If that’s the case, with all the other issues with this binding, I should just make my device accept HSV, so that the binding won’t have to convert at all. Plenty of bigger fish to fry. I think I just found another bug, but I will test that in my lab setup before posting.
It’s a closed loop, with four independent legs
binding conversion → device setting → device reading → binding conversion
Each of those points can add its own error, example a device a may have an internal register 0-100 to hold sent values 0-255, reporting the stored value introduces rounding error.
You could track it down by looking at the actual MQTT payload to “see” in between the legs.
Don’t forget autoupdate will short-circuit this loop by default.
I guess you are using the “colorRGB” channel, you didn’t say.
Here’s the channel info (straight from MQTT explorer):
The log item, on the other hand, shows HSV values: 019-07-09 18:52:35.873 [vent.ItemStateChangedEvent] - BedroomMCU_Props_DisplayColor changed from 65,14,96 to 68,14,96
I’m going to try to make my device use HSV instead.
I changed my channel format to HSV and added a 1-way HSV to RGB conversion to my code (inside the MCU) so. It works perfectly now!
With what you and @rlkoshak said, and log entries, and the fact that changing the channel type solved the problem, I’m satisfied that the conversion happens in the MQTT binding, and that this is where data was lost.
It makes sense to me that a naive implementation which simply converts the value back and forth (and even has a rounding error) would cause the effect that I saw.
It’s probably possible to make the binding not cause this issue in this scenario, by for example:
Convert HSV (from openHAB) to RGB, post to MQTT
Receive confirmation RGB value
And then, rather than converting the received RGB value back to HSV, compare it to a history buffer of the last few RGB values we sent, and if it matches one then we report the original HSV value for that RGB value back to openHAB! Cycle is broken, things just work, and the user is none the wiser.
But, the MQTT binding is nowhere near ready for this level of refinement so I’m just going to stick to HSV (now that I’m aware of the issue) and not worry more about it at the moment.
Another way of satifying the RGB requirement would be to offer RGB sliders, but I’m going to guess that’s not a standard control type in openHAB.
Thanks Rossko and Rich for the troubleshooting help and always useful information about how openHAB works under the hood!
Another way would be to provide an RGBColorType and keep it as RGB from end to end. That would be a more global change which might be harder to get approved and merged.
Also, HSV really makes more sense as a color picker user interface anyway. Converting HSV to RGB was not that difficult. Took much less typing than this thread.
