I can confirm that I have same issue. 
Bummer
Why not?
I am not intimately familiar with the ins and outs of ZigBee Source Routing, but is it safe to assume this previous issue was magnified by the use of multiple router (aka "repeater") devices on a mesh?
Also, would a change in the size of the Source Routing Table possibly disrupt the Routing Tables of those router devices?
I just want to be absolutely crystal clear about this:
The change in update 2.0.5 required a change in the code off nearly all of the Xiaomi / Aqara device drivers because there was a change in the formatting of the raw payload data of messages received from ZigBee devices, as seen by a device driver. This directly affected most of the the Xiaomi / Aqara device drivers because instead of being able to use "helpers" to reformat the data of incoming messages, the drivers work directly with the raw payload data because of the non-standard way in which Xiaomi / Aqara formats it.
However, the ZigBee stack change in update 2.0.6 affects an aspect of ZigBee network routing that device drivers (at least for Xiaomi / Aqara devices) have zero access to. Furthermore, any issues related to not completing the pairing process or problems with Xiaomi / Aqara devices connected to a ZigBee mesh network are completely unrelated to the device drivers. Unfortunately, although some ZigBee end devices allow access to settings / parameters that would help keep them connected, Xiaomi / Aqara do not.
4 Likes
I have eight xiaomi devices, updated to 2.0.6 and they were all good except two after bout an hour they dropped off. I re-paired them and we will see. they are the closest to the hub than the others as well. the rest are closer to ikea outlets.
You are welcome, I just repaired a dropped sensor near the Tradfri, confirmed with the xbee it is connected to the Tradfri. It's working, let me give it more time.
I had to factory reset both hubs today, actually I did a few minutes before the update and when I registered both they took the new firmware. Just bad timing...
I'm working on a fix for the issue, looking for a tester.
I can confirm that all my Xiaomi devices dropped with 2.0.6.111.
I have a 100% Xiaomi zigbee mesh connected to the hub that was working flawless.
Returning to 2.0.5.114 did not return the mesh all of them are non responded even though they are on the table.
Awaken the devices (not pairing, just trigger events) did not make them reconnect neither in 2.0.6 or 2.0.5.
So frustrated I'm heading to bed as re pair all my Xiaomi devices is making me sick...
What needs to be done?! My hub is pretty useless as all my automations are down anyway
You will have to update to a new version that I will make available and then pair your devices again.
Shoot away. Send the firmware my way
1 Like
I'm in a position to test, if needed, too.
I can test, and re pair all devices if necessary, I don't have any complex rules with them yet
This is strange. I wonder what is so different in these setups that is causing the drops. I have 50 Xiaomi devices (5 sengled bulbs and 4 Ikea repeaters) and have been running the betas (and now final) with no issues at all. I also have ZigBee running on channel 23 and an Eero mesh that I believe is on channel 1.
I wonder what could be causing the differences in reliability.
It is weird. I only have 10 of the Aqara temp/humidity, and 4 Ikea Tradfri outlets. I have 25 or so of other battery zigbee devices, but as those don't route I doubt that is an issue.
I'll blame it on Xiaomi. 
Still nice that the Hubitat crew is willing to test a few things and try to work through the issue, even though they aren't supported devices. 
I wanted to make sure I pointed out that is very appreciated, because I am always quicker to be critical than I am to compliment 
.
2 Likes
I have little doubt that Hubitat staff are just not going to be buying many of these to scatter through their own homes. They've made it clear these devices don't operate per a spec, sometimes not even their own.
Also means you won't be seeing drivers for them from Hubitat Staff. 
Nor wouldI expect to see them put Xiaomi issues ahead of other issues.
But that might be the limit of their "aren't supported devices" reactions. Clearly we've seen Hubitat Staff explain and explain again what's wrong/missing/undesirable about them.
But when a code upgrade unintentionally breaks a portion of their user base, I think "support" takes on a different color. 
It's a pride of ownership issue at the very least. In my opinion.
Really?? Never noticed.
4 Likes
Hey! 
(Who am I kidding, it is true more than it should be...)
1 Like
Exactly... And it has. They identified the issue and have a fix to test within a couple hours. I would call that a "different effort", to support an unsupported device that is.
5 Likes
Agreed.
I went to bed after reverting last evening and everything is still working this morning.
I see that has a fix has been released.
Great work Hubitat team!!
Now to upgrade.
For information I do not have an Xbee (whatever that is) and I don't think I have any repeaters. (How would I know if my devices are repeating through another device).
The only thing that matters for me is that the HE team jumped all over this straight away and released a fix.
Great service yet again.
6 Likes
Can you expand on what caused the problem?
Is there a possibility for future updates of a little more technical detail in the release notes on any core changes to ZigBee or Z-Wave?
It would perhaps allow people to make a more informed decision on whether to upgrade or not if we can make a judgement call on any potential impact.
For example "ZigBee stack stability improvements" sounds quite innocuous whereas the more in depth details given by @srwhite earlier in this thread may have given people more of a reason to hold off on upgrading (as in "uh-oh, ZigBee routing changes, maybe I'll wait for a few hot-fix revisions first").
I know I was about to hit upgrade when I saw @bobbles post.
Kudos on getting a fix out quickly though ..... just feel the pain for anybody now having to do the repair dance again 
1 Like
