Aeotec Smart Home Hub/2018/2015 Model Hub Firmware Release Notes - 0.52.11

Announcements Hub Firmware Release Notes
1

UPDATE: There has been an increase in the firmware version number since the start of the release. This post has been updated to reflect this new information.

We will begin rolling out Samsung SmartThings Hub firmware version 0.52.11 starting Wednesday, March 6th. 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.

Hub Target:

  • Samsung SmartThings Hub 2015 (Hub v2)
  • Samsung SmartThings Hub 2018 (Hub v3)
  • Aeotec Smart Home Hub

Release Date: 6 March 2024 ~ 14 March 2024

Note that this release will be spread out over two weeks, so you may not see your Hub update on the first day of the release period.

Release Notes

General

  • Users can create and update Multi-Hub networks with Samsung SmartThings Hub 2018 & Aeotec Smart Home Hub.
  • Increased the delay on join before telling sleepy Z-Wave devices to sleep to ensure they are fully configured.
  • Changes default configuration for the following Zigbee clusters to reduce battery drain. Users may want to re-add contact, motion, or temperature sensors if they notice high battery drain. Configuration changes included:
    • The measured temperature should now only send spontaneous reports if the temp changes by 1C (up from .16C), and the maximum time between reports is now 10 minutes, up from 5.
    • The Intruder Alarm System Zone cluster is no longer a configured/monitored attribute, meaning the hub will no longer ping it if it hasn’t been reported and instead rely on the device sending us spontaneous reports.

Edge Drivers

  • Added the ability to delete LAN and EDGE_CHILD devices from the driver that manages them. The Philips Hue driver will now automatically add devices when they are added to the Hue bridge and delete them when they are removed from the Hue bridge.
  • Library Updates:
    • Updated native json module to allow for JSON array encoding of lua tables, and added documentation explaining differences between native json module and dkjson.
    • Upgraded the luncheon http library for bugfixes and to enable chunked encoding.
    • Updated lustre websocket library for flexibility in websocket handshake headers.
    • Upgraded xml2lua library to pull in new features.
    • Deprecated st.base64 library in favor of GitHub - iskolbin/lbase64 at v1.5.3.

Device Firmware Updates

  • For newly claimed Hubs, eligible Zigbee and Matter devices will be updated automatically.
  • The options for device firmware updates are changing as follows:
    • Disabled → Manual update - you have the option to manually apply an update on a device-by-device basis if one is available.
    • Enabled / Enabled with Lights → Automatic update - if an update is available, it will be applied automatically with some exceptions, including Zigbee lights known to turn on after the update and battery-powered devices with < 15% battery remaining.
    • The new options are already reflected in my.smartthings.com and will also be reflected in the SmartThings app soon.
8 Likes
2

Hi - when are we getting a firmware update for ‘SmartThings WiFi Mesh’ Model ET-WV525 which was released back in 2018? I see constant updates for the 2015 (v2) and 2018 (v3) hubs, but never anything for ‘SmartThings WiFi Mesh Model ET-WV525. Why? Things have been broken for a while now and I have a separate thread going on this. I have yet to receive a call back from Samsung support with my particular issue, but there are other serious issues going on as well with this platform including in the Plume app. Can you please enlighten us users? Thank you for any feedback!

6 Likes
3

Hi,

Is the lazy_load_sub_driver function that loads only the necessary subdrivers for devices paired to the driver also a relevant change to comment on?

The stock Z-Wave Switch driver from the production channel already has this function and will be executed when the hub firmware is updated. Perhaps a confirmation would be convenient for users who use this driver to take it into account in case something does not work as expected.

With the beta firmware I have not had any problems with this driver and lazy_load function, but I only have devices that use 2 subdrivers of the 19 that the Z-Wave Switch driver has

thank you

2 Likes
4

Interesting. Other than the Thread Border Router capability, I think this is the first feature difference between the V2/2015 and V3/2018 hubs.

I don’t suppose we’ve got any clue how a “multi-hub network” differs from what is currently available…

3 Likes
5

Multi hub networks in this context are thread fabrics. So that’s why the V2 is not included.

Starting with the SmartThings Station, users can now create a multi-hub network in their home, adding additional hubs to their primary one, which becomes part of the Thread mesh. Doing so allows Matter devices to connect to the most optimal or closest hub, extending the range and reliability of their network. This will allow users to put more devices in more places around their homes while experiencing the reliability and responsiveness of local connectivity.

