As I mentioned in another thread, combination virtual devices which are both a switch and a sensor are not working for me in the new app. They don’t stay in sync, so it is possible to have one of these devices where the switch is closed but the contact sensor is open, which makes them useless for a lot of purposes.
And I am not feeling confident that the new platform will offer the same easy way to create devices of this type.
So I thought I would start a thread with some of the other options. These may be much more complex than the old virtual devices. Or they may be more expensive because they involve the purchase of actual physical devices. So they won’t be right for everybody.
However, since I depend on Home Automation in a way that more physically able people may not, I am willing to at least consider some of these as potential candidates for my “must-have“ use cases. And I thought other people might find this interesting.
Please feel free to add any additional methods that would not require using the IDE.
By the way, it’s also possible that I’m being too pessimistic, and that the new platform will eventually offer an official way to easily create a virtual switch as well as a virtual sensor which can be toggled on and off. That would be great, but they haven’t promised that as yet, and I’m not holding my breath. We’ll see what arrives when it arrives.
Alternatives to a virtual device which do not require the IDE
- Use the official API and host your own virtual device via cloud to cloud integration.
Pros: this should Probably work as long as Smartthings identifies it as a sensor to the voice assistants.
Cons: It may be technically quite complex and requires creating a developer account and learning the new API
- Use a real sensor and automate triggering it.
I have told the story in the past how once at work we had to bridge two systems which didn’t talk to each other and we ended up setting up a remote control toy car that we could have run past a motion sensor from the other system. Once that worked as a proof of concept, we made it look more professional by putting a fan inside a box with a sensor. The fan could be turned on from system A and that would trigger the motion sensor from system B.
There are lots of ways to do this with lots of different types of equipment depending on exactly what you want to do.
For example, turning on a small table lamp might trigger a motion sensor underneath the lamp just because of the heat of the bulb.
Fans, even tiny ones, can be very effective in triggering motion sensors.
You can trigger a contact sensor if you set up an actuator to open and close a cabinet door or a drawer. You might even be able to set up a Switchbot to push a lightweight cabinet door Or box lid open and then let it fall closed again.
So basically you are using one automated device to create a physical change in the environment that can be detected by a motion or contact sensor.
The programming side of these is usually really easy. The cost and challenge comes in setting up the physical change. But honestly, it can be pretty easy if you’re willing to spend the money for the right devices.
- use a Philips Hue bulb instead of a virtual switch if you have two systems which don’t communicate to each other but which can each communicate with the Hue bridge.
This won’t work for use cases which require a sensor, like triggering an echo routine. But it can work fine if you just need an on/off switch for something like Ifttt or even between two otherwise not integrated home automation systems.
This works because Philips Hue is a very friendly system and happy to integrate with many different other systems all simultaneously.
The cost for this is one $15 bulb per virtual switch. Plus figuring out where to put it so the light doesn’t bug you as it goes on and off.
Note that this method will only work with bulbs which are connected via a hue bridge. Because it’s the bridge which will make the integrations with the other systems.
- email. No, really. Some systems, such as some security systems, can you send an alert by email. Then you can receive that email on some other systems and trigger events off of that.
This used to be very easy with Gmail and Ifttt, but now Ifttt can only send an email from gmail, not process a receipt. But there are other apps and methods for processing incoming mail that you may be able to substitute.
The one thing to note with this is that there is sometimes a delay while the mail gets processed, typically about 15 minutes. So it’s good for some use cases, but not all.
The biggest advantage is that it’s probably free.
- if you are already going using HomeKit and Homebridge, you can create virtual devices there, including a switch to turn on a contact sensor. This allows you to then create HomeKit automations for things like “door left open for 15 minutes“. Most developers for HomeBridge call these “dummy devices” instead of “virtual devices.” But you cannot deal with these is trigger echo What you cannot deal with these is trigger echo routines because at present there’s no way to get Alexa to see the dummy devices. So if you go this way you have to substitute both the virtual device and the automation and the Voice assistant plus it’s a lot of work to set up and you need an additional server device. I don’t think most people are going to want to do this unless you are already using homebridge, but it is an option. (Google “Homebridge dummy sensor“ Or “Homebridge dummy switch” to find resources on this option.)
Well, those are a few possibilities. Go all in on the new platform and write your own system, find a way to physically trigger a real sensor, use Hue as an intermediary, or use email. Each method has pluses and minuses and some will only work for very specific use cases, but that’s what I’ve thought of so far.