We’re excited to announce the start of a new SmartThings Hub Firmware Beta. Version 0.46.4 will begin rolling out in batches starting on Dec 5, 2022. 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.
Known Issues
Our team has identified a few known issues that will be fixed after the rollout:
The use of driver:register_channel_handler for Lua LAN driver channel handler registration may cause the driver to hang. It is recommended to not use this handler until a fix is in place. The use of cosock.spawn without handler registration can work around this issue. See the http_button driver for use of cosock.spawn .
Version
0.46.4 (Update: 0.46.8)
Hub Target
Samsung SmartThings Hub 2015 (Hub v2)
Samsung SmartThings Hub 2018 (Hub v3)
Release Date
Release Date: Dec 6, 2022
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:
Fixed Zigbee Secure Mode and OTA settings handling
Fixed Zigbee OTA / secure mode settings incorrect defaults
Fixed Zigbee OTA / secure mode settings states not persisting / propagating properly
Updated OS build infrastructure for improved security and stability
Edge Drivers
Changed the default TCP Keepalive options for TCP Sockets that have :setoption('keepalive', true) set. Because the Edge Drivers don’t currently expose all of the API’s needed to set TCP specific Keepalive Parameters directly, we set sensible defaults per-socket for now so that TCP client sockets can detect disconnect events in a reasonable amount of time. Lua-side APIs will be added in the future to give users more control over the TCP-specific parameters for sockets with keepalive set to true.
Fixed a bug that would cause tls wrapped sockets to potentially block a driver when calling doconnect
Fixed a bug in the TCP accept implementation that would backlog more connections than intended
The st.mdns API now returns higher level data structures instead of DNS packets directly. The internals have also been refactored to offer deeper integration with the hub, leading to improved reliability, accuracy, and responsiveness.
Fixed two Z-Wave Configuration Command Class bugs to allow for unsigned, bit mask, and enum parameter type serialization, and 0-sized parameter deserialization in the PropertiesReport Command
Removed support for use of attribute id, and command id filtering options on MatterDevice:get_endpoints; added AcceptedCommandList and AttributeList attributes to the matter cluster library for all clusters.
Fixed a bug preventing use of manufacturer defined clusters with Matter devices
NOTE
Anyone who participated in the previous beta 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
RBoy
(www.rboyapps.com - Making SmartThings Easy!)
2
There is a major bug in this firmware (46.4) which I reported earlier today to the developer support team. The luxure library shipped with the firmware does not work. The edge drivers using the luxure library are working great on all my hubs running 45.11 but when I deploy the same on the hub running 46.4 it completely stops working.
1 Like
RBoy
(www.rboyapps.com - Making SmartThings Easy!)
3
There’s also an issue with cosock socket receiving where it’s hanging and not yielding in 46.4. It’s working perfectly on 45.11 but when the driver is deployed on 46.4, it hangs until some event which then triggers it then it works for a bit and then hangs again.
@RBoy our team has reported back and we have validated that LAN drivers for HTTP servers (i.e. drivers that use luxure) are working as intended for 0.46.4 on V2 and V3. We tested various drivers in addition to the http_button driver.
Can you provide us more information on your test setup please? Are you using http_button or can you provide any other driver you are using that is experiencing this problem? A log package after attempting to interact with your LAN driver would also be hugely helpful.
Thank you!
RBoy
(www.rboyapps.com - Making SmartThings Easy!)
6
I’m using luxure to setup a PUT rest endpoint to receive messages from a LAN device. I’ve also tested it with postman for debugging purposes. On 45.11 it works perfectly, using postman, it sends a HTTP PUT message to the hub luxure REST endpoint, I see the logs in the console from the edge driver when it receives the messages and postman also receives a response back from the edge driver luxure rest endpoint. However, when I deploy the same driver on 46.4 postman can’t reach the endpoint, it times out. Let me know what I can provide you.
We have determined that the problem @RBoy experienced can be worked around through use of cosock.spawn instead of handler registration with driver:register_channel_handler. See the http_button driver for use of cosock.spawn.
Our team is invesigating channel handler registration further and hopes to provide a fix in the 46.X window. In the mean time, it is recommended to not use driver:register_channel_handler until this fix is in place.
Hi @Cory_Heuschkel , they did but when I checked up at around 3pm EST they were already offline for 2 hours (according the IDE). I also verified via the CLI. I can’t say when they cam back online because i was in a meeting and didn’t check again until I got home around 5:15pm or so.
I’m in the beta but haven’t received the update yet. I think there is a problem in my account https://smartthings.centercode.com/ who should I contact? I had previously had similar problems and it had helped me @alissa.dornbos For this reason I quote you
I have signed up for the beta firmware but still didnt get the update in my hub.
I am in the middle of testing the zigbee contact sensors and got to know the beta has some fix related with zigbee. So wanna try to see whether it will help to fix the zigbee connection issue.
