Deconz Xiaomi Aqara Door/Window Sensor not reachable

Third party integrations
1

I’m having problems getting a stable connection between Homeassistant with a Conbee II and a Xiaomi Aqara Door sensor. Inside de Phoscon App the status of this sensor is Not Reachable. I can remove and add it but a few hours/days later it becomes unreachable again. Does anyone know how to fix this?

Deconz Add-On: 3.5
Hassio: 0.98.3
Phoscon/Conbee II Firmware: 2.05.67 / Firmware 264A0700

This is my latest log:

10:46:16:940 Current channel 15
10:46:16:949 Device TTL 2579 s flags: 0x7
10:46:21:955 dev /dev/ttyAMA0
10:46:21:955 GW firmware version: 0x264a0700
10:46:21:955 GW firmware version is up to date: 0x264a0700
10:47:16:254 verified group capacity: 255 and group count: 1 of LightNode 0x000d6ffffee460fe
10:47:16:254 0x000d6ffffee460fe found group 0xFFF0
10:47:16:936 Current channel 15
10:47:16:945 Device TTL 2519 s flags: 0x7
10:47:18:456 verified group capacity: 255 and group count: 1 of LightNode 0x000d6ffffe45392f
10:47:18:456 0x000d6ffffe45392f found group 0xFFF0
10:47:50:420 binding for cluster 0x0000 of 0x000D6FFFFEE460FE exists (verified by reporting)
10:47:50:420 binding for cluster 0x0006 of 0x000D6FFFFEE460FE exists (verified by reporting)
10:47:50:529 ZCL configure reporting rsp seq: 117 0x000D6FFFFEE460FE for cluster 0x0006 attr 0x0000 status 0x00
10:47:50:532 Bind response success for 0x000d6ffffee460fe cluster 0x0008
10:47:50:532 skip configure report for cluster: 0x0008 attr: 0x0000 of node 0x000D6FFFFEE460FE (wait reading or unsupported)
10:47:51:420 binding for cluster 0x0000 of 0x000D6FFFFE45392F exists (verified by reporting)
10:47:51:420 binding for cluster 0x0006 of 0x000D6FFFFE45392F exists (verified by reporting)
10:47:51:420 binding for cluster 0x0300 of 0x000D6FFFFE45392F exists (verified by reporting)
10:47:51:420 skip configure report for cluster: 0x0300 attr: 0x0007 of node 0x000D6FFFFE45392F (wait reading or unsupported)
10:47:51:525 ZCL configure reporting rsp seq: 119 0x000D6FFFFE45392F for cluster 0x0006 attr 0x0000 status 0x00
10:47:51:526 ZCL configure reporting rsp seq: 120 0x000D6FFFFE45392F for cluster 0x0300 attr 0x0008 status 0x00
10:47:51:526 ZCL configure reporting rsp seq: 120 0x000D6FFFFE45392F for cluster 0x0300 attr 0x0003 status 0x00
10:47:51:526 ZCL configure reporting rsp seq: 120 0x000D6FFFFE45392F for cluster 0x0300 attr 0x0004 status 0x00
10:47:51:529 Bind response success for 0x000d6ffffe45392f cluster 0x0008
10:47:51:529 skip configure report for cluster: 0x0008 attr: 0x0000 of node 0x000D6FFFFE45392F (wait reading or unsupported)
10:48:16:927 Current channel 15
10:48:16:931 Device TTL 2459 s flags: 0x7
10:49:16:929 Current channel 15
10:49:16:933 Device TTL 2399 s flags: 0x7
10:49:25:652 no button handler for: TRADFRI remote control ep: 0x01 cl: 0x0001 cmd: 0x0A pl[0]: 021
10:49:25:653 ZCL attribute report 0x000B57FFFEA696AF for cluster 0x0001, ep 0x01
10:50:16:928 Current channel 15
10:50:16:932 Device TTL 2339 s flags: 0x7
10:50:21:953 dev /dev/ttyAMA0
10:50:21:954 GW firmware version: 0x264a0700
10:50:21:954 GW firmware version is up to date: 0x264a0700
10:51:16:929 Current channel 15
10:51:16:933 Device TTL 2279 s flags: 0x7
10:52:16:929 Current channel 15
10:52:16:932 Device TTL 2219 s flags: 0x7
10:53:16:929 Current channel 15
10:53:16:933 Device TTL 2159 s flags: 0x7
10:54:16:929 Current channel 15
10:54:16:933 Device TTL 2099 s flags: 0x7
10:54:17:230 Announced to internet
10:54:17:230 discovery server date: Thu, 05 Sep 2019 08:54:17 GMT
10:54:17:230 local time seems to be ok
10:54:21:954 dev /dev/ttyAMA0
10:54:21:954 GW firmware version: 0x264a0700
10:54:21:954 GW firmware version is up to date: 0x264a0700
10:55:16:930 Current channel 15
10:55:16:932 Device TTL 2039 s flags: 0x7
10:56:16:930 Current channel 15
10:56:16:934 Device TTL 1979 s flags: 0x7
10:57:16:930 Current channel 15
10:57:16:936 Device TTL 1919 s flags: 0x7
10:58:01:516 New websocket 192.168.178.80:49334 (state: 3)
10:58:03:251 New websocket 192.168.178.80:49365 (state: 3)
10:58:13:211 New websocket 192.168.178.80:49501 (state: 3)
10:58:16:928 Current channel 15
10:58:16:932 Device TTL 1859 s flags: 0x7
10:58:21:956 dev /dev/ttyAMA0
10:58:21:957 GW firmware version: 0x264a0700
10:58:21:957 GW firmware version is up to date: 0x264a0700
10:59:16:930 Current channel 15
10:59:16:934 Device TTL 1799 s flags: 0x7
11:00:16:938 Current channel 15
11:00:16:947 Device TTL 1739 s flags: 0x7
11:01:16:935 Current channel 15
11:01:16:944 Device TTL 1679 s flags: 0x7
11:02:16:928 Current channel 15
11:02:16:932 Device TTL 1619 s flags: 0x7
11:02:21:953 dev /dev/ttyAMA0
11:02:21:953 GW firmware version: 0x264a0700
11:02:21:953 GW firmware version is up to date: 0x264a0700
11:02:27:745 New websocket 192.168.178.80:50510 (state: 3)
11:02:33:359 Websocket disconnected 192.168.178.80:50510 (state: 0)
11:02:34:616 New websocket 192.168.178.80:50526 (state: 3)
11:03:16:937 Current channel 15
11:03:16:946 Device TTL 1559 s flags: 0x7
11:04:10:425 Websocket disconnected 192.168.178.80:49334 (state: 0)
11:04:11:718 New websocket 192.168.178.80:50780 (state: 3)
11:04:16:939 Current channel 15
11:04:16:947 Device TTL 1499 s flags: 0x7
11:04:17:165 Announced to internet
11:04:17:165 discovery server date: Thu, 05 Sep 2019 09:04:17 GMT
11:04:17:166 local time seems to be ok
11:04:53:198 Websocket disconnected 192.168.178.80:50780 (state: 0)
11:04:57:742 New websocket 192.168.178.80:50868 (state: 3)
11:04:59:973 Websocket disconnected 192.168.178.80:50868 (state: 0)
11:05:11:008 ZCL attribute report 0x000D6FFFFE45392F for cluster 0x0000, ep 0x01
11:05:16:937 Current channel 15
11:05:16:946 Device TTL 1439 s flags: 0x7
11:05:42:563 ZCL attribute report 0x000D6FFFFEE460FE for cluster 0x0000, ep 0x01
11:06:16:938 Current channel 15
11:06:16:947 Device TTL 1379 s flags: 0x7
11:06:21:954 dev /dev/ttyAMA0
11:06:21:954 GW firmware version: 0x264a0700
11:06:21:954 GW firmware version is up to date: 0x264a0700

