We’re excited to announce the start of a new SmartThings Hub Firmware Beta. Version 0.32.x will begin rolling out in batches starting September 1st; we will send out an email when we start updating Hubs. We will be paying close attention to any issues encountered by users so your hub may not get updated right away. The hub will be offline for about a minute during the update. See below for more specific details about the update.
Version
0.32.x
Hub Target:
Samsung SmartThings Hub 2015 (Hub v2)
Samsung SmartThings Hub 2018 (Hub v3)
Release Date:
September 1st, 2020
Release Notes:
Features
Local Monitoring of Device Status - Device online / offline status for Hub Connected devices will run locally. WARNING - Immediately following this update, Beta testers will be limited to viewing the current state of a Hub Connected device. Historical state changes will be unavailable until a subsequent cloud release, scheduled for Wednesday, September 9th. During this period, any SmartApps using device health states may be affected. If this limitation affects you, we encourage you to opt out of the 0.32.X beta. Additional Notes:
All Zigbee and Z-Wave devices (including self published DTHs) and locally running LAN devices will begin using this feature.
The mechanisms for determining state will remain the same as before. Most Hub Connected Devices are pinged on a pre-determined basis (aka Check Interval). If the device fails to respond to a ping, the device is marked as Offline. Any activity from the device will mark the device Online, and reset the scheduled ping.
All Zigbee/Z-Wave devices with the Health Check capability or ones that have created a checkInterval event at some point in the device’s lifetime will follow the Ping mechanism for their health state, the rest of the devices will mirror their respective network’s status.
The ping frequency for offline devices will start to decrease as consecutive pings are missed by the device.
Z-Wave Enhancements
Added support to display the statistics for incoming and outgoing messages for each device in the mesh network. This can be viewed in the device page in the IDE/Graph.
Zigbee Enhancements
Zigbee devices that execute locally will now include one (1) decimal point of precision in temperature reports.
Bug Fixes
Sonos: Improved reliability for detecting IP address changes
Minor bug fixes and improvements
NOTE
Anyone who participated in the previous beta (0.31.x) is automatically signed up for this one.
If you’d like to participate in the beta, but haven’t taken the survey yet, you can Sign Up Here
If you’d like to opt out, you can also leave the program via the Account Settings menu item in Centercode
RBoy
(www.rboyapps.com - Making SmartThings Easy!)
2
Sounds interesting Barry, looking forward to this. Could you clarify a few things here so that we can adjust our SmartApps and expectations accordingly:
As I understand there shouldn’t be any impact of SmartApps using device health with the exception of lack of historical health state (until the subsequent cloud release)
The deviceHealth and checkInterval take precedence over Network status, is that correct?
How many pings does a device need to miss before it’s marked offline?
The backoff mechanism for pinging an offline device - you mentioned it will reset the scheduled ping, what does that mean?
As far back as I can recall, which is not that long compared to many but was before ‘device health’ came along with online/offline replacing active/inactive, us punters have never been told how on earth we are supposed to handle device status.
Health Check appeared completely unheralded in stock handlers and checkInterval was quickly identified as being important. However we also came across deviceWatch-Enroll and deviceWatch-Status that had a legacy feel, and also healthStatus which looked like a way for cloud connected or virtual devices to indicate their status. Or not. It was all just guesswork. No one would cough up the facts…
The discussion of Health Check in the ‘new’ documentation has potential but doesn’t quite tie together either with other parts of the same documentation (like the API reference) or anything we see elsewhere. It mentions UNHEALTHY for example, which is not found in the Health Check capability.
It would be great to see community handlers and new integrations using Health Check properly, but in order to do so we desperately need clear, consistent and up to date information.
Sorry, I think the source of confusion comes from a mistake I made when handing in the notes to Barry. We edited the message so many times, that we missed an error in there. We meant to say the following
The latter part, , reset the scheduled ping got thrown else where.
Anyways to answer your questions.
If the network (Zigbee, Z-Wave, LAN) is offline, all the respective devices will be marked offline.
If a device misses a ping (1), it is marked offline, bear in mind that any activity from the device resets the scheduled ping, so that means if we have not heard from the device for Check Interval + a few minutes (waiting for the device to respond), the device is marked offline.
You do make a great point about lack of documentation surrounding Device Health and its surrounding functionality. I have taken an action item, let me follow up internally and find a way to provide more documentation than what we have provided here. It will take a week or two, but I will follow up by end of next week.
Maybe though some of these features we were promised need the new firmware update in order to be implemented to the platform. We are all in the same boat. I generally feel that smartthings is going the right way, just not fast enough…
I think they are, we cost them money in cloud server processing, rarely buy samsung Zigbee products so what benefit are we to them?, I purchased a Hubitat about a week before the announcement I have moved all my cloud services to Hubitat except Ring & Nest. My Z-Wave and Zigbee are still on smartthings but I can pull them into hubitat using HubConnect and still using ActionTiles. I will still keep ST alive for services that Hubitat can’t support.
BTW hubitat C7 Hub isn’t fully working, I tried to move zwave devices over and it crashed, I moved everything back to ST. I’m now on the Hubitat Beta team and this week alone there’s been 6/8 updates and there’s still issues, the grass isn’t always greener but it’s nice having all local devices and webcore though
This firmware is the step in the right direction as this will reduce traffic to & from cloud servers, the amount of times devices have be shown offline due to cloud server issues
Opting out via the Centercode link will remove you from the beta program entirely, you will not get any future beta firmware updates unless you re-enroll. If you would like to just skip this 0.32.x beta, send me a DM and I will make sure your hub is off the beta list for this round.
It is about the online/offline status of devices. You will see endless reports of devices that are reported as Offline but are clearly functioning just fine. This is because the device monitoring is all cloud based and isn’t entirely reliable for all devices.
The idea is that as Zigbee and Z-Wave devices, and local Wi-Fi devices, are communicating directly with the hub, it would be better to monitor their online/offline status on the hub itself (‘locally’).
Any reason why the new app shows a ton of devices offline while the IDE shows them all online? I am already on 32.6 firmware. Prior to the upgrade, a smaller number (I think I still really dislike using the app so I avoid it at all costs) of devices were marked as offline even though they were not. I thought the new local health check was going to fix this, not make it worse. Is it possibly a matter of the scheduled health check not up yet? If so, any way I can trigger a general refresh without having to go to each device?
EDIT: I don’t have anything in CenterCode referencing this beta so I can’t submit anything there. [now fixed - thank you @BarryA]