We are going to release a hotfix on Wednesday, September 18th for SmartThings Hub 2015 (v2) and 2018 (v3). Firmware version 27.9 will include additional improvements for LAN and Z-Wave device communication issues.
We are going to release a hotfix on Tuesday, September 10th for SmartThings Hub 2015 (v2) and 2018 (v3). Firmware version 27.8 will include improvements for some LAN communication issues and connectivity fixes for multi-endpoint devices.
We’re excited to announce the release of Samsung SmartThings Hub firmware version 0.27.6. Once downloaded, your Hub will briefly go offline as it reboots and applies the update; most customers will experience less than one minute of downtime. We will update the status page when the release is complete.
Samsung SmartThings Hub 2015 (Hub v2)
Samsung SmartThings Hub 2018 (Hub v3)
Release Date: 26 August 2019 ~ 27 August 2019
Zigbee bulbs can now remember the previous level if they were turned off by setting the dimmer level to zero
Firmware updates for various Zigbee devices including SmartThings Smart Plug (UK) and Aurora lights
Minor Z-Wave improvements for recovering communication with devices
Could you please clarify what you mean by “Zigbee bulbs can now remember the previous level if they were turned off by setting the dimmer level to zero”? Specifically, does this mean if a bulb is on and turned off (i.e. by a power outage) then when power is restored to the bulb (after a power outage or by a wall switch for instance) then the bulb will return to its previous state? This would be a huge improvement and eliminate the need for the canary bulb work around I currently use (which isn’t totally reliable). I have all Cree bulbs would this new feature apply to them too? Thank you!
This addresses a very specific use case that would cause some Zigbee bulbs to appear non-functional. The use case that is being addressed here is:
Start with a Zigbee dimmable bulb turned on
Through some means set the bulb to 0%
At this point the bulb would appear turned off and would report as being turned off in the app.
Through any means turn the bulb back on (voice assistant, automation, app, etc).
Because the bulbs last level was 0% the bulb will turn back on to 0% or 1%. This results in it appearing that the bulb didn’t actually turn back on and just causes a world of confusion/frustration. The fix in the 27.X release causes the bulb, in this case, to turn back on to what ever the bulbs level was all the way back when we started at #1
The use case you mention with the canary bulb is not something that would be addressed by this change.
It appears that a change was made in 27.6 that has broken the proper receipt and processing of unsolicited LAN messages to port 39500 on the ST v2 Hub (only hub I have to test with!) This has broken both ST_Anything and OmniThing from being able to send status updates through the ST Hub to the ST Cloud to be processed by custom DTHs. These projects both utilize the MAC address of the sending microcontroller as the DNI of the ST Device. Communications from ST to the microcontroller still works fine.
Please advise if this change was intentional or not…and if there is a way to fix it.
There seems to be an issue with the update breaking several SmartApps.
This is impacting one of my projects. This change was not in the release notes, nor was it described in the beta. Can someone in ST engineering look into this? What was the reason for this change, and how can an application be modified or the firmware fixed?
I am also having the same issue as described here. I have several sensors that are no longer working since the firmware update. Is it possible to change back to an earlier firmware version or prevent these firmware updates in the future?