Cloud or Local execution of code on the Hub

Hi all,

I am completely new to SmartThings and just doing a bit of research into it first. I was reading the documentation and there seems to be a lot of mention on the cloud and using AWS lambda. I was wondering does SmartThings allow you to program and run code locally on the hub?

In the documentation automation’s are described as " An example of an Automation is a WebHook or AWS Lambda function that uses the SmartThings REST API to control and get status notifications from SmartThings devices."

Is there an alternative instead of going through the REST API for communicating directly from the hub to the devices? Say I have a Z-Wave smart plug connected to my SmartThings Hub, can the Hub execute scripts/automatons locally to turn on/off this smart plug based on certain conditions I define?

Any useful links/help is welcome!

Thanks

EDIT

I do see in the rules portion of the documentation it mentions “In a future release of the API, local execution of rules on the SmartThings hub will be supported, making rules a great choice for those looking to create fast, stable and secure automations.” Any information or updates on this?

Not as such, no.

Yes and no and sort of.

You don’t explicitly differentiate between cloud and local execution when working with SmartThings. You just use SmartThings. Currently if you happen to work with a particular app that has some of its logical rules implemented in the hub, and with particular devices that have their device handlers implemented on the hub, and you use that app, those rules, and those devices, then the code will end up executing on the hub rather than in the cloud. This is transparent to you though.

As ST phase out their legacy architecture they will be able to introduce more stuff that will run locally but there is no indication that they plan to make this anything more than incidental. It is more a case of providing higher level APIs to work with. If you use those then you may gain the benefit of local execution. If you want to do something more custom you’ll probably be hosting it yourself and ST will just be providing low level services.

I suspect I’ve not explained that very well but I’m sure someone else will take a crack.

1 Like

Hi Graham,

Thanks for the reply.

So I cant tell certain devices/rules/apps to communicate directly with the hub, I just have to choose ones that already do? If so is there anyway you know how which ones do and which ones don’t from your experience?

If most devices are reliant on the cloud to operate, if there is a network error and communication to the cloud is lost, does every device to your knowledge stop operating or is there any hand off to the hub for local control? Say there is maintenance going on and cloud services are down can you not use your devices?

Only hub connected devices (read: zigbee / ZWave) that use Samsung provided device handlers (because they are loaded intonthe hub firmware) are eligible to be running locally. You can determine which devices you have and where they’re running by logging into the IDE at https://account.smartthings.com and choosing the devices tab in the menu on a mobile browser or tab on desktop.

You read correctly that thd rules API will eventually become the local execution arm.

Currently local automation is restricted to the Smartlighting smartapp and only when in conjunction with devices that run locally.

When a device uses cloud execution and the cloud is not present, automation of those devices cease until the cloud returns.

1 Like

Hi Nathan,

Thanks for the reply.

Just to be clear so I can set up the device to connect locally to the hub this way but automation scripts are not stored locally on the hub and not executed locally on the hub for this device?

So the only combination of both local hub automation and local hub connection that smartThings offer is smart lights that use the Smartlighting smartapp and use Samsung provided device handlers?

Correct the only combinations that run/store automation locally are local capable direct connected devices (that sounds limiting until you take a look at all the default device classes available - most zigbee / ZWave devices fit into one of tje classes) usong either the SmartThings Smartlighting smartapp or certain portions of the execution portion of SmartHome Monitor (SHM) in the classic app. Considering Classic is currently in process of being retired, I wouldnt consider that option as valid anymore and only say Smartlighting at this point.

You can design your setup around these limits and have a perfectly well functioning system when the Internet is down, use smart switches instead of bulbs, use ZWave or Zigbee devices and stick to thd default Device Handlers except for specific purposes, and use Smartlighting for automations that must function when the Internet is down.

There are known plans to move a lot more local, but they gave to get through this Classic to NewApp migration first to clear out a lot of old code to make room for the new.

I’ve noticed that one particular SmartApp (that runs on multiple target devices) are often slow to respond. These are smartapps I’ve written. I’m guessing that they’re running in the cloud. I’m wondering if there are settings on my home internet router that might interfere with delivery of messages. Are there ports I need to keep open or internal routes I need to set up to ensure delivery of SmartThings cloud messages?

ALL smartapps run in the cloud. (Except Smartlighting and SHM before it was killed off.)
If your hub shows online - you’re fine. It’s something else. Cloud response times have been all over the map for a few months. SOOO…

So what’s the Smartapp?

Also when I originally responded last August, Smartlighting WAS the only way to do local automations. NOW the automation creator can create local automations IF you have the 35.x firmware and are in the local automation beta program.

So when I wired my home (1990s) pre-X10, pre-Zigbee, pre-yeah… you get it. I put in low voltage relay lighting to control all the lights in the home. As home automation has matured, I have had to build different interfaces between the various systems and this relay lighting.

Three pieces in this particular implementation:

  1. I have an Arduino that does SmartThingsàrelay control. It has its own device handler modeled after some things Dan O.

  2. Then I have virtual switch that is, well a really boring virtual switch. Just On() and Off().

  3. Finally I have a smartApp that sees an event on the Virtual Switch (2) and sends message through the device handler (1) to the Arduino.

Of course, automations can act on that Virtual Switch as well. When there is motion on the Front Porch, turn on the light. Or whatever.

This has all been working for months, but about 4 weeks ago it started being really goofy. I figured I had a component fail and did all kinds of troubleshooting. Instrumented the heck out of everything to send stuff to logs. In the end, I’m convinced my local Arduino is not getting messages from ST, or is getting them late.

I haven’t made the transition to the new dev world for ST.

I’m trying to convince my wife that she should learn it for me!

Paul

What’s the DTH you are using for the virtual switch?

I ask because there was a platform change in that timeframe and the stateless virtual Switches started getting goofy. Many people had to change to the “simulated switch“ DTH in order to get things working again.

Not sure if that’s relevant, but just thought I would mention it. This was an undocumented platform change, and we’re still not entirely sure what happened, just what the workaround is.

1 Like

Oooh. Interesting. I had built my own virtual switch… or modified someone else’s

Are you just referring to the simulated-switch that’s in the git for SmartThings?

https://github.com/SmartThingsCommunity/SmartThingsPublic/blob/master/devicetypes/smartthings/testing/simulated-switch.src/simulated-switch.groovy

If so, I might be able to use that. Are there any untouchable parts that make that Simulated Switch somehow like the virtual switch DTH?

Paul

Not sure what you mean by “untouchable parts“, but yes, it’s just another kind of non-physical switch. But it does have state, that is it is either on or off. So you will have to do something to turn it off in order to make it ready to use again.

I typically just use “power allowance“ in smartlighting to have the switch always turn itself off again after one minute, that works well enough for me, but you might need some other method.

Thanks all. To be clear, the simulated switch DTH you’re talking about is the one that is in the ST Git, correct? Just want to be sure I’m not missing the point.

This one:

OK. Got it. Thanks. I suspect that it that pull down maps to the DTH definitions in the Git Repository. I need a peek under the covers to adjust my SmartApps to call the right method names when I get feedback on relay positions, but this sends me in the right direction. Thanks for the pointers. I’ll let you know what I learn.

–Paul

1 Like