While we wait for the stock mirror routine to arrive.
This driver creates virtual devices to be able to automate state synchronization between a real device and this virtual mirror device, writing 2 routines instead of 4 routines without entering an infinite loop.
Install the driver on your Hub from the channel
In the App add a new device and Search nearby.
The “MAIN Virtual Mirror” device will appear on devices without an assigned room. It will indicate “Total Devices: 0”.
This device allows you to create virtual devices and have control of those that have been created so far. When one is uninstalled, making a refresh of this device, the total number that remain installed is updated.
When the driver is updated to this version, new devices created will be created with the mirror-only profile by default.
Devices already created will have to clear the cache or go to preferences and make a profile change and clear the app cache.
They also lose the personalized name, I don’t know why. the changed icon does not lose it.
│ Name │ Virtual Mirror Mc │
│ Version │ 2022-06-13T11:36:31.760021953 │
Testing and testing I have seen a case where mirroring automations can enter an infinite loop.
After thinking about it a lot, I have seen that it is not a problem with the virtual device. It is a problem of the execution delay and the zigbe or zwave network.
It only happens when the physical device goes very quickly from Off to On and back to Off or vice versa.
When a very fast Off-On-Off sequence is made, 2 events are generated that trigger the two automations in a very fast sequence.
The first On command generated in the device triggers the automation and generates another On command for the device. When it reaches the device, the light is already Off and therefore turns On again.
The first Off command generated in the device triggers the shutdown automation and generates another Off command for the device. When it reaches the device, the light is already on and therefore goes off again.
This generates an infinite loop because the two automations are triggered with a very short interval and before the generated command reaches the device through the network, it has already changed to the opposite state.
The solution is to add to the automation to put everything ON, in the IF part, that the real switch is On for 1 sec and in the other that it is Off for 1 sec.
This slows it down a bit in normal operation but prevents automations from triggering with very fast changes in the physical switch.
They also start running in the cloud, hopefully only for now.
Note: Making this change only in one of the two automations also works, since the sequence of the received commands is broken, but one automation would work locally and another in the cloud, I don’t know if it’s worth it
As an idea and request from @milandjurovic71, virtual devices with multiple switches (SwitchBoard) have been added in a single “main” component to be able to control irrigation devices with multiple channels and other uses.
@milandjurovic71 will be able to explain the uses that he has given them, since it is his idea and he knows better than me.
Can be created with 2, 3, 4 and 5 switches. The default icon is irrigation and can changed by some of app list for plug device.
There is a custom capability to enter the name of the device it controls. This name is only seen in the details view. If one day the names can be changed dynamically, it will be modified.
I have changed the name of the driver to Virtual Switches Mc and also avoid errors with the name Virtual Devices of Taustin
The update will be done automatically. I have tried the update several times and it works fine, although it is possible that you need to clear the cache of the app and refresh the Main device, when you open it for the first time
Thank you @Mariano_Colmenarejo for creating this virtual device.
I am using this driver where only one switch needs to be on, and all others are off. This driver eliminates loop issue when routine are used to activate/deactivate other switches, and run forever in circles.
It replicates Home Mode, or SmartThings Home Monitor functionality, where only one state is active.
I am planning to use this for my 4 zone drip irrigation timer, where only one zone can run at the same time.
Another use, I have used switchboard with 3 switches, to control 3 different lights with single Ikea dimmer remote. This Switchboard is displayed on Fire tablet, with Ikea Dimmer next to it. However I have plans to upscale the dimmer.
I have created automations, where when one of this switches are active, and Ikea Dimmer is pushed up or down, it changes light level +/- 5%, and when dimmer is held up or down, it changes light temperature by +/- 100K. Each switch on SwitchBoard is named for individual set of lights in the same room.
This way I can change level and temperature on 3 different set of lights with single dimmer and this Switchboard.
My intention is to swap Ikea dimmer for different device: Smart Knob, as driver for it became available, created by @erickv.
To introducing these changes and if some user has already made some automation in his system, I will not do the automatic update,since the automations created with switchBoards old version would stop working when it is updated automatically without prior notice.
In this way, the best thing is for each user to migrate their devices to the new version of the driver when it suits them best.
The current version will automatically be called Virtual Switches Mc-(OLD).
The procedure to migrate the devices to the new version:
Install in your Hub the new version Virtual Switches Mc
Add new device and search nearby. The new MAIN Virtual Switch device will be created
You can see the Total Devices created in the MAIN Virtual Switch that you already had installed. You can refresh the device so that it is updated.
On each device you want to migrate, make a driver change in the app and choose the new Virtual Switches Mc driver.
You will not lose the automations created for Virtual Mirror devices.
For automations of Virtual SwitchBoards you need edit and modified them. Only the custom names of the switchBoards will be reinitialized, since the system does not recover them when changing drivers.
Once you have migrated all your devices to the new driver and the total counter is 0 then you can delete the MAIN device and the driver -(OLD)
I tested the migration process with all device types and works fine