55.X Hub V2/V3 Customer Beta Release Notes

Developer Programs Hub Firmware Beta
1

55.X Customer Beta Release Notes

Hey everyone!

We’re excited to announce the start of a new SmartThings Hub Firmware Beta. Version 0.55.2 will begin rolling out in batches starting no sooner than 13-Nov-2024. 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.

Version

  • 0.55.2

Hub Target

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

Release Date

  • Release Date: 13-Nov-2024 or 14-Nov-2024 Version 55.2
  • Release Date: 05 Dec 2024 Version 55.4

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

  • Fixed a race condition during Zigbee device firmware updates where status messages can be received out of order, resulting in the status “Requesting update” being displayed until the update completes when “Updating” should have been displayed.
  • Fixed an issue that may affect onboarding for battery-powered Zigbee devices in certain (uncommon) situations.

Edge Drivers

  • Extend the latency improvements for default handlers introduced in the 0.54 release to include Color Temperature and Color Control capabilities for Zigbee and Z-Wave devices.
  • Fixed a bug related to very large messages in the communication layer between edge drivers and the hub software
  • Made performance improvements for drivers that opt out of the Zigbee attribute monitoring functionality that is provided by default for Zigbee drivers.

NOTE

Anyone who participated in the previous beta is automatically signed up for this one, unless you have unenrolled.

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 or reach out to a SmartThings team member to assist.

4 Likes
2

Can you please elaborate on this. I’ve been struggling with health check and battery powered ZigBee leak sensors. @nayelyz has also been talking to the team but this looks like another. :wrench:
Would appreciate some clearer guidance on how health check works and the impact of this change. Does this mean that health check is disabled for battery operated devices which use default configurations ? Does this apply all default configurations (battery, IASZone, Temperature etc)!

1 Like
3

Would appreciate some clearer guidance on how health check works and the impact of this change. Does this mean that health check is disabled for battery operated devices which use default configurations ? Does this apply all default configurations (battery, IASZone, Temperature etc)!

Sorry for the confusion Rboy, this release note is not clear. The only change related to the zigbee attribute health monitoring (which we automatically do by default based on monitored/configured attributes in the driver) is that if the driver opts out of this monitoring, it actually gets the latency and memory savings from opting out. The hub is tracking device health for all hub connected devices in some way, including battery devices. The monitoring functionality provided by the Lua libs will only stop if your driver opts out of it.

For context, this change was made because we will be making ST drivers opt out of this monitoring to get the small memory/latency improvement. The functionality itself has been there since edge drivers were first released, and its purpose is to be a defensive mechanism to try to keep devices online, but the hub has its own algorithm for determining device health based on protocol, capabilities, and device configuration. The attribute monitoring mechanism in the zigbee lua libraries is not something that directly affects the health of a zigbee device, and the only way it would affect it is if it causes a device to send a message to the hub; it is not involved in determining the length of time without communication it takes for a device to be marked offline.

4

Just so I understood your comment about ZigBee devices attribute monitoring not affecting the heath status. I can have no attributes being monitored or have some monitored with a large reporting interval and it will have no impact on the device health.

For clarification:

If the driver opts out of Heath monitoring (and how does one do that)

  • Does that mean that HubCore will not longer mark the device offline?

OR

  • Does it mean that the driver now needs to manage the online / offline status of the device?

Also what is the longest a ZigBee battery device can go without sending a message before being marked offline? I’m really struggling with this one because I’ve noticed that if I configure a device to send reports every 4-6 hours it gets marked offline! I’ve had to reduce that reporting interval to 2 hours to prevent it from being marked offline which is very excessive and can drain battery life.

1 Like
5

I think it would all be a lot clearer if the release notes removed the word health and just referred to ‘Zigbee attribute monitoring’. I don’t think I’ve ever seen ‘health’ used in that context before. All it does is make you think of ‘device health’ which is something different.

My understanding is that monitored attributes don’t really gain you anything if you have a well behaved device that is reporting in regularly using well understood capabilities/attributes. They are more useful for devices that basically need polling now and again or have obscure custom functionality.

It sounds like it has been established that not monitoring attributes by default gives a worthwhile performance benefit with no real negatives.

2 Likes
6

Zigbee attribute monitoring is used, so far, to trigger a function called healt_check when the device has not sent messages for that attribute monitored for 1.5 times the maximum interval configured in the device attribute.

This function performs a reading of the attribute until it responds or a spontaneous message is received, “reportAttribute command”

