Local Execution - LAN Control

I do not see any documentation in the new platform on LAN Control/local execution of WIFI devices. I see local execution support announced in the update to legacy platform → Announcement | Changes to our Legacy SmartThings Platform. Only documentation I can reference for LAN Control is from the legacy documentation → Division of Labor — SmartThings Classic Developer Documentation

Should I follow the legacy documentation - using SmartApps and DTH for LAN control or is there another mechanism for it that is not yet documented?

Will the legacy flows be supported down the line or deprecated?

Hopefully others with much deeper knowledge than me will chime in, but I did just want to make sure we’re all talking about the same thing here.

The “Local execution“ referred to in the document you link to has to do with the hub communicating directly to the device. So far so good.

However, the code which instructs the hub to communicate to the device ran in the smartthings cloud. Not locally on the hub. From that same document:

After the end device receives the multicast M-SEARCH, it is supposed to issue a unicast search response , delayed by a random number of seconds between 0 and MX (4 in this case). The search response sent from the device back to the Hub should look something like this:
HTTP/1.1 200 OK CACHE-CONTROL: max-age=100 EXT: LOCATION: SERVER: FreeRTOS/6.0.5, UPnP/1.0, IpBridge/0.1 ST: urn:schemas-upnp-org:device:ZonePlayer:1 USN: uuid:RINCON_000E58F0FFFFFF400::urn:schemas-upnp-org:device:ZonePlayer:1
This will get routed back to the cloud where it will be converted into an Event that will fire the ssdpHandler method with the following description:

*(Emphasis added)

The smartapp shown in the page you link to also runs in the cloud.

At the present time, no custom code can run on the hub. Whether it’s a device type Handler or a smartapp. Instead, they run in the legacy groovy cloud which sends instructions to the hub.

Why this all matters is that most people use the phrase “local execution“ to mean “will run even if the Internet is not available“ and that is not true for the legacy pages you linked to.

There was an exception for two SmartThings developed integrations, Phillips hue and Sonos, but Those were a special case based on an agreement between the two companies. Not your typical developer contribution.

You may have already known all that, I just wanted to mention it, to make sure there wasn’t any confusion over what could “run locally“ on the legacy platform.

You could tell the hub to monitor the local network, but you still need the Internet to get to the cloud piece which will decide what to tell the hub to do.


Thank you for the explanation. I understand the ‘local’ part in legacy platform.
Is my understanding of ‘local execution meaning it will run even if the Internet is not available’ true for what was announced in the new platform? Do we know if this is something that will be publicly available outside of explicit partnerships?

They haven’t yet announced anything that would allow custom code to operate without the Internet. Whether that will be possible or not someday is as yet unknown. The next step is to allow at least some of the rules API to run locally, but we aren’t even there yet. Also, the app requires the Internet because it goes through the smartthings cloud, and they haven’t said anything about plans to change that architecture.