This will be an open beta, as the driver is not expected to need many updates. Any updates will happen automatically if they are released. Those updates will be announced in this thread, so please watch for notifications.
There are some other quality virtual device drivers. The intent of this driver is to enable users to create their own smart apps / devices to enable automations that are not possible with their physical devices. For example, associating a relay/contact sensor to make a door. Follow the invite link below to install the driver. This will create a Virtual Hub in a “No Room Assigned” room within the ST app. You can use this virtual hub to create further devices.
Here is a Garage Door Example connecting a relay and contact sensor to automate the door. You should consider the safety of automating a door before doing this with a physical device. Manufacturers frequently add safety mechanisms like alarms, blinking lights and delays. You should consider these when creating a solution of your own:
These are virtual implementations of each functionality. For occupancy as an example, you can connect that to a motion sensor (motion equals occupied, no motion after 10 min equals not occupied). It’s helpful if you want the interface of an occupancy sensor for either an automation or a dashboard
Consumables are items that are counted or periodically replaced. You can count dishpods for each dishwasher cycle or days to replace a water pitcher in the fridge. It can also warn you when you hit a threshold so you can reorder supplies (bags, pods. etc)
@Paul_Oliver There’s already an Edge Driver for this.
Of course @Mariano_Colmenarejo already did it, it’s under Virtual Appliances Mc.
From a Routine, input any text you like…
Thanks for the suggestion. Your idea to use @Mariano_Colmenarejo Virtual Appliance text option solved the problem. @blueyetisoftware sorry to have bothered you.
This approach isn’t deterministic. If an event is missed (zwave, network, etc) Then you risk inverting the state opening the door when it should have closed, and vice versa. That other driver also treats the door as a switch, while this driver treats the door as an actual door with more than 2 states. (open, opening, closed, closing, unknown)
This would be pretty straight forward and fits the intent of the driver to be a generic set of tools. I’ll add it to the list for an upcoming release.
I’ve never seen it get out of sync when routines are used this way. I always assumed it meant “if A is opened, then set B to open”. Not toggling B on any toggle of A. Perhaps i misunderstood.
But your point about discrete events is taken especially for a security/door/lock type device! Thanks!
I wish it worked like this. It would be great for synchronizing lights as well. The drivers are sent a distinct event for each and not an event carrying a “state”. You are basically saying “if toggled”, “then toggle” as you summarized above. You can test this by temporarily disabling your automation, changing the state of one to make them out of sync, and then turning the automation back on.
I’m seeing this now. Thanks for pointing it out. I assumed the routine would do a "if toggled(), look at the trigger device state and call on() or off() accordingly for the target" I thought that because there is no toggle() command for switch capabilities.
One feature request for the garage door:
Could there be a lockout toggle preventing the door from being opened? A boolean parameter that if set, would simply ignore digital requests to open the door (action swallowed, don’t pass along) We only want to be able to remotely close the door, never accidently open it. Default would be “false”.
