I’ve been gone from the environment and community awhile, but a need has arisen, and I want to get opinions on the best way to implement:
I have a light switch that I want to turn into a smart light switch - preferably through SmartThings, but I’m not locked into it.
I need to be able to turn the light switch on and off through a REST API. I don’t really care whose.
I need the light switch to also work independent of the software solution.
I’m looking for the light switch recommendation, as well as confirmation one can rather easily communicate with the light switch, either through SmartThings or, should that not work, going direct. My programming environment is Java and bash, depending on what’s needed.
Background:
I am purchasing a house that has a living room with a cathedral ceiling and a pellet stove. The central heat is propane, and the pellet stove is a more economical heating solution than the propane.
The master bedroom is upstairs, and there is an interesting fan that can draw heat from the cathedral end of the living room ceiling and pull it into the master bedroom. It’s a rather curious and interesting solution.
I have a rather extensive integration with an Ecobee thermostat, plus a feed from the electrical service provider.
I want to combine some analytics I’m already using to start looking at various factors to decide when to turn the switch on that controls the fan. I’d like to stay with this approach, hopefully use SmartThings to talk to the light switch, but just call through REST to poll switch state through SmartThings, and turn the switch on and off through SmartThings.
If it doesn’t work effectively through SmartThings purely as GET and/or POST commands, I’m good with a Wifi-enabled solution for the light switch that doesn’t involve SmartThings, but that would not be my preference.
What country are you in? The device selection does vary.
Meanwhile, it sounds like Shelly might be an option for you. They are available in many countries. They have their own local server if you want to use that or you can use their Wi-Fi cloud, and with the new smartthings architecture you can communicate with them through an edge driver. So lots of options. Inexpensive and quite well engineered for the price.
Ok, then I think you’ll definitely want to look into edge and what it’s going to offer. You’ll have a lot of interesting choices once it’s fully deployed, just be aware that it’s still in beta.
Are there not any off the shelf existing light switches that would do the trick that are already integrated with ST? I do agree this looks interesting, but probably more integration work right now than I really want to apply myself to. I’d rather play around with the temp logic and getting it right than trying to figure out how to make the switch itself work.
I looked around at the Cync switches, a couple others, and started looking at the ST CLI. It never quite feels like simplicity is available in the ST solutions.
If you’re going to use it with SmartThings, why do you need to communicate with the switch itself through a rest API? I guess I’m not really understanding the project. I mean, you certainly can do what you’ve described with, for example, the Shelly devices, but why would you want to? Why not communicate with smartthings, and let it turn on a zigbee or Z wave switch through its normal communication methods?
Cync doesn’t integrate with SmartThings, but there are lots of switches that do. Zooz and Inovelli are two very popular Z wave brands, excellent engineering. And there are probably a dozen others that have manufacturer provided integrations. So I’m just not sure why you’re trying to go outside the smartthings ecosystem and then come back into it through a side door.
Also, what are the specs on the fan? Most light switches, regardless of protocol, are not engineered to handle a motor like a fan. You need to look at a motor control switch. These may look exactly like a light switch, but they are built differently. If it’s just a plain on/off switch for the fan, then you’ll be able to find a relay that will work. If it has variable speed control, you’ll need one specifically designed for a fan.
Why going outside and coming back in? A good question.
I’m not trying to, really. But all my decisions are going to be made outside the environment. I previously found the ST extension mechanisms tedious. The entire world had gone RESTful, and then there was the ST approach.
I know what I want to do and when I want to do it: I want to turn a light switch on, and turn a light switch off. I know when I want to do it. I just want a switch I can do that with very easily from the outside with a REST call. It’s about like Kramer and Movie Phone: Why don’t you just tell me that you want to turn the light off!
As for the fan, it’s some home-rigged thing with a fan that is smaller than a simple fan to move the air around in a room during the summer. It’s about a 10" diameter fan that is just that: a fan. It really is run by a simple light switch that is next to it in the wall. It’s actually a rather clever idea to pull heat from one room to another while changing floors.
The fan is still a motor: the physics are different than a bulb. But if it’s a small enough load and it’s just an on/off switch, you’re probably OK.
As for the integration part, Smartthings is in the middle of a huge transition. Under the new architecture, smartthings will no longer host groovy code. Instead, you can write whatever code you want, host it yourself, and come in through the API. So much more like what everybody else was doing.
That should work for any switch of any protocol connected to your SmartThings account. (That’s the front door to the new ST architecture)
If, as you’ve described, you also want to be able to go directly to the switch through the switch’s own API, but do polling through the ST API, you should be able to do that with one of the Shelly WiFi devices. Just make sure you get one Spec’d for US wiring, they are available in a number of different countries.
Connect it to your ST account through an Edge driver and it will appear on the list of devices available through the ST API, as well as still being available through its own API.
