Automations versus apps

[SoNic]

This is my first contact with Smartthings and I need help understanding something.

I have a Honeywell thermostat - TH9320WF5003WW1. It is connected to my house WiFi, has been recognized by ST and I managed to create an automation Using mt Samsung S21 phone).
But that is running in the cloud.
I though that, if I buy the Samsung WiFi hub, I will be able to transfer that automation easily on the hub and run locally, independent of my Internet connection. Well… it seems that I was wrong.

I tried to see if I can easily re-create that simple automation with code (that I assume will run on my hub, but I can’t find an easy IDE to do that.
More, that automation is visible only on the ST app on my phone, not on the online website.
So at this point, what’s the purpose of a hub, if there are no easy to use applications or development? Am I missing something here?

[orangebucket (Graham)]

Many home automation and control devices work on private networks using Zigbee and Z-Wave wireless technology. The hub acts as a controller for these networks and links them with the SmartThings cloud. There are also Wi-Fi/Ethernet devices that can be controlled directly across your home network instead of their connecting to dedicated servers in the cloud. The hub gives SmartThings the ability to communicate with them over your home network. If you don’t have any such devices you don’t need a hub.

The hub also has a limited, but growing, ability, to run some automations on the local hub so they work when the internet is down. Obviously this will only be for devices that are connected directly to the hub and for other things the hub can determine for itself without contacting the cloud. This isn’t something you get to decide. If things can be run locally they will be.

Currently, the public presence of SmartThings on the web consists of a the IDE and the Developer Workspace. The IDE is part of the legacy platform that still powers device handlers and some apps but is blissfully unaware of things like Automations. Although limited as far as IDEs go, it really is about supporting development. The Developer Workspace works with the current platform and is largely a front end for the REST API under all the bluster. Neither are about day to day administration and control - that is what the mobile apps do.

[SoNic]

@orangebucket

If you don’t have any such devices you don’t need a hub.

Thanks! I guess this was another impulse buy from my part, not researching completely the problem before.
The thermostat is shown in my phone ST app as “direct connected device”. Probably because of the TCC app that I have installed for it?
Is not attached to the Samsung hub, but I can see it in ST web page for my devices. That was what confused me.

@orangebucket

…but is blissfully unaware of things like Automations.

That was another confusing thing. I can see the automation on my phone’s ST app, but not over the web.

[SoNic]

[orangebucket (Graham)]

@SoNic

The thermostat is shown in my phone ST app as “direct connected device”. Probably because of the TCC app that I have installed for it?

Possibly. I’m not familiar with either the device or app. Generally speaking devices are described from the point of view of the ST Cloud, so devices connected to a third party cloud are ‘cloud connected’, devices connected to the hub are ‘hub connected’, and then you get ‘direct connected’ devices which communicate directly with the ST Cloud using MQTT. The latter are usually MCU based devices but I guess they don’t have to be.

However SmartThings do have a healthy track record for using the same terminology for two different things, and in the app ‘direct connected devices’ seem to be ones the app itself can talk to. Mine shows the tele and a number of Bluetooth devices, none of which I seem to be able to anything with in SmartThings apart from some very limited direct control in the app.

[JDRoberts]

SmartThings is still primarily a cloud based system. A few things can run locally, but not many, and nothing that requires custom code. They keep promising that there will be more local operations in the future, but they’ve been promising that for six years now and we aren’t there yet.

In a smartthings system, the purpose of the hub is to provide a zigbee radio and a zwave radio in order to communicate with devices of those protocols. The hub is not needed for communication with Wi-Fi devices. Those either communicate to their own cloud which then sends messages to the smartthings cloud (“cloud connected“ in smartthings terminology), or in a few cases can communicate directly to the smartthings cloud via Internet (“Direct connected“ in smartthings Termanology).

You can’t write your own code and have it run on the hub at the present time.

You can write your own code on your own server device and communicate to the smartthings cloud, which is the future model for custom code.

Under the old model, you could write some code in groovy and smartthings would let you run it in their cloud, but that’s going away sometime this year.

So, yeah, it doesn’t run the way you thought it did. And you don’t need a hub at all unless you want to run zigbee or Z wave devices.

If you want a hub that can run your own code, look at Hubitat or Homeseer or Ezlo vera. Every system has its own pluses and minuses, but those all offer more options to people who want to run their own code locally.

[JDRoberts]

btw, Samsung is so UNcommitted to local operations that they developed one of the few WiFi routers ever that requires the Internet in order to run the local WiFi. That’s…weird. It’s not how most Wi-Fi routers work, not even WiFi mesh.

And regardless of which smartthings hub model you have, the app can only talk to the hub if Internet is available to both and the smartthings cloud is operational, even if they are on the same local Wi-Fi. They didn’t have to design it that way, but they did.

[TonyFleisher]

@JDRoberts

The hub is not needed for communication with Wi-Fi devices. Those either communicate to their own cloud which then sends messages to the smartthings cloud (“cloud connected“ in smartthings terminology), or in a few cases can communicate directly to the smartthings cloud via Internet (“Direct connected“ in smartthings Termanology).

While this is generally true, there are a few cases where the hub communicates with local network connected devices like the Hue bridge.

[prjct92eh2 (Jimmy)]

I think Sonos and Hue are the only two wifi device that communicate through the hub at this point.

[SoNic]

@JDRoberts

And regardless of which smartthings hub model you have, the app can only talk to the hub if Internet is available to both and the smartthings cloud is operational, even if they are on the same local Wi-Fi.

I was afraid about that. Like my Honeywell thermostat talks to the Honeywell cloud and that talks with Samsung Smartthings cloud? Then from there goes back to my phone apk?

That’s… money making source in the future like the IFTTT?

@prjct92eh2

I think Sonos and Hue are the only two wifi device that communicate through the hub at this point.

So… it’s a business limitation. Thanks!

[JDRoberts]

@SoNic

Like my Honeywell thermostat talks to the Honeywell cloud and that talks with Samsung Smartthings cloud? Then from there goes back to my phone apk?

Yes, that’s the basic model for “cloud to cloud“ integration, which is most third party WiFi devices. As others have mentioned, there are some options for creating an MQTT integration for a simple WiFi device like a switch that can go directly to the smartthings cloud.

And, as @TonyFleisher and @prjct92eh2 said, there are special integrations which were created for the Phillips hue bridge and Sonos which do allow for a Wi-Fi device to operate without going through the smartthings cloud: but that doesn’t change the fact that the smartthings app still has to go through its own cloud. Sigh.

So if you want to set up a rule where your Hue lights turn on when a smartthings – connected motion sensor detects motion, you can make that run locally. But only if you have a smartthings hub. There’s also an alternative hue/smartthings integration for a hub optional configuration that goes the normal cloud to cloud route.

So as always, it comes back to the first rule of home automation: “the model number matters.“

[prjct92eh2 (Jimmy)]

@SoNic

So… it’s a business limitation. Thanks!

hard to say. Some wifi devices don’t have a local API at all, so there is no choice but cloud-to-cloud. Some do have one, but SmartThings still uses cloud-to-cloud.

[SoNic]

@JDRoberts

the model number matters

LOL, yes.
BTW I have the aptly named “Samsung SmartThings WiFi”, the number is ET-WV525BWEGUS.

[JDRoberts]

@SoNic

@JDRoberts

the model number matters

LOL, yes.
BTW I have the aptly named “Samsung SmartThings WiFi”, the number is ET-WV525BWEGUS.

If you’re still in the return period, return it. Aeotec hasn’t picked that one up yet, and it may be EOL pretty soon. Also, it’s just not a very good Wi-Fi router.

You may not need a hub at all if all you have are Wi-Fi devices or other cloud to cloud integrations.

If you decide you do want Z wave or Zigbee, either get an older smartthings V2 or V3 (hard to find, but available in some kits), or better yet, wait for the new Aeotec model.

https://www.amazon.com/dp/B08TWDNQ5Q