Deconz-rest-plugin: Xiaomi sensors getting stuck

[xhemp]

I am using ConBee:

Version 2.05.31 / 22/06/2018
Firmware 261F0500

But my Xiaomi motion sensors simply lose connection and they stop working. Tried to push the configure button a few times but it just doesn't work.
Found a few threads with some issues but I don't know if it's related or not.

Edit: Noticed something else as well. The window/door sensors also get stuck but in a different way. When the sensor shows closed and I open a door or window, it doesn't detect it's opened but if I close it and re-open it, it starts working fine, it's weird.
If you need any logs or to run deCONZ with any switch and capture something, let me know.

[goermezer]

Same for me with Aqara type of motion sensor. Interestingly I have two of them, which work very reliable without issues so far. They are also very hard to pair with Raspbee. Sometimes a shutdown of the Pi and removing power cable helps me to integrate them to the network.

[ebaauw]

I find, the first time I open the door shortly after restarting deCONZ, the notification of my Xiaomi Aqara door sensor goes MIA. I suspect a timing issue, where deCONZ uses the notification to create/activate the sensor resource, but doesn’t process it, as the sensor resource hasn’t yet been activated.

Sometimes a shutdown of the Pi and removing power cable helps me to integrate them to the network.

That sounds like meshing related issues. You might try resetting the RaspBee instead. Stop deCONZ and issue sudo GCFFlasher_internal -r from the command line.

[xhemp]

@ebaauw Interesting. I don't have an issue with the door/window sensors getting stuck and not working at all, it's just after a long time, they just don't recognise the door opening which defeats the entire purpose. I have to open, close and then it will work (dont know for how long, though).

Woke up this morning and I have 5 working and 1 not working (stuck).
Scratching my head trying to understand what's going on. On my Xiaomi gateway they worked well (as expected) so I don't believe it's the sensor as it's very random.

[manup]

Xiaomi battery powered devices don't like loosing the parent node (for example light is not powered any longer) To improve situation it's best that the devices are forced to connect to the nodes which are always powered, by pairing / rejoining them while only these parent nodes are powered.

Not sure if this is the problem in this specific case?

[xhemp]

This box is always powered on but do you mean if I need to restart the Pi or the service for any reason, I need to pair/rejoin the sensors again?

[manup]

I mean the other mains powered devices to which the sensors might be paired (parent nodes) like lights.

[xhemp]

ConBee is only powered to Hue lights (which are powered on) and the Xiaomi sensors/switches. Switches are working fine (always) but the sensors have that problem.
I have one of them doing that right at this moment, just got stuck.

[manup]

And the lights are also always powered on?
In deCONZ GUI you can see to which parent node the sensor is connected.

Are the lights by any chance IKEA lights?

[xhemp]

They are always powered on and no, they are Philips Hue lights.
I am running deCONZ headless but I can surely boot in the GUI and have a look but may need help on going through it (just got my ConBee yesterday) so quite new on it.

[xhemp]

deCONZ GUI

It's called Single Bedroom sensor and it wasn't even there.
On Phoscon, it says the following on that sensor:

Refreshed: 04/07/2018, 19:19:44

[goermezer]

@ebaauw When I do "sudo GCFFlasher_internal -r". Do I have to pair all sensors again? What kind of reset is it? Is it similar to a power off of the Raspbee module?

[manup]

Exactly, it is just a forced power cycle of the RaspBee. Sensor pairings aren't affected.

[xhemp]

So yesterday I had to remove and re-add that single bedroom sensor, this morning I have the same happening with 2 other sensors.
They are not even showing on the deCONZ GUI (I run it headless but since yesterday, I am running the GUI).
Anything I can do or test?

[ebaauw]

@xhemp , except one, all your Xioami switches and sensors (grey nodes) are connected directly to the ConBee (blue node), instead of through one of your lights (yellow nodes). Note that the mesh network is formed by the mains-powered routers (yellow and blue nodes), and that the battery-powered end-devices (grey nodes) only connect to one router node.
The current ConBee / RaspBee firmware supports only 10 end-device connections, so additional sensors will have to connect through another router.

