Hub Firmware Release Notes - 18.18


Some things are processed locally. Typically devices using stock handlers for example. Smart Lighting smart app runs local.

(Dave) #341

ST seem to have strict rules on local handling. Devices must be on their approved list and they must use stock device handlers. I thought my devices should comply, but I think it’s the none-stock handlers that are causing some of my devices to run using the cloud


At the present time no custom code of any kind can run locally. Routines do not run locally. Disarming/arming smart home monitor does not run locally. The SmartThings mobile app on your phone cannot talk to the hub locally. Anything using “sunrise” or “sunset” times cannot run locally.


Automations created through the official smartlighting feature are eligible to run locally as long as all the devices included in that automation use device type handlers which are available to run locally. And there’s a very small part of smart home monitor which does the same.

There’s no official list of which device type handlers run locally, but there is a community FAQ in this forum:

Note that it’s not enough to just be an official integration or even just a stock device type handler. For example, nothing that references a Hue bulb which is attached to the hue bridge can run locally in this sense. It’s just a specific set of stock device type handlers.

So how useful is it? It just depends on what you have set up. You could certainly have SmartThings brand motion sensors triggering GE zwave light switches set up with the official SmartLighting feature and it would continue to work even if your Internet had gone out. But it’s definitely a limited set of devices and features. :disappointed_relieved:

Further community discussion in the following thread:

(DavidK) #343

I have around 96 devices with only 25 or so that run in the cloud.

So I have designed my system around using as much local processing as possible.

Yes, I wish Smart Things had more devices that work local, but for now I work within the limitations of the system, and for automations which are time sensitive or reliability is important I design the automation around local processing supported devices.

Example of time sensitive/reliable required automation, turning on the lights triggered by opening the basement door; if the door open close sensor takes too long to turn on the lights, I might as well use the light switch, and if I start walking down the stairs without lights, it can be dangerous.

For this application I would use an open close sensor that runs local, like a Smartthings multi-sensor or an iris open/close, these will turn on the basement lights instantly, every time!

Same thing for front bathroom and laundry and some other rooms. Open the door and the lights go on instantly, every time, regardless of the state of the smartthings cloud.

I use the ecolink tilt sensor on the garage doors. I have one zwave and one zwave plus tilt sensor. The lights are triggered on by the tilt sensor and they work instantly every time.

I have found that zigbee devices inside the house are VERY reliable, but inside the garage zigbee is mostly NOT reliable and zwave is mostly reliable.

I think that metal in the garage causes reception problems.

In fact it seems that reliability of devices within the garage changes whether the cars are inside the garage or not.

Placing a zigbee repeater in the ceiling of the garage did NOT help, so I assume that it is reception problems with walls and metal and not a distance issue.

(Joe) #344

On 18 or .20 which I’m in all switches and sensors are local. If you use their dth.

(Joe) #345

More things show local on my ide then cloud now. As I have allot of wall switches and sensors. Probably 100 combined. I have 156 total devices now I believe.

(Joe) #346

But with all that said even local my switches keep dropping along with my locks and garage openers. It’s very frustrating and hope they get it fixed as usually a reboot fixes it but it almost daily. .20 is a little better but not ready for the masses.

(DavidK) #347

@joewom and all the others with devices that drop off, have you, each of you, filled support tickets? What did they say?

Are they aware of your specific issue?

It’s possible that there are multiple unrelated problems that all need fixes and without sending in specific requests maybe they do not know about all the issues?

Having devices drop off of the hub is horrible!

They are aware of the xiomi button issues, i think from reading these forums, are they aware of any other issues?

(Joe) #348

Absolutely why I signed up for beta to help others. I have sent about 6 emails or more to they are well aware.

(Tony) #349

Anyone could recommend a device handler for Osram lightify bulb that can run locally ???
Ideally with colour, dimming and white Temp control?

This is the key for me, as I would like to be able to, at least, control my light when off line, as a minimum requirement !!!

Currently, on FW 18.18, my hub disconnect once or twice a day randomly for 10 to 20 minutes at a time… (and the broadband/internet connection is fine…) This is particularly annoying when this happen in the morning at breakfast as we have to have breakfast in complete darkness, using flashlight !!! My lady is far from impressed with this!


Have you tried the “GE Link Bulb”? Works on the IKEA bulbs for local

(Realy Living Dream) #351

I would flip the light switch to powercycle the bulbs on before I fumbled around with flashlights.

New with 18.20 is that " no load" switches and SmartTiles panels are NOT being updated with proper change of state. Example I open the cellar door and cellar lights all come on, I come back out of the basement and both the GE no load ZW switch that groups all the cellar lights and the Cellar lights tile on control panel are not showing the lights as on. So I need to turn the switch on, before I can turn light off.

Other thing I’m noticing is GoControl/MonoPrice ZW motion sensor & Fibaro G5 are showing motion, yet the SL rule to turn on GE ZW plug that controls porch lights in NOT firing.


Have you reported these issues? Thanks for calling it out here.

(Dave) #353

I’m now at version 18.21. No advance notification from ST. Just an alert telling me the hub had gone down and to check internet connection. Fingers crossed no issues…

(Nick Stevens) #354

All - there is an update going out for users currently on 18.18. We found a critical bug with the ZigBee firmware and decided to make a push-then-notify. A followup email will be coming soon.

(Bob) #355

Hi @nastevens.
I’m on 18.20 and today, after a power cut, a Hue motion sensor and then all my Xiaomi sensors (yes I know there may be more going on with the Xiaomi’s) are having issues.
I cannot do anything with the Hue.
Could this be related to the ZigBee firmware bug?
If so, please, please, please update my hub ASAP.
I’m having to re-educate the family how to push switches etc. :slight_smile:

(Dave) #356

Thanks for communicating the update

Have you reduced 3 axis reporting from ST multi-sensor (to preserve battery)?

(Mark) #357

Cheers Nick!

Could you please give a little more info with regards to what it fixes please. Greatly appreciated!



(Nick Stevens) #358

That sounds a lot more like general ZigBee network problems due to a missing/lost router, possibly due to the power outage. You might be able get them back by doing a factory reset of the devices and then re-adding them to the Hub. Note that you don’t need to do a “remove” from the SmartThings app, so you won’t lose automations.

(Nick Stevens) #359

It was a roll-back of the ZigBee radio firmware update we deployed in 18.18. We identified a problem that could very rarely cause the loss of all ZigBee network settings, and haven’t been able to get to true root cause. We’re working with the radio vendor to figure out what’s going on, but because of the severity we decided a roll-back was prudent.