Device issues after getting SSD

[Jens]

I am having the same issue after adding a SSD to my RPi 4b.
I am using the ConBee II stick (firmware 26660700) with Phoscon 2.12.06 / 19.8.2021 and Raspberry Pi OS 64bit. I was using 32bit before on the SD card, and the exact same hardware setup worked fine on that system.
I am using

• the original RPi power supply,
• a shielded extension cable that is 2 meters away from RPi and the SSD,
• an USB 2 port for the ConBee II (extension cable),
• the app is only opened once (single browser tab)
• I rebooted a lot of times,
• I also disconnected and reconnected the ConBee II a few times.

The Phoscon app still refuses to have any device added. Everything works fine in the app, only adding devices never finishes.
I actually restored the device database and connection to previously learned devices (on the 32bit) system were successfully restored. But the sensors I had e.g. reset after upgrading (because I thought I’d have to reconnect them all anyway) are gone.

How else can we debug this? What do I have to look for in the logs?

Thank you!

[Smanar]

Yep 2 thing that are working sometime, if the issue is perturbation.

• Plug the SSD on a USB 2.0
• Use the extension cable but on the SSD.

[Jens]

My SSD is already connected via a shielded 30cm USB cable and is not in “line of sight” of the RPi, so any emissions of the SSD should not be an issue. Also, I have tried the pairing process with Zigbee sensors directly next to the USB stick, which didn’t work either, and with Zigbee sensors directly next to a Zigbee repeater (Innr plug), which also didn’t work - I don’t see how interference between two USB ports could cause this.

I will try exchanging cables, but I don’t see this as a solution:

• The SSD would be severely degraded in performance (I measured it: hdparm -tT returns ~190MB/s on USB3, and ~36MB/s on USB2),
• The USB stick would have worse coverage in our house (the 3m extension cable puts it below the stairs, but the RPi is not there)

Also, connection to all other Zigbee devices works 100% fine. Just new ones are not detected. If it really were an interference problem, wouldn’t also existing communication be disturbed?

[Smanar]

Was to make a test, I m agree using a SSD on USB 2.0 is not a good idea.

Can you take a look in logs if you have connexions issues ? (or others errors ? )

Also, connection to all other Zigbee devices works 100% fine. Just new ones are not detected. If it really were an interference problem, wouldn’t also existing communication be disturbed?

Right, but the inclusion procedure is less permissive than normal working mode.

[Jens]

Sure can do.
What am I looking for? The logs are REALLY verbose.
The problem is I cannot watch the logs live, since I would be in the basement and there is no screen connected to the RPi.

Is the inclusion procedure really so sensitive that the pairing does not work even if the Zigbee sensor is 10cm away from the ConBee stick, and the RPi and SSD are 3 meters away from both?

That sounds to me like a serious design issue.

[Smanar]

No I mean the procedure, it s event based, if a step not working, the inclusion can fail. On normal working mode connexions issues can be invisible.

You have an headless setup ? You can use command line too https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/deCONZ-debug-flags

I think only flags “error” and “error_l2” will be usefull “info” and “info_l2” can be usefull too to check for permit join. and just need logs during the inclusion.

[Jens]

Hello,

here’s the log. It seems that deCONZ isn’t even waiting for a full minute (or even 3 minutes as it claims), it’s finished after 10 seconds. But it doesn’t show the sensor that it found.

The sensors in question are still listed in deCONZ, can I somehow force reconnect them although they have been reset? In the UI and the log, the “missing” sensors have these IDs:

12:55:34:095 Node: id: 6, 00:15:8d:00:04:86:cf:a2 (0x00158D000486CFA2) scene: 52,823626, 29,436296
12:55:34:098 Node: id: 12, 00:15:8d:00:03:fb:4b:f4 (0x00158D0003FB4BF4) scene: 93,590277, -299,096076

This is the log from starting to scan for devices in the web ui, until it says “done”. But the sensor I had reset (one of the above) isn’t reconnected.

