It may be an update for the new UK plug, not prior models. @BroderickCarlin can you clarify which model UK plugs are getting the firmware update?
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!
The update is for the new UK plug, not prior models
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 have a V2 Hub updated to 000.027.00006
Currently all my Zigbee devices seem to be down/Offline. Is there an outage? or is it related to the firmware update? I have tried rebooting the hub with no change. Thanks
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?
I’m having the same issue as everyone else. All my sensors are not updating their status since the update.
Is there a way to roll my firmware back?
@prjct92eh2: Thanks for the confirmation. Are there any plans for future updates for the WiFi hub as well? Why do all the other hubs receive updates, but this specific hub not? Any reasons for that?
This firmware update has broken status updates and motion reporting from my connected WeMo motion sensors.
This integration no longer works for me after the firmware update. It worked up until the firmware update.
The Raspberry Pi can see all of the activity, but ST is showing nothing.
I post unsolicited messages to port 39500 on a V2 hub from Tasker on Android. They are still being received and processed by my own custom DTH which uses the MAC address of the Android device as the DNI. That might suggest the problem either isn’t 27.6 or has a narrower focus.
Having the same issue since yesterday’s update (2:03 PM CST), sensors are ACTIVE but the child devices don’t report any readings and recreating one doesn’t also create the child device. One of the sensors is reporting luminance in my living room and dims the light automatically, which is broken right know.
Thanks for the info, @orangebucket. Can you please share with me (via PM) an example of the exact command you are issuing via Tasker? That would allow me to compare your syntax to mine to see if the formatting is different.
Openhab2 device handler is broken by this update. Openhab still receives updates from SmartThings, but commands sent from openhab to the ST hub time out.
Openhab reports a timeout, while ST reports “error received a request with an unknown path: HTTP/1.1 200 OK”
This firmware has adversely affected all my Fibaro Dimmer 2’s, they are now all unresponsive but showing online in the IDE, just me?
This update broke the MQTT Bridge. Device updates are being sent as before but the hub no longer accepts/processes commands.
All of my ST_Anything ESP 8266 devices have broken as of 18.21BST last night. I wish Samsung wouldn’t keep doing this, super frustrating. Here.
We are aware of the issue and some engineers with knowledge of that portion of the system are currently digging to figure out the root cause