What still works if I lose broadband? (Or, if it’s easier, what stops working?)
Lighting Automations ?
That’s a really hard question(s) to answer because it depends heavily on what devices you have. If you have zwave/zigbee devices using stock handlers that are all local, and use something Like Smart Lighting that has all the devices in the automation local, that those should still run via the Smart Lighting rule - BUT, you won’t be able to control them with the mobile app. You actually won;t be able to control ANY device with the mobile app when your Internet is down.
There’s quite a few discussions around here already on what happens when your Internet/power goes down.
2 Likes
What Doesn’t work: control by app or automation of any device NOT using a device handler capable of running locally on the hub (See https://account.smartthings.com > My Devices : Sort by Execution Location)
Only Samsung provided default device types are allowed to run locally on the hub - so if you installed custom code to make your device run, it’s Cloud.
The SmartLigthing SmartApp is capable of running locally and will control devices locally IF they are also capable of running locally.
SOME portions of the old Smartthings Home Monitor (SHM) app, specifically concerning leak sensors and sirens.
As @johnconstantelo mentioned - local control includes preset automations, but the App wouldn’t be able to connect to the hub so it can’t send commands.
Pretty much anything else doesn’t.
How this plays out in real life:
Case 1, I have Dome water sensors and a LeakGopher main water valve. If I use my Dome water sensor and LeakGopher devices with manufacturer provided device handlers, they are now Cloud devices and will not be able to alert or automatically close valves on detected leak if my Internet is disconnected. If I instead use the default Samsung provided Zwave Leak Sensor and Zwave Valve device types respectively, the leak detection module in SHM (Classic) CAN automate a valve close on water detection.
The system will setup with Samsung provided device handlers by default - UNLESS the end user added a custom device handler with a matching device fingerprint. So had I done nothing, it would run local by default.
If I like to use all the features of a device (Say, for instance, I wanted to modify the onboard alarm behavior of the Dome device) I can install the Dome device handler. NOW that device is no longer local (And any subsequent devices of the same type will also default to that custom code because of a ZWave fingerprint match) until I change them back to the default device type manually.
I think you can see the pro’s of using the default handlers in this scenario. I’d like to keep my kitchen cabinets intact.
Case 2, I use RBoy’s custom lock device handler and SmartApp because I can get advanced management for users on three locks in my system. But it’s not a big deal that it runs in the cloud, because I can still unlock the lock by hand with the keypad without the cloud, and my DSC alarm panel is still accessible inside the house with a 60 second delay timer. What I lose without the cloud is successful code entry on teh lock ALSO disarming the main security system. What I gain with custom code is the advanced lock management features - and it’s worth the exchange. That said, I specifically chose devices that still worked with their own onboard self contained logic and operations in absence of the Internet.
It’s a delicate dance. Do I want custom capabilities, or do I want local execution? I play that game every time I add a new device to the setup.
It’s better in the post Groovy days, the Samsung team is providing more default DTHs that run locally every update for more device types and future updates and the Rules API appear to be geared at more local execution but as you mentioned in another thread - it’s just not here yet.
Hope that made it as clear as mud. 
3 Likes
That’s very useful information. So the key is whether the required handlers can run on the hub.
Supplementary question: The Smartthings (RESTful) API is a cloud based api, isn’t it? Is there any way to talk to the hub directly on the home WLAN?
1 Like
The hub can issue HTTP commands (and receive the requests from same - think polling)
I use this through WebCore to command a tablet running Fully Kiosk (accessible through a REST API) one of my custom devices makes use of this to communicate with an RPi running a Python script called AlarmServer to interface with my alarm system.
It can, of course fully participate on Zwave and Zigbee networks it is a controller for.
I do not believe it can accept unsolicited messages nor can it perform telnet or SSH commands.
It’s more than that. The SmartApp must be capable of running locally, and there are very few of those right now.
1 Like
SmartThings is primarily a cloudbased system. They didn’t have to design it that way, but they did.
As of this writing only some of the automations created in SmartLighting and A few of the automations created through smartthings home monitor can run locally. Everything else requires an Internet connection to the smartthings cloud.
You can’t even change the location mode from “away” to “home” without the cloud.
You can’t arm or disarm smartthings home monitor without the cloud.
You can’t run any custom code without the cloud.
The official Geopresence feature will not work without the cloud.
Notifications, even push notifications to your phone on the same Wi-Fi network as the hub or SMS notifications, will not work without an active cloud connection. All notifications are issued from the smartthings cloud, not from the hub or the app on your phone (With the exception of the ADT/smartthings dual logo panel which has its own cellular communications. However, that model is in “end of life“ status and in any case its notifications can only be used with a paid ADT contract).
And the app cannot communicate with the hub without going through the smartthings cloud even if they are both on the same WiFi network.
Also, you cannot create any new rules or edit any existing rules or scenes without the cloud.
Again, they didn’t have to design it that way, but they did.
While it’s true that zwave or Zigbee devices Connected directly to the smartthings hub and using stock DTHs can run some pre-configured smartlighting automations, that’s not what most people are looking for in a Home Automation system.
If you do not think that you will have a consistent Internet connection, you are better off looking at some of the competitor systems which can do much more locally, including Hubitat, Insteon, Apple Homekit, or Vera.
2 Likes
It’s a strange design choice. I wonder what motivated it. So we have our homes nicely covered with a Zigbee or Zwave network, and they cripple it with a trip over broadband, even to another country or continent and back.
I wonder what the insurance companies make of it.
I wonder if Samsung will ever sell my data or use it for other purposes internally.
True to form though:
a) take cron and deploy 80% of it’s power (/schedules endpoint)
b) take boolean algebra and deploy (less than) 80% of it’s power (/rules endpoint, Automations)
c) take a mesh network and cut it off from itself at the hub
They don’t care. It’s never been a UL listed product for either security or health monitoring, so as far as I know there’s never been an insurance company that offered discounts for any version.
(Again, other than the ADT dual logo line which is now end of life as ADT ended up buying their own DIY home automation system, now known as “ADT blue.“.)
I wonder if Samsung will ever sell my data or use it for other purposes internally.
The company is legally required in the US and the EU to reveal that information in their terms of service and privacy policies, so you can just look it up.
https://www.smartthings.com/privacy
In addition to what it says there, though, the most important part in my opinion is the last paragraph:
Updates To This U.S. Privacy Notice
.
This U.S. Privacy Notice may be updated periodically and without prior notice to you to reflect changes in our personal information practices with respect to SmartThings. We will post a notice on the SmartThings app to notify you of significant changes to this U.S. Privacy Notice and indicate at the top of this Notice when it was most recently updated.
Laws in other regions are different so you should always read the one that applies to where you are.
But the short answer is that they haven’t promised not to and they have said they may change their current policies without prior notice, so it could happen.
From https://www.home-assistant.io/blog/2016/01/19/perfect-home-automation/,
YOUR SYSTEM SHOULD RUN AT HOME, NOT IN THE CLOUD
Looks like the author has a “let’s do it right” attitude rather than “let’s make it look as though it’s right”
There are multiple systems that run primarily locally and multiple systems that run primarily in the cloud. There are different pluses and minuses for each. It’s just a matter of finding one that will work best for your own needs and Preferences. 
I think it’s also important to remember the history of smartthings. Its founding CEO was not a technical person or intended it as a developer platform. He was a non-technical person who wanted an easy to use phone app that could work with off-the-shelf devices from multiple brands without his having to learn any of the technical stuff.
It was all about ease of use for nontechnical people, with very much a “black box“ approach so they wouldn’t have to know the internals.
Staff have posted in the forum more than once that their typical customer has fewer than 15 devices and never uses any custom code.
So it’s not really fair to compare it to A system that was designed for programmers to develop on, like Insteon or even Hubitat. Or Home Assistant. All of which have many more features aimed at developers but not as pretty of a phone app.
It’s not that one group is better than the other. They are aimed at different audiences.
It’s true that over the years a quite active developer community did grow, with power users creating some really imaginative and useful code, but that’s still not the target market.
So if you find it interesting and useful, that’s great, but if not, there are other platforms which provide a lot more features for developers. Like backup, restore, and the ability to defer updates. just sayin’…
3 Likes
@JDRoberts I think I understand that you are saying that Smartthings should be looked upon as a consumer platform, and as such I would have no complaints. There is a consistency, predictability and simplicity to the way the devices can be commissioned. As a consumer, I would have few complaints.
Having said that, the choice to cripple a perfectly adequate home mesh network by sticking a broadband connection in the middle is not confined to developer interest only. I wouldn’t pick up my phone to call my wife next to me at the dinner table. In some cases, that kind of architecture is needed. E.g. NASA, between mission control and space vehicles, but I hardly think that the Smartthings cloud is hosting much more that 80% of cron, and boolean algebra engine.
WRT the level of developer participation: basically, Smartthings need to decide if they want to engage with a developer community, and if they do, they should do it properly. That begins with the Getting Started path. It should get you started
https://smartthings.developer.samsung.com/docs/index.html
But, after clicking through a couple of circular paths to get started with SmartApps, you realise that it’s out of date (e.g. copy the public key from the Apps workspace page - there ain’t no public key anymore). The “tutorial” link has no tutorial. It takes you back to 2 samples, or you can choose to go straight to SDK. Basically, does anyone ever walkthrough what is effectively the landing stage for new developers, and actually check it?
I understand that Smartthings was not started out as X, but if they choose to make an offering in X, then it should be done professionally and honestly. A good start would be to put some effort into correctly documenting what it does, and making sure it does what is documented. That responsibility can’t be evaded by saying it started out as a consumer platform.
1 Like
The legacy system was designed this way to be affordable and the hub had very little processor/memory. You cannot look at those design choices through the lenses of what we have available today.
SmartThings had several technical founders and holds several patents these can easily be found with the USPTO
I agree, but this topic is forking into several different areas. If you want to start a new thread with specific developer experience issues I would be happy to move this conversation there.
2 Likes
Cool, thanks! I have corrected my post above. 
As of this writing, All custom code runs in some cloud, including custom DTHs. For hub-connected devices, such as a zigbee keypad or a zwave light switch that uses central scene commands, that’s the SmartThings cloud.
Also, any command that starts in the app goes through the SmartThings cloud.
Nothing to do with the rules engine.
This is very true.
SmartThings seemed quite revolutionary back when Samsung acquired them, mostly because their app felt very modern compared to almost everything else in home automation (except Nest), even much more expensive systems. It demoed beautifully in terms of press coverage just because of the screenshots.
I would argue that even the cloud piece felt 21st century at that time. Siri was clunky, but real, although you still had to push a button to get her attention. Amazon had not yet released Echo. The iPhone 5 was cool, but still limited.
But the press was all over the idea of the cloud. Netflix was approaching 50 million subscribers and streaming was gaining popularity fast. Roku was in its third generation. Facebook acquired WhatsApp and Oculus VR and posted over one billion in profit.
If your movies and your music and your conversations were all moving online, a cloud based smart home seemed to make sense, too. After all, Nest Thermostat sales were growing and they had just released their WiFi enabled smoke detectors.
Exciting times, and SmartThings was an exciting product. 
1 Like
Yeah, I agree, I’m actually looking at it from the glasses of a distant past! I believe the quote from Home Assistant founder was from 2016 ! From https://www.home-assistant.io/blog/2016/01/19/perfect-home-automation/ , and I retired about 8 years ago so I think my lenses go back even further than that!
And back then, reliable broadband was just as hard to obtain as local processing power.
It’s an easy excuse to make, but I think we have been aware of those design considerations since the first micro.
More constructively, is there a roadmap?
1 Like
Perhaps this was the kind of “reasoning” that gets us all into trouble so often. “cloud” has become a buzz word, and if something is in the cloud it means its good.
I was working on some ideas around 2000 about the “virtual” lifestyle where we wouldn’t actually own anything physical, but could just travel from place and place and pick up a compatible phone (this was before 4G and UK phones would not work in the US) from a local shop and just register it with the virtual cloud, or pick up a diskless laptop (like chromebook) and login to the cloud from anywhere and all the apps and data you own would just be there. In other words, my idea of a cloud was something that make would make space/distance disappear. Smartthings idea of a cloud is make sure we are aware that in between your motion detector and your nightlight is a trip to London and back.
1 Like
SmartThings legacy architecture is from 2013. The difference back then was that SmartThings was just something one could plug in and the “server” ran in the cloud. You don’t need to be a sysadmin to run SmartThings. Since 2013, things have changed and our architecture has changed. The goal is to move more stuff out of the cloud and into the hub.
5 Likes