We’re excited to announce the start of a new SmartThings Hub Firmware Beta. Version 0.36.x will begin rolling out in batches starting in the week of March 15th; 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.36.x
Hub Target:
Samsung SmartThings Hub 2015 (Hub v2)
Samsung SmartThings Hub 2018 (Hub v3)
Release Date:
March 15th - March 19th, 2021
Release Notes:
New Features
Z-Wave:
Automatic handling of Sleepy device cycles by the Hub – This shifts the generation of Wake Up No More Information (WUNMI) command from the DTHs to the Hub. The Hub will drop any WUNMI command sent from the DTHs, instead, the Hub will monitor the incoming and outgoing traffic and generate WUNMI command when appropriate
Bug Fixes
Z-Wave:
Fix an issue where network repair error logs were not shown properly in the mobile application
Zigbee:
Fixed situations where larger networks would report “Unknown Route” for some devices in the Groovy IDE
Minor bug fixes and improvements
NOTE
Anyone who participated in the previous beta (0.35.x) is automatically signed up for this one.
If you’d like to participate in the beta, but haven’t taken the survey yet: Sign Up Here
Nice! Hope the z-wave network gets faster. @Kianoosh_Karami can you please explain what the wunmi thing does and why the dths will drop it? Also, no updates on the local control ?
DTHs will know when the device wakes up as it always has; Wake Up Notifications from the device will be propagated to DTHs. The change is only for the Wake Up No More Info cmd, which the hub will send when appropriate.
So the cycle is like this:
Device sends a Wake Up Notification to notify that we can send commands
The DTH handles the report by potentially sending any cmds that are need to be sent (i.e. Battery Get)
When the hub no longer detects communication with the device for X seconds, the hub will send the Wake Up No More Info command. (X is configurable by us and is currently ~2 seconds)
So in (2), the DTH writer will no longer be responsible for sending the No More Info cmd to conserve battery after communicating. It won’t do any harm if a DTH does try to send a No More Info cmd, it just won’t be sent to the device until the hub knows communication with the device is complete. Does this clarify your question?
1 Like
RBoy
(www.rboyapps.com - Making SmartThings Easy!)
7
Thanks yes. So if the device doesn’t respond in 2 seconds then the hub will automatically send a no more wake up command, is that correct?
So if there is more than a second or two combined network latency, cloud latency, and mesh latency dth will be unable to send commands to the device?
RBoy
(www.rboyapps.com - Making SmartThings Easy!)
13
I believe what happens right now (for most DTH’s) is that the DTH will send a bunch of commands ending with a WUNMI command with a 2-3 second delay between each command. So the device should anyways go to sleep after X seconds (depending on how many commands are being sent). However some DTH’s don’t handle a WakeUp event or send a WUNMI command to the device, so the device will eventually timeout in about a 30 seconds (if I remember correctly) and go back to sleep.
A thought here, if it’s not being done already, maybe the hub can check if there are commands being sent in response to a WakeUp event and have a different WUNMI timeout (say 10 seconds) in this scenario v/s if no commands are being sent (assuming the hub will ignore an explicit WUMNI command from the DTH) and then send a WUNMI in 2 seconds. To make it more engaging, maybe even look at the wake up interval if that’s available (e.g. some DTH’s set the device to wake up every 10-30 minutes while others go to sleep for 6-24 hours) to factor in the decision of how long to wait before sending a WUNMI.
@RBoy Would this also ensure sensors on busy networks will be able to finish sending commands? It sounds like the current implementation might just leave them behind. #NoSensorLeftBehind
I have enrolled a hub on the beta test. No new firmware being indicated but the Zigbee version is now 5.1.2 and all my Ikea buttons have stopped reporting. Not entirely the start I was hoping for …
Update: Hmm. Four decided they really couldn’t possibly start pairing without a new battery, one didn’t want to feel left out and didn’t mind the same battery as long as I took it out, and two decided the joke was over.
Still on .035 here. I also do not see beta on Centercode.
I recently received an e-mail from SmartThings requesting an NDA signature, so I’m wondering if they are adding that as a requirement. I have no issue signing one, but I’m honestly too lazy to print out a Word doc (that was still dated 2019), sign it, and send it back in. Get with the times, guys - eSig is super easy now.