12:57:28:465 poll node 00:15:8d:00:03:89:3f:ca-01-0702
12:57:28:466 Poll ZHAConsumption sensor node Consumption 2
12:57:28:964 send permit join, duration: 59
12:57:29:355 poll node 00:15:8d:00:03:89:3f:ca-01-0b04
12:57:29:356 Poll ZHAPower sensor node Power 3
12:57:30:168 poll node 00:15:8d:00:03:89:3f:ca-01
12:57:30:168 Poll light node Steckdose 1. OG
12:57:31:007 poll node 00:15:8d:00:03:89:3f:ca-01-0702
12:57:31:008 Poll ZHAConsumption sensor node Consumption 2
12:57:31:889 poll node 00:15:8d:00:03:89:3f:ca-01-0b04
12:57:31:889 Poll ZHAPower sensor node Power 3
12:57:32:781 poll node 00:15:8d:00:03:89:3f:ca-01
12:57:32:782 Poll light node Steckdose 1. OG
12:57:33:621 poll node 00:15:8d:00:03:89:3f:ca-01-0702
12:57:33:621 Poll ZHAConsumption sensor node Consumption 2
12:57:33:964 Daylight now: solarNoon, status: 170, daylight: 1, dark: 0
12:57:33:968 Master: read param with arg 0x19
12:57:33:973 Device TTL 6418 s flags: 0x7
12:57:34:464 poll node 00:15:8d:00:03:89:3f:ca-01-0b04
12:57:34:465 Poll ZHAPower sensor node Power 3
12:57:35:269 void deCONZ::zmNode::setFetched(deCONZ::RequestId, bool) fetched item: 9, node: 0x0000
12:57:35:355 poll node 00:15:8d:00:03:89:3f:ca-01
12:57:35:356 Poll light node Steckdose 1. OG
12:57:36:167 poll node 00:15:8d:00:03:89:3f:ca-01-0702
12:57:36:168 Poll ZHAConsumption sensor node Consumption 2
12:57:36:379 void deCONZ::zmNode::setFetched(deCONZ::RequestId, bool) fetched item: 9, node: 0xE349
12:57:36:379 skip configure report for cluster: 0x0702 attr: 0x0000 of node 0x00158D0003893FCA (seems to be active)
12:57:36:380 skip configure report for cluster: 0x0702 attr: 0x0400 of node 0x00158D0003893FCA (seems to be active)
12:57:36:380 skip configure report for cluster: 0x0B04 attr: 0x050B of node 0x00158D0003893FCA (seems to be active)
12:57:36:380 skip configure report for cluster: 0x0B04 attr: 0x0505 of node 0x00158D0003893FCA (seems to be active)
12:57:36:381 skip configure report for cluster: 0x0B04 attr: 0x0508 of node 0x00158D0003893FCA (seems to be active)
12:57:36:464 add task 519 type 21 to 0x00158D0003893FCA cluster 0x0004 req.id 210
12:57:36:475 Erase task req-id: 210, type: 21 zcl seqno: 94 send time 0, profileId: 0x0104, clusterId: 0x0004
12:57:36:493 verified group capacity: 14 and group count: 2 of LightNode 0x00158d0003893fca
12:57:36:494 0x00158d0003893fca found group 0xFFF0
12:57:36:494 0x00158d0003893fca found group 0x0001
12:57:37:009 poll node 00:15:8d:00:03:89:3f:ca-01-0b04
12:57:37:009 Poll ZHAPower sensor node Power 3
12:57:37:391 void deCONZ::zmNode::setFetched(deCONZ::RequestId, bool) fetched item: 9, node: 0xE349
12:57:37:889 poll node 00:15:8d:00:03:89:3f:ca-01
12:57:37:890 Poll light node Steckdose 1. OG
12:57:38:444 void deCONZ::zmNode::setFetched(deCONZ::RequestId, bool) fetched item: 9, node: 0xE349
12:57:38:781 poll node 00:15:8d:00:03:89:3f:ca-01-0702
12:57:38:782 Poll ZHAConsumption sensor node Consumption 2
12:57:39:621 poll node 00:15:8d:00:03:89:3f:ca-01-0b04
12:57:39:622 Poll ZHAPower sensor node Power 3
12:57:39:964 send permit join, duration: 0
12:57:40:177 Search sensors done
12:57:40:464 poll node 00:15:8d:00:03:89:3f:ca-01
12:57:40:465 Poll light node Steckdose 1. OG
12:57:40:515 read attributes of 0x00158D0003893FCA cluster: 0x0006: [ 12:57:40:516 0x0000 12:57:40:516 ]
12:57:40:517 add task 537 type 19 to 0x00158D0003893FCA cluster 0x0006 req.id 236

[Mimiix]

Can you also add APS and APS L2?

@Smanar We want APS for seeing if theres communication.

[Jens]

I also just exchanged the USB2 port (where the ConBee II is connected) to a USB3 port (next to the SSD port), this did not help.

The other two differences to my previous system (where pairing worked fine) were

• Upgrade to 2.12.06 from 2.12.05
• Upgrade system to 64bit (Raspbery OS, not just the kernel)

Is it possible that the version upgrade changed something in the pairing process?

