52.X Hub V2/V3 Customer Beta Release Notes

52.X Customer Beta Release Notes

Hub Firmware 0.52.X Beta

Hey everyone!

We’re excited to announce the start of a new SmartThings Hub Firmware Beta. Version 0.52.1 will begin rolling out in batches starting on 11-Jan-2023 for V2/V3 Hubs. 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. If your hub has not yet updated, but you would like to get the update please reach out to me via direct private message. I will keep this post updated when additional releases are planned for the Customer Beta Population. The hub will be offline for about a minute during the update. See below for more specific details about the update.

Version

  • 0.52.1 Released Jan 11, 2024
  • 0.52.4 Released Jan 30, 2024
  • 0.52.5 Released Feb 01, 2024
  • 0.52.6 Released Feb 02, 2024
  • 0.52.7 Released Feb 09, 2024
  • 0.52.8 Released Feb 20, 2024

Hub Target

  • Samsung SmartThings Hub 2015 (Hub v2)
  • Samsung SmartThings Hub 2018 (Hub v3)

Release Date

  • Release Date: Starting Jan 11, 2024

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:

  1. Go to SmartThings Web (my.smartthings.com)
  2. Log in to your Samsung Account
  3. Select the Menu (⋮) and choose Settings
  4. Toggle on Account Data Access
  5. Select the time period and choose Confirm

Customer Beta Release Notes

52.1

  • Changes were made to the Zigbee and Thread stacks. Please call out potential issues you may experience with Zigbee or Matter-Thread devices.
  • Fix rare bug causing the Zigbee secure mode and device firmware update settings to temporarily revert back to their default values until the next hub reboot.
  • Fix bug where battery-powered Z-Wave devices go to sleep before they are fully configured on the initial join.
  • Automatic device firmware updates for Zigbee and Matter devices will be enabled by default on newly claimed hubs.

52.4

  • Enabled json array encoding for native json module, and improved native json module documentation
  • Upgraded xml2lua library module from v1.2-4 to v1.6-1
  • Upgraded lustre websocket library from v0.1-3 to v0.1-4
  • Deprecated st.base64 library in favor of https://github.com/iskolbin/lbase64/tree/v1.5.3 Can’t find link
  • Upgrade luncheon http library from v0.1.0-1 to v0.3.0-1 (chunked encoding support)
  • Fixed a bug in thread.lua where unregistered sockets that are read ready could cause a driver crash
  • Fix rare bug where Zigbee network incorrectly reforms, resulting in loss of communication with Zigbee devices until they are manually rejoined.
  • Changes default configuration for some Zigbee clusters to reduce battery drain.
  • Added the ability to delete LAN and EDGE_CHILD devices from the driver that manages them.

52.5

  • Various Fixes

52.6

  • Various fixes improve Zigbee and Thread radio stability

52.7

  • Various Fixes

52.8

  • Changes were made to the Zigbee and Thread stacks. Please call out potential issues you may experience with Zigbee or Matter-Thread 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

If you’d like to opt-out, update your preferences via the Account Settings menu item in Centercode

7 Likes

Can you confirm if it’s coming to smartthings station aswell?

As with previous releases, the customer beta program is limited to the V2 and V3 products. 52.x is expected to be released to other platforms, including the SmartThings Station product, but only after the release reaches general availability (this is the first customer beta release for the 52.x series).

3 Likes

Thanks for confirming. The reason why I was asking is because i am hitting the same bug in smartthings station regarding the zigbee channel.

So this is a weird one. As of two days ago, 01/25 around 4:30 a.m. local, all zigbee and z-wave devices are offline, wifi devices are still good. I’m assuming that’s when the 52.1 update hit. I have restarted the hub, unplugged it for 30 mins and restarted. Here’s the wild part, 61 devices are showing as offline, always 61 on subsequent restarts, in the app but it is closer to 115 that are actually offline. The rest show as online but are not controllable. I have repaired many of them bit they then drop offline.

Hey @Victor_Napolillo Thank you for reaching out.

We want to look into this issue quickly. In order to best support you can you please do the following?

  1. Go to SmartThings Web (my.smartthings.com )
  2. Log in to your Samsung Account
  3. Select the Menu (⋮) and choose Settings
  4. Toggle on Account Data Access
  5. Select the time period for at least a month and choose Confirm
  6. Private message me the account email address you use to log-in to with the SmartThings App

Thank you.

1 Like

Full access granted, c’mon in!

Hello.

We will be releasing 52.4 today or early tomorrow. Here are some important release notes of fixes withen that release.