2

I had similar problems with door sensors that are fairly far away from the Conbee stick. I resolved this by adding some mains powered Zigbee devices (Tradfri LED drivers in this case) in between.

3

Or change the Zigbee channel to something which is not interfering with your WiFi.

4

Hello when you adding powered zigbee device like tradfri, the tradfri it’s connected with the conbee or withe the ikea hub ?

5

I have Hue lights (connected through Hue hub) about 1m away from the sensor. Hue uses Zigbee too. On channel 20. Conbee II is working on channel 15. Maybe this is causing issues. I’m at work so can’t test it right now.

6

Hue lights connected to a Hue hub are not working as repeaters for your Conbee network.

1 Like
7

With Conbee. You don’t need the IKEA hub if you have a Conbee.

8

Hmmm I made the assumption that any Zigbee device that is powered could act as a repeater. Even if it’s on another hub. The Conbee however is just 2 meters from the sensor. Conbee is attached with a usb extension cable to raspberry pi. Is the range of the Conbee that bad?

9

They only act as a reapter for devices in the network they are in.
The range of the Conbee is pretty good in my opinion but a common issue is inteference either by WiFi or another Zigbee network. Take a look at this for some more info.

1 Like
10

I had exactly same problem. Changed battery in one of my (brand new) switches 3 days ago, still keeping connection. Dont know how, but it seems to have fixed my problem at least

11

I changed the Wifi channel to Channel 1 (was channel 6). Hue hub is now on channel 20 and Conbee on 25. I re-added the Aqara sensor to the Conbee and it’s working for now. If I get connection problems again then I will remove the Hue Hub and add the Hue lights to Conbee. So the Hue bulb will become a Zigbee repeater to help the Aqara sensor to connect to the Conbee.