[RELEASE] Xiaomi Sensors and Button (beta)

I paired it with the clicky clicky method, not with the catchall

1 Like

What has changed in the last few days? I paired mine a few hours ago and it’s still going strong. No battery though.

Still not working for me. Perhaps they are changing things for people behind the scenes slowly. No idea really. Mine dropped off after an hour after no activity.

Same way I have tried.

My hub just went offline and looking at the zigbee side it went from Active to Inactive back to Active so perhaps whatever changes are being pushed behind the scenes it was my turn. Just added a few sensors so will soon know. It has not however changed any of the activity dates or last updated dates on my hub so this could have simply been just another glitch caused the .18 update of course.

Thanks.

EDIT: No change for me unfortunately. After an hour of inactivity they have all dropped offline.

Are your newly paired sensors dropping offline after an hour with the new firmware, or, are all sensors dropping offline after an hour with new firmware.

Edit: from further reading, it appears all Xiaomi sensors are dropping. I only got my sensors yesterday, I’ve disabled Zigbee OTA updates. Will this prevent update? or is it the firmware itself?

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.

20 Likes

So if I’m understanding this correctly… the 0.18 firmware will prevent the xiaomi sensors/buttons from working properly as-is. The 0.18 firmware is currently being rolled out in the UK and everyone’s existing and new xiaomi sensors are dropping after an hour as explained by tpmanley’s post. US users are currently on 0.17 and do not have the issue. The 0.18 firmware will be rolled out to US users at some point. I’m not looking forward to when that happens…

I am using 0.18 on UK hub with 2 xiaomi windows sensors and one xiaomi button but have not experienced any drop out so far, isn’t that should only affect people when it is newly added or readded? Of course that would be a potential issue, one point uncertain though is do xiaomi’s sensors have multiple firmware levels with different behaviour
@tpmanley thanks for the analysis but I think this is a good reason why everyone should be able to opt out for firmware update when every device at home is stable and willing to accept the security risk if any

I could join new sensors and they show battery and haven’t dropped so far.
But I am using quite a few Xiaomi outlets around the house (next to about 5 zwave outlets), including 2 very close to the hub.

It could be that all my sensors are using a Xiaomi outlet as router.

I also followed the checkin behavior since one of my sensors dropped off a few months ago. (Using webcore to check this)
I can confirm that the checkin occurs about once an hour.

Actually:
The “Original” Xiaomi’s check in every 60 minutes
The Aqara’s check in every 50 minutes

Thanks @RInkelk

Could others that have success in keeping them online please list what other zigbee devices they have, e.g. ST mains socket, Xiaomi etc.

I would rather purchase something I may have use for like the ST UK socket but not sure if that will be sufficient of course.

Thanks Tom!

Off the top of your head would the ST power outlet work in this situation or would it get updated with f/w that would put it in the same boat as the hub itself and prevent it from acing as a repeater effectively in this situation?

Also, several people have tried with the .20 hub release and see to have had much better results in getting the sensors to stay online. Is this simply coincidence and/or the sensors have routed through a different device this time as you describe or could there be some change on .20 which is helping the situation?

Thanks again!

Mark.

Well I’ve just updated to hassio 0.50 and alot of xiaomi gear is supported OOTB. Still waiting for the gateway to be at a UK source :frowning:

Have to say I’m very impressed with HA and the coexistence with ST. I’m planning on adding devices to HA and creating a simulated version in ST. I should be able to publish the simulated device to the MQTT bridge and then create automations so HA updates it when the real device state changes. I can’t see a simulated humidity sensor though which is a bit of a bummer

Just a quick check in.

I have firmware 000.018.00018 since roll-out (UK hub), and about 15 Xiaomi devices - buttons, motions sensors, temperature sensors and door/window sensors. I haven’t noticed any changes in behaviour at all. My devices are still online, and working properly just as before.

I think it’s about adding new devices that’s causing the issue.

1 Like

Yup as Rinke mentions. Existing senors are absolutely fine and stay online without issue. It is when you try to add a new sensor. However the caveat here is do not power down your hub for any length of time. I did this to try an rebuild the mesh and I lost all my EXISTING Xiaomi sensors. Can easily pair them back of course but they only last an hour lol.

Also if ST force a mesh rebuild OTA for any reason or you have a power cut for a good length of time (if no UPS of course) then the existing sensors will drop off. This is of course unless you have other zigbee devices that they may be routing through as described above.

1 Like

Do you have any Xiaomi outlets. Or any other zigbee repeaters ?
Like tpmanley said; if the sensors are being repeated this might solve that issue. But if you have a different experience…

Tempted to bring the hub offline just to see if my xiaomi outlets do their work and will bring all my sensors back online…

By the time is is available here you will probably have had it delivered from China lol

Nice work though. I really moved onto ST to keep all under one roof, I still have Wireless Sensor Tags integrated but am really trying to move away from them also. I know it does not leave much of a failsafe even though everything is on a UPS and a separate 4G router.

Think I am going to get a load of z-wave door sensors for the main windows and slowly play with a zigbee repeater (perhaps the ST UK outlet) if Tom or anyone else can confirm it may work and not have the same obstacles as the hub does with a f/w update. I would rather purchse something that will be of use rather than a Xiaomi outlet that I cannot plug anything into.

Just a real shame that they cannot put a little bit of code in the hub f/w that if sensor = Xiaomi then to handle the checkin as it did previously.

Okay, then I’m with you. No hub power down, got it. :slight_smile:

I do have several IKEA Trådfri bulbs on Zigbee that might act as routers though, so maybe I’m in luck anyway. I will not try that out deliberately though, hehe. Hopefully we can find a fix somewhere down the line! Would be a real issue (for me) if the Xiaomi hardware stopped working.

1 Like

None unfortunately.

I only the Xiaomi and one single ST Multi Sensor, the rest of my things are all Z-Wave.

I am happy to preferably pick up a ST UK Outlet if that may help or even a Xiaomi one to hide away somewhere but there really is no guarantee that this situation can get even worse with a future update (could obviously get better of course).

Based on my current situation I need something that is going to be reliable. I think I am going to have to invest in some Fibaro or similar Door Sensors which I know are fully compliant and if anything happens then ST will fix it pretty quickly.

The Xiaomi sensors I have will still come in more than useful (the fridge for one lol) once I can get them hooked up properly with some sort of repeater so nothing will be lost in the long run I guess, just out of pocket :grin:

I’ll do another small test: i’ll delete one of my xiaomi sensors from ST and then add it again with the clicky method, see if it starts showing battery and stays connected

1 Like