Thank you for asking for real-world use cases. One of the most important use cases for me is what I call “virtual parallel switches.”
In my home, I use Sonoff Zigbee switches to reproduce the behavior of traditional parallel/three-way switches, but using local scenes.
For example:
Switch A → controls the light
Switch B → is physically independent, but should behave as a second parallel switch
I therefore create two local automations:
- Switch A ON → Switch B ON
- Switch A OFF → Switch B OFF
And, importantly, the reverse direction as well:
- Switch B ON → Switch A ON
- Switch B OFF → Switch A OFF
This makes the two physical switches behave as if they were part of the same electrical circuit, even though there is no traveler wire between them.
I use this extensively throughout my home. The screenshots attached to this post show several examples of these local automations currently running in my home, including bedrooms and corridors.
A very important problem: automation loops
There is, however, a significant problem with the way I currently have to implement this.
When I create a virtual parallel circuit involving three or more switches, I frequently experience what I call automation loops.
An automation loop happens when one automation changes a switch, that change triggers another automation, which changes another switch, and eventually the resulting change triggers the first automation again.
For example:
A ON → B ON → C ON → A ON → B ON → C ON → …
The system can continue executing these automations repeatedly, even though all switches are already supposed to be synchronized.
In my case, this can become much more serious than simply generating unnecessary automation executions.
The lights can start turning ON and OFF continuously, sometimes repeatedly cycling between states, and they do not stop by themselves.
When this happens, I have to manually power-cycle the ZBBridge-U — turn it off and turn it back on — to stop the loop and restore normal operation.
This is particularly frustrating in a real home environment.
For example, I use virtual parallel switches for the lights in my corridors. When the children are already tired and we are putting them to bed, having the corridor lights suddenly start turning on and off continuously is extremely disruptive. It can wake the children up and make a normally simple bedtime routine very frustrating.
So I believe loop prevention is an essential requirement for local scenes, especially when using bidirectional synchronization between three or more devices.
Ideally, the bridge should understand the difference between:
A physical user action:
Switch A physically changed → synchronize B and C
and
A state change caused by the automation itself:
A → B → C
The second type should not be allowed to restart the same automation chain indefinitely.
A local automation engine should therefore have some form of loop detection / execution context / recursion protection.
For example, once a scene has started synchronizing a group of switches, subsequent state changes generated by that same scene should not trigger the same synchronization chain again.
It would also be useful if an action such as:
Switch B → ON
were simply ignored when B is already ON, rather than generating another state-change event capable of triggering additional automations.
Why local execution is important
This is actually one of the main reasons why I would like to see local scenes/offline automation supported by ZBBridge-U.
These automations are not dependent on the cloud. They are basic state-to-state relationships that should continue working even if the Internet connection is completely unavailable.
For a smart home, I consider this a fundamental function. If I physically press a wall switch to turn on a light, another physical switch configured as its virtual parallel switch should immediately reflect the same state — even when the Internet is down.
The key requirement is that the local scene must react to the actual physical state change of the Zigbee switch, rather than requiring an Internet connection or cloud processing.
Features I would prioritize
- Zigbee switch ON/OFF → Zigbee switch ON/OFF
- Bidirectional synchronization
- One trigger → multiple actions
- Multiple switches controlling the same virtual circuit
- Very low latency
- Execution entirely inside the Zigbee bridge/local network
- Operation without Internet/cloud connectivity
- Persistence after bridge reboot
- Built-in loop detection and prevention
- Protection against recursive/chained automation execution
- No unnecessary trigger when the target device is already in the requested state
- Reliable synchronization of 3, 4 or more switches
For me, virtual parallel switching is one of the clearest and most useful real-world applications for local scenes, because it allows smart switches to reproduce conventional electrical behavior while also giving much more flexibility.
And solving the loop problem would make a huge difference in reliability. I would be very interested in testing this functionality with ZBBridge-U and providing detailed feedback before the official release.
