Although they aren’t officially supported I know a lot of people use these sensors so I’ve been looking into the issue with the 0.18.X firmware on my own time and I think I may know what’s going on.
As you probably know, the Xiaomi sensors are very sleepy. Most sleepy end devices that we support will wake up every 6 seconds to 2 minutes to check for messages and to make sure its parent knows it is still there. The Xiaomi sensors do this closer to once an hour. That is zigbee compliant behavior so everything is fine so far.
The zigbee specification includes a section called End Device Aging. It states that a parent must forget about a child that doesn’t check in for a certain amount of time. In other words if the parent (like the hub or another router on the network) hasn’t heard from a device within a certain amount of time it must tell the device to leave and rejoin the network. This isn’t an uncommon thing to happens on a zigbee network and most devices will handle this just fine. When the device does it right you’ll never even notice it was gone for a brief period.
By using a zigbee sniffer I can see all the communication between the sensor and the hub. The sensor is quiet for about an hour and then sends a checkin message to the hub. The timeout for end devices has elapsed so the hub’s zigbee radio doesn’t recognize the sensor anymore. Therefore per the specification it sends the sensor a leave and rejoin request. The sensor replies with a message saying it is going to leave and rejoin. Then it does leave but it does not attempt to rejoin. Instead it appears to factory reset itself. This is why it drops offline and I believe is non-compliant behavior.
The end device aging timeout has not changed between the 0.17 and the 0.18 release. However we did upgrade the zigbee stack between these two releases. The zigbee stack is provided by the radio vendor and they frequently update it to introduce new features and fix bugs. I suspect that the cause for the change in behavior between 0.17 and 0.18 is due to a bug fix to make the stack compliant with the zigbee specification. The 0.17 firmware did not send the leave and rejoin request after the end device timeout which I believe was likely a bug in that version of the stack. Just to be sure I am double checking with the radio vendor on this.
One thing you can try to get around this issue is to get the device to join through a device other than the hub. Different routers can have different end device timeouts and if you can find one that has a long enough timeout or that doesn’t enforce the timeout then the sensor may stay on the network. You’d have to have the sensor far away from the hub and close to routers like outlets or bulbs while you join it.
Another idea is you join it like normal, but then you power off the hub for an hour (or wait 45 minutes and then power it off for 30 minutes or something) so that it is powered off at the time the sensor does it’s hourly checkin. Most devices will search for a new parent in this situation. You may have to experiment with powering off different types of routers as well until you find one that has the necessary behavior to make it work.
I have not tried either of these potential workarounds myself but in theory they should work. The second one is probably easier to do if you can handle the hub being offline for a while.
I know these potential workarounds aren’t ideal, but unfortunately I can’t commit to changing the behavior of 0.18.X back to the way it was for a number of reasons. However I will look into the options as time allows.
I’ve also purchased the Xiaomi gateway with the intention of sniffing the traffic between it and the sensors to see how it behaves. If I learn of anything that could be done in the DTH that would improve the experience with the sensors I’ll be sure to post back it. Let me know if someone already did this.
This got much longer than I intended but I hope it’s informative.