I took a look and it looks like it is Xiaomi sensors that are causing problems. I haven’t used these myself but my understanding is they can be a little temperamental to join and keep joined. There are other threads on the forums that cover those devices in more detail. According to the logs those devices are leaving your hub’s network on their own accord. It doesn’t look like it’s caused by anything the hub is doing. I know some of my coworkers have had these devices on the 0.18 firmware for months without any issues so I don’t believe it’s something wrong with the firmware itself.
Did I miss an email? We are the beta testers at least the email I got said so. I had some issues but they are clearing up as I send it in to the beta email address. So when it is released others don’t have this issue. Unless my email was wrong and they released it to everyone.
However, I have ones that I added before and they are still online. The latest ones have exactly the same fingerprint so ‘it appears’ to me that nothing has changed on that side.
I am also not the only one experiencing this issue. See Adams post above, same sensors though.
So devices added before the f/w update are fine, devices added after drop off. This is using the same DH, of course perhaps the DH needs to be updated now of course. All I can see is that the old ones are checking in every hour yet the ones I add now do not do so. This is with the same DH which obviously also applies to the existing devices right.
OK, so there is the possibility that the sensor f/w has changed but they do have the same ‘Raw Description’ the DH is the same and the only thing that has changed apart from this is the Hub f/w. Apologies, I am not technical enough so of course the DH may need to be updated but then if this is the case then something in the Hub f/w has still changed to warrant the DH change.
Is there anything that the hub would do when adding devices to prevent it receiving wakeup notifications from them please?
EDIT: Here is the DH just in case.
Also just checked the boxes/packaging the old and new devices all have the exact same manufacturing date etc. Surely if the devices are identical, the old ones that were paired prior to the f/w update stayed and are still online yet ones I try to add post Hub f/w update drop off after an hour can only point to a change in the hub f/w causing the issue?
Are you able to push the previous f/w to my Hub please?
What make and type of sensors?
Xiaomi Door Sensors
Thread here xiaomi-sensors
I really cannot put the issue down to anything else but the Hub f/w. Someone added slightly different but the same brand sensors earlier today and they are still online after 7 hours but they are on the previous hub f/w
Another user has just confirmed that they added 6 sensors on the latest Hub f/w and they all dropped off an hour later. It really does look like it is either a Hub f/w issue or something that has been broken in the cloud along with the the f/w update as others on the previous f/w do not have this issue with adding new devices.
Please look into and sort this asap! This issue may not only apply to Xiaomi sensors and my effect all zigbee devices.
I use some of the Xiaomi sensors in my house. Those devices can appear to join the network, but then fall off after an hour or two. See Xiaomi Zigbee Door/Window Sensor, Motion Sensor, & Smart Button Device Type [beta] for an older report of the same behavior. The devices do not follow the zigbee spec, and while they can join and play nice they are a bit temperamental when joining. I’ve had the best luck with the method described in Xiaomi Zigbee Door/Window Sensor, Motion Sensor, & Smart Button Device Type [beta] to get the devices to join and stay joined.
I do not think it is an issue with the sensors. I have some that are still paired (paired prior to the hub update), never had a problem in adding them. It really seems that after the hub f/w update several of us can easily pair them but then they drop off. It looks like the heartbeat is either not getting through or he hub is just ignoring it.
All of mine have the same Raw Description, same Manufacturing Date, same DH yet any I pair since the update drop off after an hour.
They aren’t different sensors, but what happens during the join process affects whether or not the device will stay on the network for more than an hour. As I said before the devices do not follow the zigbee spec, and are extremely sleepy devices. It is not uncommon for them to miss a message that is a part of the pairing process and not fully join the coordinator. As I linked above, people have been experiencing exactly the behavior you express for a while. Devices that successfully receive all the necessary messages as a part of pairing will stay paired, but those that go to sleep and miss a message will fall off the network after a while. Have you tried the method I linked above for pairing? By pressing the button on the device in regular intervals I have had better luck getting the device to stay awake and fully complete the join process.
Thanks! I did not try pressing the reset button periodically after the pairing process completed.
Just find it strange, I added them previously, paired first time, stayed paired. Yesterday I added 10 new sensors at least 4 times, that is 40 pairing attempts where they all paired successfully yet they all dropped off after an hour without fail unless I kept opening closing the contact. Surely at least one of the attempts should have completed the pairing process successfully out of all those attempts. That is why I really think the hub update has changed something which is causing this.
Still, tomorrow I will pair one yet again and press the reset button every 30mins or so for a while to see if that helps or not.
You have to press the button every 3 seconds during the pairing process, not every 30 min after. You have to force the device to listen to the complete join handshake. It’s not impossible that something has changed, and we will investigate, but I just wanted to point out that people have been seeing exactly the behavior you are describing (myself included) for quite a while.
Ah, I do do that, otherwise they do not pair at all.
Thank You! I was aware of them dropping off but never had this issue myself.
Look forward to your findings. In the mean time I have added one back again so will see if it holds this time.
Something strange happened about an hour ago when I received a notification that one of the sensor had come back online however I had already deleted it from my devices so perhaps someone is making changes to the cloud.
All of my Xiaomi devices are online and functioning as they did prior to the upgrade.
As are mine.
The issue is with adding one after the update, they all pair fine but they will drop off after an hour. I have tried everything and must have completed over 50 attempts, even though they appear to have paired fine every time they will drop off after an hour. However I try to pair the same thing happens, a few others have also reported the same issue after the update as well as someone pairing successfully and it staying paired but they have not had their hub updated.
In the IDE my hub uptime seems to get stuck at around 30 seconds. I am sure this worked correctly before the update, well at least I think it did. Is anyone else seeing the same? I have rebooted several times and the uptime went to 29, 31, 29 seconds after each boot and then just sits there, it does not increment further!
Really not happy with this update! If possible please push the previous version to my hub.
Your mad because a counter that doesn’t matter isn’t working?
Correct the counter is not really a big issue but it does have its uses. I have larger concerns with the update tbh.
Also, something as fundamental as the uptime should not be broken though should it?
It’s been broken before of I remember.
I’ve been on this version for some time and the 18 betas and I have had 0 issues. Lucky I guess.
Yeah, ignore the uptime shown in the IDE. That is basically the uptime at the time that one of the messages to the cloud containing information that changes infrequently changed, not the current uptime. We’ll probably hide this in a future cloud release as it is confusing.
The number is stuck at ~30 as the last time that message was sent the device had just booted. In previous versions this number used to be bigger on startup because startup was significantly slower.