[Jens]

Sure, here’s with APS debugging. I tried to pair this sensor:
12:55:34:095 Node: id: 6, 00:15:8d:00:04:86:cf:a2 (0x00158D000486CFA2) scene: 52,823626, 29,436296

The connection should be established through the Innr plug gateway because the stick is too far away. (This used to work fine - but I also tried in the basement directly, where the ConBee stick is located, and it didn’t work either.)

19:41:26:969 send permit join, duration: 59
19:41:26:970 APS-DATA.request id: 227, addrmode: 0x02, addr: 0xfffc, profile: 0xA1E0, cluster: 0x0021, ep: 0xF2 → 0xF2 queue: 1 len: 6 tx.options 0x00
19:41:26:987 HTTP API GET /api/AB4DA90329/sensors/new?=1637700080383 - 192.168.178.83
19:41:26:989 ApiMode: 0
19:41:26:990 {“lastscan”:“active”}
19:41:26:992 APS-DATA.confirm id: 226, status: 0x00 SUCCESS
19:41:26:994 APS-DATA.confirm id: 227, status: 0x00 SUCCESS
19:41:27:020 aps request id: 226 finished, erase from queue
19:41:27:100 aps request id: 227 finished, erase from queue
19:41:27:490 HTTP API GET /api/AB4DA90329/sensors/new?=1637700080384 - 192.168.178.83
19:41:27:491 ApiMode: 0
19:41:27:492 {“lastscan”:“active”}
19:41:27:980 Mgmt_Lqi_req zdpSeq: 19 to 0x00158D0003893FCA start index 2
19:41:27:981 APS-DATA.request id: 233, addrmode: 0x03, addr: 0x00158d0003893fca, profile: 0x0000, cluster: 0x0031, ep: 0x00 → 0x00 queue: 0 len: 2 tx.options 0x00
19:41:27:989 HTTP API GET /api/AB4DA90329/sensors/new?=1637700080385 - 192.168.178.83
19:41:27:990 ApiMode: 0
19:41:27:990 {“lastscan”:“active”}
19:41:27:992 APS-DATA.confirm id: 233, status: 0x00 SUCCESS
19:41:27:993 APS-DATA.confirm request id: 233 → confirmed, timeout 298625013
19:41:28:005 APS-DATA.indication srcAddr: 0xe349, srcEp: 0x00 dstAddrMode: 2, profile: 0x0000, cluster: 0x8031, lqi: 31, rssi: -90
19:41:28:006 APS-DATA.indication request id: 233 → finished
19:41:28:006 APS-DATA.request id: 233 erase from queue
19:41:28:007 ZDP status = 0x00 → SUCCESS
19:41:28:008 ZDP Mgmt_Lqi_rsp zdpSeq: 19 from 0x00158D0003893FCA total: 5, startIndex: 2, listCount: 2
19:41:28:008 * neighbor: 0x00158D00047BC495 (0xCD8F), LQI: 128, relation: 0x01 rxOnWHenIdle: 0
19:41:28:009 * neighbor: 0x00158D0003FB4BD1 (0x4DA9), LQI: 115, relation: 0x01 rxOnWHenIdle: 0
19:41:28:489 HTTP API GET /api/AB4DA90329/sensors/new?=1637700080386 - 192.168.178.83
19:41:28:490 ApiMode: 0
19:41:28:490 {“lastscan”:“active”}
19:41:28:994 HTTP API GET /api/AB4DA90329/sensors/new?=1637700080387 - 192.168.178.83
19:41:28:994 ApiMode: 0
19:41:28:995 {“lastscan”:“active”}
19:41:29:495 HTTP API GET /api/AB4DA90329/sensors/new?=1637700080388 - 192.168.178.83
19:41:29:496 ApiMode: 0
19:41:29:496 {“lastscan”:“active”}
19:41:29:997 HTTP API GET /api/AB4DA90329/sensors/new?=1637700080389 - 192.168.178.83
19:41:29:998 ApiMode: 0
19:41:29:998 {“lastscan”:“active”}
19:41:30:498 HTTP API GET /api/AB4DA90329/sensors/new?=1637700080390 - 192.168.178.83
19:41:30:498 ApiMode: 0
19:41:30:499 {“lastscan”:“active”}
19:41:30:640 HTTP API GET /api/AB4DA90329/sensors?=1637700080391 - 192.168.178.83
19:41:30:641 ApiMode: 0
19:41:30:861 Mgmt_Lqi_req zdpSeq: 20 to 0x00158D0003893FCA start index 4
19:41:30:861 APS-DATA.request id: 246, addrmode: 0x03, addr: 0x00158d0003893fca, profile: 0x0000, cluster: 0x0031, ep: 0x00 → 0x00 queue: 0 len: 2 tx.options 0x00
19:41:30:872 APS-DATA.confirm id: 246, status: 0x00 SUCCESS
19:41:30:873 APS-DATA.confirm request id: 246 → confirmed, timeout 298627894
19:41:30:885 APS-DATA.indication srcAddr: 0xe349, srcEp: 0x00 dstAddrMode: 2, profile: 0x0000, cluster: 0x8031, lqi: 39, rssi: -89
19:41:30:885 APS-DATA.indication request id: 246 → finished
19:41:30:886 APS-DATA.request id: 246 erase from queue
19:41:30:886 ZDP status = 0x00 → SUCCESS
19:41:30:887 ZDP Mgmt_Lqi_rsp zdpSeq: 20 from 0x00158D0003893FCA total: 5, startIndex: 4, listCount: 1
19:41:30:887 * neighbor: 0x00158D0003FB4B97 (0xCE69), LQI: 87, relation: 0x01 rxOnWHenIdle: 0
19:41:30:000 HTTP API GET /api/AB4DA90329/sensors/new?=1637700080392 - 192.168.178.83
19:41:30:001 ApiMode: 0
19:41:30:001 {“lastscan”:“active”}
19:41:31:501 HTTP API GET /api/AB4DA90329/sensors/new?=1637700080393 - 192.168.178.83
19:41:31:502 ApiMode: 0
19:41:31:502 {“lastscan”:“active”}
19:41:32:002 HTTP API GET /api/AB4DA90329/sensors/new?=1637700080394 - 192.168.178.83
19:41:32:003 ApiMode: 0
19:41:32:004 {“lastscan”:“active”}
19:41:32:504 HTTP API GET /api/AB4DA90329/sensors/new?=1637700080395 - 192.168.178.83
19:41:32:504 ApiMode: 0
19:41:32:505 {“lastscan”:“active”}
19:41:33:005 HTTP API GET /api/AB4DA90329/sensors/new?=1637700080396 - 192.168.178.83
19:41:33:006 ApiMode: 0
19:41:33:007 {“lastscan”:“active”}
19:41:33:507 HTTP API GET /api/AB4DA90329/sensors/new?=1637700080397 - 192.168.178.83
19:41:33:508 ApiMode: 0
19:41:33:508 {“lastscan”:“active”}
19:41:34:013 HTTP API GET /api/AB4DA90329/sensors/new?=1637700080398 - 192.168.178.83
19:41:34:013 ApiMode: 0
19:41:34:014 {“lastscan”:“active”}
19:41:34:220 Mgmt_Lqi_req zdpSeq: 21 to 0x00212EFFFF054BC8 start index 0
19:41:34:221 APS-DATA.request id: 6, addrmode: 0x03, addr: 0x00212effff054bc8, profile: 0x0000, cluster: 0x0031, ep: 0x00 → 0x
00 queue: 0 len: 2 tx.options 0x00
19:41:34:225 APS-DATA.confirm id: 6, status: 0x00 SUCCESS
19:41:34:225 APS-DATA.confirm request id: 6 → confirmed, timeout 298631253
19:41:34:227 APS-DATA.indication srcAddr: 0x0000, srcEp: 0x00 dstAddrMode: 2, profile: 0x0000, cluster: 0x8031, lqi: 204, rssi:
-52
19:41:34:227 APS-DATA.indication request id: 6 → finished
19:41:34:228 APS-DATA.request id: 6 erase from queue
19:41:34:228 ZDP status = 0x00 → SUCCESS
19:41:34:229 ZDP Mgmt_Lqi_rsp zdpSeq: 21 from 0x00212EFFFF054BC8 total: 2, startIndex: 0, listCount: 1
19:41:34:229 * neighbor: 0x00158D0003893FCA (0xE349), LQI: 32, relation: 0x02 rxOnWHenIdle: 1
19:41:34:510 HTTP API GET /api/AB4DA90329/sensors/new?=1637700080399 - 192.168.178.83
19:41:34:511 ApiMode: 0
19:41:34:512 {“lastscan”:“active”}
19:41:35:010 HTTP API GET /api/AB4DA90329/sensors/new?=1637700080400 - 192.168.178.83
19:41:35:011 ApiMode: 0
19:41:35:012 {“lastscan”:“active”}
19:41:35:106 HTTP API GET /api/config - 127.0.0.1
19:41:35:107 {“apiversion”:“1.16.0”,“bridgeid”:“00212EFFFF054BC8”,“datastoreversion”:“93”,“devicename”:“ConBee II”,“factorynew”
:false,“mac”:“dc:a6:32:4f:43:7f”,“modelid”:“deCONZ”,“name”:“Raspberry-GW”,“replacesbridgeid”:null,“starterkitid”:"",“swversion”
:“2.12.6”}
19:41:35:512 HTTP API GET /api/AB4DA90329/sensors/new?=1637700080401 - 192.168.178.83
19:41:35:513 ApiMode: 0
19:41:35:514 {“lastscan”:“active”}
19:41:35:639 HTTP API GET /api/AB4DA90329/sensors?=1637700080402 - 192.168.178.83
19:41:35:640 ApiMode: 0
19:41:36:013 HTTP API GET /api/AB4DA90329/sensors/new?=1637700080403 - 192.168.178.83
19:41:36:014 ApiMode: 0
19:41:36:014 {“lastscan”:“active”}
19:41:36:515 HTTP API GET /api/AB4DA90329/sensors/new?=1637700080404 - 192.168.178.83
19:41:36:516 ApiMode: 0
19:41:36:516 {“lastscan”:“active”}
19:41:37:015 HTTP API GET /api/AB4DA90329/sensors/new?=1637700080405 - 192.168.178.83
19:41:37:016 ApiMode: 0
19:41:37:017 {“lastscan”:“active”}
19:41:37:100 Mgmt_Lqi_req zdpSeq: 22 to 0x00212EFFFF054BC8 start index 1
19:41:37:101 APS-DATA.request id: 19, addrmode: 0x03, addr: 0x00212effff054bc8, profile: 0x0000, cluster: 0x0031, ep: 0x00 → 0
x00 queue: 0 len: 2 tx.options 0x00
19:41:37:105 APS-DATA.confirm id: 19, status: 0x00 SUCCESS
19:41:37:106 APS-DATA.confirm request id: 19 → confirmed, timeout 298634134
19:41:37:108 APS-DATA.indication srcAddr: 0x0000, srcEp: 0x00 dstAddrMode: 2, profile: 0x0000, cluster: 0x8031, lqi: 117, rssi:
32
19:41:37:109 APS-DATA.indication request id: 19 → finished
19:41:37:110 APS-DATA.request id: 19 erase from queue
19:41:37:110 ZDP status = 0x00 → SUCCESS
19:41:37:111 ZDP Mgmt_Lqi_rsp zdpSeq: 22 from 0x00212EFFFF054BC8 total: 2, startIndex: 1, listCount: 1
19:41:37:112 * neighbor: 0x00158D00045C9D5D (0x7CB9), LQI: 255, relation: 0x01 rxOnWHenIdle: 0
19:41:37:518 HTTP API GET /api/AB4DA90329/sensors/new?=1637700080406 - 192.168.178.83
19:41:37:520 ApiMode: 0
19:41:37:521 {“lastscan”:“active”}
19:41:37:974 Device TTL 3194 s flags: 0x7
19:41:38:018 HTTP API GET /api/AB4DA90329/sensors/new?_=1637700080407 - 192.168.178.83
19:41:38:019 ApiMode: 0
19:41:38:020 {“lastscan”:“active”}
(…)