Power cycling or resetting the ConBee or RaspBee should force the sensors to re-connect through a light; power cycling the light (are you using traditional wall switches?) forces the sensor to connect to the ConBee or through another light.

I don’t know the physical layout of your home, but it might help to place strategically a light between the ConBee and living room and/or between the ConBee and (upstairs?) office, to “offload” those sensors from the ConBee.

It's called Single Bedroom sensor and it wasn't even there.
On Phoscon, it says the following on that sensor:
Refreshed: 04/07/2018, 19:19:44

On restart, deCONZ restores the /sensors resources from its database, and “activates” these when it sees the correponding node. The GUI only shows connected nodes. That’s how the Phoscon app still sees a previously connected sensor, where the GUI doesn’t show it.

[xhemp]

@ebaauw Thanks! I believe the info that the ConBee firmware supports only 10 end-device connections (is that limit going to change?) is what I am seeing then, I have just counted number of connections on my GUI linked to the ConBee and I can see only 10 Xiaomi devices.
I can't see any Xiaomi devices connecting to one of the Hue lights, they are just connected to each other and to the ConBee. Is there any way to force it? ( I have traditional wall switches and tried to power cycle the light but it didn't change anything I'm afraid).

[ebaauw]

I can't see any Xiaomi devices connecting to one of the Hue lights, they are just connected to each other and to the ConBee.

Hm, I though the Kitchen Sensor connected to one of the Kitchen lights, but my eyes might have beed crossed.

End-devices cannot connect to each other. The GUI draws the lines based on the neighbour tables reported by the routers. It might take some time for the old router to realise it has lost the end device and/or for deCONZ to poll the neighbour table, so sometimes you see two lines connecting the end device.

Is there any way to force it?

Tricky. It might be enough to remove and re-insert the sensor battery while it's closer to one of the lights than to the ConBee, especially when it's out of (direct) range of the ConBee. Otherwise, try shielding (as in Faraday's cage) or powering down the ConBee (quit deCONZ and power down the RPI or remove the ConBee), then remove and re-insert the sensor battery.

I have traditional wall switches and tried to power cycle the light but it didn't change anything I'm afraid

Power-cycling a router only works for ditching the connected end devices, not for attracting new end devices. So, powering down the lights forces the sensors to re-connect to the ConBee; powering down the ConBee forces the sensors to re-connect to a light.

The sensor will only re-connect when its awake. Xiaomi devices only wake up once every 50 minutes or so, or when something happens (motion detected, switch pressed). Quickly power-cycling the lights won't do anything while the sensor sleeps. The remove/re-insert battery is to force the sensor to wake and announce it's presence on the network.

[xhemp]

Looks like that did it, Erik! (I'm Eryck, btw), great approach.
The only thing I did different is that I didn't have to remove the battery, just a pin on the hole on sensors and push the configure button on the multi sensor/switches and voila, I was able to connect to some of them to the Hue lights.
I just got 2 innr lights and they are fine too.
I will keep it running for a few days and report back.
Only thing I am missing now is being able to connect the Yeelights ( I have a few) :)

[ebaauw]

I just got 2 innr lights and they are fine too.

These are very similar to the Philips Hue lights (the company was founded by former Philips employees). You shouldn’t run into any meshing problems with these.

Only thing I am missing now is being able to connect the Yeelights ( I have a few) :)

Afaik, they come in Bluetooth and WiFi versions, not ZigBee?

[xhemp]

Good to know about the innr lights, thanks for that.
Hmm, that's true, they are indeed WiFI and not ZigBee, my bad on this one.

[xhemp]

I think this one is working fine after @ebaauw's tip:

Powering down the ConBee (quit deCONZ and power down the RPI or remove the ConBee), then remove and re-insert the sensor battery.

I didn't need to remove the battery, just pushing the button/pushing the pin on the sensors did it for me.
@goermezer You may test the above and see if you still have issues with yours.