Please share if you run into issues, your communication is always appricated. Please see the linked steps above to turn on support access.

Thank you.

52.4 Release Notes Customer Beta V2/V3

  • Enabled json array encoding for native json module, and improved native json module documentation
  • Upgraded xml2lua library module from v1.2-4 to v1.6-1
  • Upgraded lustre websocket library from v0.1-3 to v0.1-4
  • Deprecated st.base64 library in favor of https://github.com/iskolbin/lbase64/tree/v1.5.3Can’t find link
  • Upgrade luncheon http library from v0.1.0-1 to v0.3.0-1 (chunked encoding support)
  • Fixed a bug in thread.lua where unregistered sockets that are read ready could cause a driver crash
  • Fix rare bug where Zigbee network incorrectly reforms, resulting in loss of communication with Zigbee devices until they are manually rejoined.
  • Changes default configuration for some Zigbee clusters to reduce battery drain.
  • Added the ability to delete LAN and EDGE_CHILD devices from the driver that manages them.
2 Likes

Hi @alissa.dornbos

Please, could you specify which clusterd and new default configuration values are going to be established or where to find the information?

My drivers use optional custom configurations of cluster 0x0500 to reduce battery consumption and the default value is 300 sec, the same as the current defaults.
I would need to update those defaults of my driver preferences with the new values.

On the other hand, how are going to reconfigure the clusters of the devices already installed in the hub, if the doConfigure lifecycle is not executed without reinstalling the devices?

Thank you

3 Likes

Hi @Mariano_Colmenarejo, I checked with the devs who worked on this and here is my current understanding:

could you specify which clusterd and new default configuration values are going to be established or where to find the information?

This will be the TemperatureMeasurement cluster which will change to have a max interval of 600 and reportable change of 100 (1 degree celsius), and the IAS Zone attribute will no longer be monitored for zigbee motion sensors by default.

how are going to reconfigure the clusters of the devices already installed in the hub, if the doConfigure lifecycle is not executed without reinstalling the devices?

This will only take effect for newly joined devices at this time.

Hi @grantelbert

Thanks for the reply.

The IASZone will no longer be monitored by the motion sensors, but the configuration of the maximum report interval will still be 300 sec?

Nothing changes in the contact sensors?

Here’s the answer I got when I asked your question:

We will no longer be polling or configuring the reporting for the IAS Zone attribute by default. We will still send the enroll response, so we will still be notified about changes. This should bring the drivers in line with how DTHs dealt with the IAS Zone attribute.

Does that answer your question?

Thanks for answering,

Yes, but it generates new ones for me.

So have they also changed the way of managing the Offline status of the devices, which were previously monitored with attribute 0002 of cluster 0500?

Until now, if no messages were received from the device of the monitored attribute for about 2:30 hours, the device was marked offline.

Since unconfigured periodic reports will no longer be received, if a device has not changed its status in 3 or 4 hours, will it no longer be marked offline?

I think these doubts are important to know since going offline and returning online with a change of state has been one of the main problems of several devices that use this cluster.

Will you recommend users reinstall their installed devices, which use cluster 0500, such as contact, motion, water leak, smoke, so that they benefit from these changes when version 52.x of the firmware is generally released?

Thanks again

2 Likes

Hello - We will be rolling 52.5 out to Customer Beta hubs today.

If you are expirencing bugs, please dont feel shy to reach out. Your welcome to by making a post on this thread, and then sending myself or another team member the email you use to log-in to the SmartThings app with.

As a reminder, its best to turn on impersonation access for long periods of time so that we can best support you.

To provide our team access, please follow these instructions:

  1. Go to SmartThings Web (my.smartthings.com )
  2. Log in to your Samsung Account
  3. Select the Menu (⋮) and choose Settings
  4. Toggle on Account Data Access
  5. Select the time period and choose Confirm

It seems that the latest firmware version has an option to update the firmware automatically or manually.

At least I had not seen it before, although I no longer trust what I see on smartthings

1 Like

Now we need that option for the hub firmware itself…

1 Like

In case it’s of any use to you, although I am convinced that my opinion matters very little to you, I have seen one of the most important changes planned in this version 52.x (libraries version 9) that you have not mentioned.

The function that allows you to load into memory only the subdrivers that have devices paired to the driver and load the necessary ones when a device that needs it is added.

This is intended to free up hub memory, especially in drivers that have many subdrivers.

I have modified one of my drivers, which has 26 subdrivers, to use this function and it is working fine.

In the driver I have 2 double devices and three child devices