Does this help?

[Swoop]

You seem to have more than one Phoscon tab open (maybe even accros devices). When you see permit join duration set to 59 and within around 10 secs it is set to 0, that’s a very strong indication.

So give it a try with only 1 tab open.

[Jens]

Yes, I did (smartphone & PC). Now it’s only the PC (192.168.178.83)

21:46:38:437 HTTP API GET /api/38D7042DC3/sensors/new?=1637707571370 - 192.168.178.83
21:46:38:438 ApiMode: 0
21:46:38:438 {“lastscan”:“active”}
21:46:38:481 APS-DATA.request id: 47, addrmode: 0x02, addr: 0xfffc, profile: 0x0000, cluster: 0x0036, ep: 0x00 → 0x00 queue: 1
len: 3 tx.options 0x00
21:46:38:481 send permit join, duration: 59
21:46:38:482 APS-DATA.request id: 48, addrmode: 0x02, addr: 0xfffc, profile: 0xA1E0, cluster: 0x0021, ep: 0xF2 → 0xF2 queue: 2
len: 6 tx.options 0x00
21:46:38:522 APS-DATA.confirm id: 47, status: 0x00 SUCCESS
21:46:38:561 aps request id: 47 finished, erase from queue
21:46:38:583 APS-DATA.confirm id: 48, status: 0x00 SUCCESS
21:46:38:641 aps request id: 48 finished, erase from queue
21:46:38:802 Node 0x00158D0003FB4BD1 is known by 0 neighbors, last seen 0 s
21:46:38:939 HTTP API GET /api/38D7042DC3/sensors/new?=1637707571371 - 192.168.178.83
21:46:38:940 ApiMode: 0
21:46:38:941 {“lastscan”:“active”}
21:46:39:282 Node 0x00158D000418D6DC is known by 0 neighbors, last seen 0 s
21:46:39:441 HTTP API GET /api/38D7042DC3/sensors/new?=1637707571372 - 192.168.178.83
21:46:39:442 ApiMode: 0
21:46:39:442 {“lastscan”:“active”}
21:46:39:761 Node 0x00158D00045C9D5D is known by 0 neighbors, last seen 0 s
21:46:39:942 HTTP API GET /api/38D7042DC3/sensors/new?=1637707571373 - 192.168.178.83
21:46:39:943 ApiMode: 0
21:46:39:944 {“lastscan”:“active”}
21:46:39:001 Mgmt_Lqi_req zdpSeq: 5 to 0x00158D0003893FCA start index 0
21:46:39:002 APS-DATA.request id: 56, addrmode: 0x03, addr: 0x00158d0003893fca, profile: 0x0000, cluster: 0x0031, ep: 0x00 → 0
x00 queue: 1 len: 2 tx.options 0x00
21:46:40:015 APS-DATA.confirm id: 56, status: 0x00 SUCCESS
21:46:40:016 APS-DATA.confirm request id: 56 → confirmed, timeout 306137022
21:46:40:031 APS-DATA.indication srcAddr: 0xe349, srcEp: 0x00 dstAddrMode: 2, profile: 0x0000, cluster: 0x8031, lqi: 39, rssi:
-89
21:46:40:031 asdu: 0500050002c84b05ffff2e2100c84b05ffff2e2100000004020003c84b05ffff2e2100cdb2d0feff277184e89c1202021e
21:46:40:032 APS-DATA.indication request id: 56 → finished
21:46:40:033 APS-DATA.request id: 56 erase from queue
21:46:40:033 ZDP status = 0x00 → SUCCESS
21:46:40:034 ZDP Mgmt_Lqi_rsp zdpSeq: 5 from 0x00158D0003893FCA total: 5, startIndex: 0, listCount: 2
21:46:40:034 * neighbor: 0x00212EFFFF054BC8 (0x0000), LQI: 3, relation: 0x00 rxOnWHenIdle: 1
21:46:40:035 * neighbor: 0x847127FFFED0B2CD (0x9CE8), LQI: 30, relation: 0x01 rxOnWHenIdle: 0
21:46:40:241 Node 0x00158D0003FB4BF4 is known by 0 neighbors, last seen 0 s
21:46:40:443 HTTP API GET /api/38D7042DC3/sensors/new?=1637707571374 - 192.168.178.83
21:46:40:444 ApiMode: 0
21:46:40:445 {“lastscan”:“active”}
21:46:40:485 HTTP API GET /api/config - 127.0.0.1
21:46:40:486 {“apiversion”:“1.16.0”,“bridgeid”:“00212EFFFF054BC8”,“datastoreversion”:“93”,“devicename”:“ConBee II”,“factorynew”
:false,“mac”:“dc:a6:32:4f:43:7f”,“modelid”:“deCONZ”,“name”:“Raspberry-GW”,“replacesbridgeid”:null,“starterkitid”:"",“swversion”
:“2.12.6”}
21:46:40:721 Node 0x00158D0003FB4D10 is known by 0 neighbors, last seen 0 s
21:46:40:943 HTTP API GET /api/38D7042DC3/sensors/new?=1637707571375 - 192.168.178.83
21:46:40:944 ApiMode: 0
21:46:40:944 {“lastscan”:“active”}
21:46:41:201 Node 0x847127FFFED0B2CD is known by 1 neighbors, last seen 1089 s
21:46:41:444 HTTP API GET /api/38D7042DC3/sensors/new?=1637707571376 - 192.168.178.83
21:46:41:445 ApiMode: 0
21:46:41:445 {“lastscan”:“active”}
21:46:41:609 HTTP API GET /api/38D7042DC3/sensors?=1637707571377 - 192.168.178.83
21:46:41:610 ApiMode: 0
21:46:41:682 Node 0x00158D000465B84A is known by 0 neighbors, last seen 0 s
21:46:41:945 HTTP API GET /api/38D7042DC3/sensors/new?_=1637707571378 - 192.168.178.83
21:46:41:946 ApiMode: 0
21:46:41:946 {“lastscan”:“active”}
21:46:42:162 Node 0x00158D0003FB4B72 is known by 0 neighbors, last seen 0 s
21:46:42:430 M-SEARCH * HTTP/1.1
HOST: 239.255.255.250:1900
MAN: “ssdp:discover”
MX: 1
ST: urn:dial-multiscreen-org:service:dial:1
USER-AGENT: Google Chrome/95.0.4638.69 Linux

