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:
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)
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)
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”.