Didn't see any issues over the weekend with this.

[xhemp]

Something interesting I have just seen. I was finding strange that my lights were switching off and on after a minute or so even though there was movement and the sensor was supposed to be seeing that.
When I went to look into the logs, I saw that the sensor was not getting any movement at all but was polling every 60 seconds, like this:

2018-07-11 10:21:21 DEBUG (MainThread) [pydeconz.deconzdevice] Office Sensor: update lastupdated with 2018-07-11T09:21:21 2018-07-11 10:21:21 DEBUG (MainThread) [pydeconz.deconzdevice] Office Sensor: update presence with False 2018-07-11 10:21:21 DEBUG (MainThread) [pydeconz.websocket] Websocket data: {"e":"changed","id":"34","r":"sensors","state":{"lastupdated":"2018-07-11T09:21:21","presence":false},"t":"event"} 2018-07-11 10:21:23 DEBUG (MainThread) [pydeconz.deconzdevice] Office Sensor: update lastupdated with 2018-07-11T09:21:23 2018-07-11 10:21:23 DEBUG (MainThread) [pydeconz.deconzdevice] Office Sensor: update presence with True 2018-07-11 10:21:23 DEBUG (MainThread) [pydeconz.websocket] Websocket data: {"e":"changed","id":"34","r":"sensors","state":{"lastupdated":"2018-07-11T09:21:23","presence":true},"t":"event"} 2018-07-11 10:22:24 DEBUG (MainThread) [pydeconz.deconzdevice] Office Sensor: update lastupdated with 2018-07-11T09:22:24 2018-07-11 10:22:24 DEBUG (MainThread) [pydeconz.deconzdevice] Office Sensor: update presence with False 2018-07-11 10:22:24 DEBUG (MainThread) [pydeconz.websocket] Websocket data: {"e":"changed","id":"34","r":"sensors","state":{"lastupdated":"2018-07-11T09:22:24","presence":false},"t":"event"} 2018-07-11 10:22:47 DEBUG (MainThread) [pydeconz.deconzdevice] Office Sensor: update lastupdated with 2018-07-11T09:22:47 2018-07-11 10:22:47 DEBUG (MainThread) [pydeconz.deconzdevice] Office Sensor: update presence with True 2018-07-11 10:22:47 DEBUG (MainThread) [pydeconz.websocket] Websocket data: {"e":"changed","id":"34","r":"sensors","state":{"lastupdated":"2018-07-11T09:22:47","presence":true},"t":"event"} 2018-07-11 10:23:47 DEBUG (MainThread) [pydeconz.deconzdevice] Office Sensor: update lastupdated with 2018-07-11T09:23:47 2018-07-11 10:23:47 DEBUG (MainThread) [pydeconz.deconzdevice] Office Sensor: update presence with False 2018-07-11 10:23:47 DEBUG (MainThread) [pydeconz.websocket] Websocket data: {"e":"changed","id":"34","r":"sensors","state":{"lastupdated":"2018-07-11T09:23:47","presence":false},"t":"event"} 2018-07-11 10:23:55 DEBUG (MainThread) [pydeconz.deconzdevice] Office Sensor: update lastupdated with 2018-07-11T09:23:55 2018-07-11 10:23:55 DEBUG (MainThread) [pydeconz.deconzdevice] Office Sensor: update presence with True 2018-07-11 10:23:55 DEBUG (MainThread) [pydeconz.websocket] Websocket data: {"e":"changed","id":"34","r":"sensors","state":{"lastupdated":"2018-07-11T09:23:55","presence":true},"t":"event"} 2018-07-11 10:24:55 DEBUG (MainThread) [pydeconz.deconzdevice] Office Sensor: update lastupdated with 2018-07-11T09:24:55 2018-07-11 10:24:55 DEBUG (MainThread) [pydeconz.deconzdevice] Office Sensor: update presence with False 2018-07-11 10:24:55 DEBUG (MainThread) [pydeconz.websocket] Websocket data: {"e":"changed","id":"34","r":"sensors","state":{"lastupdated":"2018-07-11T09:24:55","presence":false},"t":"event"}

