The conventional way to do this is to link three devices with three individual Items, and in addition manage them with a Group. This prevents unwanted interactions, and also still allows individual control if required.
For example, consider a single Item can only have one state. With three links, its going to hold the last state reported - but not all devices might be the same, especially if there is some change in progress and they’re all reporting various things at various times.
Note that the UI widget is linked to this (poorly defined) state.
Anyway, that’s background. I think for your immediate problem you should look into your events.log and see what happens to your Item - commands, state changes - because this is really needed to understand widget behaviour.
The conventional way to do this is to link three devices with three individual Items, and in addition manage them with a Group
Thanks, I know that (more or less…) but my home is small and I don’t have many rooms / devices so the extra effort to make the groups is not worth for me, besides, this “shortcut” works perfectly well after all, the devices controlled with that “shortcut” are all using tasmota and they “understand” the commands given. The issue with the color picker has been there from the start, even with “correct” items (I have the same issue even with one item, and many people do), I’m having the exact same issue than OP.
Please lets not deviate from the color picker issue, my bad coding is not the culprit here (at least not for this issue) and there are many comments saying the color picker is broken. Don’t want to sound mean but its just to cut this here, since I see that this is already starting to go the path of the “scapegoat” (aka, “its your fault”).
To resolve problems like this means first to diagnose, “what is going wrong”? Many things are happening in this situation, most of them not part of the problem, A valid approach is to simplify, removing clutter to gain a view of the real issue.
You know this. Apparently you do have a simpler example that also goes wrong in the same way, so just present that.
I suppose that it is worth mentioning that I discovered this issue for myself two days ago, (rather than two years ago), and that I did a lot of debugging on my own use case, and was brilliantly supported by @Lolodomo as a sparring partner and code guru. And the result is that in these two days @Lolodomo has kindly generated three PRs that address and solves, at least my own use case.
It may or may not be that these fixes also solve the OP’s use case, or @elcosomalo 's use case. Who knows? But I can only suggest that more information on those use cases, coupled with a dialog, and dedicated hard work, can probably solve them too.
@elcosomalo the above mentioned three PRs have been merged into OH main, and will therefore be included in v3.4. Milestone 6 on December 11th. So you may want to test whether the current SNAPHOT or the December 11th Milestone 6 will have also resolved your issue. Maybe it did, and maybe it did not, and due to your unwillingness to provide additional data about your use case, I can only guess.
Thanks, its working perfectly now, no more brightness switching, and the color selector doesn’t go off-limits now like it happened before. Seems you finally fixed this long standing issue once and for all. Thank you for your work.
