See the first post in this thread. Instead of creating a hidden sensor in a switch, the edge drivers created in the method described in this thread add a switch to each virtual sensor so that you can actuate it. That then makes them usable to trigger Alexa routines. So use the method from this thread to create a virtual contact sensor, and you will find that you can turn it on and off from smartthings as desired. On is open, off is closed.
Includes a switch in each virtual device to control device state (also useful for Alexa triggers)
Yes that would be possible to do however it’s best to stay away from settings for now - until they get those settings problems addressed.
What do you see as the advantages to having one device with all those capabilities vs having them in separate devices?
I think the capabilities would have to always show on the device details screen; don’t think you could control the display dynamically. So not sure what ‘enabling’ or ‘disabling’ them would actually accomplish?
Forgive my fogie memory but i think the original IDE driver was created by one of the hubitat guys before they left ST, it was not a well received item due to its multiple options
JD or someone with a better memory than me I’m sure would know the full story
Though having thought about it, would a single driver like this cut down on the driver limit count, instead of multiple drivers to do simple tasks would this not help ?? Duno
This is what i’ve tried to use and it works fine to be honest. I just thought that having a switch icon on a virtual device that will trigger switches thru Alexa would look nicer. But if it’s going to be too complicated, then i guess i am fine with the virtual sensors. Thanks for the advise.
I did that with a DTH and had the option of linking all the capabilities so they were all active or inactive, or their working independently.
Working independently required custom capabilities for each capability to handle the active/inactive commands for each. That was fine programmatically but not for the detail view as last time I checked separate commands still weren’t supported, only the single setter command with an argument. I gave up waiting for that basic functionality after about a year.
Advantage was simply that I only had to have one DTH. Theoretical advantages would have been that I could have shared the device but I didn’t need to. I could also repurpose the device without creating a new one but that is a trivial gain. If I had a use for a device that went active for, for example, motion and contact simultaneously that would be great, but I didn’t find one.
A disadvantage is that the app really doesn’t ĺike having controls that don’t do anything when you press them. If a control is supposed to set an attribute in a certain way it gets cross if it doesn’t. In theory you can make the visibility of each control conditional. In practice it didn’t work.
Another disadvantage it that you can’t hide the existence of the capabilities. You may not be using the motion sensor, for example, but the device is still a motion sensor as far as ST is concerned.
Ah yes, I see. It looks like the device ‘name’ may be for compatibility with legacy devices as much as anything. I haven’t looked at other integrations, but it can’t be changed in the API and it doesn’t appear in the Edge device object at all. That is pretty reasonable actually, the label is sufficient.
The energy monitor ST smart app wants an actual device to measure its energy useage, wash machine blah blah
Completely useless unless you have compat hardware
Anyway to create or spoof a driver into pretending to be a bit of hardware, If the spoofed device pulled in power useage info from a smart plug the energy smart app might have a use for watching power used at plugs rather than hardware
I have a camera out front that records on movement and a few other internal triggers, trouble is in the UK at this time of year we suffer from spider invasions, cameras are always a good place for spiders as there is generally a small amount of heat around the camera, this causes the camera to record when arms and legs creep across the lens
I also have security lighting that is triggered by a passive movement detector, no heat no spider attack
When the movement detector detects movement the security lights come on and the camera switches to day mode and records
Inline with the movement sensor and attached lighting I have a smart plug that detects power draw, that triggers a virtual switch to on and in turn switches the vedge smoke on, that pops up on the TV and gets saved in the vedge smoke history, so instead of looking at the cameras recorded events which are mainly spider legs at mo, I look at the history of the vedge smoke device for events and then check the camera for the corresponding event time frame
That’s sounds pretty cool! Great use for a virtual device!
I learned that insects can be attracted to infrared light from security cameras. In fact I had to turn off the infrared on my cameras for this very reason. Best to have a setup like yours with separate light turned on by its own motion detector.
Yeah I’m pretty bonkers on cameras, they are cool gadgets
My passive detector is situated separate from the actual lights so is 100% reliable for detection, trip the sensor, lights on camera into colour day mode, much better for intruder ID
I also have a 10w led flood, fitted backwards so it washes the wall with light, this is just enough to make the camera stay in day mode if I want but externaly the 10w looks almost pointless for security, when infact the camera sees very well and in colour
Lots of tricks and lots if fun, seen my car rifled twice now, never caught the perps though, just watched them the next day, my fault for leaving the car unlocked and being asleep
Also have an awesome PTZ out back, upside down it makes for a wicked telescope for star gazing
Also constructed a pretty technical roof closure system for it to stop rain getting in the electrics
To me this is like the ‘virtual thermostat’ discussion in another thread. It is working against the architecture. In ST that is really the job of an app.
@orangebucket you are probably right as Edge architecture will probably not allow this.
Even in Groovy there is Virtual Thermostat, but also required SmarApp to connect external devices.
@fido Some developers might start creating apps as they have in the past. For example, besides device handlers, @RBoy has a lot apps done in groovy. He might start converting them to new platform.
I can see need for those, as we all want to have same functionality that we have with groovy.
I like to have all batteries listed in one app, with their status and type, and alarm when they go below specified level. Currently @RBoy has groovy app.
It’s the same for Virtual Thermostat, that I am looking for.
The beauty of the Edge platform for me is that I ‘feel’ free to code up anything I want. I can’t really explain, but the DTH/Groovy environment just felt more restrictive. On Edge, I feel like I’m basically on a Raspberry Pi and you can write whatever code logic your heart desires. The only limiting factor is input and output. You can’t get access, or subscribe to, other devices for state query or control; and you are limited with what you can output to the user via standard & custom capabilities. It may be contrary to the intended architecture, but it is possible to do some limited things in an Edge driver which SmartApps were really intended for.
Can you write a driver that manages a bunch of power sense plugs, collates values, applies computation, and outputs results through a device capability? Sure! Just create a dummy/virtual device to use for that output.
Can you write a virtual thermostat driver that connects to external devices? Sure - as long as you have a way to exchange data with them on the LAN.
Are these things something that probably should be done in a SmartApp? Sure. But the world we have at the moment is that if you want local execution, there is no Edge SmartApp environment (maybe there will be one in the future??). So I do in a driver as much as I possibly can do, and with Edge and its ability to connect with other things on the local LAN, the possibilities are endless.
