Cannot create backup / strange behavior in logs

I have HA installed on RPi 4B and Conbee II with extender connected to USB 2.0 port.
Conbee II has newest firmware (0x26720700), deCONZ add-on is 6.10.0 (Phoscon app is 2.12.06).
Core is 2021.11.1, Supervisor is 2021.10.8 and HA OS is 6.6.
This issue happened also on older firmware/deCONZ/Core etc (can’t remember when this started).

I cannot create backup in Phoscon app (Menu → Gateway → Backup options → Create backup):

image

I noticed this strange behavior in deCONZ logs. Every 10 seconds I get:

11:08:15:702 apsUseExtPanid is 0xDDDDDDDDDDDDDDDD but should be 0, start reconfiguration
11:08:15:702 tcAddress is 0x0000000000000000 but should be 0x00212EFFFF06668D, start reconfiguration
11:08:15:703 Skip automatic channel change, TODO warn user

11:08:25:701 apsUseExtPanid is 0xDDDDDDDDDDDDDDDD but should be 0, start reconfiguration
11:08:25:701 tcAddress is 0x0000000000000000 but should be 0x00212EFFFF06668D, start reconfiguration
11:08:25:702 Skip automatic channel change, TODO warn user

11:08:35:701 apsUseExtPanid is 0xDDDDDDDDDDDDDDDD but should be 0, start reconfiguration
11:08:35:702 tcAddress is 0x0000000000000000 but should be 0x00212EFFFF06668D, start reconfiguration
11:08:35:702 Skip automatic channel change, TODO warn user

Also I noticed, that every hour I get this in Supervisor log:

21-10-13 11:35:22 INFO (MainThread) [supervisor.hardware.monitor] Detecting HardwareAction.REMOVE hardware /dev/ttyACM0 - /dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2256117-if00
21-10-13 11:35:22 INFO (MainThread) [supervisor.hardware.monitor] Detecting HardwareAction.REMOVE hardware /dev/bus/usb/001/003 - None
21-10-13 11:35:25 INFO (MainThread) [supervisor.hardware.monitor] Detecting HardwareAction.ADD hardware /dev/bus/usb/001/004 - None
21-10-13 11:35:25 INFO (MainThread) [supervisor.hardware.monitor] Detecting HardwareAction.ADD hardware /dev/ttyACM1 - /dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2256117-if00
21-10-13 11:35:26 INFO (MainThread) [supervisor.hardware.monitor] Detecting HardwareAction.REMOVE hardware /dev/ttyACM1 - /dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2256117-if00
21-10-13 11:35:26 INFO (MainThread) [supervisor.hardware.monitor] Detecting HardwareAction.REMOVE hardware /dev/bus/usb/001/004 - None
21-10-13 11:35:29 INFO (MainThread) [supervisor.hardware.monitor] Detecting HardwareAction.ADD hardware /dev/bus/usb/001/005 - None
21-10-13 11:35:29 INFO (MainThread) [supervisor.hardware.monitor] Detecting HardwareAction.ADD hardware /dev/ttyACM0 - /dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2256117-if00

21-10-13 12:35:26 INFO (MainThread) [supervisor.hardware.monitor] Detecting HardwareAction.REMOVE hardware /dev/ttyACM0 - /dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2256117-if00
21-10-13 12:35:26 INFO (MainThread) [supervisor.hardware.monitor] Detecting HardwareAction.REMOVE hardware /dev/bus/usb/001/005 - None
21-10-13 12:35:28 INFO (MainThread) [supervisor.hardware.monitor] Detecting HardwareAction.ADD hardware /dev/bus/usb/001/006 - None
21-10-13 12:35:28 INFO (MainThread) [supervisor.hardware.monitor] Detecting HardwareAction.ADD hardware /dev/ttyACM1 - /dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2256117-if00
21-10-13 12:35:30 INFO (MainThread) [supervisor.hardware.monitor] Detecting HardwareAction.REMOVE hardware /dev/ttyACM1 - /dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2256117-if00
21-10-13 12:35:30 INFO (MainThread) [supervisor.hardware.monitor] Detecting HardwareAction.REMOVE hardware /dev/bus/usb/001/006 - None
21-10-13 12:35:32 INFO (MainThread) [supervisor.hardware.monitor] Detecting HardwareAction.ADD hardware /dev/bus/usb/001/007 - None
21-10-13 12:35:32 INFO (MainThread) [supervisor.hardware.monitor] Detecting HardwareAction.ADD hardware /dev/ttyACM0 - /dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2256117-if00

During this REMOVE and ADD issue deCONZ log looks like this:

