Bidirectional concept for item and proxy item required

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.

Does anybody has an idea for this?

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?

I thought that was important. Command steered rules are no good for that.

not sure what you mean…
The whole thread is all around a GUI update (within my proxy item and rule concept) to a widget if a button is pressed.

That I’d like to understand. I chose received command. Why is it better to choose received update or changed in this case?

Are we talking real physical buttons or something in your widget?

Real physical buttons don’t usually generate OH Item commands.

Real buttons


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.

Oookay … then another rule for the second pathway?

Commands dummy Item
Command-triggered rule to transform
Commands real Item
Binding controls device

Device reports status
real Item updated
change-triggered rule transforms
Updates dummy Item
updates widget display

You may need to disable autoupdate on one or more Items to stop it giving you false updates.

exactly. This is how the first rule works as of now. As said, works great.

perfect. That is the idea of the rule #2.
In rule #2 at this point:

Updates dummy Item

rule #1 is being triggered.
Do you think that autoudate will refrain rule #1 from being triggered?

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.

Ok - understood.
Rule #1

  • Item BRIGHTNESS received command from widget
  • transforms and does a sendCommand to WW and CW

Rule #2

  • 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.