21:46:42:447 HTTP API GET /api/38D7042DC3/sensors/new?=1637707571379 - 192.168.178.83
21:46:42:447 ApiMode: 0
21:46:42:447 {“lastscan”:“active”}
21:46:42:641 Node 0x00158D0003FB4D00 is known by 0 neighbors, last seen 0 s
21:46:42:881 Mgmt_Lqi_req zdpSeq: 6 to 0x00158D0003893FCA start index 2
21:46:42:882 APS-DATA.request id: 69, addrmode: 0x03, addr: 0x00158d0003893fca, profile: 0x0000, cluster: 0x0031, ep: 0x00 → 0x00 queue: 1 len: 2 tx.options 0x00
21:46:42:892 APS-DATA.confirm id: 69, status: 0x00 SUCCESS
21:46:42:892 APS-DATA.confirm request id: 69 → confirmed, timeout 306139901
21:46:42:906 APS-DATA.indication srcAddr: 0xe349, srcEp: 0x00 dstAddrMode: 2, profile: 0x0000, cluster: 0x8031, lqi: 39, rssi: -89
21:46:42:907 asdu: 0600050202c84b05ffff2e210095c47b04008d15008fcd12020280c84b05ffff2e2100d14bfb03008d1500a94d12020273
21:46:42:907 APS-DATA.indication request id: 69 → finished
21:46:42:907 APS-DATA.request id: 69 erase from queue
21:46:42:907 ZDP status = 0x00 → SUCCESS
21:46:42:908 ZDP Mgmt_Lqi_rsp zdpSeq: 6 from 0x00158D0003893FCA total: 5, startIndex: 2, listCount: 2
21:46:42:908 * neighbor: 0x00158D0003FB4BD1 (0x4DA9), LQI: 115, relation: 0x01 rxOnWHenIdle: 0
21:46:42:948 HTTP API GET /api/38D7042DC3/sensors/new?=1637707571380 - 192.168.178.83
21:46:42:948 ApiMode: 0
21:46:42:949 {“lastscan”:“active”}
21:46:43:121 Node 0x00158D0003FB4BD2 is known by 0 neighbors, last seen 0 s
21:46:43:431 M-SEARCH * HTTP/1.1
HOST: 239.255.255.250:1900
MAN: “ssdp:discover”
MX: 1
ST: urn:dial-multiscreen-org:service:dial:1
USER-AGENT: Google Chrome/95.0.4638.69 Linux

