We’re excited to announce the start of a new SmartThings Hub Firmware Beta. Version 0.48.1 will begin rolling out in batches starting on May 8, 2023. This will be a phased rollout so that we can keep a close eye on any issues that arise so your hub may not be updated immediately. The hub will be offline for about a minute during the update. See below for more specific details about the update.
Version (Release Date)
0.48.1 (May 8th - 9th, 2023)
0.48.2 (May 17th - 18th, 2023)
0.48.3 (May 31st - June 1st, 2023)
Hub Target
Samsung SmartThings Hub 2015 (Hub v2)
Samsung SmartThings Hub 2018 (Hub v3)
Help Us Help You
As part of our Beta program, it is important for our support team to investigate logs from Hubs running that are reporting errors. To provide our team access, please follow these instructions:
RBoy
(www.rboyapps.com - Making SmartThings Easy!)
2
I’ve come across a fairly major bug in this firmware. Sometimes, when a Z-Wave device is paired and the Z-Wave driver doConfigure lifecycle is called by hubcore, the hub’s node id in the environment variable driver.environment_info.hub_zwave_id is missing. This causes a loss of directional communication with the device because association configuration requires this node id and the times this id goes missing while pairing the device can no longer initiate communications with the hub. I’ve also raised a ticket for it.
@alissa.dornbos , same here. I still haven’t received the update. I did get an email from ST saying there was some sort of issue validating my hubID, but it’s correct and I validated everything on my end that was asked of me. Not sure why this hub beta had issues while all the other ones in the past were just fine.
Hello @johnconstantelo and @GiacomoF, I’m looking into both of your cases as to why your hubs were not updated and will hopefully have a resolution shortly. Thanks.
1 Like
RBoy
(www.rboyapps.com - Making SmartThings Easy!)
9
I’m still seeing the behavior today, it’s easy to replicate, every time I pair the device and update the driver I can see the issues (once in a rare while the information will be populated during pairing but most of the time it’s missing). Let me explain what I’m observing in more details:
When a device is paired there are three lifecycle handlers called, init, added and doConfigure. During the first 2 there’s absolutely no information in driver.environment_info (it reports an empty table {}), where as during doConfigure it’s only partially populated with only the hub_zigbee_eui but the hub_zwave_id is missing (this is the critical one for z-wave devices)
When a driver is updated, init is called and this time driver.environment_info only contains hub_zigbee_eui (v/s nothing during a pairing) but the hub_zwave_id is still missing.
doConfigure and added are never called again for z-wave devices other than during the initial pairing so there’s no way to tell if that information gets populated later on.
When the other lifecycle handlers like infoChanged and removed are called after the pairing is completed or when capability commands like refresh are called, it does contain the hub_zwave_id in the driver.environment_info structure so I don’t see any issue there.
I hope this helps pin point the source of the problem.
A couple of other bugs/things I’ve noticed with this firmware.
When the lifecycle handler init is called during pairing or after a driver update, the driver.environment_info structures are empty during pairing and only contains the zigbee_eui after a driver update, which means there is no zwave_hub_id. Is this by design or a bug?
When the lifecycle handler added is called, the driver.environment_info structures are empty, which means there is no zwave_hub_id and there’s also no zigbee_eui. I’m going to assume that this is a bug because there are ST drivers in production today which are communicating with the device during the added lifecycle but without the hub id, the association groupings will fail and it will lead to a loss of communication with the devices that require association groupings.
According to the documentation the infoChanged lifecycle handler is called when there are changes made to the device information, quoting: An example could be a change to the name of the device. I can confirm that this is NOT happening with firmware 48.1. When the device name is changed the infoChanged handler is not being called.
Hello - We have released 48.2 with a fix for this, can you confirm if you are still running into this ?
Thank you for your communication.
2 Likes
RBoy
(www.rboyapps.com - Making SmartThings Easy!)
13
It’s been fixed with 48.2, thanks for the quick turnaround.
1 Like
RBoy
(www.rboyapps.com - Making SmartThings Easy!)
14
So I found another bug in the 48.2 firmware. I have a sleepy z-wave device. When I try to exclude it, the mobile app exclusion screen (and device) confirm that it’s been excluded.
However the device is still showing up in the list of devices in the account and I also noticed the driver removed lifecycle method isn’t called.
I’ve submitted the hub logs from the IDE (hub ID D052A83575270001), time is about 6:20pm EST, device id fe42833a-b6c3-47be-a529-85f663d123bb
RBoy
(www.rboyapps.com - Making SmartThings Easy!)
15
@alissa.dornbos I’m seeing this issue repeatedly (as in about 30%-40% of the time with z-wave sleepy devices), the device excludes successfully but it isn’t removed from the mobile app and the driver removed lifecycle isn’t called essentially creating a ghost device in the system and only way to remove it to forcefully delete it.
I’m seeing a secondary issue, where I’ve seen one device get duplicated in the mobile app while pairing. Also when I force deleted some ghost devices (which excluded successfully but didn’t disappear from the app), it also seemed to disconnected an unrelated working z-wave device, as in it could no longer communicate with the hub. There seems to be some wires getting cross internally.
@alissa.dornbos , what’s provided in the 48.3 release that we just got for our hubs? I’ve noticed a few Zigbee switches go offline for an hour or so and then come back on their own or after being manually used (this could have been under 48.2, but not sure).
EDIT : add a leak sensor to the mix of devices going offline. The batter died and I replaced it, which made it report data for just about an hour but now it’s offline for no reason at all.