New Smartthings restful API about smartthings-mqtt-bridge

[andrewsayre]

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]

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]

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]

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]

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.