Ok…
It’s possible write a routine to mirroring active scene of one virtual switcher??
If first virtual switcher scene change a second virtual switcher change to same active scene???
Not right now since there’s no method to set a specific scene that takes a number, the idea was always to control it with relative commands like next or previous.
What is exactly the use case so the mirroring is needed?
Edit: I’ve implemented it anyway, will publish the update in a couple days after some testing. For the mirroring, Rules API are needed since the app routines cannot copy values.
New version 2026-04-08 improves direct control with scene numbers.
The switcher always had a list of actions like Next, Previous or Scene 5 but the relative scene steps were limited to +/- 1 or +/- 2 and specific scenes were a list and not a number.
Now there are actions with actual numbers:
- Specific scene 5 is exactly the same as picking Scene 5 in the list.
- Relative scene step -1 is exactly the same as picking Previous.
The interesting part is that you can programatically set the scene number with Rules API automations, for instance to mirror the scene number of another scene switcher.
How to mirror a scene switcher
To copy the current scene of a switcher into another whenever it changes, creating a rule in the advanced website (AWA) is needed.
The rule is a simple “if the original scene changes, pass to the mirror the original scene” but, as usual, it is incredibly verbose. In the following rule, you have to replace the original switcher device ID in two places and the switcher that acts as mirror in one. The device IDs can be copied directly from the devices section of the AWA.
Check that the “mirror” has the same or more Number of scenes to cycle defined in the settings than the original, otherwise you’ll have unexpected results. Also, double check the IDs and actions for potential infinite loops.
[
{
"if": {
"changes": {
"operand": {
"device": {
"devices": [
"ORIGINAL-SWITCHER-DEVICE-ID"
],
"component": "main",
"capability": "panelorange55982.activeScene",
"attribute": "scene"
}
}
},
"then": [
{
"command": {
"devices": [
"MIRRORED-COPY-SWITCHER-DEVICE-ID"
],
"commands": [
{
"component": "main",
"capability": "panelorange55982.changeActiveScene",
"command": "changeScene",
"arguments": [
{
"device": {
"devices": [
"ORIGINAL-SWITCHER-DEVICE-ID"
],
"component": "main",
"capability": "panelorange55982.activeScene",
"attribute": "scene"
}
}
]
}
]
}
}
]
}
}
]
When you paste it in the AWA has to look like this:
Now the mirrored switch replicates the scene number of the original.
Hi,
I use your driver to control 15 color scenarios, because it’s not possible change the switching delay by routines i use 2 virtual switchers for animation. Each one with different time switching delay…
My scenario:
15 routines for each switcher when i want 2 leds
more 15 routines for each switcher when i want 3 leds
15+15+15+15 =60 routines!!!
I cannot set the simple rule “if switch1 or switch2 then..” because i have a lot of conditions to met at same time. Using your driver with “reactive current” i can reduce some animation routines but will create a lot of others routines with “reactive current” to met all conditions and pre conditions for my needs…
With mirroring option a can do the same using only 30 routines… First virtual switcher to set color scenarios with a time delay for long spanning and second virtual switcher with different time delay that when activated mirror to first virtual switcher…
Thank you very much to implement this in your excellent driver…
Now i rid off 30 animation routines and a lot more routines needed to maintain use of second virtual switcher operating only when some conditions are met…
Very good! Excellent work… THANK YOU!!!
No problem! Deleting routines no longer needed always brings joy! So is it already working as expected with the reduced routine count?
On the first reading I didn’t fully get the whole scenario but I believe I get it now, make the second switcher cycle the scenes of the first switcher with its own timer so you don’t need to create routines with the second switcher. That’s a great workaround indeed!
It’s working like a charm… I’m very happy with results and happy to free some hub memory…
Thanks
A question I forgot, that different time delay is a fixed delay always or do you use the Additional random offset feature too?
For now I’m using fixed time on 2 switchers but I’m thinking to add another one to try this additional time delay option…
OK! I’m working on an interesting update so you can free more hub memory 
but it will be for fixed times only.
Ok. I’m looking forward to seeing…
Version 2026-04-16 is a massive update but I’ll try to cut to the chase in this comment: the basics of the new features and what to do if the update is not seamless as it should be.
Improved details screen
Media track control
The new Next and Previous buttons in the app don’t play music but can be handy to change the current scene. Mind the app is cloud based, don’t trust much what it displays or does: always prefer local automations for controlling the Switcher!
Delay Override
Now you can change the switching delay dynamically:
-
A value greater than 0 seconds means to override the switching delay in settings and use that instead. Set 60 and scenes will cycle with a 60 second interval regardless of the settings.
-
0 means no override, i.e. use the settings as always.
-
Tip: If you change the override in the middle of an auto-cycle it changes how long the next and following scheduled scenes will remain active, that’s useful in colour animations to set the time to stay in each colour! There are new settings for the Delay Override to reset the override when an auto-cycle starts and to define the behaviour when changes mid-cycle.
Loop single scene action
Makes previous workarounds obsolete. Now you can have one switcher with multiple scenes and only repeat the scene you want instead of cycling through all of them.
The feature adheres to existing auto-cycle behaviours you already know:
-
Max circular loops setting is the number of times the scene will activate if not stopped. The default is 1 so you’ll want to change it or there won’t be any repetition!
-
Stop the loop with Auto-cycle [STOP] action. Loop control: Stop and Loop single scene: 0 will also stop for parity.
-
There can only be one loop active at a given time, if you were looping scene 1 and start looping scene 2, the loop of scene 1 will stop automatically.
-
Use same action for start / stop setting will stop the loop with the same action that started it. This is super useful for buttons with no held / release events since you don’t need a explicit stop, the same button press that runs “Loop single scene: 2” will start and stop the loop of Scene 2.
-
Starting scene also delayed setting will activate the scene for first time after the delay instead of instantly.
Post-update troubleshooting
The update should be seamless but there are new capabilities and many changes to the tight autocycle internals. I’ve spent a fair amount of time testing with typical use cases so hopefully nothing breaks but let me know.
Here are some tips if the update is not smooth:
-
If you can’t open a switcher device don’t panic, close the SmartThings app and open it again.
-
If the next/previous buttons are disabled, try refreshing the device with a pulling down gesture in the device screen to force an initialization.
-
If the delay override cannot be changed from the app, either ignore it or set it to 0 with a routine to force an initialization.
If that still does not work, @Pyrylamo found a good workaround, thanks!
Hope you enjoy the updates! I’ll eventually follow up with fun cases, hidden tricks and revisit the older examples that now can be made easier.
Refreshing doesn’t help.
Manually routine doesn’t change anything
Strange but not surprising given how picky the SmartThings app is.
Can you check in the AWA for the device that the attributes for mediaTrackControl are ["nextTrack","previousTrack"] and for delayOverride is 0 s?
- If the values are correct it’s some weird app cache, try to close it and open it again or just wait until it eventually fixes itself.
- If the values were empty and the app didn’t initialize them try doing it from the AWA (
refreshandoverrideDelaycommand with 0 in both fields)
Hi, click the button to create a new switcher…
Open the switcher and after that all the others are updated…
You can delete the new one after that…
The only way that worked for me…
Gotta love the app 
Definitely a cache issue and a good workaround!!
That is what AWA shows
@Pyrylamo work around worked. Creating 1 new switcher fixed all 3 of my switchers
I’ve pushed a small update, version 2026-04-17, that adds a new setting for the auto-cycles / loops called Reset Delay Override on start.
When enabled, starting an auto-cycle or loop resets the recently introduced Delay Override to 0. That way you start with a clean slate, with the starting scene staying active for the time specified in settings.
I realized that setting was needed when trying to rewrite the original Pomodoro timer example of two years ago using overrides. With the new reset setting can be done as envisioned: 2 scenes (focus and rest), switching delay setting of 25 minutes that will be used for the focus phase and a delay override of 5 minutes that will only apply to the resting phase.
Yes… good point…
Nice work on all updates… Goodbye mirror rules and secondary switcher..
But now, you open a new world of possibilities… I’m studying that and will redo a lot of things other way and add others…
In my first changes, i missed an override relative delay step option.. Will be very useful to easily increase delay with remote button… But it’s ok, i’ll do it with a workaround…
I’m happy with updates and thank you for your help, work and tips in all your driver’s creations…