21:46:43:450 HTTP API GET /api/38D7042DC3/sensors/new?_=1637707571381 - 192.168.178.83
21:46:43:450 ApiMode: 0
21:46:43:451 {“lastscan”:“active”}
21:46:43:601 Node 0x00158D00047BC495 is known by 1 neighbors, last seen 614 s
21:46:43:743 APS-DATA.indication srcAddr: 0xe349, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0B04, lqi: 47, rssi:
-88
21:46:43:744 asdu: 18e80a0b05290000
21:46:43:744 Node data 0x00158d0003893fca profileId: 0x0104, clusterId: 0x0B04
21:46:43:745 0x00158D0003893FCA: added ZCL value 0x01/0x0B04/0x050B
21:46:43:745 [INFO] - No button map for: SP 120, unicast to: 0x0000, endpoint: 0x01, cluster: 0x0B04, command: 0x0A, payload: 0
B05290000, zclSeq: 232
21:46:43:746 ZCL attribute report 0x00158D0003893FCA for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000
21:46:43:746 payload: 0b05290000
21:46:43:746 0x00158D0003893FCA (SP 120) create binding for attribute reporting of cluster 0x0702 on endpoint 0x01
21:46:43:747 queue binding task for 0x00158D0003893FCA, cluster 0x0702
21:46:43:747 binding for attribute reporting of ep: 0x01 cluster 0x0B04 seems to be active
21:46:43:748 Websocket 192.168.178.83:38770 send message: {“e”:“changed”,“id”:“3”,“r”:“sensors”,“state”:{“current”:0,“lastupdat
ed”:“2021-11-23T22:46:43.745”,“power”:0,“voltage”:234},“t”:“event”,“uniqueid”:“00:15:8d:00:03:89:3f:ca-01-0b04”} (ret = 181)
21:46:43:748 APS-DATA.request id: 76, addrmode: 0x03, addr: 0x00158d0003893fca, profile: 0x0000, cluster: 0x0021, ep: 0x00 → 0
x00 queue: 1 len: 22 tx.options 0x04
21:46:43:753 HTTP API GET /api/38D7042DC3/sensors/3 - 192.168.178.83
21:46:43:753 ApiMode: 0
21:46:43:754 {“config”:{“on”:true,“reachable”:true},“ep”:1,“etag”:“e38e89f711c2205da78759ea57349173”,“lastannounced”:null,“last
seen”:“2021-11-23T20:01Z”,“manufacturername”:“innr”,“modelid”:“SP 120”,“name”:“Power 3”,“state”:{“current”:0,“lastupdated”:“202
1-11-23T22:46:43.745”,“power”:0,“voltage”:234},“swversion”:“2.0”,“type”:“ZHAPower”,“uniqueid”:“00:15:8d:00:03:89:3f:ca-01-0b04”
}
21:46:43:769 APS-DATA.confirm id: 76, status: 0x00 SUCCESS
21:46:43:770 APS-DATA.confirm request id: 76 → confirmed, timeout 306140768
21:46:43:787 APS-DATA.indication srcAddr: 0xe349, srcEp: 0x00 dstAddrMode: 2, profile: 0x0000, cluster: 0x8021, lqi: 39, rssi:
-89
21:46:43:788 asdu: 6f00
(…)