From the previous announcement, which initially applied only to station hubs.

4 Likes
6

Thanks, @JDRoberts !

Almost makes Thread sound useful. :rofl:

4 Likes
7

When it says re-add, can you just reset a zigbee device and rejoin it, or do you need to actually remove it from the hub and re-add it? If the latter, that would be a lot of effort to redo automations. Do I also read the second bullet to be possible battery saving if you have a device capable of being used in smart things home monitor, but are choosing not to?

3 Likes
8

How about improvements to location tracking? My location has been very poor lately, using pixel 6 and Samsung s23 ultra.

1 Like
9

I am also wondering the same thing, as I have about 30 devices currently experiencing the dreaded and ridiculous battery drain issue(s). That said, it is encouraging to finally, after long long last, see an attempt to actually address the issue(s)… I won’t be holding my breath in anticipation of this actually working tho.

5 Likes
10

Great news that Thread support is improving and now at least their own hubs can share the same Thread network.

I guess the next step is opening up a bit to use the standard APIs provided in Android or iOS so they can either join a existing Thread network or let others join the one created by the hub.

5 Likes
11

I believe the Station multi-hub implementation also merges the Zigbee networks. But i’m guessing the multi-pan setup in the V3/Aeotec makes it easier to implement the same way as the Station vs the V2’s zigbee-only chip.

2 Likes
12

Hi,

The second point of battery saving refers to the fact that cluster 0500 and attribute 0002, used for motion, contact, water leak, smoke detector and others sensors, will no longer be configured and monitored.

Attribute monitoring is used to trigger Health Check when no messages are received from the monitored attribute for x time and send a read device attribute command, ping.

This does not save any battery, because these devices are asleep and do not pay attention to the ping, but this does reduce the number of messages on the zigbee network, in a useless procedure in sleeping devices.

What no longer fits me is that they say that they do not configure attribute reports.
This would mean that the device will not send periodic reports to the hub and could appear offline after a few hours of non-use.

I have seen in the stock zigbee motion sensor code that they send a configuration (0xFFFF, 0x0000, 0), equivalent to default configuration, instead of current default configuration (30, 300,1) until it is implemented in the 52.x libraries

This could save battery if the reports were configured by default at (30,900,1) 900 seconds maximum interval or greater, I have them configured at 3600 sec my sensors and it works very well.

When they publish the code of the libraries we will clear up doubts about what they are really going to do

3 Likes
13

Hi,

I have the beta 52.09 firmware installed on my v3 hub and I was starting to modify my drivers to adapt them to the new firmware libraries 52.09 and my surprise is that I keep seeing that every time the driver is initialized, attribute 0x0002 of cluster 0x0500 continues to be included in the monitored_attrs table and in fact the health_Check continues to be executed if I force that no messages arrive in 1.5 times the 300 sec of the default configuration (450 sec).

Here are the logs that prove it, I added a function to manually remove attribute 0002 from the monitored_attrs table in my drivers and I found this surprise, for me of course.

Can see the attribute 0x0021 (33 dec) (battery percentage remaining) 32400 sec (21600 x 1.5) and 0x0002 (IASZone.attributes.ZoneStatus) 450 sec (300 x 1.5) in my 4 contact sensors, before manually removing attribute 0x0002.