I was intrigued by that and couldn't explain it. What I did was to remove the motion sensor from deCONZ and re-add it and it started working well again but this morning, the same thing is happening again.
Any ideas why?

[xhemp]

So if I don't reset it but just put a pin on the pinhole on the motion sensor, it looks like it "wakes up" and starts updating again.

Edit: Just saw the same thing on another issue ( #549 ) which cleared it for me:

This does explain why the sensors work with 5 second interval directly (first 2 hours) after inclusion and when the button has been pressed... and fall back to the 1 minute interval after the 2 hours.
So this is a device (firmware) limitation.

[manup]

Some Questions:

1. Do you use a USB extension cable?
2. Are the mains powered router devices like lights always powered?
3. Can you please provide screenshots of the network to see which unresponsive sensors are connected to which router?
4. Which deCONZ and Firmware version are you running?

I was really expecting this to "just work". Is this expected behaviour? Is this normal?

When the network is stable it should just work. However note that this particular mix of routers from Osram and Xiaomi is not not so common and testet.

In my experience the most reliable routers are the Philips lights. We have mixed results with Osram and Xiaomi devices.

[xhemp]

Just my 2 cents, I am using 2.05.47 and haven't had this issue in a long time (40 nodes in total)

[chimpy]

@xhemp @manup Thanks for your replies.

I deleted my post before your replies as I realised that I had not added root to the dialout group, my FW version was not accurate and needed updating. After upgrading to the latest FW (2630) and latest software (2.05.54) I have no issues AFAICT.

All paired sensors (including the previously stuck ones) are now immediately responsive when I trigger them (motion or opening or whatever).

Thank you again :)

@manup I am using the deconz deb file on Ubuntu Server. What is the best way of accessing the gui?
I shutdown deconz and start deconz-gui, however it complains that there is no xserver/display :0. I tried doing sudo x11vnc -display :0 -create and then rerunning sudo systemctl start deconz-gui but I get the same error. Not sure where to go from here.

[xhemp]

@xhemp @manup Thanks for your replies.

I deleted my post before your replies as I realised that I had not added root to the dialout group, my FW version was not accurate and needed updating. After upgrading to the latest FW (2630) and latest software (2.05.54) I have no issues AFAICT.

All paired sensors are now immediately responsive when I trigger them (motion or opening or whatever).

Thank you again :)

Nice one, @chimpy !

[chimpy]

After swapping out a couple of Xiaomi plugs with an Osram plug and an Innr 120 plug (because they are earthed), a few of my Xiaomi end devices aren't responding any more :( I guess this is because they are "sticky"?

I did a reset with the GCF tool, but this didn't solve anything. It might have even made it worse.

Will the Xiaomi sensors/switches come back online by themselves? Pushing the little button on the back of sensors to try to nudge them to reconnect has only worked with one sensor out of three that I tried. Please tell me I don't need to repair them all!
(FYI I almost never turn off my zigbee routers).

[manup]

Sometimes they can figure out a new parent node on their own, but that's rather rare.

You may try to press the small button 5 times quickly to start a signal test on the sensor.

If that doesn't work, start the sensor search and reset the sensor by holding the small button until it blinks. The sensor should then rejoin the network. Not you don't need to delete the sensor, just rejoin it.

[martin3000]

Many many people have the problem that their xiaomi/aqara sensors fall asleep and stop working. This is not limited to conbee users. Users with other zigbee sticks have the same problem. But I'm sure that users of the aqara gateway do not have this problem.

My assumption is that the aqara sensors need some kind of keep-alive signal from the coordinator. If they do not get this, they go into deep standby. Maybe this is to save battery while they are in a store waiting for customers. I think something is needed to keep them alive. And nobody has found out so far.

[ebaauw]

Plausible. Technically, it would have to be a reaction to the Xiaomi special attribute report, or the device wouldn't receive it due to its radio being switched off. Alternatively, it could be a magic configuration setting upon pairing. The only way to be sure is: to sniff the Zigbee traffic between the Aqara gateway and the devices.

