Thanks again. U seem to be teaching in a real good way.
Yes i am sure about the 0-255 values used by esphome and secondly esphome immediately changes values from rgb( containing brightness ) to most bright rgb value for the same color, thus all those conversions are essentially required.
I would the try the bigdecimal conversion and report back.
Also the postUpdate and sendCommand work work identically in this particular case because we have a rule specifically made to act upon any change in the item value. So even using postUpdate changes the value, which triggers the rule 2 which sends mqtt command to esphome, then esphome sends back state msg and rule 1 gets triggered and that too with changed rgb values i.e without brightness info.
You’ll appreciate that is possible to send a command that does NOT change the state value. Please, please, do not think state updates and commands are the same. You will get into a terrible mess with openHAB.
you need to change the rule triggers. Then the one that publishes to the device should trigger on commands. This rule publishes to the device. The device changes state and publishes the change. The second rule triggers on the change and updates the Item.
You may need to set autoupdate to false on the Item like rossko57 suggests. this prevents the item from changing on the command.
No I just meant both lead to the same result in our particular case. Though I get the basic idea about postUpdate that it does not forward the command to the related binding. But here we have no channel associated with the color picker item and hence no binding involved. As we have defined rules to be executed on any change in the item value, so essentially both the commands postUpdate and sendCommand eventually change the value of the item and the rule gets triggered no matter which one we have used.
Okay.
Rule 1 - gets update from the state mqtt msg
Rule 2 - sends command to the command topic on a change in color picker.
Which rule needs to be set to autoupdate - off.
autoupdate applies (or not) to individual Items.
The autoupdate feature is enabled by default. When an Item receives a command, autoupdate predicts the likely effect on the Item state and issues an update to that effect. It’s like a psuedo-binding.
If linked. a real binding might act on the command and provide a real update some time later.
It’s about making a responsive UI etc. in the face of sluggish real hardware.
It follows that if you disable autoupdate on an Item that has no command binding … you can send a command and it gets no subsequent state update/change at all.
You can of course listen for commands and manipulate states with rules in the usual way.
I’ve not studied your rules, but it sounds like that effect may be of use here.