None of us know how rolling deployments are spread around. But I’d be willing to bet it isn’t batched up by country. My V2 hub updated without incident sometime in the last 48 hours.
Hi @jkp yes, it’s showing the firmware version 000.050.00010 in both the Advanced Web App and the Android client UI. But you’re right, that’s always the first thing to check. (It’s an “interesting feature”, it seems like the version info is being persisted in two different databases that aren’t quite keeping the values synced).
@TheHundredthIdiot useful to know, thanks. I’m on an Aeotec myself, AFAIK they are all v3. But as @HalD alluded to above, thinking about it it doesn’t make sense to rollout a firmware update region by region. Far better practice to implement a Canary Release model:
A small sample of hubs from each region are updated on day 1. Then after that 0.1% of users have the updates, the ST engineers look for signs the release broke something - either by uptick in support issues, viewing server logs etc. So if it did seem to break something, it’s only infuriated 0.1% of users, so then the release can be rolled back or fixed-forward with a patch. But if nothing broke they can try and release to a bigger batch, say 1% in the next few days, and monitor again. Then if successful go up to 10% and so on until everyone is upgraded or the whole release was binned.
That’s how I’d do it, anyway.
But if your Zigbee devices are offline before and after the release, well… it’s a moot point anyway
Still at 000.050.00010…
Correct. The Aeotec hub is the same hardware as the Samsung 2018/V3 hub.
from what I know, the hub v2/v3 rollout uses a gradual percentage deployment and can take a while (longer than you might expect) because everything is monitored for any new issues that could be associated with a new release. I don’t know what the algorithm does but as the percentage value is increased I would expect the new allotment would be used by the most active region at the time of the change. that could mean the rollout is somewhat biased based on the most active regions.
@jnettleton really interesting, thanks - the gradual percentage deployment sounds like the “canary release” that I described above - but perhaps that’s just a UK term in software engineering over here? Not sure, I’ll Google it 
But even more interesting was the last thing you said. The timezone differences and other temporal factors would almost certainly bias one region over another during a prolonged rollout. It makes a lot of sense now, thankyou!
… Was thinking where I got the original “rollout is by region” idea from - it doesn’t fit the aggregate anecdotal stories in these threads, and makes no sense for good-practice software engineering. That’ll teach me not to just repeat stuff i read parrot-fashion: I need to engage my brain instead!
perhaps there’s room for improvement. I’ll suggest trying a percentage in each region but it may not be feasible based on the total number of hubs. by region could be useful because of different devices, unique scenarios, internet speeds, etc.
Update paused - end date to be announced
Just adding to the ongoing set of issues resulting from 15.02. Erratic behavior of many zigbee smart lights going offline. Before 15.02 all my Juno Connects would rediscover properly if they went offline and were power cycled. My commercial electric lights do rediscover on power cycle. Now I have tried to delete and add the Juno(s), but the add success is sporadic and doesn’t help keep them from going offline. I also have multiple zwave devices that are now going offline. I hope the pause with 15.02 rollout is to actually roll it back. This is horrible…
North Eastern USA here and 2 of my V3 hubs have updated to 51 and 1 V3 Hub still at 50. No problems right now, everything is working normally.
Seems my device is also experiencing some odd behavior after the update, linked lights from Wiz and others randomly dime or reset, Aqara E1 connected to a V3 via matter no longer allows the paired devices to be seen as online when the Aqara app can control them fine. OLD devices showing up that were deleted over a year ago (Ring A19) bulb. Its as if my profile has somehow reset. Other than the Aqara devices this system has been up and stable for the last 5+ years. I have 137 devices and up until recently had no issues beyond the occasional reset of a bulb.
Hi,
FYI, i’m on firmware 51.01 as well, and all my Hue Motion Sensors keeps failing and dropping off the platform. It still shows the sensores is online in the ST app, but its no responding on motion nor automations. All motion sensors keeps dropping off after several hours. I have to reset the sensors and search for nearby devices to get them on again.
The sensors is connected directly to ST Hub via the Hue Motion Sensor driver.
Frustrating
I too am having all kinds of problems with zigbee devices going offline and using more battery in the last month or so. nothing has changed in my setup , only the new firmware releases. i’m on 51.02 now. Thanks for the christmas present smartthings!
Hi,
From time to time I perform a reboot or shutdown of the hub to free up space in the Hub’s memory, since I carry out many tests with drivers in development and that causes unwanted waste to remain in memory. Normally, after a reboot or turning off the hub, the memory status of my Hub V3 drops from Soft Limit to status OK.
I just turned the Hub off and on and the memory result has been very bad 
, it has gone up to Hard Limit and I can see in CLI logs all the drivers are rebooted sequentially time to time to free up hub memory.
I have done a reboot of the Hub from my.smartthings.com, advanced users and now it has worked fine again, the memory status is down to OK and all the drivers work correctly now.
There is something in firmware 51.02 that is not working fine and it does not always fail for everyone.
As I am quite persistent, I have tried reboot the Hub again several times and the memory status Hard Limit problem has happened again randomly and when it occurs the drivers are initialized sequentially in an order that initializes all the drivers.
This causes affected devices to performance poorly, with delays or not executing actions.
During the reboots of the hub I have monitored the logs with the CLI and I have seen to my surprise that errors were appearing in some drivers when executing the driverSwitched life cycle code.
Investigating a little more, driverSwitched runs with an error on devices that have a Provisioning State = DRIVER_SWITCH assigned.
This is the first time I have seen the driverSwitched life cycle run on a Hub reboot.
Maybe now someone will respond saying, well, it should be normal or that has always been happening on edge.
Well, my anticipated answer is that I reboot the Hub many times during driver debugging, to see how it behaves in these hub reboot processes, which are frequently carried out by updating the firmware or personally. I have never seen these errors in my drivers.
These errors are due to the fact that the driverSwitched life cycle, in my Mc drivers, includes a configuration code for the devices in which this configuration is critical for its operation and if users access the driver with a driver change from a different one, the configuration is necessary. Just as it was done in groovy when a device was changed from one DTH to another DTH in the IDE
The error occurs because some environment variables necessary for binding are not yet available in the drivers and a fatal error occurs.
I don’t know if drivers from other developers have code in the driverSwitched life cycle.
I have modified and published all my drivers that use the driverSwitched lifecycle, introducing a 2 sec delay to execute the configuration and set Provisioning State = “PROVISIONED” after configuration performed and the errors no longer occur.
Until they change something again it seems to work fine
I have rebooted the Hub several times and the errors no longer occur.
The memory status Hard Limit appears when starting init the drivers.
Sometimes in a few minutes the memory status goes to Soft Limit and then to Ok in other few minutes. Without any driver being reinitialized.
But other times it remains at Hard Limit for a long time and the drivers begin to initialize sequentially every minute or so and sometimes it takes up to 15 or 20 minutes to go down from Hard Limit to Soft limit and the drivers stop initializing and after a while the status changes to Ok status and everything starts working fine without delays
Perhaps it would be convenient when the Hub is rebooted to leave the app without using it until the memory status drops to soft limit and hub stabilizes.
I don’t know if this can help someone monitor their Hub with problems.
I have firmware vesion 51.02 and ever sense the uodate one of my zigbee motion sensors is detecting motion when no one is in room. I even took the motion sensor down and turned it over so it would be immposible to see motion. Do I need to reinstall the motion sensor?
My Ikea sensors always did this when their battery level was low
Anybody have any idea when the update, or a new one since it sounds like there is a problem with this rollout, will continue? So far I have an Aeotec hub on 51.02 (no problems that I have noticed so far) and V2 hub on 50.10.
best advice is to keep checking the Status page for any updates to the rollout or the first post of this thread. 