The lumi.ctrl_neutral in-wall switches poll the _Time_ cluster of the coordinator every minute, and drop off the network, if they don't receive any answers. After we implemented the _Time_ custer on the deCONZ gateway, I haven't had any issues these anymore, though.

I haven't seen any similar behaviour on any of my other XIaomi devices. Of course, I only have a limited set of models:

lumi.ctrl_neutral2
lumi.curtain
lumi.sensor_cube
lumi.sensor_magnet.aq2
lumi.sensor_switch.aq2
lumi.sensor_wleak.aq1
lumi.vibration.aq1
lumi.weather

[martin3000]

Ah ok, lumi.sensor_magnet.aq2 and lumi.vibration.aq1 work fine and dont fall asleep? And they don't need the time cluster?

[ktpx]

Having this issue with a brand new Conbee II. Stops responding overnight. Have to re-add sensor. Aquara Door/window sensor..

Seems i had old FW (new stick), hopefully that fixes it :D

[vhristev]

My sensor is working but from time to time it does not power on my hall light. Now I'm trying to figure out what is the issue.

• Link quality
• Sensor got to sleep somehow ( i know about duration time )
• Home Assistant or zigbee2mqtt stick

[merdok]

Same issue here with an Aqara Motion sensor. The sensor simply stops responding after a while and it needs to re-added again to make it work for a short time. Any solution for this?

[ktpx]

Same issue here with an Aqara Motion sensor. The sensor simply stops responding after a while and it needs to re-added again to make it work for a short time. Any solution for this?

Have you made sure you have the latest firmware on the conbee gw? That fixed it for me, atleast.

[merdok]

Yes, i have the latest firmware. My Conbee 2 already came with the latest firmware installed...

[ktpx]

Yes, i have the latest firmware. My Conbee 2 already came with the latest firmware installed...

Ok. I thought the same, and the software claimed as much. But when i downloaded the FW, it was not the latest at all. (even if the stick was just purchased).

[merdok]

But i see the version of the firmware on the Conbee 2 and it is the latest here: https://www.dresden-elektronik.de/rpi/deconz-firmware/?C=M;O=D.
Or is the firmware 264A0700 not the latest?

[manup]

Yes that's the latest version.

Is the motion sensor connected directly to the ConBee II or to a router device like a light?

[merdok]

The motion sensor is directly connected to the ConBee II. I also put the motion sensor straight next to the ConBee II (10cm distance) to make sure it is not a distance issue, but that did not help...

Except the motion sensor i currently have only 2 more devices connected to the ConBee II (Xiaomi Switch and Aqara Switch) and they both work fine.

[ktpx]

What i upgraded to was 26490700 (second latest i guess..), which fixed it for me, not seen the issue since ..its talking directly to conbee, no repeaters on that network.

[merdok]

Maybe the issue is back again present in the latest firmware?
This is really frustrating because i need to reset the sensor everyday to make it work, which is not really useful for home automation...

[ktpx]

My issue was with a door/window sensor though, i do not have any zigbee/xiaomi motion sensors.

[merdok]

So maybe the issue was just fixed for the door/window sensor and not the motion sensors?

[manup]

The motion sensor is directly connected to the ConBee II. I also put the motion sensor straight next to the ConBee II (10cm distance) to make sure it is not a distance issue, but that did not help...

Did you see the line between the motion sensor and the blue coordinator node?

Except the motion sensor i currently have only 2 more devices connected to the ConBee II (Xiaomi Switch and Aqara Switch) and they both work fine.

Are these mains powered switches? If so please power them off when pairing the sensor, so that it is forced to select the coordinator as parent.

[merdok]

I run in headless mode and have no access to the GUI.
Those are battery powered switches. I even removed them from the gateway and just left the motion sensor connected, but still the same issue. The sensor just stops working after some time and i need to repair it.

Maybe indeed this issue was not fixed for the motion sensor in the latest firmware and only for the door/window sensors?