2024-03-05T21:31:28.682133865Z TRACE Zigbee Contact Mc  Found DeviceLifecycleDispatcher handler in zigbee_contact
2024-03-05T21:31:28.760628657Z PRINT Zigbee Contact Mc  monitored_attrs-Before remove att 0x0002 >>>>>> {{33={expected_interval=32400.0, last_read_time=1709652802}}, {2={expected_interval=450.0, last_read_time=1709674028}}}
2024-03-05T21:31:28.832102282Z PRINT Zigbee Contact Mc  monitored_attrs-after remove att 0x0002 >>>>>>  {{33={expected_interval=32400.0, last_read_time=1709652802}}}
2024-03-05T21:31:28.910306198Z PRINT Zigbee Contact Mc  ***** function no_offline *********
2024-03-05T21:31:28.988977532Z DEBUG Zigbee Contact Mc  Puerta SĂłtano device thread event handled
2024-03-05T21:31:29.026907448Z TRACE Zigbee Contact Mc  Found DeviceLifecycleDispatcher handler in zigbee_contact
2024-03-05T21:31:29.081279365Z PRINT Zigbee Contact Mc  monitored_attrs-Before remove att 0x0002 >>>>>> {{33={expected_interval=32400.0, last_read_time=1709652786}}, {2={expected_interval=450.0, last_read_time=1709674039}}}
2024-03-05T21:31:29.086680365Z PRINT Zigbee Contact Mc  monitored_attrs-after remove att 0x0002 >>>>>>  {{33={expected_interval=32400.0, last_read_time=1709652786}}}
2024-03-05T21:31:29.117326657Z PRINT Zigbee Contact Mc  ***** function no_offline *********
2024-03-05T21:31:29.188020240Z DEBUG Zigbee Contact Mc  Puerta Portal device thread event handled
2024-03-05T21:31:29.272237240Z TRACE Zigbee Contact Mc  Found DeviceLifecycleDispatcher handler in zigbee_contact
2024-03-05T21:31:29.548379740Z PRINT Zigbee Contact Mc  monitored_attrs-Before remove att 0x0002 >>>>>> {{33={expected_interval=32400.0, last_read_time=1709652733}}, {2={expected_interval=450.0, last_read_time=1709674016}}}
2024-03-05T21:31:30.068850490Z PRINT Zigbee Contact Mc  monitored_attrs-after remove att 0x0002 >>>>>>  {{33={expected_interval=32400.0, last_read_time=1709652733}}}
2024-03-05T21:31:30.512952574Z PRINT Zigbee Contact Mc  ***** function no_offline *********
2024-03-05T21:31:30.621681615Z DEBUG Zigbee Contact Mc  Puerta Felisa device thread event handled
2024-03-05T21:31:30.672240449Z TRACE Zigbee Contact Mc  Found DeviceLifecycleDispatcher handler in zigbee_contact
2024-03-05T21:31:30.737956990Z PRINT Zigbee Contact Mc  monitored_attrs-Before remove att 0x0002 >>>>>> {{33={expected_interval=32400.0, last_read_time=1709652788}}, {2={expected_interval=450.0, last_read_time=1709674086}}}
2024-03-05T21:31:30.742851074Z PRINT Zigbee Contact Mc  monitored_attrs-after remove att 0x0002 >>>>>>  {{33={expected_interval=32400.0, last_read_time=1709652788}}}

If I remove the contactSensor capability from the driver Template, then at driver initialization the attribute 0x0002 is not added to the table monitored_attrs.

Only battery percentage attribute is in the table monitored_attrs

2024-03-05T21:35:23.786191276Z TRACE Zigbee Contact Mc  Found DeviceLifecycleDispatcher handler in zigbee_contact
2024-03-05T21:35:23.901483276Z PRINT Zigbee Contact Mc  monitored_attrs-Before remove att 0x0002 >>>>>> {{33={expected_interval=32400.0, last_read_time=1709653021}}}
2024-03-05T21:35:24.081462067Z PRINT Zigbee Contact Mc  monitored_attrs-after remove att 0x0002 >>>>>>  {{33={expected_interval=32400.0, last_read_time=1709653021}}}
2024-03-05T21:35:24.184546942Z PRINT Zigbee Contact Mc  ***** function no_offline *********
2024-03-05T21:35:24.258742776Z DEBUG Zigbee Contact Mc  Puerta SĂłtano device thread event handled
2024-03-05T21:35:24.332760442Z TRACE Zigbee Contact Mc  Found DeviceLifecycleDispatcher handler in zigbee_contact
2024-03-05T21:35:24.373471942Z PRINT Zigbee Contact Mc  monitored_attrs-Before remove att 0x0002 >>>>>> {{33={expected_interval=32400.0, last_read_time=1709652963}}}
2024-03-05T21:35:24.447847817Z PRINT Zigbee Contact Mc  monitored_attrs-after remove att 0x0002 >>>>>>  {{33={expected_interval=32400.0, last_read_time=1709652963}}}
2024-03-05T21:35:24.531103317Z PRINT Zigbee Contact Mc  ***** function no_offline *********
2024-03-05T21:35:24.633107401Z DEBUG Zigbee Contact Mc  Puerta Felisa device thread event handled
2024-03-05T21:35:24.704865401Z TRACE Zigbee Contact Mc  Found DeviceLifecycleDispatcher handler in zigbee_contact
2024-03-05T21:35:24.780308651Z PRINT Zigbee Contact Mc  monitored_attrs-Before remove att 0x0002 >>>>>> {{33={expected_interval=32400.0, last_read_time=1709653037}}}
2024-03-05T21:35:24.855789776Z PRINT Zigbee Contact Mc  monitored_attrs-after remove att 0x0002 >>>>>>  {{33={expected_interval=32400.0, last_read_time=1709653037}}}
2024-03-05T21:35:24.924168234Z PRINT Zigbee Contact Mc  ***** function no_offline *********
2024-03-05T21:35:25.009041151Z DEBUG Zigbee Contact Mc  Puerta Casa device thread event handled
2024-03-05T21:35:25.130851401Z TRACE Zigbee Contact Mc  Found DeviceLifecycleDispatcher handler in zigbee_contact
2024-03-05T21:35:25.452334526Z PRINT Zigbee Contact Mc  monitored_attrs-Before remove att 0x0002 >>>>>> {{33={expected_interval=32400.0, last_read_time=1709652973}}}
2024-03-05T21:35:25.519705109Z PRINT Zigbee Contact Mc  monitored_attrs-after remove att 0x0002 >>>>>>  {{33={expected_interval=32400.0, last_read_time=1709652973}}}