With the measure of memory I know:

  • old driver version: 2800 kbytes
2024-02-04T14:18:00.269411675Z PRINT Z-Wave Switch and Child Mc  Memory >>>>>>> 2836.125         Kbytes
  • new driver version: 1700 kbytes
2024-02-04T14:21:30.199081087Z PRINT Z-Wave Switch and Child Mc  Memory >>>>>>> 1704.337890625   Kbytes

Modified Zigbee Motion Sensor Mc too, with 14 subdrivers:

  • Old version:
2024-02-04T15:18:54.050410233Z PRINT Zigbee Motion Sensor Mc  Memory >>>>>>>    2231.978515625   Kbytes
  • New version:
2024-02-04T15:20:36.625730204Z PRINT Zigbee Motion Sensor Mc  Memory >>>>>>>    1085.56640625    Kbytes

Modified Zigbee Contact Mc too, with 7 subdrivers:

  • Old version:
2024-02-04T15:41:28.555520850Z PRINT Zigbee Contact Mc  Memory >>>>>>>  1697.43359375    Kbytes
  • New version:
2024-02-04T15:43:50.415755121Z PRINT Zigbee Contact Mc  Memory >>>>>>>  1044.4130859375  Kbytes

Modified Zigbee Smoke/CO Detector Mc too, with 5 subdrivers:

  • Old version:
2024-02-04T15:57:59.852680175Z PRINT Zigbee Smoke/CO Detector Mc  Memory >>>>>>>        2514.0703125     Kbytes
  • New version:
2024-02-04T16:00:30.418494276Z PRINT Zigbee Smoke/CO Detector Mc  Memory >>>>>>>        1905.1767578125  Kbytes

Modified Z-Wave Siren Mc too, with 11 subdrivers:

  • Old version:
2024-02-04T16:52:47.794624671Z PRINT Z-Wave Siren Mc  Memory >>>>>>>    3393.8681640625  Kbytes
  • New version:
2024-02-04T16:55:04.889912430Z PRINT Z-Wave Siren Mc  Memory >>>>>>>    1200.46875       Kbytes

Modified Z-Wave Bulb Mc too, with 5 subdrivers:

  • Old version:
2024-02-04T17:10:26.316050726Z PRINT Z-Wave Bulb Mc  Memory >>>>>>>     2385.4296875     Kbytes
  • New version:
2024-02-04T17:16:27.292514539Z PRINT Z-Wave Bulb Mc  Memory >>>>>>>     1160.7861328125  Kbytes

Measured just after the installation of each version.

I will try these 6 modified drivers to see if everything works well

After having 6 drivers installed using only the subdrivers of the devices that I have and an apparent reduction in memory usage, the status of the Hub driverMemoryLimitStatus remains the same, SoftLimit

I don’t understand why you release the beta versions of the firmware and hide to the volunteer testers what new things they can try.

Well this is going to give me a lot of work to modify all the drivers :man_facepalming: so that users of my drivers can benefit from this possible good improvement when the official firmware version is released.

And you too, I only see the modified Z-wave Switch in your github

6 Likes

Hello - We have released 0.52.6 to the V2/V3 Customer Beta population.

52.6 Release Notes:

  • Various fixes improve Zigbee and Thread radio stability

I guess this is the ‘lazy loading of sub-drivers’ thing? I read the pull request last October but hadn’t grasped that it hadn’t been committed then until I saw a similar pull request in mid-January that referenced the change required in the Lua libraries. It did seem like an obvious change to make (with hindsight).

I would have thought that they’d want the changes to the libraries and the Zigbee Switch to be beta tested before they started encouraging community developers to follow suit. However I personally prefer to be warned of areas of interest as unless my hub starts doing something unusual like tap dancing on the shelf I am probably not going to notice anything.

2 Likes

Hey @Mariano_Colmenarejo, your opinion definitely matters to us and we’re a fan of the work you’ve done on the platform with all your community drivers. I’m going to discuss with the team to provide a recommendation on use of the lazy sub-driver loading features and any considerations that go along with its use.

It’s great to see the reduction in memory for your drivers. With regards to SoftLimit/HardLimit, there’s a range of values there so it is not entirely unexpected that reducing the memory of drivers doesn’t move it out of that window. There’s also some things in play under memory pressure that may result in a reduction in memory for drivers improving performance without changing the number measured for “total” driver memory consumption (e.g. memory regions being swapped out to compressed memory, etc.). In those cases, reducing memory may improve system performance by reducing page cache faults even if it doesn’t move the needle for SoftLimit.

4 Likes