SmartThings Community

Hub Firmware Release Notes - 18.18

When I see vibration. But don’t remember seeing around 10 data transmits for each event previously.

Ask smartthings support.

Don’t know. It seems it reports as long as there is vibration detected?

You can reset the sensor and see if it behaves the same.

There is definitely something still very wrong with the ST Multi Sensor, perhaps it is resolved with he .20 update but despite requesting it I have still not received it.

The original .18 update killed the battery on mine, the sensor kept going offline. Deleted and added it back with a brand new battery 2 days ago. Showed as 100% it is now ALREADY DOWN TO and fluctuating between 83% and 67%.

I am also seeing the countless Threeaxis reports (up to 60 events on one trigger) although unsure if this is the cause of the drastic battery drain or not. This is not consistent though at other times I only see one threeaxis report. It is also when on the bench so no further vibrations on the actual sensor yet the reports seemed to keep coming…

I am just glad that I never invested in more of these as I doubt I could afford all the batteries now lol

1 Like

As my st outlet and multisensor went offline and online today I thought it may be a good time to have OTA firmware update, the the multisensor battery went from 100 to 1 then 17 then 1 again, may be I should ignore it a while and wait for the newer .20 firmware
The 1% battery warning from smartthings app is annoying though

That battery behaviour is same as mine (I’m guessing ST doesn’t display anything between 1 and 17). After a number of alternate 1 and 17 readouts, it eventually displayed 1 constantly before adding an exclamation mark on the sensor’s icon, and finally a notification at 10am everyday to remind me, before going offline today. New battery sorted it, though I’m nervous as to how fast the new battery will deplete.

1 Like

Getting to think that ST should perhaps consider sending us out a load of new batteries (yeah right! :rofl:). My sensor was brand new and either the update drained the battery or was reporting incorrectly, either way I had to replace the battery. Also what I am seeing with the new battery dropping so rapidly is pretty unacceptable.

I really hope there are lessons being learnt with this update! Glad to be part of the process to improve future updates at my expense :rofl::rofl::rofl::rofl:

My multisensor is just a couple of months old from starter kit is that an expected usage pattern after a firmware update for battery operated ZigBee device, all my other devices including zwave don’t have such OTA capability may be it is a good thing

I would think that it is pretty unreasonable for a f/w update to drain the battery completely (not saying it has not done that though of course as it appears it has). Not sure that the sensor f/w update is the culprit here or not but since then mine is still eating up battery like the clappers so something is broken somewhere. There is definitely something not quite right, does the .20 update resolve this, no idea, also no idea when they are even going to bother updating the rest of us to .20…

.20 does seem to help allot while I don’t think it is fixed but I don’t get the daily issues I did get on .18.

1 Like

Is there a way to force this update without getting the beta? Really want to update the Halo in my house and don’t like waiting :slight_smile:


.20 is the beta until it is not anymore. Meaning it solves the issues and they roll with it. Or it does not and they send another beta .30 maybe and so on until it’s ready.

1 Like

The IDE is still showing my firmware version as 000.017.00012

Has this rollout been completed already? If so, why has my hub not been updated?

It’s mentioned further up in this thread. ST have stopped the roll out for now while they troubleshoot issues that have happened to those that did get it.

It was put on hold due to numerous issues reported. They only put it out it Public Beta for a few days which was not enough time for the users to report any issues, they then pushed it to live much to the frustration of numerous users.

There is a new .20 beta but no idea when this will be signed off and what the next version will be.

I would be grateful that you did not receive it. I never had a single issue with my system in 18 months until the .18 update.

Thanks for the update.

“faster … local automation” ??? what local automation, nothing works locally, all is done in the cloud!!!

I initially got the Hub V2 with the hope that my ZigBee lights on/off will at list work locally (off line) if not connected… well nope!
My broadband is a LTE mobile connection (rural environment) and therefore I am disconnected from time to time, meaning that Smartthings hub is a dead duck until the connectivity is re-established ! not great…

Any plan to bring the light processing local (bulb and switch) I have Osram Lightify bulbs (directly connected to the hub) and virtual switches (mobile app).


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

1 Like

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:


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.


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