search

stjohnjohnson / smartthings-mqtt-bridge

Bridge between SmartThings and MQTT
https://hub.docker.com/r/stjohnjohnson/smartthings-mqtt-bridge/
MIT License
366 stars 242 forks source link

New Smartthings restful API #198

Open mschwartz opened 5 years ago

mschwartz commented 5 years ago

https://smartthings.developer.samsung.com/docs/api-ref/st-api.html#section/Overview https://smartthings.developer.samsung.com/develop/index.html

Smartthings has a beta API available now that allows you to perform RESTful http calls to their cloud to perform various functions.

Rather than the complicated process of adding code in the IDE, this bridge could use the HTTP API. Dropping in the new HTTP API version of smartthings-mqtt-bridge shouldn't change anything about how the MQTT messages are processed. Only the transmission mechanism would change under the hood.

The benefit is fairly obvious, aside from no need to add code via the IDE. You only have to use the IDE to generate a token, one time, that you'd paste into the yml configuration file.

As is, I really appreciate the bridge and use it as a core piece of my custom home automation software.

https://github.com/RoboDomo

andrewsayre commented 5 years ago

Thanks for sharing this! You may also be interested to know there is a new SmartThings native integration in Home Assistant that uses this API

mschwartz commented 5 years ago

That's where I probably found out about the new API.

That said, I'm not much of a fan of any of the existing solutions like HA.

In fact, that this is now native in HA is kind of contrary to my desired architecture. Which is microservices, each doing MQTT protocol and obscuring the oddities of the API/protocols beneath. For everything.

The advantages are numerous. But start with the ability to have cron jobs.

My Nest thermostat doesn't let me turn on the heat from 6AM to 9AM due to a "rush hour" program I joined with the gas company. A cron job runs at 5:45 and turns on the heat; the cron task just runs the mqtt commandline command to do it.

Cheers

mschwartz commented 5 years ago

Looking at the API and their cli example, I don’t see how it’s feasible for the MQTT bridge.

There’s no notification or event API, no EventSource or WebSocket.

The cli example has an “all devices status” method, but it enumerates all devices (1 request), then makes one request per device to get each device status.

The rate limiter they put on requests means an unacceptable latency in update to a UI when a switch is turned on or off. Depending on how many things on your hub. I have ~30. A fan switch and dimmer for two ceiling fans, dimmers on 10 lights. Several motion sensors. Two multifunction sensors, two garage door sensors, etc. maybe 1/3 of my switches are z wave, the rest the stock non smart kind.

I will look at the HA implementation to see what they do.

Until then, this bridge software is definitely the way to go. If HA has big latency, this bridge is a better way to go. IMO.

andrewsayre commented 5 years ago

Take a look here https://smartthings.developer.samsung.com/docs/guides/smartapps/basics.html

There is a mechanism to receive webhooks, which is part of the new SmartApp/Automation construct. This is what the HASS integration uses in conjunction with the API.

mschwartz commented 5 years ago

Yeah, I saw that already. The problem is I don't want to open an HTTP port on my home LAN to support the web hooks.

This is one of the sillier things I've seen in all the cloud IoT services. I have an Amazon Echo in my house. To add/create commands through Amazon, I have to open an HTTP port. Now for this new API, same thing.

1) Instead of simplifying things, that server at the open HTTP port has to be secured and made more and more complex as more cloud services want to post to it (e.g. provide SmartApp and Alexa, and whatever future, web hooks).
2) I have an Echo and ST Hub on my LAN already. They can talk to every device on my LAN, as long as I don't have firewall rules blocking them. Why don't THEY do the HTTP to my webhook server behind my firewall from the device? The Echo and ST Hub are already communicating with their respective clouds... 3) THIS bridge does exactly what #2 says should be done. To configure, I put the MAC address and local LAN IP in the configuration dialogs, not some public IP with an open http port.

I might be pretty good about hardening and securing a server I expose to the hacker infested internet, but not a lot of "regular" users are.