Hub Firmware Beta 45.6

Hi, everyone, the team is reviewing these cases. If we need more info, we’ll let you know.
We’ll keep you updated.

Good evening .
Another problem after updating the HUB firmware. Yesterday due to continuous key response delays I unpaired and reset my three Fibaro KeyFob. Since then I have not been able to associate them anymore. When I try they are detected as Z-Wave devices with security S0-failure.

Thanks @nayelyz and @andresg,

I currently have 4 of the ikea dimmer switches that are inoperable and 2 ikea remotes which started working again after removing/adding the devices.

Both remotes are newer than the dimmers so i’m guessing this is a Compatibility issue with the new Zigbee Stack.

Is the there any method to push the Ikea firmware updates via the ST hub? Or are you able to add bacward Compatibility?

Hi, @Benjamin_Ginders

Thanks for sharing this new information. We already add it to the report.

Update 0.45.7 Rolled out on Oct 3 with the following changes:

  • Changes to provide additional diagnostic information to SmartThings Engineers to debug Zigbee issues.
  • Issue with edge drivers TCP servers fixed which could result in new connections not being accepted after two clients are accepted in a short window of time.
  • Limits for total memory used by edge drivers adjusted for V3; warnings for this will be shown in the mobile app when attempting device join through the catalog if above the low or high thresholds. The previous limits were set higher than intended and this feature would not have worked as intended for V3 hubs.

Ciao @nayelyz I tried to answer here but the topic is closed: Aeotec Smart Home Hub/2018/2015 Model Hub Firmware Release Notes - 0.44.09 Just to say that the problems we encounter in many in Italy with Vimar devices
(I talked about it in this topic [Vimar] user in italy?)
started with this firmware, before everything was ok.
If I can do anything else to give you more information let me know, thanks

Is there/will there be a way for the user to see/monitor memory use - maybe as a metric on the hub device in the app - before it reaches critical and triggers the warning?

1 Like

I point out that even after this update Zigbee from ide seems not detected and everyone disconnected. Tried several reboots, but the situation does not change and all zigbee devices obviously remain offline.

My Zigbee shows functional but Zigbee switch button presses are still not received by the hub.

I have readded 2 of the dimmers and tried switching drivers which works successfully along with battery reporting, the only thing that isn’t registered is button presses.

@posborne , @nayelyz, @andresg please feel free to pull another report from my hub, the connection should still be open.

Firmware 45.7. Now olse z-wave not detect

I started up logcat on all drivers and happened to catch a cycle where for about 15 minutes a different driver (I never saw the same one twice) restarted every 60+/- seconds. It seems like it’s done as I haven’t seen anything restart in the past 10 minutes. Is this expected behavior now? If so, how often is this happening?

I’m also seeing some suspicious disconnects in the IDE hub logs throughout the day. The hub hasn’t gone into a full tail spin though.

At the hard memory limit that is now enforced (prior to other failure points), this is part of the attempted recovery behavior. Though this is subject to change part of the current algorithm to attempt to get total memory back below the threshold is to stop and restart the “oldest” running driver (essentially random but consistent order to start) once each minute. In some cases, depending on the workload, some drivers may have had a memory usage spike which bloated their heap size beyond normal bounds and this recovery would eventually result in that memory stabilizing below the threshold.

As for the disconnects, we did identify cases where when the driver restarts happen that there can be high kernel CPU which can sometimes result in disconnects and there’s a fix for the case there I was able to reproduce that is planned to be in the next release to beta.

Ack, so the drivers are completely reloading during this attempted recovery? Which means messages/timers are likely to get lost or mishandeled?

PLEASE document these limits and give us tools so we can manage to them.


At least my Hub reset all the Zigbee groups upon update on the latest firmware.

This means all the Ikea buttons and some of the other Zigbee 3 devices required re-pairing or refreshing (as my drivers re-validate groups on refreshing)

for the multiple disconnection problems mentioned in this post:
[Vimar] user in italy?)
it happened even before installing the beta firmware 45.6 (and now 7), a friend of mine with the same problems solved by resetting the hub and then deleting all the zigbee devices and reassociating them.
Now I would like to try this path, but stopping only at reset, without deleting the devices. Is there anything that might be bothering me with having the beta firmware now? I think after the reset it will restore the same beta firmware and all edge drives that I currently have in the hub right? This one operation should clean up the hub, but not lose any data?

Multiple hub disconnects overnight. @posborne Assuming these new limits stay in place, what’s your best guess for the number of drivers that a v3 hub can now safely run?

1 Like

You guys need to allow force applying edge driver, as we could with stock DTHs.
There are many custom edge drivers of similar functionalities out there, just because fingerprints are not included in the stock edge driver.

If you allow force applying edge driver, it will help reduce unnecessary driver installations to the ST Hub, which could be helpful for saving memory usage.


It could do, but wouldn’t the limitation be that it would have to work with the default behaviour of the driver, when you might really want it to work like one of the sub-drivers? Or is there a way around that that I am not aware of because I really don’t like have limited understanding of Edge drivers?

If such a thing we’re allowed it would be good if ST could track the fingerprints of the devices being used in such a way to guide other users.

It would be sad to discover at this point in the game that our hubs are not going to be able to support a local execution installation with the current limits of 200 devices, 200 routines and 50 drivers.

It would be downright disappointing.

Or maybe smartthings hope that when everything related to the groovy stock DTHs in the Hub firmware disappears, which are still in the hub living with Edge, it will free up enough space for everything to flow correctly?