[Mimiix]

I see logs i didn’t even know where they come from and i don’t see logs i’d like to see.

Can you please enable loglevels:
APS/APS_L2
ERROR/ERROR_L2
INFO/INFO_L2

Then post the results on pastebin instead of the forum?

[Jens]

Weird. But thank you, here you are:

Link: Pastebin.com - Locked Paste
Password: GTs4E9GPyv
(will expire in 1 week)

join starts at about 17:12:50

Thank you!

[Mimiix]

Can you update the firmware to the latest? http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_ConBeeII_0x26720700.bin.GCF

Also, How many routers/sensors do you have>?

[Jens]

First, Thank you VERY much for guiding me so far.
I updated the firmware to the version above successfully.
I have 13 Xiaomi Aqara temperature / humidity / pressure sensors configured, 4 of which are not active right now because they were reset when I tried to get them reconnected using a fresh installation (which also did not work).
I have one Innr electrical plug as a router extending the reach of the ConBee II Zigbee network to the upper floors.
This all worked beautifully on the Raspberry Pi 4b with SD card, until the SD card failed, as they always do. My server is simply too active to be able to use a SD card forever.

[Mimiix]

I think , at first, you need to add more routers. The innr’s arent that great on repeating. Conbee can theoretically have 16 devices connected at the same time. However, we often see that being lower. In your case that’s 10 in total.

