You can do this by not connecting your relay to the ‘opening’ event in the automations. In the example above there are 4 automations, 2 for the door to trigger the relay and 2 for the contact sensor to update the door. Removing the opening->relay automation would prevent it from being opened.
Keep in mind that most relays are momentary and stateless meaning they will just physically toggle the door. If it is closed, and you trick into thinking it is open, and close again, the state would be inverted. The relay itself will also always be capable of opening the door if pressed.
I was just thinking the UI of the virtual device could reflect that its being locked out. Instead of changing to “opening…” it would indicate LOCKED.
I plan on having discrete open/close events to the opener vs just simulating momentary presses of a wall button. We’ll see how that shakes out once I get it all integrated.
It shouldn’t stay in this state. It should move to “unknown” if you try to open it, and it physically cannot open. You can also go into the settings and play with configuring a separate door lock. I have been thinking about making the door un-openable if locked with a distinct lock
Right, but the UI changing to “opening…” is scary if you’re not at home and can’t see that it doesn’ actually open. 10 seconds later it changes to unknown but then you don’t know what happened. I’m thinking WAF here. It would be better if the UI did not change from closed, or it indicated it was locked out until going back to closed.
The lock could just be my lockout. Maybe the parameter is a “lock prevents” with options of “nothing”, “opens”, “closes”, “both opens and closes”. So you can configure what behaviour the lock has on the open/close actions.
Edit: I could do this with my routine to open. Only allow opening if the lock status isn’t locked. But the nicer UI above I feel would be cleaner too.
A virtual device which shows the current SmartThings Location Mode is exactly what I am looking for also. It keeps you from having to dig into the app to determine the current mode (which now requires you to go to Home, Manage Locations, then Home again to see the current mode). I am currently using a custom DTH which displays the mode on a device tile as pictured above, which I am certain will be going away at completion of the edge driver transition. Since I am using 4 different Location Modes in my routines, the suggestion to use the text virtual device would require me to have 4 more routines, and I am on the cusp of reaching SmartThings scene / routine cap already.
Anything you can do to create the virtual device to keep the tile in sync with the actual Location Mode, without having to use routines to do so, would be greatly appreciated.
I am not aware of a way to do this without routines. The location mode isn’t exposed to Edge drivers at this point. If someone finds a way, I would be happy to add this.
I’m having trouble getting the initial device created. Normally when I install a driver like this I simply go to the Add Driver and Search Nearby and it pops up. I have installed and reinstalled the driver and the device is not being created. Am I missing something?
Probably not. That is all that is needed. I have seen some chatter about discovery of ALL devices being broken on iOS. Do you happen to be using the iOS app? You can message me on the side as well.
Do you have any info what’s going to happen to the modes in a long run. You can’t manage modes from the app and if IDE is going away with Groovy then how are they managed after that?
They can be managed by typical CRUD operations on the API, similarly to rooms, but this has never made it to the public API reference for whatever reason and the CLI hasn’t picked them up either.
Should we read anything into that? Perhaps not. It is tempting though.
I sometimes wonder if a high-up at ST has had a nightmare involving Location Modes and has been out to get them ever since. They do rather bury them in the app.
This has been very useful, I was able to use your garage door example to successfully set up an edge virtual garage door using your utility. Thanks much for that!
Can you provide an example of how to set up the virtual thermostat to use the temperature from a sensor or more than one sensor? I’m a bit stuck as the routines only allow an update if it hits a specific temperature or range of temperatures…
I’m sorry, I thought there was a virtual thermostat in there, I must have been been looking at one of the other virtual device creators. So far your devices and tutorials have been the most useful, and the garage door opener the only more complicated virtual device I have working.
I look forward to it. If there’s any way to include and average multiple sensors, that would be great!