It does not intervene at all in the offline monitoring of the device, we knew that a long time ago, and offline status only depends on a SECRET algorithm in the hub.

In battery-powered devices that sleep deeply, healt_check has never been of any use, since they are asleep and neither listen nor respond to attribute readings.

In mains-powered devices, they do respond to that reading of the healt_check and reset the function until 1.5 times the maximum interval of receiving messages from the attribute has elapsed again.

So, I think it’s right that for devices with battery and that sleep deeply, something that is useless should be removed.

There are devices with battery that do respond to heat_check and refresh, samjin sensors (smartthings, aeotec, motion, multipurpose…)

If monitoring is removed for all zigbee devices, if they are fine configured and do not exceed the interval threshold of the SECRET algorithm there should be no problem, but we will see what happens with devices when users change from one driver to another (zigbee thing for example) and the device configuration is not done???

The time to mark offline zigbee devices with on/off attribute is about 20 or 25 minutes without receiving messages.

For battery powered sensors it is about 2 hours. (smoke, contact, motion,…)

Observed so far, wasting time to be able to understand it, since nobody in smartthings reports it and that we need configure our devices without the battery running out prematurely and not being marked offline

4 Likes
7

It would be awesome if there was a button in the app under the hub settings to check for a recent firmware update.
Im still waiting here, still no v55 update.

8

I’ve not had an update either, though I’ve changed my hub details on Centercode and that always creates uncertainty.

9

Mine got updated to 55.2 half an hour ago, I have a routine in Google Home to notify me if a sensor went offline and everything was offline for a brief time so that must be it.

No problems so far, all the devices came back online.

Edit: If anyone is interested about the notification when a sensor goes offline: Routine in Google Home to notify me if a sensor went offline - #2 by mocelet

10

Hi @carter.swedal

Rereading the clarification about attribute monitoring in firmware version 55.x post, I see the correct interpretation is that the default attribute monitoring is not removed by default and what they are going to do is remove it in the stock drivers and make it optional to disable it for other non-stock drivers, in order to improve some memory and latency.

language comprehension problems!

I have tested the new firmware 55.2 and indeed if you do not disable monitoring of the device attributes with the device:remove_monitored_attribute(cluster_id, attribute_id) function, after device configuration, they will continue to be monitored as before.

On the other hand, I know I’m persistent, but there are users who could be affected by this problem:
I have also found that in this firmware version 55.2, when reinstalling a device without previously uninstalling it, the init life cycle is still not executed, but the doConfigure life cycle is executed, and therefore in these cases, if device need a custom configuration in the driver will be reconfigured with the default configuration.

In the App, when you perform a diagnosis for an offline zigbee device, at the end of the process the user is advised to solve the problem:
“Reset the device and try to add it again.”
I understand that this is called reinstallation without uninstallation.

1000019519
1000019519864×1920 76.2 KB

11

I am still struggling with this.

I understand that the custom configuration is typically defined in the ‘init’ lifecycle and then used to configure the hardware in the ‘doConfigure’ lifecycle.

What I don’t understand is why the driver would forget the custom configuration as a result of the ‘reinstallation without uninstallation’. The driver wouldn’t know the device has been reset. Indeed it doesn’t seem to know anything is happening until another ‘doConfigure’ lifecycle comes along. Isn’t the whole point that the device hasn’t been uninstalled and so shouldn’t need another ‘init’?

If there is an issue (and your seeing one is more than good enough for me to believe there is one) it is that some or all of the typical content of an ‘init’ handler appears to be needed at a point when it reasonably shouldn’t be needed. So the question is really why does it seem to be needed? Is the ‘reinstallation without uninstallation’ a little more destructive than has been allowed for?

12

The driver does not forget the configuration, the one that forgets the configuration is the device, because it resets and goes into pairing mode.

The Hub detects a device attemting to join and configures it, but now it will configure it with the default reporting intervals instead of the custom ones, if it needs them, because those custom values ​​are in the function that is executed in the init lifecycle, which is not executed in these cases.

Yes, when a device is added to the driver for the first time it follows a path and it should follow the same one, except for the added lifecycle, since the device already exists, but smartthings now excludes init as well and according to its definition, which can be seen in the stock driver function name, init = device initialization not driver initialization