Adding more routers would help here at first.

[Jens]

No, this is not the root cause, for three reasons:

1. Exactly this setup worked 100% reliably before I upgraded to 64bit deCONZ 2.12.06 (from 32bit deCONZ 2.12.05).
2. 64bit 2.12.06 even could not connect to any new sensor on a totally empty fresh installation.
3. I found the real root cause.

The real root cause were apparently batteries in the sensors below 50% charge level. Not anywhere near a battery warning level, but putting a new battery in each sensor just for the pairing process now worked beautifully and all my sensors are online again (for now, with the previous batteries!). Pairing even worked through 2 flights of stairs (from the upper floor while the ConBee II stick is in the basement) so distance to routers does not seem to be a problem in my network.

Wow. In hindsight, it seemed obvious to try this but it took me a while… It seems at least the Xiaomi Aqara sensors need more power to join than to operate, and <50% battery level just isn’t enough. This may apply to more sensor OEMs (I don’t know).

Can you do me a favor and document this in some FAQ? The next guy/gal having this issue should not have to search for the answer as long as I did.

Thank you

[Smanar]

@Jens

Can you do me a favor and document this in some FAQ? The next guy/gal having this issue should not have to search for the answer as long as I did.

Lol, not only you.

And about battery it s normal, it s the normal working mode, the discharge is not proportionnal, you will have 100% during 2 years, then 90% during 1 years and the battery go to 80% to 50% in 2 month (for exemple).
A Xiaomi battery under 75% can be replaced.