12:35:27:280 device state timeout ignored in state 3
12:35:27:544 device state timeout ignored in state 3
12:35:27:704 device state timeout ignored in state 3
12:35:27:864 device state timeout ignored in state 3
12:35:28:024 device state timeout ignored in state 3
12:35:28:184 device state timeout ignored in state 3
12:35:28:344 device state timeout ignored in state 3
12:35:28:504 device state timeout ignored in state 3
12:35:28:664 device state timeout ignored in state 3
12:35:28:824 device state timeout ignored in state 3
12:35:28:984 device state timeout ignored in state 3
12:35:29:144 device state timeout (handled)
12:35:29:201 wait reconnect 15 seconds
12:35:29:225 void zmMaster::handleStateIdle(zmMaster::MasterEvent) not connected goto OFF state
12:35:29:226 device state timeout ignored in state 1
12:35:29:361 0x0017880102B5A93C error APSDE-DATA.confirm: 0xA7 on task
12:35:30:201 wait reconnect 14 seconds
12:35:31:201 wait reconnect 13 seconds
12:35:32:201 wait reconnect 12 seconds
12:35:33:201 wait reconnect 11 seconds
12:35:34:201 wait reconnect 10 seconds
12:35:34:501 sensor 30 (PHOSCON_VPIR): disable presence
12:35:34:504 rule event /sensors/30/state/lastupdated: 0 -> 0
12:35:35:201 wait reconnect 9 seconds
12:35:36:201 wait reconnect 8 seconds
12:35:37:201 wait reconnect 7 seconds
12:35:38:201 wait reconnect 6 seconds
12:35:39:201 wait reconnect 5 seconds
12:35:40:201 wait reconnect 4 seconds
12:35:41:201 wait reconnect 3 seconds
12:35:42:201 wait reconnect 2 seconds
12:35:43:201 wait reconnect 1 seconds
12:35:43:279 COM: /dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2256117-if00 / serialno: DE2256117, ConBee II
12:35:44:201 Skip idle timer callback, too early: elapsed 905 msec
12:35:44:908 Device firmware version 0x26720700 ConBee II
12:35:44:916 Device firmware version 0x26720700 ConBee II
12:35:44:918 unlocked max nodes: 512
12:35:45:008 Device protocol version: 0x010E
12:35:45:149 CTRL ANT_CTRL 0x03
12:35:45:151 CTRL ZDP_RESPONSE handler 0x0000
12:35:45:152 CTRL reconfigure ZDP_RESPONSE handler 0x0001
12:35:45:191 Device protocol version: 0x010E
12:35:45:203 trigger rule 19 - pir-fsm-state-dimm1
12:35:45:205 rule event /sensors/34/state/status: 1 -> 2

And of course during that ADD/REMOVE Zigbee devices are unavailable.

So first thing I did was to change apsUseExtPanid in deCONZ to 0x0000000000000000 and tcAddress to MAC of Conbee II 0x00212EFFFF06668D as deCONZ log suggests.
After saving that in deCONZ everything works great and I can make backup of config through Phoscon app until HA host reboots/power outage.
After reboot apsUseExtPanid goes back to 0xDDDDDDDDDDDDDDDD and tcAddress to 0x0000000000000000 and I think this is the main problem :).

You probably used z2m or zha.

Those scrambled the network settings on the stick.

Do you have any of those still running?

Yup, a few months ago i connected my second Conbee II and configured Z2M for a few days. Since then I don’t use that stick anymore.
Do you know how to fix that? Any similar bug report? Thanks in advance!

It’s not a bug, it’s normal behavior in this case. The reason that the reboot scrambles it again, is probsbly because the z2m also starts at boot

I’ve uninstalled Z2M few months ago and don’t use this addon.

I have the exact same problem. I’m currently running 2.13.02 / 2021-11-10 with
Conbee II Firmware 26720700 (which is the latest available as of today) on a Raspbian Buster system.

I haven’t tried obtaining backups with older firmware, which I regret now, because that would be valuable information to post here.
This is because as soon as I got my system running, first thing I did was update to current available firmware. But I can tell that the same problem with backup occurred while running deCONZ 2.13.01 with said latest firmware.

I have tried changing apsUseExtPanid (to 0x0) and tcAddress (to the Conbee II MAC address) and then the backup immediately works. That is, UNTIL the system is rebooted. From then on, it fails again until I redo above mentioned changes.

Is there a way to make the changes permanent?

TIA
Cesar

1 Like

Unexpected thing happened today…
Having already tried twice, I decided to try yet another time the above mentioned changes. And it seems the third time is the charm. The changes now seem to remain even after reboots and backups works as expected.

Well, I’ll wait for stable release and check if it fixes this bug.

I’ve upgraded to 2.13.04 and nothing changed.

Can you share your network settings?

Sure, there you go:

Above is just after host reboot and below is after I manually fix “APS Use Ext PAN ID” and “TC Address”.

The TC link key seems to be incorect too. Did you ever use Z2M or ZHA?

Yep, before Deconz I had Z2M. What do you suggest to fill in TC link key?

0x5a6967426565416c6c69616e63653039

Updated TC Link Key as you suggested - after host reboot everything looks exactly like on 1st screenshot :confused: . It doesn’t save those manually entered IDs/Addresses.

Do you still have Z2m running? Also, i think you need to leave the network, then write the network config and then join again.

I’ve uninstalled Z2M months ago.
Your suggestion to leave the network and then save the config solved this puzzle - now, after restart all those settings are remembered. TYVM!

1 Like

@Mimiix, I have to ask one more thing, as I found after changing APS Use Ext PAN ID, that none of the Neighbor Links are drawn in GUI. After analysing ZDP logs, I’ve changed APS Use Ext PAN ID to the previous version (0xDDDDDDDDDDDDDDDD) and the links started to draw. I know this value is inproper so I’ve change it back to 0.
Now with APS Use Ext PAN ID set to 0x0000000000000000 I’ve noticed in my ZDP logs:
image
And I want to fix this :). So I started repairing my devices but nothing changed in ZDP logs. Do I have to delete device from Deconz and pair it again? Or is there any other fix for those different pan error?

Yes.

That other Pan is stored in the device. I don’t think you can change that thus you need to reset and re-pair.