Closed elafargue closed 4 years ago
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)
Same on my side: Version Version: 2.05.72 / 12/12/2019 Firmware version: 264A0700
On win no errors accurs.
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
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.
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
If you are lucky, you can try that https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2493
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
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.
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
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.
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
@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 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.
@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
@MattL0 Yes.
Also @elafargue , I've learned that the error you describe often happens when Modemmanager is still on/enabled.
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.
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:
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
returns0x0
).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?