Hi, @rossetyler
Following up, the engineering team mentioned they are aware of this limitation to make a Rule about a circular dependency (mirror actions).
So, they suggest this workaround:
Create a virtual device containing the capabilities you want to mirror on the physical devices.
You can use the “Labs” tool in the app, the command to create virtual devices (here) or a Community driver like this one to create it.
Use the virtual device to synchronize the devices, this way, the commands will go from only one source to both devices.
I have my doubts.
If such a solution exists, please publish an example here.
If a solution exists, why isn’t this capability available natively?
Consider physical switches A and B with a virtual one C.
When a physical action is taken on A, it will trigger A’s rule to update C.
This will trigger C’s rule to update A (and B) which will trigger (re-enter) A’s rule to update C … ad infinitum.
This seems like the same problem to me.
@JDRoberts
Of course the speed(s) of the runner(s) will affect the outcome of a race (who wins, who collides, who crashes and burns). That is not my point.
My points are:
This capability should be natively supported.
Native or not, such capability will require software techniques to avoid these demonstrated non-deterministic results.
Code re-entry guards are trivially implemented in general purpose languages to avoid chasing one’s tail forever. Of course, we are not dealing with a general purpose language here but, it seems to me, some type of re-entry guard needs to be supported. AFAICT, it is not. I suspect that it is not trivial because, if it were, I suspect we would have native device mirroring already.
Swapping out my V2 hub for a V3 hub is what broke things for me. That should never happen.
I have used this method for 3 or 4 years to effectively create an actionable “group”. It’s useful in some situations but it’s not the same as having a bi-directional mirroring capability.
Some limitations:
You must perform actions on the virtual device to trigger all the physical devices. So it’s only accessible from the app or a voice assistant,
Because of point 1, it is not fully local and won’t work during an Internet outage,
If any of the physical devices are switched manually, the virtual device and any other physical devices will become out of sync with the device that was manually changed.
Similarly, if all the physical devices are manually changed they will be out of sync with the virtual device.
As I posted previously, the easy fix to this situation is to check the state of the “mirror to” device to ensure it’s in the proper state for the execution of the “mirror to” action of the Routine or Rule.
The problem is that the Routine or Rule doesn’t know if the ‘mirror to’ device is in the proper state for the ‘mirror to’ action because the action is required, or if it just looks like it is in the proper state because it has changed state since the mirroring cycle began.
Yes, and as I said then that made things better. For some types of interactions it works most of the time but for others it often fails (although not as bad). I don’t know why it works better and I don’t know how to make it work completely.
There is still a problem. I suspect the problem is not trivial because SmartThings Smart Lighting would certainly support it.