It would be good if it was something like that where a fix could be added before it was too late.
Otherwise if there was a bug in 52.9 that got past beta testing then the beta testers probably aren’t going to know if 52.11 is fixed, only if it has gone horribly wrong. That’s actually fair enough as the bugs in betas aren’t supposed to hit you in the face. It is just nice to have some guidance on what the changes are so you know how best to help.
All my devices no longer report ZDO messages from the Basic cluster with each ZCL ReportAttribute message.
Except for 2 Tuya plugs that do not accept the new configuration, they must be wrong, because other identical ones have updated themselves perfectly.
Only some battery powered devices that are normally asleep have had to be re-paired with quick and easy the method:
A/C powered devices reconfigured themselves with firmware update and Hub reboot
I don’t seem to be getting beta updates even though centercode says I’m in it 
even after reboots and resets to force it to check for updates
I believe we’ve spoken about issues with the beta access before but I think the problem is worse now
Hi @alissa.dornbos ,
I’m not sure what various fixes were included in 52.11, but this morning I have 6 devices offline, all battery powered. 4 motion sensors, 1 contact sensor, and one door lock. All Zigbee. I don;t have time to look at this for a while, but from my perspective, things are not getting better. If it’s a battery reporting issue, I’ll find out, if it’s another change in the Zigbee stack that is having unintended consequences, please figure that out. Also, can ST please be more specific on the release notes??
EDIT: Make that 11 Zigbee devices offline now. 3 contact sensors, 1 lock, 2 switches, and 5 motion sensors. Unfortunately I’m nowhere near home to diagnose this.
EDIT: All devices back online as of 3:15pm. One motion sensor needed the battery replaced after a new one was consumed in a week, so hopefully a reset and rejoin will force the updated changes mentioned elsewhere. Root cause was that one of the two switches (actually Jasco outlets) locked up, froze, or something and needed to be power cycled to get it back online. Because of this, I assume, Zigbee routes through these outlets failed and caused the other devices to go offline. That begs the question of why didn’t Zigbee messages reroute, and/or was the failed switch alive just enough to still be seen as a valid router in the mesh? @JDRoberts I’d be curious of what you think.
BTW, The breaker I reset also had the other outlet on the same circuit so I’m not sure which of the two outlets would be the problematic one. Regardless, these are being replaced by Inovelli’s dual outlets when they become available.
Zigbee devices don’t reroute on the fly the way z wave devices do. Instead, at the time of joining, each new child device chooses its parent and then it only knows about network options that that parent tells it about. This can lead to what is called “the orphan problem“ in Zigbee, where a child device gets lost for a while because its parent is not available.
Eventually, things will get sorted out, but it can take several hours or even until the next day. And in a few cases, it doesn’t fix itself until the device selects a new parent.
this problem was much worse in ZHA 1.2 then in Zigbee 3.0, so that’s the good news. The following describes the ZHA 1.2 process.
Information Only: ST not working 100%. Heal zigbee network - #13 by JDRoberts
With Zigbee 3.0, Devices no longer give themselves the orphan designation, And the finding a new parent can happen much more quickly. But it still takes at least until the next check in.
So it’s pretty common in Zigbee For problems to resolve themselves in a day or so, but not immediately. And Zigbee 3.0 devices will have fewer problems of this type than the older ZHA 1.2.
Thank you for that summary!
I kind of suspected a mesh issue when I saw the outlets show up as offline. These older Jasco outlets have become unreliable lately, and they’re next on my list for replacement.
Hello All
I want to communicate that for users previously in the 52.X Release, we will be pushing an update to 52.20 tomorrow Friday, March 15. This release involves the following changes. Please let us know if you see anything concerning.
52.20
Release Target: Friday March 15
Thank you!
I remember having to write release notes for my software that are as non-informational as this, due to “corporate policy.” Is there any way you can elaborate on exactly what this changes? Totally understand if policy prohibits you from saying…
Seriously. This is why I won’t participate in the beta program. Yes, I am critical sometimes of things not caught in beta and perhaps I shouldn’t if I don’t contribute but, I can’t work with a lack of information like that.
Totally understand! (I just left the Sonos Beta program.)
Back in the day (this was the late '80s, early '90s) I worked for one of the big-three minicomputer manufacturers, writing what amounted to embedded printer drivers. It was “corporate policy” to only document customer issues fixed in a release! Not issues fixed that happened to be noticed by engineering or the QA group. (Yes, that was back when we had QA groups and test scripts and thorough regression testing. There were about fifteen people testing printers!)
Now, I understand modern development philosophies and that speed-to-market is important. But my experience is that software developers–particularly those who didn’t develop the original software–tend to add bugs. They don’t “know” the code. They are notoriously poor testers. Okay, I’ll admit when I was managing software teams, they got tired of listening to me! 
But all of that is moot anyway when management says, “Ship it!”
Will this fix the Z wave edge driver memory issue that community members have been reporting on the production release?
And that is the crux of the issue …
Hmm, Zigbee devices too maybe… The behavior Eric mentions has also been observed with Zigbee devices.
Hello Everyone
Thank you again for your participation. We are releasing 0.52.21 to V2/V3 previously enrolled Customer Beta Hubs tomorrow Thursday, March 28, 2024.
Please see these release notes regarding 52.21
My v3 hub just finished updating to beta version 52.21.
With 25 drivers and 75 devices between zigbee, zwave and virtual
I was just able to see the initialization process after the firmware update (hub green led on) with the CLI logs, and it took about 7 minutes to stabilize the hub memory driverMemoryLimitStatus.
Hub has stopped initializing one driver approximately every minute sequentially when the memory has changed from hardLimit to softLimit status.
I already have 7 drivers that use the “lazy_load_sub_driver” function, which only loads into memory the subdrivers that have paired devices and are supposed theses drivers to require less hub memory.
I imagine that in hubs with a higher load of devices and drivers it will take much more than 7 minutes to memory stabilize.
I think this must be taken into account this stabilize time when user rebooting the Hub, since it may take a long time for everything to work correctly.
I have not seen any offline devices during the process