SmartThings Community

Hub Firmware 18.x Beta

One odd thing happened since 18.18. May or may not be related.

About 4 hours after the update, I got a Notification that my SmartThings Hub was disconnected. (Thursday at 8:28pm EDT). I checked IDE and it showed the hub was online. Everything was working fine. There were no network issues. Never received a notification that it was back online.

Today, I received a Notification that my Hub was now active. (Saturday at 3:50pm EDT) There were no other notifications today according to the Notification Messages log

So, there was a 39 hour gap between the two notifications. But again, everything has been working fine…

Lots of issues since the update to 18.18

  • Some Devices forgotten
  • General Z-wave network unreliable (even more so than before)

only good thing is the reboot is much faster

I’d like some of my devices back… how do you do this?

FWIW my hub went offline for 10 min today, I wasn’t expecting an update and it doesn’t appear to have updated (running 18.18). I can confirm my internet connection was active and healthy at the time (9:37am-9:47am).

Oddities after the update: 1) some things are faster, while others are really slow (hue), 2) lost a few devices, replaced and they work again, 3) random weirdness. None of this was present prior to the update.

Devices that execute locally should generally be faster, at least within variables controlled by the hub. Nothing related to hue has changed with this update (we do have some improvements planned here for the future) so changes in responsiveness may just be due to cloud load and other factors that are beyond the control of the hub software.

If you can, please send a message to noting what these were. We aren’t aware of any specific devices issues right now so gathering more information is critical here.

More specifics here would be helpful, obviously. Feel free to include that in any report to the beta list.

1 Like

This is going to be a little long but I’ll try to explain what’s going on here.

The percentage is calculated based on the battery voltage reported by the sensor. Previously a voltage of 3.0V was considered 100% and 2.1V or below was considered 1%. We did make some changes to the voltage reported by the sensor and yesterday we released changes to the SmartSense Multi Sensor and SmartSense Motion Sensor DTHs to adjust how that voltage is converted to a percentage. We made these changes in an attempt to improve the accuracy of the battery percentage reporting to the extent possible given the hardware design and the battery technology.

The SmartSense Motion Sensor requires at least 2.4V to operate all the components in the sensor. The DTH change we released yesterday reports 2.4V as 1% instead of 2.1V like it did before. This means you may see a drop in the percentage, but the new value should more accurately reflect the remaining life of the battery. It’s going to be slightly better if the firmware has been updated. If the percentage drops to 1% the sensor is effectively dead and you’re likely to observe false motion events as a result of the PIR sensor dropping below its required operational voltage. If you don’t update to the new firmware this will likely happen at a value higher than 1% (ex: 33%).

The SmartSense Multi Sensor can operate at 2.1V so we didn’t adjust the lower range. However we adjusted the upper end of the range from 3.0V to 2.7V for both the SmartSense Multi Sensor and the SmartSense Motion Sensor. That’s because new batteries generally report 2.7V. If you had recently put in brand new batteries you might see the percentage rise a bit. However keep in mind that these batteries will quickly drop to the 2.5V-2.6V range and stay there for most of the life of the battery at which point the battery voltage quickly drops.


How does one get on the Beta list?

We had an signup period during the 17.x beta and just reinvited those people for 18.x. @slagle has some plans for improving how we do beta releases moving forward, but at the moment there is no really straighforward answer. We’ll definitely be providing notice on the forums when there is another beta opportunity available.


Thanks for the reply. My two Samsung sensors now read 83 percent battery so both have gone up since my last check point where each were at 56.
The OTA occurred minutes/ hours after the beta occurred back on the 12, no further changes there.
Separate question what is the frequency of health check if turned on? And does it run at a certain time? Are any Zwave sensors covered by health check (example Zooz door/ window contact)


All of the devices on are health checked.

Devices like Zooz which aren’t natively supported by SmartThings also aren’t health checked.

There are two main components to the health check, the frequency of device polling/check-in and the check interval. In general we will mark a device as “offline” if it has missed two polls/check-ins but we add a little buffer as well. So a device that is polled every 5 minutes, we would likely set the check interval as 12 minutes. That would allow for two polling opportunities (2 poll events which are 5 minutes apart to get 10 minutes) and a little buffer (2 minutes).

Here’s a more complicated example of the health check frequency for Z-Wave motion sensors:

These devices only check in every 4 hours. So the check interval is 8 hours plus a buffer. 8 * 60 * 60 gives you 8 hours (or 28,800 seconds) which accounts for 2 check-ins from the device plus a 2 minute buffer (2 * 60 or 120 seconds). The device would need to miss 2 check-ins during that 482 minute check interval to be marked as “Offline”.


You wrote:


How are these updates deployed? Local DTHs are run local so they are contained within firmware in the Hub and not the cloud? correct?

Or does this run in the cloud?

You wrote this today 7/19 and said this happened yesterday. Should we have gotten a hub update yesterday?

Just curious!


For hubs with 0.18 the handling of the battery message happens in the cloud for now while most of the rest of the messages are still handled locally on the hub.

1 Like

That’s interesting. Does this imply that devices can now have certain capabilities run local and certain in the cloud?

[quote]@tpmanleyWe did make some changes to the voltage reported by the sensor and yesterday we released changes to the SmartSense Multi Sensor and SmartSense Motion Sensor DTHs to adjust how that voltage is converted to a percentage.

What about the SmartSense Motion detectors, mine are way off.

All these comments on Iris FW updates makes me question. I have all my Iris devices using the ST ( Centralite) device types, in the hopes that I might someday have local control. Will they still update, or do I need to changes them all back to the stock Iris device types ?

Iris motion are showing
Current Version: 0x1C005310
Target Version: 0x1C005310
Last Updated: 2017-06-28 9:09 PM EDT

So obviously they’ve updated, however as others have stated
Iris Smart plugs ( Using ST SmartPower DT) are showing

Current Version: 0x20015010
Target Version: 0x20015010
Last Updated: N/A


Other than my iris button, all of my iris devices run local.

They are all running stock device types.

Meaning whatever device type is picked when paired.

Smart sense motion
Smart power outlet
Smart sense open closed sensor

1 Like

Firmware updates are independent of the DTH you use. Also, there is no firmware update for the Iris plugs unfortunately. I have a bunch of them. Seems only officially supported Iris devices get updates (motion, open/close, water sensor).

Edit: As a note, there actually is a firmware update for the CentraLite branded plugs though.

Do your iris devices not run local?

They didn’t when I set them up about 18 or so months ago :wink:
I’m a firm believer in " If it ain’t broke, don’t fix it". So if everything is working I don’t mess with it.

So true. But I believe you’d get an ever better experience with the Smart Sense handlers. The Iris sensors are fast and with local processing I find them extremely responsive where it counts - turning on lights, fans, etc.

1 Like