local device_init = function(self, device)
  device:set_component_to_endpoint_fn(component_to_endpoint)
  device:set_endpoint_to_component_fn(endpoint_to_component)

  local configuration = configurationMap.get_device_configuration(device)
  if configuration ~= nil then
    for _, attribute in ipairs(configuration) do
      device:add_configured_attribute(attribute)
      device:add_monitored_attribute(attribute)
    end
  end

  local ias_zone_config_method = configurationMap.get_ias_zone_config_method(device)
  if ias_zone_config_method ~= nil then
    device:set_ias_zone_config_method(ias_zone_config_method)
  end
end

I know you think that code should be in doConfigure instead of init, my drivers already have it in both. All that’s left is for smartthings to decide and fix the firmware or fix their drivers, in the meantime they are misconfiguring user devices when they reinstall them, for example, when they try to stop them from being marked offline and users don’t know it and the worst thing is, when they fix it they will still be misconfigured until they are reinstalled, if someone warns them.

3 Likes
13

OK let’s talk in terms of configured attributes. They typically get set up in init along with other stuff that initialises the device in the driver.

When doing a ‘reinstallation without uninstallation’ these configured attributes need setting up again. I am asking why. Why are they no longer configured attributes?

If, as part of the reinstallation, the driver device object is destroyed and and a new one created then yes there should without question be an ‘init’.

If the driver device hasn’t been recreated then why doesn’t the driver still have the custom configured attributes when the ‘doConfigure’ comes calling to configure the hardware?

My point was that there are two scenarios there and I am not currently able to test them for myself to know which is correct.

If it is the former then ST are clearly missing an obvious need for the driver device to be initialised.

If it is the latter then ST are missing something more subtle. They probably think the ‘init’ isn’t necessary but clearly something has actually been lost.

Actually I don’t. I did think that for a few hours but revised my opinion when I saw what I had overlooked.

2 Likes
14

Is it just me thats noticed responsiveness seems to have become sluggish? Ive noticed with this update that turning anything on or off, whether it be zigbee or zwave, it is noticeably slower to initiate and is very annoying now with this update. Also, my zigbee rgbw controllers are still randomly disconnecting, but then are able to reconnect after maybe 10 minutes… very annoying, but this has been an issue for months.

15

Since you are more persistent than me, you have made me recreate everything and check cli logs against and indeed the configuration values ​​of the attributes are saved with device:get_field() and when the device is reinstated it does so with the same device.id and therefore the doConfigure function recovers with device:get_field() the configuration values ​​saved in the first init life cycle.

You are right and I am glad that it is ok

1 Like
16

Now I’m more confused than before.

When, where and how should I configure the reporting intervals?

Can you point me to a driver on your GitHub where you are configuring it?

(I just slapped it in doConfigure, because I thought that was enough.)

17

This is the correct function

2 Likes
18

This update is ruining the experience completely, my innovelli switches arent responding half the time now but nothing ever says disconnected but yet i cant control anything… this update is not good at all.

So none of my zwave innovelli switches are responding at all now, but my zwave locks are working… i dont get it.

I restarted the switches but got nothing.
Restarted the hub and my switches are back again… lets see how long.

19

I can have no attributes being monitored or have some monitored with a large reporting interval and it will have no impact on the device health.

@RBoy This is correct. The Monitored attributes and corresponding health check functionality does not affect the algorithm the hub uses to monitor device health.

If the driver opts out of Heath monitoring. Does that mean that HubCore will not longer mark the device offline? Does it mean that the driver now needs to manage the online / offline status of the device?

No, and no. As mentioned, the “health check” and monitored attribute functionality in the driver has no bearing on the algorithm the hub uses to determine device health for a device.

How does a driver opt out of attribute health monitoring?

Set health_check = false in your driver template.

Also what is the longest a ZigBee battery device can go without sending a message before being marked offline?

We made a configuration change so that most zigbee battery powered devices (namely sensors) will be marked offline after ~4 hours without the hub receiving communication from the device (As noted by others this was previously 2.5 hours). We did this to facilitate slightly more conservative reporting intervals for these devices. I’ll also remind you and others that multiple factors are used by the hub and platform to determine device health, and we do not guarantee this 4 hour configuration will be applied to all zigbee devices with the battery capability, and that we may change it in the future. I understand this is not ideal for driver developers, and I will continue to advocate within ST for changes to the way we determine device health so that we can support device configurations that save battery with long reporting intervals, as well as any other device configuration.

2 Likes
20

I always treat online and offline as suggestions. Unfortunately the mobile apps take them as absolute facts and can actually prevent users taking diagnostic or corrective actions. It would be nice to have an ‘Excuse me, are you absolutely sure the device is offline?’ button to bring the device back online.

3 Likes