Actually, what would be nice is for everything to run locally all of the time, except for things like cloud-to-cloud integrations. That was the original promise from ST for Hub v2.0 when it was released. Almost 2 years later and the exact same SmartApps (Smart Lighting and tiny bit of SHM) are the only apps to run locally.
It would also be very nice if your phone is on same network as your hub, for it to communicate directly instead of having always go through the cloud.
[UPDATE] For those reading this fairly old comment, I actually did find a solution to my ideal home automation local processing platform in the form of Hubitat Elevation. Great little hub, which keeps your data private and runs all groovy code locally.
XOh Smart Home Monitor, I know about it. But my mind don’t link the abbreviation.
But wait! That could be an answer to my idea. If the ST will insert/include a condition like “if internet OFF” then I could trigger a SHM routine where I could use only confirmed locally devices…
But for that, we need an “internet status” condition inserted into SmartThings.
I agree that it would be much more useful if we had many more device handlers and smartapps that were capable of running locally in the first place.
All due respect to the OP, I think it would be a waste of time for ST staff to work on adding this functionality. It would make so much more sense for them to devote their resources to making local processing actually work, period.
It’s an interesting idea, but over the last two years since local processing was first introduced for SmartLighting and a small amount of SHM, it’s become clear that expanding it in any way is just not a high priority for the company.
This has to do with the SmartThings architecture. Anything which is going to be run locally has to be updated in firmware and sent to every customer of the company. That’s why so few things run locally. Even routines don’t run locally because customers can create their own routines.
If you need more local processing with the ability to do your own custom programming, look at Indigo, Vera, Homeseer or Openhab.
If you want more local processing just to get greater stability you can look at HomeKit or even Wink.
But if you like the flexibility and power of the SmartThings platform, I’m afraid we’re stuck with a mostly cloud-based platform for the foreseeable future.
You can see more discussion in the following thread, but remember that regardless of what the company has said they hoped to do, what they have delivered is local processing limited to just SmartLighting.
There is no switch. The limited local processing occurs whether or not the hub currently has an active internet connection. Obviously if the hub has lost internet connectivity, then the local processing is all that occurs.
Since local processing seems to be important to you (based on your other posts on the same subject), I suspect you will be disappointed by the pretty minimal capability that the ST hub has for local processing.
The Z wave standard allows for the possibility of multiple controllers on one network, but one controller is the primary and any others are “secondary.”
(also, for the purposes of this note, I’m going to assume that you meant “Openhab,” a popular open source platform often used with Z wave devices.
If by chance you meant something else, we would need to know more about that particular platform.)
A. SmartThings as a Primary Zwave Controller
So far, so good. the problem is that while the SmartThings hub does contain a certified Z wave controller, it is a multiprotocol platform, and of course most of your processing runs in the SmartThings cloud, and so it just doesn’t play nice with other zwave controllers.
If SmartThings is set up as the primary Z wave controller, You can add another controller device like an Aeotec USB stick running on a laptop, and have that other device be a “secondary.” But only for Z wave. And SmartThings does not support all of the advanced zwave options for controller management, like controller shift.
All of which means that your secondary has to be smart enough to continually request new information from the primary, and also you can’t switch back-and-forth between which one is the primary, which is something we do for some use cases.
use case 1: SmartThings talks to the secondary, and the secondary is part of a platform which can talk to some end devices which are invisible to smartthings
So what would you get from having another Z wave controller on your network acting as a secondary?
It really comes down to specific use cases. Most commonly if the other controller is part of a system which happens to have additional protocols that SmartThings doesn’t have, you might use it so that you would have a total system where your Z wave devices could act as proxies, like virtual devices, and you could get some control from SmartThings over some of the other protocol devices that way.
For example, openhab works with EnOcean Devices if you have the right plug-ins and antennas. Smartthings does not have any way of talking to enocean devices.
So if you had a group of switches in one room and four of them were Enocean and one of them was Z wave, and you always wanted to treat them all as one group, it would likely be possible to add a Z wave controller that works with openhab and have that controller be a secondary to your smartthings hub and add just the Z wave switch to SmartThings and then when you turned on that Z wave switch from SmartThings, openhab would also turn on the Enocean switches.
You would never actually see the Enocean switches as things in your SmartThings account, but you could set up some automations where the end result would be those switches going on and off.
We do have some community members who have done stuff like that with both vera and with the staples hub.
The main problem is that because SmartThings doesn’t support all of the advanced controller options, it can get very annoying as you start adding additional Z wave devices. In some cases you will have to completely remove the secondary and then completely re-add it in order to get the new device information.
But it is an option that works for some people in some situations.
use case 2: using utilities that the secondary controller has that smartthings does not
For reasons that have never been fully explain, but that probably go back to that multiprotocol issue, smartthings does not provide customer-facing network mapping utilities for its Z wave network. But if you add a secondary, most commonly an Aeotec zstick, you can use the secondary’s mapping utilities to see your entire Z wave network. There are community members who have added a secondary just for this purpose.
Use case 3: run the secondary locally if the internet is down?
To be honest, I have no idea if the secondary Z wave controller can continue to operate locally if the SmartThings cloud is not available to the smartthings hub acting as the primary zwave controller.
Theoretically, I would think that it would. Just as a Z wave direct association will work even if the SmartThings cloud is not available.
But I have learned with SmartThings not to assume that reality will follow theory.
I have not heard one way or another from anyone who has this kind of set up whether their zwave network from a secondary controller continues to operate fine if the SmartThings cloud is not available. Hopefully someone who has tried it can let us know.
So all I can say at this point is that it’s possible it might work, but someone would have to try it to know for sure.
Conclusion: SmartThings as zwave primary, OpenHab as zwave secondary
So you could have SmartThings as your Z wave primary controller and openhab running an Aeotec zstick on a laptop as your Z wave secondary controller and both would have access to the Z wave devices that were connected to SmartThings at the time that you added the zstick to your network as long as the SmartThings hub was running as expected.
You can’t run the openhab software on the SmartThings hub itself. You have to get a completely separate Z wave controller Device, again, most typically the Aeotec zstick, and then add that device as a secondary to your SmartThings Z wave network.
As far as what you would get out of that, some additional utilities and maybe the ability to do some indirect integration with some devices of other protocols.
What I don’t know is whether you can get any additional local operation that way. I know that custom code device type handlers would not be available if the cloud is not available, because they are not loaded into the SmartThings hub itself. So I have no idea how the secondary Controller Will work if the primary can’t reach the cloud. Again, I hope someone who has tried it and tell us more.
B. OpenHab as primary, SmartThings as secondary
Smartthings cloud architecture just doesn’t make this work well. In fact, SmartThings now has an official support statement that says they will not help you if you try to use the hub as a secondary, which is never a good sign.
SmartThings strongly discourages adding the Hub to another Z-Wave network. We cannot offer support for disconnected Z-Wave devices or the inability to add devices through the Hub as a result of including the Hub into another Z-Wave network.
I know there are a few community members who have added a SmartThings hub as a secondary, most typically to a security system, but they are only using it for pretty simple stuff, usually control of lights, and in general I think this is not going to work as expected.
Sorry that answer is so long. The multiprotocol aspects of the SmartThings platform, and in particular, the cloud-based architecture, just really complicates this issue.
If you want to try it, you should try adding your openhab device as a secondary, and see what happens. But the results may not be satisfactory, and you should be prepared to completely rebuild your openhab network from scratch if necessary. Maybe even a couple of times. So it’s not going to be a smooth or easy set up.
Thank you, that no good if you lose your internet connection, you lose everything. May I’m switching to some hub is capable, to use local prossissing not cloud prossissing, specially for safty and security
The reason I originally started with lighting automation (back in the X10 days) was the simple desire to never come home to a dark house-- as long as the power is on, I want a few lights on during the evening. Part convenience, part paranoia; it has always been a priority, especially for security when no one is home. Moving to a cloud based system introduces lots of ways to derail this.
If your backup needs are simple and you don’t really need a second hub, but just want to have a few devices that can be scheduled or turned on/off independently of the cloud, a $9.99 device like the Intermatic Zwave Master Controller is a cheap way of providing local on/off control and several light timers (with optional sunrise/sunset scheduling) without requiring internet connectivity. When you ‘pair’ it with ST it learns your Zwave network config from the SmartThings hub; you can then assign a dozen devices to its on/off/dim switches and optionally program on/off times for them. Its on/off actions aren’t communicated to the SmartThings hub (so you can’t use it to initiate routines) but SmartThings/ActionTiles/etc. will see the change in state of the lights that it controls. If you have a few lights with fixed on/off schedules (or sunrise/sunset based on/off times) it could prove useful as a backup. It’s homely, comparatively low-tech, but I have found it very useful. https://www.zwaveproducts.com/shop/brands/intermatic/z-wave-master-controller-with-timer