Is the Beta 52.09 firmware the same as the final 52.09 firmware that will be updated starting tomorrow?

Is it something I have misunderstood?

Thanks

4 Likes
14

Does this Multi-Hub Mesh update apply to TV’s aswell? Considering that they’re mostly all open-thread networks :thinking:

15

The 52.x libraries are available now. I’ve only taken the briefest of looks and I have a limited understanding of them anyway.

All I could see was a method in the motion sensor defaults that could be used to turn off configuration and monitoring on the IAS Zone cluster. The comments were a little garbled and to me just suggested that here was a method to do the job for you if you wanted to, which you might want to.

That’s as far as I got.

It doesn’t really inspire confidence to see comments that refer back to the device handlers like they are a source of long lost ancient wisdom to be emulated but not truly understood.

3 Likes
16

I answer myself.

Investigating the stock drivers I have been able to see that point 2 for saving battery with the configuration and monitoring of the IASZone cluster does not refer to all the devices in the driver, only to certain devices within the driver and that is why in each initialization of the driver all devices are added to the attribute monitoring table and then in the init lifecycle need remove from the list the ones they think should be removed.

That’s what I was doing in my drivers, but it didn’t fit and it still doesn’t fit, due to one note in the stock drivers that it would no longer be necessary remove monitoring and configured attributes with the new libraries.
I understood that they were referring to the 52.9 libraries, but that may not be the case

-- TODO: the IAS Zone changes should be replaced after supporting functions are included in the lua libs
local do_init = function(driver, device)
  device:remove_monitored_attribute(zcl_clusters.IASZone.ID, zcl_clusters.IASZone.attributes.ZoneStatus.ID)
  device:remove_configured_attribute(zcl_clusters.IASZone.ID, zcl_clusters.IASZone.attributes.ZoneStatus.ID)
end

I will continue looking for the light among the fog, hahaha.

4 Likes
17

Thanks for advice, I will look at them more carefully tomorrow, but at first glance, I have only seen what you refer to in the motionSensor defaults, but I have not found in the stocks drivers when that function is called directly, they may add it in the near future.

In any case, I understand that healtCheck is eliminated on sleeping devices since it is of no use, but that the configuration of periodic reports of the IASZone attribute is not carried out is something I do not fully understand, without modifying what currently seems to cause them to be displayed offline contact and motion devices, no messages received for about 2 hours.

To reduce battery consumption, I would understand that the maximum interval should be extended from 300 sec to a longer one, I use 3600 sec and it works perfectly, but hey, we’ll see.

1 Like
18

Hi,
Im guessing is related to this, all my zigbee devices went offline last night, and it has not worked since. Any idea when will this be fixed???

1 Like
19

Suggest you check the firmware version on your hub to see if it was uodated to 52.09

20

It actually wasn’t, it is still 51

2 Likes