Conbee II stick crashing USB controller after a couple of hours

[elafargue]

With a Conbee II on a Raspberry Pi 4, with no other USB peripherals, the Conbee II always crashes after a couple of hours (from a few minutes to 24+ hours) with the following error:

Feb  4 22:32:45 home kernel: [103786.097031] xhci_hcd 0000:01:00.0: xHCI host not responding to stop endpoint command.
Feb  4 22:32:45 home kernel: [103786.113071] xhci_hcd 0000:01:00.0: Host halt failed, -110
Feb  4 22:32:45 home kernel: [103786.113077] xhci_hcd 0000:01:00.0: xHCI host controller not responding, assume dead
Feb  4 22:32:45 home kernel: [103786.113130] xhci_hcd 0000:01:00.0: HC died; cleaning up
Feb  4 22:32:45 home kernel: [103786.113219] usb 1-1: USB disconnect, device number 2
Feb  4 22:32:45 home kernel: [103786.113227] usb 1-1.4: USB disconnect, device number 35
Feb  4 22:32:45 home kernel: [103786.113234] usb 1-1.4.1: USB disconnect, device number 37
Feb  4 22:32:45 home kernel: [103786.113379] cdc_acm 1-1.4.1:1.0: failed to set dtr/rts

The device disappears from the USB bus afterwards. Rebooting the RPi 4 puts it back online again. When this happens, no error is raised with power supply or throttling (vcgencmd get_throttled returns 0x0).

Conbee II info:
Version Version: 2.05.72 / 12/12/2019
Firmware version: 264A0700. / "This version is up to date"

I have tried with multiple USB2.0 or USB3.0 extension cables, putting a USB2.0 hub on the RPi4 side, or at the end of the extension cable, same result everytime.

If this a known problem on this firmware version? Anything I could try to improve reliability?

[Smanar]

Can you make a try with a windows machine ?
There is some users with the same problem and on windows you can see the device making a connected/disconnect loop (with the sound)

[MeisterHoppel]

Same on my side:
Version Version: 2.05.72 / 12/12/2019
Firmware version: 264A0700

On win no errors accurs.

[elafargue]

Is there anything else we can do to help debug this issue? Other Zigbee radio interfaces on my Pi 4 and super stable and work great, it's too bad the Conbee II has this instability since the utilities that come with it are really useful

[manup]

Does this still occur with 2.05.73? It has a few fixes related to the issue and in 2.05.74 (arriving soon) there are further fixes to address the issue.

[DJM25]

Can you make a try with a windows machine ?
There is some users with the same problem and on windows you can see the device making a connected/disconnect loop (with the sound)

I have this problem on windows, the device making a connected/disconnect loop (with the sound). What I can do ?
Version Version: 2.05.71 / 17/11/2019

[Smanar]

If you are lucky, you can try that #2493

[DJM25]

If you are lucky, you can try that #2493

I'm unlucky, other way ?

Reboot device /dev/ttyACM0 (ConBee II)
action: update firmware after 28 ms
flashing 161378 bytes: |=====error: timeout flashing firmware after 3009 ms
Reboot device /dev/ttyACM0 (ConBee II)
retry, failed

1607: Error: uart reset failed, check retry

[gotson]

I have the same issue on an Intel NUC NUC8i5BEK.

Conbee II:
Version 2.05.74 / 25/02/2020
Firmware 264A0700

For me it can take up to a week to happen.

[DJM25]

If you are lucky, you can try that #2493

I'm unlucky, other way ?

Reboot device /dev/ttyACM0 (ConBee II)
action: update firmware after 28 ms
flashing 161378 bytes: |=====error: timeout flashing firmware after 3009 ms
Reboot device /dev/ttyACM0 (ConBee II)
retry, failed

1607: Error: uart reset failed, check retry

Lucky with a new test, I install a UBUNUTU 18.4 LTS, remove all USB devices >

/usr/share/deCONZ/firmware$ sudo GCFFlasher_internal -d /dev/ttyACM0 -t 60 -f /usr/share/deCONZ/firmware/deCONZ_ConBeeII_0x26490700.bin.GCF
GCFFlasher V3_13 (c) dresden elektronik ingenieurtechnik gmbh
Reboot device /dev/ttyACM0 (ConBee II)
R21B18 Bootloader
Vers: 2.07
build: Jun 17 2019
flashing 158985 bytes: |=====error: timeout flashing firmware after 3007 ms
Reboot device /dev/ttyACM0 (ConBee II)
Reboot device /dev/ttyACM0 (ConBee II)
R21B18 Bootloader
Vers: 2.07
build: Jun 17 2019
flashing 158985 bytes: |==============================|
verify: .
SUCCESS
Wait 10 seconds until application starts

[manup]

Small update on this, I'm currently digging in the ConBee II firmware usb code. One thing I've noticed is that Linux does send MTP probes and the Modem Manager might also dig into the serial communication when the device is plugged in and after an reboot.

This can be disabled by following udev rules (will be included and installed automatically in the next releases)

cat /etc/udev/rules.d/69-conbee.rules

# ConBee II disbale modem manager and mtp probing
ATTRS{idVendor}=="1cf1", ATTRS{idProduct}=="0030", ENV{ID_MM_DEVICE_IGNORE}="1"
ATTRS{idVendor}=="1cf1", ATTRS{idProduct}=="0030", ENV{MTP_NO_PROBE}="1"

After creating this file the udev rules needs to be reloaded:

sudo udevadm control --reload-rules

This is not a silver bullet for all issues but should help to prevent triggering unwanted states in the firmware.

[MattL0]

Can you make a try with a windows machine ?
There is some users with the same problem and on windows you can see the device making a connected/disconnect loop (with the sound)

Small update on this, I'm currently digging in the ConBee II firmware usb code. One thing I've noticed is that Linux does send MTP probes and the Modem Manager might also dig into the serial communication when the device is plugged in and after an reboot.

This can be disabled by following udev rules (will be included and installed automatically in the next releases)

cat /etc/udev/rules.d/69-conbee.rules

# ConBee II disbale modem manager and mtp probing
ATTRS{idVendor}=="1cf1", ATTRS{idProduct}=="0030", ENV{ID_MM_DEVICE_IGNORE}="1"
ATTRS{idVendor}=="1cf1", ATTRS{idProduct}=="0030", ENV{MTP_NO_PROBE}="1"

After creating this file the udev rules needs to be reloaded:

sudo udevadm control --reload-rules

This is not a silver bullet for all issues but should help to prevent triggering unwanted states in the firmware.

I have a docker install. I already mapped my conbeee2 to a udev rule. (Z-WAVE stick have the same port ).

Anyways since the docker install only see the ''fake '' usb port i create with a udev rule...
It seems prudent to create those rule you have posted outside of docker ( on the main ubuntu partition)?

---

did it anyways.. can't hurt

[Mimiix]

@elafargue and others: I've got alerted that the latest firmware update should resolve the crashing. Are you able to update your devices?
Follow this guide to do so :)

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[MattL0]

@elafargue and others: I've got alerted that the latest firmware update should resolve the crashing. Are you able to update your devices?
Follow this guide to do so :)

This one ? http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_ConBeeII_0x26580700.bin.GCF

[Mimiix]

@MattL0 Yes.

Also @elafargue , I've learned that the error you describe often happens when Modemmanager is still on/enabled.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.