Hi
Since I upgraded to Conbee II I have tons of issues with my network. I did some investigation and looks like Conbee II makes USB controller to "go mad" after some time.
I have tons of entries like this in my dmesg:
[Jun16 13:36] usb 1-7: USB disconnect, device number 12
[ +0.000177] cdc_acm 1-7:1.0: failed to set dtr/rts
[ +0.311314] usb 1-7: new full-speed USB device number 13 using xhci_hcd
[ +0.149492] usb 1-7: New USB device found, idVendor=1cf1, idProduct=0030
[ +0.000002] usb 1-7: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ +0.000001] usb 1-7: Product: ConBee II
[ +0.000001] usb 1-7: Manufacturer: dresden elektronik ingenieurtechnik GmbH
[ +0.000001] usb 1-7: SerialNumber: DE1962673
[ +0.000857] cdc_acm 1-7:1.0: ttyACM1: USB ACM device
[Jun16 13:37] usb 1-7: USB disconnect, device number 13
[ +0.347853] usb 1-7: new full-speed USB device number 14 using xhci_hcd
[ +0.149544] usb 1-7: New USB device found, idVendor=1cf1, idProduct=0030
[ +0.000004] usb 1-7: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ +0.000003] usb 1-7: Product: ConBee II
[ +0.000003] usb 1-7: Manufacturer: dresden elektronik ingenieurtechnik GmbH
[ +0.000003] usb 1-7: SerialNumber: DE1962673
[ +0.002566] cdc_acm 1-7:1.0: ttyACM0: USB ACM device
[Jun16 13:39] perf: interrupt took too long (2510 > 2500), lowering kernel.perf_event_max_sample_rate to 79500
[Jun16 14:05] wmiir[30693]: segfault at 0 ip 00007fe1dae7d676 sp 00007ffeb4ccb728 error 4 in libc-2.24.so[7fe1dadfd000+195000]
[Jun16 14:08] usb 1-7: USB disconnect, device number 14
[ +0.000203] cdc_acm 1-7:1.0: failed to set dtr/rts
[ +21.859248] usb 1-7: new full-speed USB device number 15 using xhci_hcd
[ +0.149435] usb 1-7: New USB device found, idVendor=1cf1, idProduct=0030
[ +0.000001] usb 1-7: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ +0.000001] usb 1-7: Product: ConBee II
[ +0.000001] usb 1-7: Manufacturer: dresden elektronik ingenieurtechnik GmbH
[ +0.000001] usb 1-7: SerialNumber: DE1962673
[ +0.001056] cdc_acm 1-7:1.0: ttyACM0: USB ACM device
[ +7.181029] usb 1-7: USB disconnect, device number 15
[ +0.348461] usb 1-7: new full-speed USB device number 16 using xhci_hcd
[ +0.149582] usb 1-7: New USB device found, idVendor=1cf1, idProduct=0030
[ +0.000004] usb 1-7: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ +0.000002] usb 1-7: Product: ConBee II
[ +0.000003] usb 1-7: Manufacturer: dresden elektronik ingenieurtechnik GmbH
[ +0.000002] usb 1-7: SerialNumber: DE1962673
[ +0.001070] cdc_acm 1-7:1.0: ttyACM0: USB ACM device
[ +14.670456] wmiir[31150]: segfault at 0 ip 00007f3956c4b676 sp 00007ffddee2e9d8 error 4 in libc-2.24.so[7f3956bcb000+195000]
Also if there is any HDD connected to the same USB controller it disappears from the system with IO error after Conbee II start bootlooping.
Any ideas what to do to fix this?
Can you please provide more details on your setup:
Not sure if it is related but the wmiir crashing with segfault in libc doesn't look good either.
Which OS distribution and version
Docker host:
Ubuntu 18.04.2 LTS
I had same issues on Debian Stretch.
Do you use an USB extension cable
Currently no, but I had the same issues when i used extension.
Which deCONZ version
2.05.65 (docker)
Which firmware version is installed on ConBee II
0x26490700
Any other USB devices attached
Some bluetooth dongle, pendrive for /boot, a hub with 3x USB HDDs
I am still searching where wmiir issue is exactly... I think it is from one of the docker containers...
To be sure that Conbee II is the problem I switched back to Conbee I - everything else stayed the same.
I used method from https://github.com/dresden-elektronik/deconz-rest-plugin/releases/tag/V2_05_59.
Conbee II usually started bootlooping within couple hours after startup. Will see how it works with older stick.
Any other USB devices attached
Some bluetooth dongle, pendrive for /boot, a hub with 3x USB HDDs
But the ConBee II was connected directly or via USB hub?
What system is this, a Raspberry Pi?
Since versions are fine I can only guess that the devices may make trouble together on the USB ports. This can only be ruled out by testing one device at the time.
I have dell 3060 mff. Conbee II was tested on:
Issue happens when there is any USB disk attached to any USB port.
I now replaced Conbee II with Conbee I and everything works. On every port... Also I do not see the segfault anymore.
Also have you tested Conbee II memory when getting hot? After each issue it was hot. Maybe that is the problem?
Issue happens when there is any USB disk attached to any USB port.
Interesting is this is spinning disk or flash? I can only imagine some kind of interference might happen here.
Spinning. SSD is all the time in m.2 slot. Working great.
I returned my Conbee II to Amazon. When I get refund I will order new one. Maybe those issues were connected to faulty stick...
I'm seeing the exact same messages with a loop of USB disconnect and reboot in my kernel log. I'm not completely sure of the timeline, but I think this started after I was tinkering with firmware flashing that failed. This wasn't initially a problem during the first few hours that the stick was connected.
I tried to recover from not seeing the device connect properly in the Phoscon app. Can't remember whether the last firmware I successfully flashed was 0x26480700 or 0x26490700, but the flashing was working very intermittently to begin with -- perhaps related to spinning USB disks?
I've tested the same stick in the current state with an Intel NUC (with spinning USB disks connected) and a Raspberry Pi 3B (without any USB devices) with equal results. I'm going to get a replacement stick as well to see whether the problems persist.
perhaps related to spinning USB disks?
Spinning. SSD is all the time in m.2 slot. Working great.
Just had a discussion with a colleague, at least for Raspberry Pi when you're using a external drives you need to make sure that they have either a separate power supply or are connected via an external powered USB-hub.
The Raspberry Pi alone is likely not able to deliver the required powerer for all these USB devices. We suggest using at least the 2.5A power supply to use the RaspBee, ConBee and ConBee II, depending on what else is connected to the Raspberry Pi an even higher power supply is needed.
In my case HDDs are connected to Unitek HUB (Unitek HUB 7xUSB 3.0 + BC ) with external power supply. Power is not the issue here. It is something else...
As I have issues with Xiaomi not responding with Conbee I and Xioami devices worked very well with Conbee II while it was operational I decided to order new Conbee II right away. Hopefully I will receive it by the end of the next week. We will see if @bjome 's suspicions about failed flashing is right. I will not touch my new Conbee with flasher older than 3.5.
I have the same issue. Similar logs. It happens every hour for me. I did upgrade the firmware but do not recall ever having a failed update. I am also running on a docker host running Debian Stretch and Kernel 4.19
Can you please provide more details of your setup:
My external disks are also powered from separate power supply. Also, for me, this is not affecting RPi but an Intel NUC.
Anyway, I replaced my stick. The new stick has been connected and shows the hourly boot loop. Unfortunately, I cannot easily test without the USB disks as they host system partitions, but I’ll see if I can find the time.
Tried with and without extension cable. Firmware version is the default 0x26420700. Deconz version 2.05.65 via Docker on Ubuntu. For me the Phoscon app shows “Firmware: Not connected” most of the time but once in a while it shows the firmware version. The deconz GUI reflects this as “Not in network”. I am never able to discover any devices.
Here are some things I’m thinking may be of interest:
USB controller: Intel Corporation Sunrise Point-LP USB 3.0 xHCI Controller (rev 21) as reported by lspcifailed to set dtr/rts message of importance?For the record I’m also seeing the wmiir segfault occasionally.
I have Dell Optiplex 3060 with
USB controller: Intel Corporation Cannon Lake PCH USB 3.1 xHCI Host Controller (rev 10)
HDD: 1f75:0621 Innostor Technology Corporation
@manup are you able to test Conbee II with some intel nuc?
I am using an HP z210. The USB controller is: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 04)
2.05.640x26490700Bus 002 Device 074: ID 1cf1:0030 Dresden Elektronik
Bus 002 Device 003: ID 0bda:0181 Realtek Semiconductor Corp.
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 006: ID 0764:0501 Cyber Power System, Inc. CP1500 AVR UPS
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
So I updated the docker container to a version with 2.05.66 and the issue seams to have gone away.
I get this error about every minute but it seems to work now:
17:02:44:633 Device TTL 2397 s flags: 0x7
17:02:54:610 unsupported device type 1 (TODO)
17:02:59:611 remove outdated neighbor 0x2932
17:03:04:611 unsupported device type 1 (TODO)
17:03:14:610 unsupported device type 1 (TODO)
17:03:24:611 unsupported device type 1 (TODO)
17:03:34:610 unsupported device type 1 (TODO)
WOW. That quite promising.
I am still waiting for my replacement Conbee II. Can't wait to see if it actually works :-).
For me 2.05.66 did not change anything. What changes in this release do you think make a difference?
Anyway, here is my log output from deconz:
deconz | [marthoc/deconz] Starting deCONZ...
deconz | [marthoc/deconz] Current deCONZ version: 2.05.66
deconz | [marthoc/deconz] Web UI port: 15901
deconz | [marthoc/deconz] Websockets port:�15902
deconz | [marthoc/deconz] VNC Display: :10000 on port 15900
deconz | /usr/bin/xauth: file /root/.Xauthority does not exist
deconz |
deconz | New 'planck:10000 (root)' desktop at :10000 on machine planck
deconz |
deconz | Starting applications specified in /etc/X11/Xvnc-session
deconz | Log file is /root/.vnc/planck:10000.log
deconz |
deconz | Use xtigervncviewer -SecurityTypes VncAuth,TLSVnc -passwd /root/.vnc/passwd�planck:10000�to�connect�to�the�VNC�server.
deconz |
deconz | libpng warning: iCCP: known incorrect�sRGB�profile
deconz | 19:51:12:929 HTTP Server listen�on�address�0.0.0.0,�port:�15901,�root:�/usr/share/deCONZ/webapp/
deconz | 19:51:12:939 CTRL. 3.16.219:51:12:968 COM: /dev/ttyACM0�/�serialno:
deconz | 19:51:12:968 COM: --dev: /dev/ttyACM0 (ConBee II)
deconz | 19:51:12:968 ZCLDB init file /root/.local/share/dresden-elektronik/deCONZ/zcldb.txt
deconz | 19:51:13:049 parent process /bin/sh
deconz | 19:51:13:049 gw run mode: docker
deconz | 19:51:13:050 GW sd-card image version file does not exist:�/root/.local/share/dresden-elektronik/deCONZ/gw-version
deconz | 19:51:13:050 DB sqlite version 3.16.2
deconz | 19:51:13:050 DB PRAGMA page_count:�30
deconz | 19:51:13:051 DB PRAGMA page_size:�4096
deconz | 19:51:13:051 DB PRAGMA freelist_count: 0
deconz | 19:51:13:051 DB file size 122880�bytes,�free�pages�0
deconz | 19:51:13:051 DB PRAGMA user_version:�6
deconz | 19:51:13:051 DB cleanup
deconz | 19:51:13:051 DB create temporary views
deconz | 19:51:13:053 don't close database yet, keep open for�900�seconds
deconz | 19:51:13:054 started websocket server at�port�15902
deconz | 19:51:13:055 discovery updated announce�interval�to�10�minutes
deconz | 19:51:13:056 found node plugin: libde_rest_plugin.so�-�REST�API�Plugin
deconz | 19:51:13:057 found node plugin: libde_signal_plugin.so�-�Signal�Monitor�Plugin
deconz | 19:51:13:061 found node plugin: libstd_otau_plugin.so�-�STD�OTAU�Plugin
deconz | 19:51:13:075 COM: /dev/ttyACM0 / serialno:
deconz | 19:51:13:075 COM: --dev: /dev/ttyACM0�(ConBee�II)
deconz | 19:51:13:125 DEV config changed event
deconz | 19:51:13:166 Device firmware version 0x26420700
deconz | 19:51:13:168 scan skip host .2
deconz | 19:51:13:170 unlocked max nodes: 200
deconz | 19:51:13:244 Device protocol version: 0x0108
deconz | 19:51:13:255 new node - ext: 0x00212effff0407a3, nwk: 0x0000
deconz | 19:51:13:406 Current channel 15
deconz | 19:51:13:422 CTRL ANT_CTRL 0x03
deconz | 19:51:13:446 Device protocol version: 0x0108
deconz | 19:51:13:494 Current channel 15
deconz | 19:51:13:510 CTRL ANT_CTRL 0x03
deconz | 19:51:13:534 Device protocol version: 0x0108
deconz | 19:51:13:582 Current channel 15
deconz | 19:51:13:598 CTRL ANT_CTRL 0x03
deconz | 19:51:13:622 Device protocol version: 0x0108
deconz | 19:51:13:670 Current channel 15
deconz | 19:51:13:686 CTRL ANT_CTRL 0x03
deconz | 19:51:13:718 Device protocol version: 0x0108
deconz | 19:51:13:767 Current channel 15���������������������������������������������������������������������������������������deconz | 19:51:13:783 CTRL ANT_CTRL 0x03
deconz | 19:51:13:806 Device protocol version: 0x0108
deconz | 19:51:13:854 Current channel 15
deconz | 19:51:13:870 CTRL ANT_CTRL 0x03���������������������������������������������������������������������������������������deconz | 19:51:13:894 Device protocol version: 0x0108
deconz | 19:51:13:942 Current channel 15
deconz | 19:51:13:959 CTRL ANT_CTRL 0x03
deconz | 19:51:13:982 Device protocol version: 0x0108��������������������������������������������������������������������������deconz | 19:51:14:030 Current channel 15
deconz | 19:51:14:046 CTRL ANT_CTRL 0x03
deconz | 19:51:14:070 NET ZDO start network status 0xC4
deconz | 19:51:18:348 GW update firmware found: /usr/share/deCONZ/firmware/deCONZ_ConBeeII_0x26490700.bin.GCF������������������deconz | 19:51:18:348 GW firmware version: 0x26420700
deconz | 19:51:18:348 GW firmware version shall be updated to: 0x26490700
deconz | 19:51:18:677 Announced to internet
deconz | 19:51:50:751 New websocket 192.168.0.24:52109 (state: 3)��������������������������������������������������������������deconz | 19:51:53:004 Remove websocket 192.168.0.24:52109 after error Unknown error
deconz | 19:51:54:862 New websocket 192.168.0.24:52110 (state: 3)
deconz | 19:51:57:899 Remove websocket 192.168.0.24:52110 after error Unknown error��������������������������������������������deconz | 19:51:58:953 New websocket 192.168.0.24:52111 (state: 3)
deconz | 19:52:16:454 scan skip host .22
deconz | 19:52:27:857 scan finished
deconz | 19:53:28:571 GW firmware version: 0x26420700
deconz | 19:53:28:571 GW firmware version shall be updated to: 0x26490700
deconz | 19:53:33:741 Remove websocket 192.168.0.24:52111 after error Unknown error
deconz | 19:53:34:841 New websocket 192.168.0.24:52112 (state: 3)
deconz | 19:53:35:706 Remove websocket 192.168.0.24:52112 after error Unknown error
deconz | 19:53:36:773 New websocket 192.168.0.24:52113 (state: 3)
deconz | 19:53:48:898 Device protocol version: 0x0108
deconz | 19:53:48:948 Current channel 15
deconz | 19:53:48:964 CTRL ANT_CTRL 0x03
...
deconz | 19:53:49:036 Current channel 15
deconz | 19:53:49:052 CTRL ANT_CTRL 0x03
deconz | 19:53:49:076 NET ZDO start network status 0xC4
deconz | 19:53:59:302 void zmMaster::handleStateIdle(zmMaster::MasterEvent) not connected goto OFF state
deconz | 19:53:59:302 device state timeout ignored in state 1
deconz | 19:54:00:052 wait reconnect 15 seconds
deconz | 19:54:01:052 wait reconnect 14 seconds
deconz | 19:54:02:053 wait reconnect 13 seconds
deconz | 19:54:03:052 wait reconnect 12 seconds
deconz | 19:54:04:052 wait reconnect 11 seconds
deconz | 19:54:05:052 wait reconnect 10 seconds
deconz | 19:54:06:052 wait reconnect 9 seconds
deconz | 19:54:07:052 wait reconnect 8 seconds
deconz | 19:54:07:791 void MainWindow::devConnectClicked() choose com /dev/ttyACM0
deconz | 19:54:07:808 Device firmware version 0x26420700
deconz | 19:54:07:813 unlocked max nodes: 200
deconz | 19:54:07:884 Device protocol version: 0x0108
deconz | 19:54:07:932 Current channel 15
deconz | 19:54:07:948 CTRL ANT_CTRL 0x03
deconz | 19:54:08:052 wait reconnect 7 seconds
deconz | 19:54:09:052 wait reconnect 6 seconds
deconz | 19:54:10:052 wait reconnect 5 seconds
deconz | 19:54:11:052 wait reconnect 4 seconds
deconz | 19:54:12:052 wait reconnect 3 seconds
deconz | 19:54:13:052 wait reconnect 2 seconds
deconz | 19:54:14:052 wait reconnect 1 seconds
deconz | 19:54:18:278 Remove websocket 192.168.0.24:52113 after error Unknown error
deconz | 19:54:19:382 New websocket 192.168.0.24:52115 (state: 3)
deconz | 19:55:38:571 GW firmware version: 0x26420700
deconz | 19:55:38:571 GW firmware version shall be updated to: 0x26490700
deconz | 19:57:16:784 send NWK_Addr_req to node 0x00212EFFFF0407A3
deconz | 19:57:16:784 APS-DATA.request id: 4, addrmode: 0x02, addr: 0xfffd, profile: 0x0000, cluster: 0x0000, ep: 0x00 -> 0x00 queue: 0 len: 11 tx.options 0x00
deconz | 19:57:16:784 failed to send NWK_Addr_req to 0x00212EFFFF0407A3
deconz | 19:57:17:256 send NWK_Addr_req to node 0x00212EFFFF0407A3
deconz | 19:57:17:256 APS-DATA.request id: 5, addrmode: 0x02, addr: 0xfffd, profile: 0x0000, cluster: 0x0000, ep: 0x00 -> 0x00 queue: 0 len: 11 tx.options 0x00
deconz | 19:57:17:256 failed to send NWK_Addr_req to 0x00212EFFFF0407A3
deconz | 19:57:18:522 send NWK_Addr_req to node 0x00212EFFFF0407A3
deconz | 19:57:18:522 APS-DATA.request id: 6, addrmode: 0x02, addr: 0xfffd, profile: 0x0000, cluster: 0x0000, ep: 0x00 -> 0x00 queue: 0 len: 11 tx.options 0x00
deconz | 19:57:18:523 failed to send NWK_Addr_req to 0x00212EFFFF0407A3
deconz | 19:57:19:165 send NWK_Addr_req to node 0x00212EFFFF0407A3
deconz | 19:57:19:165 APS-DATA.request id: 7, addrmode: 0x02, addr: 0xfffd, profile: 0x0000, cluster: 0x0000, ep: 0x00 -> 0x00 queue: 0 len: 11 tx.options 0x00
deconz | 19:57:19:165 failed to send NWK_Addr_req to 0x00212EFFFF0407A3
deconz | 19:57:27:483 Node_Descriptor_req zdpSeq: 4 to 0x00212EFFFF0407A3
deconz | 19:57:27:483 APS-DATA.request id: 8, addrmode: 0x02, addr: 0x0000, profile: 0x0000, cluster: 0x0002, ep: 0x00 -> 0x00 queue: 0 len: 3 tx.options 0x00
deconz | 19:57:29:041 Node_Descriptor_req zdpSeq: 5 to 0x00212EFFFF0407A3
deconz | 19:57:29:042 APS-DATA.request id: 9, addrmode: 0x02, addr: 0x0000, profile: 0x0000, cluster: 0x0002, ep: 0x00 -> 0x00 queue: 0 len: 3 tx.options 0x00
deconz | 19:57:48:594 GW firmware version: 0x26420700
deconz | 19:57:48:594 GW firmware version shall be updated to: 0x26490700
deconz | 19:58:13:431 Remove websocket 192.168.0.24:52115 after error Unknown error
As I haven’t run deconz successfully yet I don’t really know what to look for. What does NET ZDO start network status 0xC4 mean?
Edit: fix log
Yesterday I received my new Conbee II. I moved my network onto the new stick. For now I stayed on 0x26420700. It is working and it is stable for full 24 hours. Only Xiaomi buttons are not working at all. I think I need to upgrade firmware to make them usable. Will see whether new firmware breaks things.
BTW. The segfault:
wmiir[27559]: segfault at 0 ip 00007f00e0317676 sp 00007fff84594fe8 error 4 in libc-2.24.so[7f00e0297000+195000]
is for 100% caused by Conbee II. I have container with VNC enabled, but deconz GUI works despite the error. So this may be a red herring.
As I haven’t run deconz successfully yet I don’t really know what to look for. What does NET ZDO start network status 0xC4 mean?
0xC4 means the Zigbee network couldn't be started. Usually this means that the radio has a hard time
to access the media channel due interference, which can be improved with an USB extension cable.
However I think the main problem here might be the setup with the external USB disks. It might be interference due the spinning disk or USB power issues (the Raspberry Pi 4 seems to have improvements). We need to test and measure this in our lab to get a clearer picture.
Also it looks like you're running on old firmware, please update to 0x26490700 (but it won't help for the "disk issue"):
https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Update-deCONZ-manually
I'm experiencing similar issues. I had Conbee2 connected to the front of my Dell server together with a usb memory stick and a aeotec zwave stick. Got a bunch of issues resulting in unmounting the usb stick and putting it in read only mode. In some cases all other drivers would also get the same treatment. First messages would appear after 15-17 minutes taking 7-9 hours before drives getting unmounted. Moving the Conbee2 to the place where I had the old Conbee on the backside and on an extension cord seems to have mitigated at least the initial messages. Will see later today if anything will get the unmount treatment
Do you use an USB extension cable - Now yes, not when connected to the front
Which deCONZ version - 2.05.66
Which firmware version is installed on ConBee II - 26490700
Any other USB devices attached - Not on the back of the computer, on the front one usb stick and one aeotec zwave stick
@manup -> ok, I updated firmware to
GW firmware version: 0x26490700
Conbee II is connected to back of Dell 3060, to USB 2.0 controller. A disk in enclosure with separate power source is connected to the front to USB 3.0, so different controller. Will see how it works in this configuration.
Also take under consideration that most of us, with problems, aren't using Raspberry Pi.
Here is an interesting paper from Intel:
This is going to be particularly “interesting” when people start attaching USB 3.0 disks to their Raspberry Pi 4B systems, running deCONZ using a RaspBee. Cross-referencing #1643.
I guess so. We've ordered the Raspberry Pi 4 and will do various tests with USB disks in the lab to get a better understanding about interference issues and find mitigations.
Google yields familiar issues with wireless 2.4 GHz mouses and keyboards which aren't reliable when used on USB 3.0 ports or near them. Intel and Logitech recommend using USB 2.0 ports and USB extension cables which solves the issue for most people.
For RaspBee this isn't a solution, but I hope we can figure out something in the lab :)
Hm. I can confirm that the new stick in USB 2.0 is stable in my installation. This is getting interesting.
What is the status on this issue?
I am experiencing similar issues. Mine are combined with a m.2 ssd hooked up to a pi 3b+
It always worked with debian 9 but now running on 10 is showing here mentioned issues.
@manup
I just got hit by that problem again. I am unable to start my deconz. Any progress ?
@manup maybe this helps...
I read multiple issues. Everyone is saying that Conbee II is not working on the newest raspbian and Ubuntu. Then somebody mention it worked in older Debian. So I looked into kernel versions for all those distros.
I installed kernel 5.0 and looks like Combee II is stable in USB 2.0. So the issue may be in the kernel 4.4 and 4.15.
@Oliviakrkk did you do this on a raspberry? If yes, can you give some pointers?
No, on Dell 3060 mff (amd64).
I currently do not own raspberry.
Hello
I have the same issue with Synology NAS :(
Conbee I fully fonctionnal but my Conbee II loop
I use extend cable
I installed kernel 5.0 and looks like Combee II is stable in USB 2.0. So the issue may be in the kernel 4.4 and 4.15.
I don't think it is related to the kernel version, I'm running several Arch Linux boxes with recent kernel and ConBee II. For now we figure most problems due USB 3.0 periphery and USB disks/sticks connected near ConBee II.
A new firmware is cooking which highly improves device startup and non-responding ConBee II, but it won't help much for tricky setups near other USB gadgets.
Conbee I fully fonctionnal but my Conbee II loop
I use extend cable
Do you have a recent firmware installed? Should be either 0x26490700 or 0x264A0700.
@manup That's great :-). Any ETA on the new firmware?
@manup what is considered to be "tricky setups near other USB gadgets"?
I run a rpi3b+ with a ssd via usb, p1 powermeter sensor, a aeotec Z-Wave and a Conbee II. Considered to be?
And does extension cable counts as "next" to devices?
On Thu, Aug 15, 2019, 14:21 ABeumer525 notifications@github.com wrote:
@manup https://github.com/manup what is considered to be "tricky setups
near other USB gadgets"?I run a rpi3b+ with a ssd via usb, p1 powermeter sensor, a aeotec Z-Wave
and a Conbee II. Considered to be?—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1598?email_source=notifications&email_token=ABMOM4CBQ4EP23ZRVDL2N2LQEWNDTA5CNFSM4HYRJAE2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4MS5BQ#issuecomment-521744006,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABMOM4FFMISSBAZKVJOC6R3QEWNDTANCNFSM4HYRJAEQ
.
I think the extension cable counts as good to take away conbee from perturbation.
Just make sure that the extension is USB 2.0
@manup what is considered to be "tricky setups near other USB gadgets"?
I run a rpi3b+ with a ssd via usb, p1 powermeter sensor, a aeotec Z-Wave and a Conbee II. Considered to be?
According to the paper mentioned above I would guess that the SSD might be the challenge. If possible you may try to use a USB extension cable for the SSD as well, and bring the possible interference source away from the other Raspberry Pi USB ports.
But I wonder that you said it worked on Debian Stretch (9).
It always worked with debian 9 but now running on 10 is showing here mentioned issues.
But I wonder that you said it worked on Debian Stretch (9).
It always worked with debian 9 but now running on 10 is showing here mentioned issues.
This would make sense in my case since I upgraded from proxmox 5.4 to 6.0 (which goes from debian 9 base to a debian 10 base) and I started having the issues, If i just wait a while after (lots of) resets it eventually settles down.
Running into similar issues on the newly arrived Conbee 2 stick. Can't even reflash the older software as it disconnects to frequently.
A quick 'dmesg -T' gives me this:
[So Aug 18 00:30:10 2019] usb 3-3: new full-speed USB device number 6 using xhci_hcd
[So Aug 18 00:30:10 2019] usb 3-3: New USB device found, idVendor=1cf1, idProduct=0030
[So Aug 18 00:30:10 2019] usb 3-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[So Aug 18 00:30:10 2019] usb 3-3: Product: ConBee II
[So Aug 18 00:30:10 2019] usb 3-3: Manufacturer: dresden elektronik ingenieurtechnik GmbH
[So Aug 18 00:30:10 2019] usb 3-3: SerialNumber: DE1996707
[So Aug 18 00:30:10 2019] cdc_acm 3-3:1.0: ttyACM0: USB ACM device
[So Aug 18 00:30:14 2019] usb 3-3: USB disconnect, device number 6
[So Aug 18 00:30:14 2019] cdc_acm 3-3:1.0: failed to set dtr/rts
When I say frequently I mean like every 12 sec the connection is reset and you can see it in dmesg disconnecting. Flashing anything is impossible with that behavior. Do I understand it correctly that there's no solution for this issue yet? (based on discussions above..)
Which OS distribution and version
Ubuntu 18.04.2 LTS (clean install)
Do you use an USB extension cable
No
Which deCONZ version
2.05.65
Which firmware version is installed on ConBee II
0x26490700
Any other USB devices attached
No
Hi
Try to install and boot from kernel 5.0. It helped me.
Doesn't seem to be a kernel issue for me. Upgraded to kernel 5.0.0-25-generic but still have the issue that the stick gets disconnected.
On the other hand I tried to force it by reflashing it using retry mechanism provided by the GCFFlasher:
GCFFlasher_internal -d /dev/ttyACM0 -x 3 -f deCONZ_ConBeeII_0x26490700.bin.GCF -R 1000
It took approx 500 retries before it finally succeeded! Seems alls stable again now 👍 no more disconnects (for a start). I can highly suggest this option for people that are still stuck.
Based on your previous comment it seems that you had already installed firmware version 0x26490700?
I guess there must be another reason for the instability if you can please use a USB extension cable, preferably on a USB 2.0 port.
I am running conbee ii on a raspberry pi 3b+ (running hassio) and it was having issues. Tried resetting and wiping everything off again... did not work. Until I heard the extension trick. I tried the extension and everything seems to be working again?
Maybe I missed something, what was the issue? Interference?
Is there a future software update? I’m running 0x26490700
Based on your previous comment it seems that you had already installed firmware version 0x26490700?
I guess there must be another reason for the instability if you can please use a USB extension cable, preferably on a USB 2.0 port.
Same issue, with or without extension cable.. :) Anyway, brute forcing seems to do the trick.
Just updated kernel version of raspbian from 4.19.58 to 4.19.66. It's christmas now, the network got worse every 15-30 minutes a restart/reboot is required.
To be brutally honest. What is/can be done to fix this? I'm on holiday now so I haven't had the chance to try the 1000 retries flashing as proposed by @TPX01 When I get home I'll give that a shot. But then again... what can be done about it?
USB extension cables as a solution doesn't feel that comfortable and whilst other usb device work I think the challenge lies with conbee / deconz?
Is this hardware or software? To me it feels like software...
GCFFlasher_internal -d /dev/ttyACM0 -x 3 -f deCONZ_ConBeeII_0x26490700.bin.GCF -R 1000
Why don't you use the 0x264a0700.bin.GCF version?
USB extension cables as a solution doesn't feel that comfortable and whilst other usb device work I think the challenge lies with conbee / deconz?
I'm afraid without an USB extension cable and a USB 3.0 SSD nearby you likely won't get happy. This the USB 3.0 interference on 2.4 GHz can't be fixed in software.
I am hitting a similar issue. It seems to be interference between a usb3.0 and the conbee II device.
Host
Pine Rock64 board
Which OS distribution and version
Ubuntu 18.04 LTS
Do you use an USB extension cable
Yes, connected to the USB 2.0 port.
Which deCONZ version
2.05.67
Which firmware version is installed on ConBee II
0x264A0700
**Any other USB devices attached
Seagate Firecuda through USB3.0 SATA converter.
If conbee II and usb3.0 hdd are connected to the rock64, phoscon app is not able to detect sensors. It works if If I dettach the disk.
I can even hit the problem if I attach the USB disk to another host (my laptop) and put it closed to the Rock64 board!
@TPX01 Why don't you use the 0x264a0700.bin.GCF version?
Note 0x26490700 and 0x264a0700 (newer) version are both fine. The new version has fixes which are relevant only for non deCONZ clients.
If I can be so blunt this all stinks. It keeps being wonky? What is the target date for this new firmware?
Getting nearer to the point of wanting my money back.
Has anyone got some tips on alternative sticks other than the dresden stuff?
Even thinking of moving back to zigbee2mqtt as this was way more reliable.
It is reliable on my part though. Upgrades of firmwares are a pain in the * but ther than that why let that bother you? 😃
USB extension cables as a solution doesn't feel that comfortable and whilst other usb device work I think the challenge lies with conbee / deconz?
The challenge is USB 3.0 vs. 2.4 GHz devices. See also https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1598#issuecomment-508904699
To describe it differently USB 3.0 is a screaming elephant while 2.4 GHz next to it have the voice of a mice. As I noted earlier:
I'm afraid without an USB extension cable and a USB 3.0 SSD nearby you likely won't get happy. This the USB 3.0 interference on 2.4 GHz can't be fixed in software.
So no matter what Zigbee USB-dongle, Bluetooth or WiFi device you use nearby USB 3.0 devices, the signal quality will drastically drop.
While the new firmware which is scheduled during the next weeks will solve many issues of reliable starting and bootloops, it can't fix radio interference of USB 3.0 vs. 2.4 GHz.
Finally it all works. Reinstalled deconz, reflashed the stick, reset the settings on the pi. What did the trick I don't know. With the zha zigpy solution it still kept being wonky. So for now I will keep it with deCONZ.
deCONZ 2.0.5.67
Firmware 264A0700
Raspbian Buster
Even removed the extension cable. For me this was not an issue.
I have the same issue on my NUC NUC6CAYH
Version 2.05.69 / 9/6/2019
Firmware 26A0700
Intel NUC NUC6CAYH
USB extension cable: yes
USB 3.1
Ubuntu 18.04.3 LTS
@manup , can I set the new firmware?
I have same issue:
[okt 9 03:09] usb 1-1.1.2: USB disconnect, device number 74
[ +0,234434] usb 1-1.1.2: new full-speed USB device number 75 using xhci_hcd
[ +0,102348] usb 1-1.1.2: New USB device found, idVendor=1cf1, idProduct=0030
[ +0,000005] usb 1-1.1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ +0,000003] usb 1-1.1.2: Product: ConBee II
[ +0,000002] usb 1-1.1.2: Manufacturer: dresden elektronik ingenieurtechnik GmbH
[ +0,000002] usb 1-1.1.2: SerialNumber: DE1997960
[ +0,001563] cdc_acm 1-1.1.2:1.0: ttyACM1: USB ACM device
[ +3,501625] usb 1-1.1.2: USB disconnect, device number 75
[ +0,227104] usb 1-1.1.2: new full-speed USB device number 76 using xhci_hcd
[ +0,103441] usb 1-1.1.2: New USB device found, idVendor=1cf1, idProduct=0030
[ +0,000005] usb 1-1.1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ +0,000002] usb 1-1.1.2: Product: ConBee II
[ +0,000003] usb 1-1.1.2: Manufacturer: dresden elektronik ingenieurtechnik GmbH
[ +0,000003] usb 1-1.1.2: SerialNumber: DE1997960
[ +0,001704] cdc_acm 1-1.1.2:1.0: ttyACM1: USB ACM device
Docker: marthoc/deconz:amd64-2.05.69
Product: ConBee II
Version: 2.05.69 / 9/6/2019
Firmware: 264A0700
USB: 3.0 Host + 3.0 HUB
USB extension cable: yes
Should I roll back to an earlier version, e.g. 0x26490700 ?
https://www.dresden-elektronik.de/rpi/deconz-firmware/?C=N;O=A
I have another weird thins: https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1773#issuecomment-538697422
the same issue for me, it was working nice for few months..dont know what trigger the issue:
Using raspbian buster and Hassio in docker:
Oct 9 08:45:59 smarthome kernel: [ 32.888914] usb 1-1.4.1: USB disconnect, device number 6
Oct 9 08:45:59 smarthome kernel: [ 33.291678] usb 1-1.4.1: new full-speed USB device number 7 using xhci_hcd
Oct 9 08:45:59 smarthome kernel: [ 33.530372] usb 1-1.4.1: New USB device found, idVendor=1cf1, idProduct=0030, bcdDevice= 1.00
Oct 9 08:45:59 smarthome kernel: [ 33.530380] usb 1-1.4.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Oct 9 08:45:59 smarthome kernel: [ 33.530386] usb 1-1.4.1: Product: ConBee II
Oct 9 08:45:59 smarthome kernel: [ 33.530391] usb 1-1.4.1: Manufacturer: dresden elektronik ingenieurtechnik GmbH
Oct 9 08:45:59 smarthome kernel: [ 33.530395] usb 1-1.4.1: SerialNumber: DE1997280
Oct 9 08:46:00 smarthome mtp-probe: checking bus 1, device 7: "/sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.4/1-1.4.1"
Oct 9 08:46:00 smarthome mtp-probe: checking bus 1, device 7: "/sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.4/1-1.4.1"
Oct 9 08:46:21 smarthome kernel: [ 38.521978] usb 1-1.4.1: USB disconnect, device number 7
Oct 9 08:46:21 smarthome kernel: [ 38.921661] usb 1-1.4.1: new full-speed USB device number 8 using xhci_hcd
Oct 9 08:46:21 smarthome kernel: [ 39.160338] usb 1-1.4.1: New USB device found, idVendor=1cf1, idProduct=0030, bcdDevice= 1.00
Oct 9 08:46:21 smarthome kernel: [ 39.160345] usb 1-1.4.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Oct 9 08:46:21 smarthome kernel: [ 39.160351] usb 1-1.4.1: Product: ConBee II
Oct 9 08:46:21 smarthome kernel: [ 39.160356] usb 1-1.4.1: Manufacturer: dresden elektronik ingenieurtechnik GmbH
Oct 9 08:46:21 smarthome kernel: [ 39.160361] usb 1-1.4.1: SerialNumber: DE1997280
Oct 9 08:46:21 smarthome mtp-probe: checking bus 1, device 8: "/sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.4/1-1.4.1"
Oct 9 08:46:21 smarthome mtp-probe: checking bus 1, device 8: "/sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.4/1-1.4.1"
Oct 9 08:49:56 smarthome kernel: [ 253.853814] usb 1-1.4.1: USB disconnect, device number 8
Oct 9 08:49:56 smarthome kernel: [ 254.253569] usb 1-1.4.1: new full-speed USB device number 9 using xhci_hcd
Oct 9 08:49:57 smarthome kernel: [ 254.492170] usb 1-1.4.1: New USB device found, idVendor=1cf1, idProduct=0030, bcdDevice= 1.00
Oct 9 08:49:57 smarthome kernel: [ 254.492177] usb 1-1.4.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Oct 9 08:49:57 smarthome kernel: [ 254.492183] usb 1-1.4.1: Product: ConBee II
Oct 9 08:49:57 smarthome kernel: [ 254.492188] usb 1-1.4.1: Manufacturer: dresden elektronik ingenieurtechnik GmbH
Oct 9 08:49:57 smarthome kernel: [ 254.492193] usb 1-1.4.1: SerialNumber: DE1997280
Oct 9 08:49:57 smarthome mtp-probe: checking bus 1, device 9: "/sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.4/1-1.4.1"
Oct 9 08:49:57 smarthome mtp-probe: checking bus 1, device 9: "/sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.4/1-1.4.1"
Oct 9 08:50:00 smarthome kernel: [ 257.690106] usb 1-1.4.1: USB disconnect, device number 9
Oct 9 08:50:00 smarthome kernel: [ 258.083664] usb 1-1.4.1: new full-speed USB device number 10 using xhci_hcd
Oct 9 08:50:01 smarthome kernel: [ 258.322236] usb 1-1.4.1: New USB device found, idVendor=1cf1, idProduct=0030, bcdDevice= 1.00
Oct 9 08:50:01 smarthome kernel: [ 258.322243] usb 1-1.4.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Oct 9 08:50:01 smarthome kernel: [ 258.322249] usb 1-1.4.1: Product: ConBee II
Oct 9 08:50:01 smarthome kernel: [ 258.322254] usb 1-1.4.1: Manufacturer: dresden elektronik ingenieurtechnik GmbH
Oct 9 08:50:01 smarthome kernel: [ 258.322258] usb 1-1.4.1: SerialNumber: DE1997280
Oct 9 08:50:01 smarthome mtp-probe: checking bus 1, device 10: "/sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.4/1-1.4.1"
Oct 9 08:50:01 smarthome mtp-probe: checking bus 1, device 10: "/sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.4/1-1.4.1"
I'm suffering from very similar problem: just got my ConBee II today, managed to do initial setup but every single firmware update fails with a timeout after only 3 seconds. My first attempt was with the stick plugged into the USB 2.0 port of my Dell R210 (running Proxmox v6) and doing passthrough of the ConBee to my VM that runs Home Assistant and deCONZ docker (this will soon be ported to the RPi 4 that I bought).
After that firmware flash failed I decided to go on with the manual flashing option. Installed deconz directly to the physical server, removed the passthrough of the ConBee dongle to the VM, but that was when I realized that the dongle is recognized by the system but soon is ejected. Cycle repeats indefinitely; it never lasts long enough for me to be able to sucessfully flash the firmware.
Tried also on my Desktop PC (custom build, running vanilla Debian 10) and laptop (Thinkpad W530 also running Debian 10), to no success. Tried on USB 2.0 and USB 3.0 ports on all of them. Just for the sake of it booted into Windows and noticed it was also recognized and quickly ejected as well. Always in no more than 3 seconds.
I don't have an extender or powered USB 2.0 hub (will buy one tomorrow morning and report back).
Here are some other details:
Current version of the firmware on the ConBee II seems to be 0x26490700. I was trying to install firmware version 0x264a0700.
Tue Oct 15 01:18:11 root@viserion [0] ~
# dpkg -l deconz
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==============-==========================-============-============================================
ii deconz 2.05.69-ubuntu-xenial-beta amd64 A generic ZigBee monitoring and control tool```
Tue Oct 15 01:15:30 root@viserion [0] ~
# GCFFlasher_internal -l
GCFFlasher V3_06 (c) dresden elektronik ingenieurtechnik gmbh
Path | Vendor | Product | Serial | Type
-----------------+--------+---------+------------+-------
/dev/ttyACM0 | 0x1CF1 | 0x0030 | DE2123285 | ConBee II
Tue Oct 15 01:18:06 root@viserion [3] ~
# GCFFlasher_internal -d /dev/ttyACM0 -f deCONZ_ConBeeII_0x264a0700.bin.GCF
GCFFlasher V3_06 (c) dresden elektronik ingenieurtechnik gmbh
Reboot device /dev/ttyACM0 (ConBee II)
action: update firmware after 18 ms
flashing 158985 bytes: |=====error: timeout flashing firmware after 3003 ms
BTW, I have also tried running with -R 1000, but it didn't help. Let's see about the cable extender and USB 2.0 hub tomorrow, after I buy one.
Ok, back to report that I just bought a cheap USB 2.0 extension cable and also a USB 2.0 hub and tested it. Glad to say I was able to flash firmware version 0x264a0700 to my ConBee II stick and it's very stable with the USB 2.0 extension cable, not disconnecting every 3 seconds it was as before.
Tue Oct 15 10:46:29 root@viserion [0] ~
# GCFFlasher_internal -d /dev/ttyACM0 -f deCONZ_ConBeeII_0x264a0700.bin.GCF
GCFFlasher V3_06 (c) dresden elektronik ingenieurtechnik gmbh
Reboot device /dev/ttyACM0 (ConBee II)
deCONZ firmware version 264A0700
action: update firmware after 6721 ms
unlock! (6822 ms)
flashing 158985 bytes: |==============================|
verify: .
SUCCESS
Wait 10 seconds until application starts
There are some other odd things. After aforementioned successful firmware update, when I started the deconz container again, the logs show:
10:51:03:459 GW update firmware found: /usr/share/deCONZ/firmware/deCONZ_ConBeeII_0x26490700.bin.GCF
Why is it suggesting a firmware _update_ to an older version?
Also, when accessing the "Gateway" page, I don't see any firmware information: https://i.imgur.com/Cx10PRF.png
When trying to do a "Reset gateway" operation to see if it'd fix it, I was presented with "Failure" screen: https://i.imgur.com/Rg3i5vu.png
On the container logs, this is what I saw:
QNetworkReplyImplPrivate::error: Internal problem, this method must only be called once.
I have also noticed that from inside the container, there's no "Serial" being reported:
root@homeserver:/# /usr/bin/GCFFlasher_internal -l
GCFFlasher V3_06 (c) dresden elektronik ingenieurtechnik gmbh
Path | Vendor | Product | Serial | Type
-----------------+--------+---------+------------+-------
/dev/ttyACM0 | 0x1CF1 | 0x0030 | | ConBee II
Ok, new discovery: to run the docker container I was using:
docker run -d --name=deconz --net=host --restart=always -v /etc/localtime:/etc/localtime:ro -v /opt/deconz:/root/.
local/share/dresden-elektronik/deCONZ -e DECONZ_VNC_MODE=1 --device=/dev/zigbee marthoc/deconz
Meaning I was passing the /dev/zigbee device that I setup using a udev rule to map the ConBee II under /dev/ttyACM0 to the virtual device /dev/zigbee. That was causing the "Serial" to appear empty inside the container. After changing the docker run command to use /dev/ttyACM0, everything worked perfectly:
Tue Oct 15 11:08:26 root@homeserver [0] ~
# docker logs -f deconz
[marthoc/deconz] Starting deCONZ...
[marthoc/deconz] Current deCONZ version: 2.05.69
[marthoc/deconz] Web UI port: 80
[marthoc/deconz] Websockets port: 443
[marthoc/deconz] VNC port: 5900
/usr/bin/xauth: file /root/.Xauthority does not exist
New 'homeserver.de.rsaffi.com:0 (root)' desktop at :0 on machine homeserver.de.rsaffi.com
Starting applications specified in /etc/X11/Xvnc-session
Log file is /root/.vnc/homeserver.de.rsaffi.com:0.log
Use xtigervncviewer -SecurityTypes VncAuth,TLSVnc -passwd /root/.vnc/passwd homeserver.de.rsaffi.com:0 to connect to the VNC server.
libEGL warning: DRI2: failed to open swrast (search paths /usr/lib/x86_64-linux-gnu/dri:${ORIGIN}/dri:/usr/lib/dri)
libEGL warning: DRI2: failed to open swrast (search paths /usr/lib/x86_64-linux-gnu/dri:${ORIGIN}/dri:/usr/lib/dri)
libpng warning: iCCP: known incorrect sRGB profile
11:08:30:228 HTTP Server listen on address 0.0.0.0, port: 80, root: /usr/share/deCONZ/webapp/
11:08:30:242 CTRL. 3.16.211:08:30:275 ZCLDB init file /root/.local/share/dresden-elektronik/deCONZ/zcldb.txt
11:08:30:313 parent process /bin/sh
11:08:30:313 gw run mode: docker
11:08:30:313 GW sd-card image version file does not exist: /root/.local/share/dresden-elektronik/deCONZ/gw-version
11:08:30:314 DB sqlite version 3.16.2
11:08:30:314 DB PRAGMA page_count: 30
11:08:30:314 DB PRAGMA page_size: 4096
11:08:30:314 DB PRAGMA freelist_count: 0
11:08:30:314 DB file size 122880 bytes, free pages 0
11:08:30:314 DB PRAGMA user_version: 6
11:08:30:314 DB cleanup
11:08:30:315 DB create temporary views
11:08:30:317 don't close database yet, keep open for 900 seconds
11:08:30:318 started websocket server at port 443
11:08:30:319 found node plugin: libde_rest_plugin.so - REST API Plugin
11:08:30:320 found node plugin: libde_signal_plugin.so - Signal Monitor Plugin
11:08:30:324 found node plugin: libstd_otau_plugin.so - STD OTAU Plugin
11:08:30:406 Device firmware version 0x264A0700
11:08:30:413 unlocked max nodes: 200
11:08:30:512 Device protocol version: 0x010B
11:08:30:521 new node - ext: 0x00212effff04e712, nwk: 0x0000
11:08:30:604 Current channel 15
11:08:30:626 CTRL ANT_CTRL 0x03
11:08:30:660 Device protocol version: 0x010B
11:08:30:726 Current channel 15
11:08:30:748 CTRL ANT_CTRL 0x03
11:08:31:584 New websocket 127.0.0.1:48240 (state: 3)
11:08:35:462 GW update firmware found: /usr/share/deCONZ/firmware/deCONZ_ConBeeII_0x26490700.bin.GCF
11:08:35:462 GW firmware version: 0x264a0700
11:08:35:462 GW firmware version is up to date: 0x264a0700
11:08:35:508 New websocket 10.1.1.20:57286 (state: 3)
11:08:36:283 Announced to internet
Any solution to this on a Intel NUC with usb 3 ports only?
Any solution to this on a Intel NUC with usb 3 ports only?
I have a Intel Nuc with USB 3.0 and no problem, all work really fine.
Any solution to this on a Intel NUC with usb 3 ports only?
I have a Intel Nuc with USB 3.0 and no problem, all work really fine.
Interesting,
I'm running an Intel NUC with PROXMOX > HASSIO running in a vm with the USB passed through.
None of the other USBs are in use.
Heres what my HASSIO vm logs look like.
edit log was ugly
Any solution to this on a Intel NUC with usb 3 ports only?
I have a Intel Nuc with USB 3.0 and no problem, all work really fine.
Interesting,
I'm running an Intel NUC with PROXMOX > HASSIO running in a vm with the USB passed through.
None of the other USBs are in use.
Heres what my HASSIO vm logs look like.
_edit log was ugly_
I had the same problem on my server with proxmox; just ended up moving deconz onto my raspberry pi and telling hass that's where my deconz was. Bit annoying but it works fine.
Any solution to this on a Intel NUC with usb 3 ports only?
I have a Intel Nuc with USB 3.0 and no problem, all work really fine.
Interesting,
I'm running an Intel NUC with PROXMOX > HASSIO running in a vm with the USB passed through.
None of the other USBs are in use.
Heres what my HASSIO vm logs look like.
log.txt
_edit log was ugly_I had the same problem on my server with proxmox; just ended up moving deconz onto my raspberry pi and telling hass that's where my deconz was. Bit annoying but it works fine.
I ay resort to this, not my preferred solution but it will do...
Any solution to this on a Intel NUC with usb 3 ports only?
I have a Intel Nuc with USB 3.0 and no problem, all work really fine.
Interesting,
I'm running an Intel NUC with PROXMOX > HASSIO running in a vm with the USB passed through.
None of the other USBs are in use.
Heres what my HASSIO vm logs look like.
log.txt
_edit log was ugly_I had the same problem on my server with proxmox; just ended up moving deconz onto my raspberry pi and telling hass that's where my deconz was. Bit annoying but it works fine.
I may resort this this. Have you notices any reduction in performance of changes? Sensor update / lights change etc.
I may resort this this. Have you notices any reduction in performance of changes? Sensor update / lights change etc.
Nope - though my pi and my server are both on ethernet.
Any solution to this on a Intel NUC with usb 3 ports only?
I have a Intel Nuc with USB 3.0 and no problem, all work really fine.
Interesting,
I'm running an Intel NUC with PROXMOX > HASSIO running in a vm with the USB passed through.
None of the other USBs are in use.
Heres what my HASSIO vm logs look like.
_edit log was ugly_
I use NUC only with Home assistant + Deconz.
Ubuntu + docker and all work prefect.
Hello,
I got the same issue after upgradind the conbee 2. Boot loop + failed to set dtr/rts.
Can't do anything now :(
Hi, and you have other USB devices ?
Have you tried with cable or Hub ?
And what version of deconz do you use?
Op 23 jan. 2020 om 21:42 heeft Smanar notifications@github.com het volgende geschreven:
Hi, and you have other USB devices ?
Have you tried with cable or Hub ?—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
I have a similar issue as well. Somehow the ConBee II Stick gets disconnected by both ARM based devices I have. It is only correctly working under the newest firmware on the NUC or the windows 10 box. Either it is something in the ConBees firmware or i have to try an older linux kernel then 4.19.54 as I would prefer to use a small, seperate box for deconz and home-assistant.
I tried the following scenarios:
NUC7i3BNH (amd64) - Linux Kernel 4.19.0
0x264a0700- Does not work0x26490700- Does worknanoPi NEO (armhf) - Linux Kernel 4.19.54 and 5.4
0x264a0700- Does not work0x26490700- Does not worknanoPi NEO2 (arm64) - Linux Kernel 4.19.54 and 5.4
0x264a0700- Does not work0x26490700- Does not workWindows 10 machine
0x264a0700- Does work0x26490700- Does workLogs from the NUC installation and the ConBee II Firmware 0x264a0700:
Jan 24 02:57:12 vaxjo kernel: [35390.644540] usb 1-2: USB disconnect, device number 56
Jan 24 02:57:12 vaxjo kernel: [35390.949371] usb 1-2: new full-speed USB device number 57 using xhci_hcd
Jan 24 02:57:12 vaxjo kernel: [35391.098775] usb 1-2: New USB device found, idVendor=1cf1, idProduct=0030, bcdDevice= 1.00
Jan 24 02:57:12 vaxjo kernel: [35391.098777] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jan 24 02:57:12 vaxjo kernel: [35391.098779] usb 1-2: Product: ConBee II
Jan 24 02:57:12 vaxjo kernel: [35391.098779] usb 1-2: Manufacturer: dresden elektronik ingenieurtechnik GmbH
Jan 24 02:57:12 vaxjo kernel: [35391.098780] usb 1-2: SerialNumber: <removed>
Jan 24 02:57:12 vaxjo kernel: [35391.099878] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
Jan 24 02:57:15 vaxjo kernel: [35393.811948] mmcblk0: p1
Jan 24 02:57:20 vaxjo kernel: [35398.532801] usb 1-2: USB disconnect, device number 57
Jan 24 02:57:20 vaxjo kernel: [35398.889293] usb 1-2: new full-speed USB device number 58 using xhci_hcd
Jan 24 02:57:20 vaxjo kernel: [35399.038723] usb 1-2: New USB device found, idVendor=1cf1, idProduct=0030, bcdDevice= 1.00
Jan 24 02:57:20 vaxjo kernel: [35399.038725] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jan 24 02:57:20 vaxjo kernel: [35399.038727] usb 1-2: Product: ConBee II
Jan 24 02:57:20 vaxjo kernel: [35399.038728] usb 1-2: Manufacturer: dresden elektronik ingenieurtechnik GmbH
Jan 24 02:57:20 vaxjo kernel: [35399.038730] usb 1-2: SerialNumber: <removed>
Jan 24 02:57:20 vaxjo kernel: [35399.040018] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
Jan 24 02:57:39 vaxjo kernel: [35418.096790] usb 1-2: USB disconnect, device number 58
Jan 24 02:57:40 vaxjo kernel: [35418.409100] usb 1-2: new full-speed USB device number 59 using xhci_hcd
Jan 24 02:57:40 vaxjo kernel: [35418.558602] usb 1-2: New USB device found, idVendor=1cf1, idProduct=0030, bcdDevice= 1.00
Jan 24 02:57:40 vaxjo kernel: [35418.558605] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jan 24 02:57:40 vaxjo kernel: [35418.558606] usb 1-2: Product: ConBee II
Jan 24 02:57:40 vaxjo kernel: [35418.558608] usb 1-2: Manufacturer: dresden elektronik ingenieurtechnik GmbH
Jan 24 02:57:40 vaxjo kernel: [35418.558609] usb 1-2: SerialNumber: <removed>
Jan 24 02:57:40 vaxjo kernel: [35418.559946] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
Jan 24 02:57:47 vaxjo kernel: [35425.990855] usb 1-2: USB disconnect, device number 59
Jan 24 02:57:47 vaxjo kernel: [35426.369016] usb 1-2: new full-speed USB device number 60 using xhci_hcd
Jan 24 02:57:53 vaxjo kernel: [35431.712997] usb 1-2: unable to read config index 0 descriptor/all
Jan 24 02:57:53 vaxjo kernel: [35431.713004] usb 1-2: can't read configurations, error -110
Jan 24 02:57:53 vaxjo kernel: [35431.844977] usb 1-2: new full-speed USB device number 61 using xhci_hcd
Jan 24 02:57:53 vaxjo kernel: [35431.994472] usb 1-2: New USB device found, idVendor=1cf1, idProduct=0030, bcdDevice= 1.00
Jan 24 02:57:53 vaxjo kernel: [35431.994476] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jan 24 02:57:53 vaxjo kernel: [35431.994478] usb 1-2: Product: ConBee II
Jan 24 02:57:53 vaxjo kernel: [35431.994480] usb 1-2: Manufacturer: dresden elektronik ingenieurtechnik GmbH
Jan 24 02:57:53 vaxjo kernel: [35431.994481] usb 1-2: SerialNumber: <removed>
Jan 24 02:57:53 vaxjo kernel: [35431.995949] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
Jan 24 02:58:30 vaxjo kernel: [35469.048156] usb 1-2: USB disconnect, device number 61
Jan 24 02:58:30 vaxjo kernel: [35469.364557] usb 1-2: new full-speed USB device number 62 using xhci_hcd
Jan 24 02:58:31 vaxjo kernel: [35469.514038] usb 1-2: New USB device found, idVendor=1cf1, idProduct=0030, bcdDevice= 1.00
Jan 24 02:58:31 vaxjo kernel: [35469.514042] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jan 24 02:58:31 vaxjo kernel: [35469.514044] usb 1-2: Product: ConBee II
Jan 24 02:58:31 vaxjo kernel: [35469.514045] usb 1-2: Manufacturer: dresden elektronik ingenieurtechnik GmbH
Jan 24 02:58:31 vaxjo kernel: [35469.514047] usb 1-2: SerialNumber: <removed>
Jan 24 02:58:31 vaxjo kernel: [35469.515350] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
Interesting, I eventually caved to all the arguments that it’s all because of frequencies. This shows differently perhaps.
Something to check to be conclusive;
Op 24 jan. 2020 om 04:38 heeft Sascha notifications@github.com het volgende geschreven:
I have a similar issue as well. Somehow the ConBee II Stick gets disconnected by both ARM based devices I have. It is only correctly working under the newest firmware on the NUC. Either it is something in the ConBees firmware or i have to try an older linux kernel then 4.19.54 as I would prefer to use a small, seperate box for deconz and home-assistant.I tried the following scenarios:
NUC7i3BNH (amd64) - Linux Kernel 4.19.0
Without USB 2.0 extension cord - Does not work
With USB 2.0 extension cord and ConBee II Firmware 0x264a0700- Does not work
With USB 2.0 extension cord and ConBee II Firmware 0x26490700- Does work
nanoPi NEO (armhf) - Linux Kernel 4.19.54 and 5.4Without USB 2.0 extension cord - Does not work
With USB 2.0 extension cord and ConBee II Firmware 0x264a0700- Does not work
With USB 2.0 extension cord and ConBee II Firmware 0x26490700- Does not work
nanoPi NEO2 (arm64) - Linux Kernel 4.19.54 and 5.4Without USB 2.0 extension cord - Does not work
With USB 2.0 extension cord and ConBee II Firmware 0x264a0700- Does not work
With USB 2.0 extension cord and ConBee II Firmware 0x26490700- Does not work
Windows 10 machineWithout USB 2.0 extension cord - Does work
With USB 2.0 extension cord and ConBee II Firmware 0x264a0700- Does work
With USB 2.0 extension cord and ConBee II Firmware 0x26490700- Does work
Logs from the NUC installation and the ConBee II Firmware 0x264a0700:
Jan 24 02:57:12 vaxjo kernel: [35390.644540] usb 1-2: USB disconnect, device number 56 Jan 24 02:57:12 vaxjo kernel: [35390.949371] usb 1-2: new full-speed USB device number 57 using xhci_hcd Jan 24 02:57:12 vaxjo kernel: [35391.098775] usb 1-2: New USB device found, idVendor=1cf1, idProduct=0030, bcdDevice= 1.00 Jan 24 02:57:12 vaxjo kernel: [35391.098777] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Jan 24 02:57:12 vaxjo kernel: [35391.098779] usb 1-2: Product: ConBee II Jan 24 02:57:12 vaxjo kernel: [35391.098779] usb 1-2: Manufacturer: dresden elektronik ingenieurtechnik GmbH Jan 24 02:57:12 vaxjo kernel: [35391.098780] usb 1-2: SerialNumber:Jan 24 02:57:12 vaxjo kernel: [35391.099878] cdc_acm 1-2:1.0: ttyACM0: USB ACM device Jan 24 02:57:15 vaxjo kernel: [35393.811948] mmcblk0: p1 Jan 24 02:57:20 vaxjo kernel: [35398.532801] usb 1-2: USB disconnect, device number 57 Jan 24 02:57:20 vaxjo kernel: [35398.889293] usb 1-2: new full-speed USB device number 58 using xhci_hcd Jan 24 02:57:20 vaxjo kernel: [35399.038723] usb 1-2: New USB device found, idVendor=1cf1, idProduct=0030, bcdDevice= 1.00 Jan 24 02:57:20 vaxjo kernel: [35399.038725] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Jan 24 02:57:20 vaxjo kernel: [35399.038727] usb 1-2: Product: ConBee II Jan 24 02:57:20 vaxjo kernel: [35399.038728] usb 1-2: Manufacturer: dresden elektronik ingenieurtechnik GmbH Jan 24 02:57:20 vaxjo kernel: [35399.038730] usb 1-2: SerialNumber: Jan 24 02:57:20 vaxjo kernel: [35399.040018] cdc_acm 1-2:1.0: ttyACM0: USB ACM device Jan 24 02:57:39 vaxjo kernel: [35418.096790] usb 1-2: USB disconnect, device number 58 Jan 24 02:57:40 vaxjo kernel: [35418.409100] usb 1-2: new full-speed USB device number 59 using xhci_hcd Jan 24 02:57:40 vaxjo kernel: [35418.558602] usb 1-2: New USB device found, idVendor=1cf1, idProduct=0030, bcdDevice= 1.00 Jan 24 02:57:40 vaxjo kernel: [35418.558605] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Jan 24 02:57:40 vaxjo kernel: [35418.558606] usb 1-2: Product: ConBee II Jan 24 02:57:40 vaxjo kernel: [35418.558608] usb 1-2: Manufacturer: dresden elektronik ingenieurtechnik GmbH Jan 24 02:57:40 vaxjo kernel: [35418.558609] usb 1-2: SerialNumber: Jan 24 02:57:40 vaxjo kernel: [35418.559946] cdc_acm 1-2:1.0: ttyACM0: USB ACM device Jan 24 02:57:47 vaxjo kernel: [35425.990855] usb 1-2: USB disconnect, device number 59 Jan 24 02:57:47 vaxjo kernel: [35426.369016] usb 1-2: new full-speed USB device number 60 using xhci_hcd Jan 24 02:57:53 vaxjo kernel: [35431.712997] usb 1-2: unable to read config index 0 descriptor/all Jan 24 02:57:53 vaxjo kernel: [35431.713004] usb 1-2: can't read configurations, error -110 Jan 24 02:57:53 vaxjo kernel: [35431.844977] usb 1-2: new full-speed USB device number 61 using xhci_hcd Jan 24 02:57:53 vaxjo kernel: [35431.994472] usb 1-2: New USB device found, idVendor=1cf1, idProduct=0030, bcdDevice= 1.00 Jan 24 02:57:53 vaxjo kernel: [35431.994476] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Jan 24 02:57:53 vaxjo kernel: [35431.994478] usb 1-2: Product: ConBee II Jan 24 02:57:53 vaxjo kernel: [35431.994480] usb 1-2: Manufacturer: dresden elektronik ingenieurtechnik GmbH Jan 24 02:57:53 vaxjo kernel: [35431.994481] usb 1-2: SerialNumber: Jan 24 02:57:53 vaxjo kernel: [35431.995949] cdc_acm 1-2:1.0: ttyACM0: USB ACM device Jan 24 02:58:30 vaxjo kernel: [35469.048156] usb 1-2: USB disconnect, device number 61 Jan 24 02:58:30 vaxjo kernel: [35469.364557] usb 1-2: new full-speed USB device number 62 using xhci_hcd Jan 24 02:58:31 vaxjo kernel: [35469.514038] usb 1-2: New USB device found, idVendor=1cf1, idProduct=0030, bcdDevice= 1.00 Jan 24 02:58:31 vaxjo kernel: [35469.514042] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Jan 24 02:58:31 vaxjo kernel: [35469.514044] usb 1-2: Product: ConBee II Jan 24 02:58:31 vaxjo kernel: [35469.514045] usb 1-2: Manufacturer: dresden elektronik ingenieurtechnik GmbH Jan 24 02:58:31 vaxjo kernel: [35469.514047] usb 1-2: SerialNumber: Jan 24 02:58:31 vaxjo kernel: [35469.515350] cdc_acm 1-2:1.0: ttyACM0: USB ACM device —
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
Something to check to be conclusive;
- the windows 10 machine does it have usb 3 ports?
the windows 10 machine does have usb 3.0 ports, which I have used
- does windows turn these ports of while not in in use and can you plug something usb3 compatible in that port? Rerun the scenarios again.
I will try to plug a usb 3 hard drive into the same controller hub
- does the windows 10 have a wifi and or bluetooth adapter on board or attached?
It does, but it is disabled in UEFI and not showing in the Device Manager
I had the same stream of repeating USB disconnect messages on my logs, with the occasional failed to set dtr/rts too.
I have around 20 zigbee devices connected, mostly IKEA and Xiaomi, which I use all the time for my house lights.
I use a Raspberry pi 3, running Raspbian buster.
$ uname -a
Linux kastpi 4.19.75-v7+ #1270 SMP Tue Sep 24 18:45:11 BST 2019 armv7l GNU/Linux
I am running deConz 2.05.75 on docker, GW firmware 0x264A0700.
Home-assistant and node-red run on two other docker containers.
I have a an FTDI232 USB UART and a small USB 2.0 HUB connected to the raspi ports, the Conbee II is on the hub. The hub _does not_ have an external power supply. Nothing else. The raspi is on the official 5V adapter. WiFi @ 2.4 GHz.
$ lsusb -t
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/5p, 480M
|__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=smsc95xx, 480M
|__ Port 3: Dev 4, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 4: Dev 91, If 1, Class=CDC Data, Driver=cdc_acm, 12M
|__ Port 4: Dev 91, If 0, Class=Communications, Driver=cdc_acm, 12M
|__ Port 5: Dev 7, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M
# dmesg -e
[Mar13 16:40] usb 1-1.3.4: USB disconnect, device number 71
[ +0.304085] usb 1-1.3.4: new full-speed USB device number 72 using dwc_otg
[ +0.134349] usb 1-1.3.4: New USB device found, idVendor=1cf1, idProduct=0030, bcdDevice= 1.00
[ +0.000011] usb 1-1.3.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ +0.000005] usb 1-1.3.4: Product: ConBee II
[ +0.000005] usb 1-1.3.4: Manufacturer: dresden elektronik ingenieurtechnik GmbH
[ +0.000005] usb 1-1.3.4: SerialNumber: -redacted-
[ +0.000776] cdc_acm 1-1.3.4:1.0: ttyACM0: USB ACM device
[ +3.401045] usb 1-1.3.4: USB disconnect, device number 72
[ +0.000378] cdc_acm 1-1.3.4:1.0: failed to set dtr/rts
[ +0.345175] usb 1-1.3.4: new full-speed USB device number 73 using dwc_otg
[ +0.134348] usb 1-1.3.4: New USB device found, idVendor=1cf1, idProduct=0030, bcdDevice= 1.00
[ +0.000008] usb 1-1.3.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ +0.000005] usb 1-1.3.4: Product: ConBee II
[ +0.000005] usb 1-1.3.4: Manufacturer: dresden elektronik ingenieurtechnik GmbH
[ +0.000005] usb 1-1.3.4: SerialNumber: -redacted-
[ +0.000775] cdc_acm 1-1.3.4:1.0: ttyACM1: USB ACM device
[Mar13 16:42] usb 1-1.3.4: USB disconnect, device number 73
[ +0.311462] usb 1-1.3.4: new full-speed USB device number 74 using dwc_otg
[ +0.134490] usb 1-1.3.4: New USB device found, idVendor=1cf1, idProduct=0030, bcdDevice= 1.00
[ +0.000014] usb 1-1.3.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ +0.000010] usb 1-1.3.4: Product: ConBee II
[ +0.000010] usb 1-1.3.4: Manufacturer: dresden elektronik ingenieurtechnik GmbH
[ +0.000009] usb 1-1.3.4: SerialNumber: -redacted-
[ +0.002612] cdc_acm 1-1.3.4:1.0: ttyACM0: USB ACM device
[ +7.560411] cdc_acm 1-1.3.4:1.0: failed to set dtr/rts
[ +0.001366] usb 1-1.3.4: USB disconnect, device number 74
[ +0.303901] usb 1-1.3.4: new full-speed USB device number 75 using dwc_otg
[ +0.134394] usb 1-1.3.4: New USB device found, idVendor=1cf1, idProduct=0030, bcdDevice= 1.00
[ +0.000009] usb 1-1.3.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ +0.000005] usb 1-1.3.4: Product: ConBee II
[ +0.000005] usb 1-1.3.4: Manufacturer: dresden elektronik ingenieurtechnik GmbH
[ +0.000005] usb 1-1.3.4: SerialNumber: -redacted-
[ +0.002115] cdc_acm 1-1.3.4:1.0: ttyACM0: USB ACM device
[Mar14 19:52] cdc_acm 1-1.3.4:1.0: failed to set dtr/rts
At that point, 12 days ago, the error messages are gone.
I have apparently deleted the deConz container and recreated it (keeping the deConz config volume intact), but the version was and is still the same: 2.05.75. I certainly did not change anything physically. The raspi uptime is around a month, so no kernel changes either. Note that the usb "path" on the logs (1-1.3.4) matches the current device tree.
The Conbee II has not been unplugged at any point, and the last error entry on this log is the last dmesg entry on my system. The system journal also reveals mtp-probe probing for an MTP device on each reconnect, but nothing else.
All in all, the problem is gone for me without really doing anything. I hope this helps others running similar versions.
All in all, the problem is gone for me without really doing anything. I hope this helps others running similar versions.
I'm also running on a Pi (4) and have been having this usb disconnect issue for a couple of weeks now. I stumbled on another forum where a person was having usb disconnect problems with an unrelated piece of hardware. This user was able to figure out that the firmware in the usb device would cause this to happen if it was unable to connect to the relevant software within a certain period of time.
I installed deCONZ manually on Raspbian Buster and realised that i hadn't enabled it to run on boot. While trying to remedy this problem, i had been manually starting deCONZ after every boot.
After running this command sudo systemctl enable deconz-gui and enabling it to run on boot - dmesg -e is showing only 3 disconnects within a few seconds of booting and then they don't appear again. Previously, they were occuring every ten to fifteen seconds and after a day or so the Pi would become unresponsive. It would appear this has solved my particular problem.
Not sure if this is relevant to anyone else's issues but 24 hours later i've had no more disconnects.
Version : 2.05.75 / 3/8/2020
Firmware: 264A0700
This is going to be particularly “interesting” when people start attaching USB 3.0 disks to their Raspberry Pi 4B systems, running deCONZ using a RaspBee. Cross-referencing #1643.
@ebaauw thank you so much for this post. This just solved an issue I had.
Was running on a raspberry pi 4 without any problems until I decided to start using an SSD connected to a USB 3.0 cable in the adjacent port.
Started getting the 0xC4 error message and initially believed this could be a software issue until I read this post.
After reading this post suggesting there may be signal interference I got an old USB extension cable, put that in between the conbee and the raspberry pi, placed the conbee about 2 meters away from the raspberry pi and instantly it worked again.
Thanks again!
Hi,
I do have the same problems with my ConBee II and the newest Firmware: deCONZ_ConBeeII_0x26580700.bin.GCF
dmesg -e:
...
[Mai12 11:39] usb 1-1.4: USB disconnect, device number 95
[ +0,303328] usb 1-1.4: new full-speed USB device number 96 using xhci_hcd
[ +0,139129] usb 1-1.4: New USB device found, idVendor=1cf1, idProduct=0030, bcdDevice= 1.00
[ +0,000017] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ +0,000013] usb 1-1.4: Product: ConBee II
[ +0,000013] usb 1-1.4: Manufacturer: dresden elektronik ingenieurtechnik GmbH
[ +0,000012] usb 1-1.4: SerialNumber: DE2124570
[ +0,004775] cdc_acm 1-1.4:1.0: ttyACM0: USB ACM device
[ +3,393287] usb 1-1.4: USB disconnect, device number 96
[ +0,322804] usb 1-1.4: new full-speed USB device number 97 using xhci_hcd
[ +0,139031] usb 1-1.4: New USB device found, idVendor=1cf1, idProduct=0030, bcdDevice= 1.00
[ +0,000017] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ +0,000013] usb 1-1.4: Product: ConBee II
[ +0,000012] usb 1-1.4: Manufacturer: dresden elektronik ingenieurtechnik GmbH
[ +0,000011] usb 1-1.4: SerialNumber: DE2124570
[ +0,004788] cdc_acm 1-1.4:1.0: ttyACM0: USB ACM device
[ +41,011558] usb 1-1.4: USB disconnect, device number 97
[ +0,295170] usb 1-1.4: new full-speed USB device number 98 using xhci_hcd
[ +0,139028] usb 1-1.4: New USB device found, idVendor=1cf1, idProduct=0030, bcdDevice= 1.00
[ +0,000016] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ +0,000013] usb 1-1.4: Product: ConBee II
[ +0,000013] usb 1-1.4: Manufacturer: dresden elektronik ingenieurtechnik GmbH
[ +0,000012] usb 1-1.4: SerialNumber: DE2124570
[ +0,004756] cdc_acm 1-1.4:1.0: ttyACM0: USB ACM device
[ +3,401600] usb 1-1.4: USB disconnect, device number 98
[ +0,304624] usb 1-1.4: new full-speed USB device number 99 using xhci_hcd
[ +0,139042] usb 1-1.4: New USB device found, idVendor=1cf1, idProduct=0030, bcdDevice= 1.00
[ +0,000017] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ +0,000013] usb 1-1.4: Product: ConBee II
[ +0,000013] usb 1-1.4: Manufacturer: dresden elektronik ingenieurtechnik GmbH
[ +0,000012] usb 1-1.4: SerialNumber: DE2124570
[ +0,008775] cdc_acm 1-1.4:1.0: ttyACM0: USB ACM device
[Mai12 11:40] usb 1-1.4: USB disconnect, device number 99
[ +0,297020] usb 1-1.4: new full-speed USB device number 100 using xhci_hcd
[ +0,139065] usb 1-1.4: New USB device found, idVendor=1cf1, idProduct=0030, bcdDevice= 1.00
[ +0,000013] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ +0,000011] usb 1-1.4: Product: ConBee II
[ +0,000010] usb 1-1.4: Manufacturer: dresden elektronik ingenieurtechnik GmbH
[ +0,000011] usb 1-1.4: SerialNumber: DE2124570
[ +0,004725] cdc_acm 1-1.4:1.0: ttyACM0: USB ACM device
[ +3,399792] usb 1-1.4: USB disconnect, device number 100
[ +0,296431] usb 1-1.4: new full-speed USB device number 101 using xhci_hcd
[ +0,139089] usb 1-1.4: New USB device found, idVendor=1cf1, idProduct=0030, bcdDevice= 1.00
[ +0,000017] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ +0,000013] usb 1-1.4: Product: ConBee II
[ +0,000013] usb 1-1.4: Manufacturer: dresden elektronik ingenieurtechnik GmbH
[ +0,000012] usb 1-1.4: SerialNumber: DE2124570
[ +0,004764] cdc_acm 1-1.4:1.0: ttyACM0: USB ACM device
...
RPi 4, Raspbian (newest Update)
I try USB 2 or Usb 3 port, USB 2 maybe a little bit better, but still the errors appears minutely...
I ran an IoBroker with the ZigBee Adapter on it.
Any idea what I can try? // @manup
Thanks for your help!
@larskeller have you tried to update the firmware a second time ?
And if you have deco/reco too fast for a correct update take a look here https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2493
@Smanar Thanks for the hint. I successfully update the newest firmware to ConBee II. But it doesn't make a change on the deco/reco problem. :-(
After some time this message was iin the logfiles, too
cdc_acm 1-1.4:1.0: failed to set dtr/rts
It seems this issue is resolved or otherwise inactive. If it is not, please re-open!
I am experiencing this issue right now. I am running hassio in a VM within Proxmox and use USB passthrough (by-id) for my conbee 2 stick. The conbee stick is plugged into a 3.1 usb port on the back of my NUC. I see the following logs (dmesg):
[Wed Jul 8 08:51:19 2020] cdc_acm 1-3:1.0: ttyACM0: USB ACM device
[Wed Jul 8 08:51:22 2020] usb 1-3: USB disconnect, device number 62
[Wed Jul 8 08:51:23 2020] usb 1-3: new full-speed USB device number 63 using xhci_hcd
[Wed Jul 8 08:51:23 2020] usb 1-3: New USB device found, idVendor=1cf1, idProduct=0030, bcdDevice= 1.00
[Wed Jul 8 08:51:23 2020] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[Wed Jul 8 08:51:23 2020] usb 1-3: Product: ConBee II
[Wed Jul 8 08:51:23 2020] usb 1-3: Manufacturer: dresden elektronik ingenieurtechnik GmbH
[Wed Jul 8 08:51:23 2020] usb 1-3: SerialNumber: DE2129245
[Wed Jul 8 08:51:23 2020] cdc_acm 1-3:1.0: ttyACM0: USB ACM device
[Wed Jul 8 08:52:32 2020] usb 1-3: USB disconnect, device number 63
[Wed Jul 8 08:52:32 2020] usb 1-3: new full-speed USB device number 64 using xhci_hcd
[Wed Jul 8 08:52:32 2020] usb 1-3: New USB device found, idVendor=1cf1, idProduct=0030, bcdDevice= 1.00
[Wed Jul 8 08:52:32 2020] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[Wed Jul 8 08:52:32 2020] usb 1-3: Product: ConBee II
[Wed Jul 8 08:52:32 2020] usb 1-3: Manufacturer: dresden elektronik ingenieurtechnik GmbH
[Wed Jul 8 08:52:32 2020] usb 1-3: SerialNumber: DE2129245
[Wed Jul 8 08:52:32 2020] cdc_acm 1-3:1.0: ttyACM0: USB ACM device
[Wed Jul 8 08:52:36 2020] usb 1-3: USB disconnect, device number 64
[Wed Jul 8 08:52:36 2020] usb 1-3: new full-speed USB device number 65 using xhci_hcd
[Wed Jul 8 08:52:42 2020] usb 1-3: unable to read config index 0 descriptor/all
[Wed Jul 8 08:52:42 2020] usb 1-3: can't read configurations, error -110
[Wed Jul 8 08:52:42 2020] usb 1-3: new full-speed USB device number 66 using xhci_hcd
[Wed Jul 8 08:52:42 2020] usb 1-3: New USB device found, idVendor=1cf1, idProduct=0030, bcdDevice= 1.00
[Wed Jul 8 08:52:42 2020] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[Wed Jul 8 08:52:42 2020] usb 1-3: Product: ConBee II
[Wed Jul 8 08:52:42 2020] usb 1-3: Manufacturer: dresden elektronik ingenieurtechnik GmbH
[Wed Jul 8 08:52:42 2020] usb 1-3: SerialNumber: DE2129245
[Wed Jul 8 08:52:42 2020] cdc_acm 1-3:1.0: ttyACM0: USB ACM device
Eventually this seems to be causing a crash and I need to manually reboot my NUC. Help is needed :)
@jdruwe as this is a closed and an old issue, please open a new bug request including all info requested per template.
@Mimiix sorry for that, I do want to mention that I just moved it to the USB 3.1 charging port and I don't see any more logs, so fingers crossed :p
Most helpful comment
@Mimiix sorry for that, I do want to mention that I just moved it to the USB 3.1 charging port and I don't see any more logs, so fingers crossed :p