I need an idea about how to control a proxy item which is “linked” to an item through a rule in a bidirecetional way without resulting in endless loops.
this is my scenario:
Shellly RGBW2 (LED Dimmer) has 4 outputs. 2 of these outputs control a CCT LED stripe (white color LED).
An RGB LED requires 3 (or 4) outputs to get the desired color, CCT just 2 (to control warm white (WW) and cold white (CW)).
If you want your white LED in the desired color temperature you normally have to control 2 items (WW and CW). For this I have created a rule and a widget which is triggered by 2 proxy items (BRIGHTNESS and COLOR TEMPERATURE) and calculates the required values for WW and CW channel. Works perfectly so far.
My problem now is when light is switched on by switch (and not openHAB widget). The widget of course does not reflect the new state because there is no rule which transforms WW and CW from thing’s channels back to BRIGHTNESS and COLOR TEMPERATURE. This would result in endless loops.
If you look at simpler scenarios like mirroring cross-linked switches, you’ll find the key to success is acting on state changes and not on update.
Where that can fall down is with e.g. ramping dimmers, where you may get a number of changes over time as a dimmer adopts a new setting.
I suspect of you have multi-component ‘devices’ you may face similar trouble with components that change individually?
In these cases, a simple “mirror that change” action sees unwanted changes and the original target is lost.
I can’t think of any easy around that apart from having a dummy/master ‘target’, whose state is restricted from changing very often but should accept some changes from monitored devices. Complicated.
I didn’t even mention that piece. I am sure I could handle this if I came around the fundamental problem.
If there were a second rule to transform WW and CW back to BRIGHTNESS and COLOR TEMPERATURE, the rule (which is inteded to get triggered by my widget) is now triggered and sends commands to WW and CW. Ok, I could check, if the values changed and exit if not or I could use rule trigger changed instead of received command but that does not sound convincing to me. So maybe I have a complete wrong approach for controling my CCT LED?
2021-12-11 15:59:06.333 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ShellyDGSchranklicht_cw' changed from 32 to 0
2021-12-11 15:59:06.340 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ShellyDGSchranklicht_ww' changed from 38 to 0
However, that rule does not exist yet (due to risk of rule loops).
But my widget sends commands to its action item. This is where I currently use command received.
Why? Doesn’t it trigger on commands? Is there a command - this will show in your events.log?
There have been widget bugs that issue unsolicited commands in response to state changes.
Is your rule #2 sending a command? Don’t do that, do a postUpdate.
Autoupdate is about state predictions in response to commands, it never generates commands.
Item WW (or CW) received update when physical button is pressed (as can be seen in the logs)
transforms and does a postUpdate to BRIGHTNESS
that wasn’t 100% clear to me that BRIGHTNESS.postUpdate of rule #2 does never interact with BRIGHTNESS received command of rule #1. Sounds logically but would not have risked that without an expert opinion like yours.
It’s a bit headache inducing, but maintaining a clear picture of the distinction between command and state is vital to managing workflow.
Autoupdate impact here is minimal - it listens for commands and updates state with a guess. I think in your case that’s “who cares” territory.
Rule #2 runs on the guess when a command goes out, widget display updates. Later a real status might come along from device, might be the same, might not. Rule #2 runs again, “who cares”.
Unnecessary runs can be reduced by choosing changed triggering - no change, no work to do.
