Migrate HA from Pi3 to Intel Mini PC - Conbee 2 not working

Hello together,

i bought a new mini pc (N95) to migrate my HA installation from an old Pi3.
The migration was no problem. Just a fresh install and a restore out of the complete backup.
Everything works fine, except the ZHA Integration.
I am using a Conbee II from Dresden Electronic and it is working fine in the old machine (Pi3).
In the new machine i reconfigured the Conbee II and it saw the stick on the right port. But it ends up with an error in the last config screen.

I searched for the problem in the internet, but just found some different problems like loosing connections.

I added my dev log.

Perhaps someone hat the same problem and has an idea what i can do.

2024-04-27 18:17:52.954 DEBUG (MainThread) [zigpy_deconz.uart] Connecting to /dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2684116-if00
2024-04-27 18:17:52.954 DEBUG (MainThread) [zigpy.serial] Opening a serial connection to '/dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2684116-if00' (38400 baudrate)
2024-04-27 18:17:52.957 DEBUG (MainThread) [zigpy_deconz.uart] Connection made
2024-04-27 18:17:52.957 DEBUG (MainThread) [zigpy_deconz.uart] Connected to /dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2684116-if00
2024-04-27 18:17:52.957 DEBUG (MainThread) [zigpy_deconz.api] Sending CommandId.read_parameter{'parameter_id': <NetworkParameter.protocol_version: 34>, 'parameter': b''} (seq=1)
2024-04-27 18:17:52.957 DEBUG (MainThread) [zigpy_deconz.uart] Send: 0a01000800010022
2024-04-27 18:17:52.958 DEBUG (MainThread) [zigpy_deconz.uart] Frame received: 0x0a01000a000300220e01
2024-04-27 18:17:52.958 DEBUG (MainThread) [zigpy_deconz.api] Received command CommandId.read_parameter{'status': <Status.SUCCESS: 0>, 'frame_length': 10, 'payload_length': 3, 'parameter_id': <NetworkParameter.protocol_version: 34>, 'parameter': b'\x0e\x01'} (seq 1)
2024-04-27 18:17:52.958 DEBUG (MainThread) [zigpy_deconz.api] Read parameter protocol_version(None)=270
2024-04-27 18:17:52.959 DEBUG (MainThread) [zigpy_deconz.api] Sending CommandId.version{'reserved': 0} (seq=2)
2024-04-27 18:17:52.959 DEBUG (MainThread) [zigpy_deconz.uart] Send: 0d0200090000000000
2024-04-27 18:17:52.967 DEBUG (MainThread) [zigpy_deconz.uart] Frame received: 0x0d0200090000077226
2024-04-27 18:17:52.967 DEBUG (MainThread) [zigpy_deconz.api] Received command CommandId.version{'status': <Status.SUCCESS: 0>, 'frame_length': 9, 'version': FirmwareVersion<0x26720700>(reserved=0, platform=<FirmwarePlatform.Conbee_II: 7>, minor=114, major=38)} (seq 2)
2024-04-27 18:17:52.967 DEBUG (MainThread) [zigpy_deconz.api] Sending CommandId.device_state{} (seq=3)
2024-04-27 18:17:52.968 DEBUG (MainThread) [zigpy_deconz.uart] Send: 0703000800000000
2024-04-27 18:17:54.769 DEBUG (MainThread) [zigpy_deconz.api] No response to 'CommandId.device_state' command with seq 3
2024-04-27 18:17:54.770 DEBUG (Thread-27) [aiosqlite] executing functools.partial(<function PersistingListener._set_isolation_level.<locals>.<lambda> at 0x7f699caaea20>)
2024-04-27 18:17:54.770 DEBUG (Thread-27) [aiosqlite] operation functools.partial(<function PersistingListener._set_isolation_level.<locals>.<lambda> at 0x7f699caaea20>) completed
2024-04-27 18:17:54.772 DEBUG (MainThread) [zigpy_deconz.api] Serial '/dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2684116-if00' connection lost unexpectedly: None
2024-04-27 18:17:54.772 DEBUG (Thread-27) [aiosqlite] executing functools.partial(<built-in method execute of sqlite3.Connection object at 0x7f6965179f30>, 'PRAGMA wal_checkpoint;', [])
2024-04-27 18:17:54.773 DEBUG (Thread-27) [aiosqlite] operation functools.partial(<built-in method execute of sqlite3.Connection object at 0x7f6965179f30>, 'PRAGMA wal_checkpoint;', []) completed
2024-04-27 18:17:54.774 DEBUG (Thread-27) [aiosqlite] executing functools.partial(<function PersistingListener._set_isolation_level.<locals>.<lambda> at 0x7f6975b6b240>)
2024-04-27 18:17:54.775 DEBUG (Thread-27) [aiosqlite] operation functools.partial(<function PersistingListener._set_isolation_level.<locals>.<lambda> at 0x7f6975b6b240>) completed
2024-04-27 18:17:54.775 DEBUG (Thread-27) [aiosqlite] executing functools.partial(<built-in method close of sqlite3.Connection object at 0x7f6965179f30>)
2024-04-27 18:17:54.776 DEBUG (Thread-27) [aiosqlite] operation functools.partial(<built-in method close of sqlite3.Connection object at 0x7f6965179f30>) completed
2024-04-27 18:17:54.777 DEBUG (MainThread) [homeassistant.components.zha] Failed to set up ZHA
Traceback (most recent call last):
  File "/usr/local/lib/python3.12/site-packages/zigpy_deconz/api.py", line 589, in _command
    return await fut

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/zha/__init__.py", line 153, in async_setup_entry
    zha_gateway = await ZHAGateway.async_from_config(
  File "/usr/src/homeassistant/homeassistant/components/zha/core/gateway.py", line 197, in async_from_config
    await instance.async_initialize()
  File "/usr/src/homeassistant/homeassistant/components/zha/core/gateway.py", line 215, in async_initialize
    await app.startup(auto_form=True)
  File "/usr/local/lib/python3.12/site-packages/zigpy/application.py", line 233, in startup
    await self.connect()
  File "/usr/local/lib/python3.12/site-packages/zigpy_deconz/zigbee/application.py", line 97, in connect
    await api.connect()
  File "/usr/local/lib/python3.12/site-packages/zigpy_deconz/api.py", line 468, in connect
    device_state_rsp = await self.send_command(CommandId.device_state)
  File "/usr/local/lib/python3.12/site-packages/zigpy_deconz/api.py", line 508, in send_command
    return await self._command(cmd, **kwargs)
  File "/usr/local/lib/python3.12/site-packages/zigpy_deconz/api.py", line 588, in _command
    async with asyncio_timeout(COMMAND_TIMEOUT):
  File "/usr/local/lib/python3.12/asyncio/timeouts.py", line 115, in __aexit__
    raise TimeoutError from exc_val

If possible try a different USB port.

Do you use an USB extension cable ? The Pi3 does not have USB3 ports, but the Mini PC probably does.

Thank you both for the quick response.

I do not use an USB extension Cable, but my Mini PC has USB 3.0 and USB 2.0 Ports. I tested both ports.

As @francisp said, an USB extension cable is recommended. It moves the stick away from the pc and it’s electrical noise. It will most likely fix your problem.

Thanks again for the advice.
I just bouth an 1m USB 2.0 extension cable. It will be delivered tomorrow, so i’m gonna try it tomorrow evening.

Unfortunately the problem is the same while using the USB extension cable.

On the last configuration screen , i get an error “no connection”.
Any other ideas?

It shouldn’t matter but please try /dev/ttyUSB0 (or /dev/ttyUSBx where x = 1 or 2 etc. depending on which USB port is used). Also the selected option under “Datenflusskontrolle” does not show anything. Can you check that.

Is that are bare-metal installation of Home Assistant Operating System directly on the new mini pc or are you installing Home Assistant in a virtual machine and/or as a container under Docker or similar?

Asking as if using in a virtual machine and/or as a container under Docker or similar then you need manually to configure proper USB/device-passthrough as well as enable read and write access access to serial permissions. See → Technical support

Regardless, upgrade ConBee II firmware if you have not already → https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Update-deCONZ-manually

Hello Hedda,

it is a bere-metal installation of HA OS. I first tried an docker installation, but was not so happy with this way of running HA.

I’ll check the firmware update later when i am back at home. Hope to get it managed on a Mac.

I will although switch back to the other “Port”-Name (/dev/…). I read in another thread that it is recommened to use the long version.

While it is generally recommended to use /dev/serial/by-id for USB device path mapping (because USB port mapping can sometimes change on reboots or be remapped to a different port when add other USB device), I recall seeing several people complaining about difficulties mapping the ConBee 2 using /dev/serial/by-id(but unsure what the root cause and/or solution was for those)

I now tested to switch back to the long Port-Name. Without any effect.

Unfortunately the firmware update i tried did not work either. I used this instruction: How to update conbee II on hassio with deconz/phoscon integration? - #12 by thomas-svrts
It fails with “bootloader failed”.
Irritatingly, it doesn’t find suitable firmware as described in the instructions; I have to select it manually.

Normally i would thought there is a problem with the conbee 2 hardware, but as i put it back to the RP3 it works like a charm.

I although tried today a completely new restore of the new N95 from a fresh backup from the RP3, but this does not fix it either.

Try with a USB extention cable as sometimes some dongles have trouble making proper physical electrical contact in some chassis and then it can help to use a USB extension cable which has thinner plug and port

I am using an extension cable. 1m Amazon Basic USB 2.0 … But it although don’t work.

I think it has to be related, that i have made an restore on other hardware (vom PI to X86).

That should be no problem.


Any other ideas? Shall i delete the ZHA Integration and try a new setup?
I have read that Zigbee2MQTT works better.
At the moment i only have 9 devices paired with the Conbee, so it would not be that hard to start the Zigbee Integration from scratch

Can’t hurt to try. But if it is a hardware problem between your USB-ports and the Conbee, it won’t help.

I’ve now updated the firmware. But the problem is the same. No connection.

On the last screen, the empty choice under “Datenflusskontrolle” is although with empty value.

I gave up and bought the SkyConnect Stick. The migration out of the backup does not work, but now i added all the zigbee devices and it is now running again.