search

dresden-elektronik / deconz-rest-plugin

deCONZ REST-API plugin to control ZigBee devices
BSD 3-Clause "New" or "Revised" License
1.89k stars 496 forks source link

USB Disconnects running deconz on ubuntu #4267

Closed MrWGT closed 3 years ago

MrWGT commented 3 years ago

Describe the bug

Noticed a delay in reaction of switches. After digging in i found out that there are a lot of usb disconnects:

[So Jan 24 07:33:43 2021] usb 3-1.1: USB disconnect, device number 64 [So Jan 24 07:33:43 2021] cdc_acm 3-1.1:1.0: failed to set dtr/rts [So Jan 24 07:33:43 2021] usb 3-1.1: new full-speed USB device number 65 using xhci_hcd [So Jan 24 07:33:43 2021] usb 3-1.1: New USB device found, idVendor=1cf1, idProduct=0030, bcdDevice= 1.00 [So Jan 24 07:33:43 2021] usb 3-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [So Jan 24 07:33:43 2021] usb 3-1.1: Product: ConBee II [So Jan 24 07:33:43 2021] usb 3-1.1: Manufacturer: dresden elektronik ingenieurtechnik GmbH [So Jan 24 07:33:43 2021] usb 3-1.1: SerialNumber: DE2192922 [So Jan 24 07:33:43 2021] cdc_acm 3-1.1:1.0: ttyACM1: USB ACM device [So Jan 24 07:33:47 2021] usb 3-1.1: USB disconnect, device number 65 [So Jan 24 07:33:47 2021] usb 3-1.1: new full-speed USB device number 66 using xhci_hcd [So Jan 24 07:33:47 2021] usb 3-1.1: New USB device found, idVendor=1cf1, idProduct=0030, bcdDevice= 1.00 [So Jan 24 07:33:47 2021] usb 3-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [So Jan 24 07:33:47 2021] usb 3-1.1: Product: ConBee II [So Jan 24 07:33:47 2021] usb 3-1.1: Manufacturer: dresden elektronik ingenieurtechnik GmbH [So Jan 24 07:33:47 2021] usb 3-1.1: SerialNumber: DE2192922 [So Jan 24 07:33:47 2021] cdc_acm 3-1.1:1.0: ttyACM1: USB ACM device [So Jan 24 08:10:24 2021] xhci_hcd 0000:3a:00.0: WARN Cannot submit Set TR Deq Ptr [So Jan 24 08:10:24 2021] xhci_hcd 0000:3a:00.0: A Set TR Deq Ptr command is pending. [So Jan 24 08:10:24 2021] xhci_hcd 0000:3a:00.0: WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state. [So Jan 24 08:10:24 2021] usb 3-1.1: USB disconnect, device number 66 [So Jan 24 08:10:24 2021] cdc_acm 3-1.1:1.0: failed to set dtr/rts [So Jan 24 08:10:25 2021] usb 3-1.1: new full-speed USB device number 67 using xhci_hcd [So Jan 24 08:10:25 2021] usb 3-1.1: New USB device found, idVendor=1cf1, idProduct=0030, bcdDevice= 1.00 [So Jan 24 08:10:25 2021] usb 3-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [So Jan 24 08:10:25 2021] usb 3-1.1: Product: ConBee II [So Jan 24 08:10:25 2021] usb 3-1.1: Manufacturer: dresden elektronik ingenieurtechnik GmbH [So Jan 24 08:10:25 2021] usb 3-1.1: SerialNumber: DE2192922 [So Jan 24 08:10:25 2021] cdc_acm 3-1.1:1.0: ttyACM0: USB ACM device [So Jan 24 08:10:28 2021] usb 3-1.1: USB disconnect, device number 67 [So Jan 24 08:10:29 2021] usb 3-1.1: new full-speed USB device number 68 using xhci_hcd [So Jan 24 08:10:29 2021] usb 3-1.1: New USB device found, idVendor=1cf1, idProduct=0030, bcdDevice= 1.00 [So Jan 24 08:10:29 2021] usb 3-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [So Jan 24 08:10:29 2021] usb 3-1.1: Product: ConBee II [So Jan 24 08:10:29 2021] usb 3-1.1: Manufacturer: dresden elektronik ingenieurtechnik GmbH [So Jan 24 08:10:29 2021] usb 3-1.1: SerialNumber: DE2192922 [So Jan 24 08:10:29 2021] cdc_acm 3-1.1:1.0: ttyACM0: USB ACM device

Steps to reproduce the behavior

Just run deconz-gui on a intel nuc8i5beh.

Expected behavior

Should not disconnect

Screenshots

Environment

deCONZ Logs

08:10:20:784 void zmMaster::handleStateStatus(zmMaster::MasterEvent) EVENT_TIMEOUT 08:10:20:785 device state timeout ignored in state 3 08:10:20:786 enqueue event config/localtime for /config/ 08:10:20:786 Idle timer triggered 08:10:20:787 Force read attributes for ZHATemperature SensorNode MS AqaraWZ 08:10:20:787 don't create binding for attribute reporting of sensor MS AqaraWZ 08:10:20:787 Force binding of attribute reporting for node MS AqaraWZ 08:10:21:784 enqueue event config/localtime for /config/ 08:10:21:785 Wait 1s till query finished 08:10:22:785 enqueue event config/localtime for /config/ 08:10:22:785 Wait 0s till query finished 08:10:23:784 void zmMaster::handleStateStatus(zmMaster::MasterEvent) EVENT_TIMEOUT 08:10:23:785 device state timeout ignored in state 3 08:10:23:786 enqueue event config/localtime for /config/ 08:10:23:786 Idle timer triggered 08:10:23:787 Force read attributes for ZHAPressure SensorNode MS AqaraWZ 08:10:23:787 don't create binding for attribute reporting of sensor MS AqaraWZ 08:10:23:788 Force binding of attribute reporting for node MS AqaraWZ 08:10:24:784 enqueue event config/localtime for /config/ 08:10:24:785 Wait 1s till query finished 08:10:25:785 enqueue event config/localtime for /config/ 08:10:25:785 Wait 0s till query finished 08:10:26:784 Daylight now: sunriseEnd, status: 150, daylight: 0, dark: 0 08:10:26:785 void zmMaster::handleStateStatus(zmMaster::MasterEvent) EVENT_TIMEOUT 08:10:26:785 device state timeout ignored in state 3 08:10:26:786 enqueue event config/localtime for /config/ 08:10:26:786 Idle timer triggered 08:10:26:787 binding for attribute reporting of ep: 0x01 cluster 0x0405 seems to be active 08:10:26:787 Force binding of attribute reporting for node MS Schlafzimmer 08:10:27:784 enqueue event config/localtime for /config/ 08:10:27:784 Idle timer triggered 08:10:27:784 Force read attributes for ZHAPressure SensorNode MS AqaraBalkon 08:10:27:784 don't create binding for attribute reporting of sensor MS AqaraBalkon 08:10:27:784 Force binding of attribute reporting for node MS AqaraBalkon 08:10:28:784 enqueue event config/localtime for /config/ 08:10:28:785 Wait 1s till query finished 08:10:29:784 void zmMaster::handleStateStatus(zmMaster::MasterEvent) EVENT_TIMEOUT 08:10:29:784 device state timeout ignored in state 3 08:10:29:784 enqueue event config/localtime for /config/ 08:10:29:784 Idle timer triggered 08:10:29:784 Force read attributes for ZHAHumidity SensorNode MS AqaraBalkon 08:10:29:785 don't create binding for attribute reporting of sensor MS AqaraBalkon 08:10:29:785 Force binding of attribute reporting for node MS AqaraBalkon 08:10:30:784 enqueue event config/localtime for /config/ 08:10:30:784 Wait 1s till query finished 08:10:31:784 enqueue event config/localtime for /config/ 08:10:31:784 Idle timer triggered 08:10:31:784 binding for attribute reporting of ep: 0x01 cluster 0x0405 seems to be active 08:10:31:784 Force binding of attribute reporting for node MS Tiefkühlfach 08:10:32:784 void zmMaster::handleStateStatus(zmMaster::MasterEvent) EVENT_TIMEOUT 08:10:32:784 device state timeout ignored in state 3 08:10:32:784 enqueue event config/localtime for /config/ 08:10:32:785 Idle timer triggered 08:10:32:785 binding for attribute reporting of ep: 0x01 cluster 0x0405 seems to be active 08:10:32:785 Force binding of attribute reporting for node MS Arbeitszimmer 08:10:33:784 enqueue event config/localtime for /config/ 08:10:33:784 Idle timer triggered 08:10:33:784 binding for attribute reporting of ep: 0x02 cluster 0x0001 seems to be active 08:10:33:784 binding for attribute reporting of ep: 0x02 cluster 0xFC00 seems to be active 08:10:33:784 Force binding of attribute reporting for node SW Wohnzimmer Dimmschalter 08:10:34:784 enqueue event config/localtime for /config/ 08:10:34:784 Idle timer triggered 08:10:34:785 Force read attributes for ZHATemperature SensorNode MS AqaraWZ 08:10:34:785 don't create binding for attribute reporting of sensor MS AqaraWZ 08:10:34:785 Force binding of attribute reporting for node MS AqaraWZ 08:10:35:784 void zmMaster::handleStateStatus(zmMaster::MasterEvent) EVENT_TIMEOUT 08:10:35:784 device state timeout ignored in state 3 08:10:35:785 enqueue event config/localtime for /config/ 08:10:35:785 Wait 1s till query finished 08:10:36:784 Daylight now: sunriseEnd, status: 150, daylight: 0, dark: 0 08:10:36:784 enqueue event config/localtime for /config/ 08:10:36:784 Idle timer triggered 08:10:36:785 Force read attributes for ZHAPressure SensorNode MS AqaraWZ 08:10:36:785 don't create binding for attribute reporting of sensor MS AqaraWZ 08:10:36:785 Force binding of attribute reporting for node MS AqaraWZ 08:10:37:784 enqueue event config/localtime for /config/ 08:10:37:784 Wait 1s till query finished 08:10:38:784 void zmMaster::handleStateStatus(zmMaster::MasterEvent) EVENT_TIMEOUT 08:10:38:784 device state timeout ignored in state 3 08:10:38:784 enqueue event config/localtime for /config/ 08:10:38:785 Idle timer triggered 08:10:38:785 binding for attribute reporting of ep: 0x01 cluster 0x0405 seems to be active 08:10:38:785 Force binding of attribute reporting for node MS Schlafzimmer 08:10:39:784 enqueue event config/localtime for /config/ 08:10:39:785 Idle timer triggered 08:10:39:785 Force read attributes for ZHAPressure SensorNode MS AqaraBalkon 08:10:39:785 don't create binding for attribute reporting of sensor MS AqaraBalkon 08:10:39:785 Force binding of attribute reporting for node MS AqaraBalkon 08:10:40:784 enqueue event config/localtime for /config/ 08:10:40:784 Wait 1s till query finished 08:10:41:784 void zmMaster::handleStateStatus(zmMaster::MasterEvent) EVENT_TIMEOUT 08:10:41:784 device state timeout ignored in state 3 08:10:41:784 enqueue event config/localtime for /config/ 08:10:41:785 Idle timer triggered 08:10:41:785 Force read attributes for ZHAHumidity SensorNode MS AqaraBalkon 08:10:41:785 don't create binding for attribute reporting of sensor MS AqaraBalkon 08:10:41:785 Force binding of attribute reporting for node MS AqaraBalkon 08:10:44:784 void zmMaster::handleStateStatus(zmMaster::MasterEvent) EVENT_TIMEOUT 08:10:44:784 device state timeout ignored in state 3 08:10:47:784 void zmMaster::handleStateStatus(zmMaster::MasterEvent) EVENT_TIMEOUT 08:10:47:785 device state timeout (handled) 08:10:47:785 0x0017880106B0F0B4 error APSDE-DATA.confirm: 0xAE on task 08:10:47:808 device disconnected reason: 1, index: 0 08:10:47:816 device disconnected reason: 1, index: 1 08:10:47:916 aps request id: 142 prf: 0x0000 cl: 0x0031 timeout NOT confirmed to 0x842E14FFFE231B4D (0x8513) 08:10:48:784 wait reconnect 15 seconds 08:10:49:285 void zmMaster::handleStateIdle(zmMaster::MasterEvent) not connected goto OFF state 08:10:49:285 device state timeout ignored in state 1 08:10:49:784 wait reconnect 14 seconds 08:10:50:784 wait reconnect 13 seconds 08:10:51:785 wait reconnect 12 seconds 08:10:52:784 wait reconnect 11 seconds 08:10:53:785 wait reconnect 10 seconds 08:10:54:784 wait reconnect 9 seconds 08:10:55:785 wait reconnect 8 seconds 08:10:56:785 wait reconnect 7 seconds 08:10:57:785 wait reconnect 6 seconds 08:10:58:785 wait reconnect 5 seconds 08:10:59:784 wait reconnect 4 seconds 08:11:00:784 wait reconnect 3 seconds 08:11:01:784 wait reconnect 2 seconds 08:11:02:784 wait reconnect 1 seconds 08:11:02:811 COM check bootloader 08:11:02:824 COM detected application 08:11:02:845 Device firmware version 0x26680700 ConBee II 08:11:02:849 unlocked max nodes: 200 08:11:02:921 Device protocol version: 0x010E 08:11:02:994 Current channel 25 08:11:03:006 CTRL got nwk update id 3 08:11:03:010 CTRL ANT_CTRL 0x03 08:11:03:034 CTRL got stack debug assert code: 0x201D, type: 0x03 08:11:03:039 Device protocol version: 0x010E 08:11:03:105 Current channel 25 08:11:03:117 CTRL got nwk update id 3 08:11:03:121 CTRL ANT_CTRL 0x03 08:11:03:145 CTRL got stack debug assert code: 0x201D, type: 0x03 08:11:03:167 [INFO] - No button map for: lumi.weather endpoint: 0x01 cluster: 0x0402 command: 0x0A payload[0]: 000 08:11:03:167 ZCL attribute report 0x00158D00046574A8 for cluster: 0x0402, ep: 0x01, frame control: 0x18, mfcode: 0x0000 08:11:06:804 Current channel 25 08:11:06:814 CTRL got nwk update id 3 08:11:06:818 Device TTL 3565 s flags: 0x7

Additional context

Smanar commented 3 years ago

Hello, are you using a new device ? If yes, (or if no, you can too do it) please force a firmware update using command line https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Update-deCONZ-manually

And try to avoid USB 3.0

MrWGT commented 3 years ago

No, it's not a new device. Firmware is updated to latest one. Just moved from raspi 4b to "China Celeron" (= power on problem, different story 😂) and since Christmas a intel nuc8i5beh. This device only offers USB3.

Tried to follow different guides from internet and disabled modemmanager, tried to disable xhci and force ehci. But devices had no ehci with setpci... 😐

Cable for internal USB2 already ordered.

But... Conbee2 should work on USB3 also... 😏

MrWGT commented 3 years ago

Some news... After having many problems with usb disconnects they stopped suddenly without (obvious) reason. dmesg-Log:

[So Jan 24 08:10:25 2021] cdc_acm 3-1.1:1.0: ttyACM0: USB ACM device
[So Jan 24 08:10:28 2021] usb 3-1.1: USB disconnect, device number 67
[So Jan 24 08:10:29 2021] usb 3-1.1: new full-speed USB device number 68 using xhci_hcd
[So Jan 24 08:10:29 2021] usb 3-1.1: New USB device found, idVendor=1cf1, idProduct=0030, bcdDevice= 1.00
[So Jan 24 08:10:29 2021] usb 3-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[So Jan 24 08:10:29 2021] usb 3-1.1: Product: ConBee II
[So Jan 24 08:10:29 2021] usb 3-1.1: Manufacturer: dresden elektronik ingenieurtechnik GmbH
[So Jan 24 08:10:29 2021] usb 3-1.1: SerialNumber: DE2192922
[So Jan 24 08:10:29 2021] cdc_acm 3-1.1:1.0: ttyACM0: USB ACM device
[So Jan 24 08:21:36 2021] xhci_hcd 0000:3a:00.0: WARN Cannot submit Set TR Deq Ptr
[So Jan 24 08:21:36 2021] xhci_hcd 0000:3a:00.0: A Set TR Deq Ptr command is pending.
[So Jan 24 08:21:36 2021] xhci_hcd 0000:3a:00.0: WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state.
[So Jan 24 08:21:36 2021] usb 3-1.1: USB disconnect, device number 68
[So Jan 24 08:21:36 2021] cdc_acm 3-1.1:1.0: failed to set dtr/rts
[So Jan 24 08:21:36 2021] usb 3-1.1: new full-speed USB device number 69 using xhci_hcd
[So Jan 24 08:21:37 2021] usb 3-1.1: New USB device found, idVendor=1cf1, idProduct=0030, bcdDevice= 1.00
[So Jan 24 08:21:37 2021] usb 3-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[So Jan 24 08:21:37 2021] usb 3-1.1: Product: ConBee II
[So Jan 24 08:21:37 2021] usb 3-1.1: Manufacturer: dresden elektronik ingenieurtechnik GmbH
[So Jan 24 08:21:37 2021] usb 3-1.1: SerialNumber: DE2192922
[So Jan 24 08:21:37 2021] cdc_acm 3-1.1:1.0: ttyACM1: USB ACM device
[So Jan 24 08:21:40 2021] usb 3-1.1: USB disconnect, device number 69
[So Jan 24 08:21:40 2021] usb 3-1.1: new full-speed USB device number 70 using xhci_hcd
[So Jan 24 08:21:40 2021] usb 3-1.1: New USB device found, idVendor=1cf1, idProduct=0030, bcdDevice= 1.00
[So Jan 24 08:21:40 2021] usb 3-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[So Jan 24 08:21:40 2021] usb 3-1.1: Product: ConBee II
[So Jan 24 08:21:40 2021] usb 3-1.1: Manufacturer: dresden elektronik ingenieurtechnik GmbH
[So Jan 24 08:21:40 2021] usb 3-1.1: SerialNumber: DE2192922
[So Jan 24 08:21:40 2021] cdc_acm 3-1.1:1.0: ttyACM1: USB ACM device
[So Jan 24 08:28:32 2021] perf: interrupt took too long (3191 > 3141), lowering kernel.perf_event_max_sample_rate to 62500
[So Jan 24 12:55:06 2021] perf: interrupt took too long (4003 > 3988), lowering kernel.perf_event_max_sample_rate to 49750
[So Jan 24 15:43:47 2021] e1000e: eno1 NIC Link is Down
[So Jan 24 15:43:58 2021] e1000e: eno1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
[So Jan 24 19:19:59 2021] perf: interrupt took too long (5042 > 5003), lowering kernel.perf_event_max_sample_rate to 39500
[So Jan 24 23:59:59 2021] kauditd_printk_skb: 15 callbacks suppressed
[So Jan 24 23:59:59 2021] audit: type=1400 audit(1611529201.928:27): apparmor="DENIED" operation="capable" profile="/usr/sbin/cups-browsed" pid=951849 comm="cups-browsed" capability=23  capname="sys_nice"
[Mo Jan 25 07:31:19 2021] perf: interrupt took too long (6274 > 6250), lowering kernel.perf_event_max_sample_rate to 6250
[Mo Jan 25 23:59:57 2021] audit: type=1400 audit(1611615601.754:28): apparmor="DENIED" operation="capable" profile="/usr/sbin/cups-browsed" pid=1618598 comm="cups-browsed" capability=23  capname="sys_nice"

As you can the there are entries from the perf system:

[So Jan 24 08:28:32 2021] perf: interrupt took too long (3191 > 3141), lowering kernel.perf_event_max_sample_rate to 62500
[So Jan 24 12:55:06 2021] perf: interrupt took too long (4003 > 3988), lowering kernel.perf_event_max_sample_rate to 49750
...
[So Jan 24 19:19:59 2021] perf: interrupt took too long (5042 > 5003), lowering kernel.perf_event_max_sample_rate to 39500

Since this date no further usb disconnects occured. Maybe the perf system is influencing the usb disconnects?!? Therefore i modified perf parameters perf_cpu_time_max_percent 25 -> 5 perf_event_max_sample_rate ?!? -> 5000 . Now it looks like:

hoobs@awow:~$ sudo sysctl -a |grep perf
dev.i915.perf_stream_paranoid = 1
kernel.perf_cpu_time_max_percent = 5
kernel.perf_event_max_contexts_per_stack = 8
kernel.perf_event_max_sample_rate = 5000
kernel.perf_event_max_stack = 127
kernel.perf_event_mlock_kb = 516
kernel.perf_event_paranoid = 3

I inserted that parameters also to my /etc/sysctl.conf

hoobs@awow:~$ cat /etc/sysctl.conf
#
# /etc/sysctl.conf - Configuration file for setting system variables
# See /etc/sysctl.d/ for additional system variables.
# See sysctl.conf (5) for information.
#
kernel.perf_cpu_time_max_percent=5
kernel.perf_event_max_sample_rate=5000

#kernel.domainname = example.com
...

Maybe some others with usb disconnect can try it and give a positive answer?!?

SwoopX commented 3 years ago

Hm, intetesting observation. I'm running a rather comparable setup in my dev environment (NUC -> Ubuntu VM). Never had any disconnects or trouble though...

However, in turn, it would presumably mean that significantly lowering that value results in disconnects again. Happy to check my values later.

MrWGT commented 3 years ago

If I understand it correctly kernel.perf_cpu_time_max_percent is the amount of CPU time the perf system is allowed to use. So going from 25 to 5% gives under some conditions 20% more CPU time to other apps.

MrWGT commented 3 years ago

Linux kernel tracks of how long perf's non-maskable interrupt(NMI) handler is performing. If the sample duration exceeds a configurable threshold(perf_cpu_time_max_percent), it drops the sample rate. This allows to prevent system from hanging because it spends all of its time handling sampling process.

https://stackoverflow.com/questions/49807213/maximum-sampling-frequency-supported-by-perf

So if perf nmi is higher than usb c irq maybe xhci is missing data? At least on a embedded CPU a nmi blocks other interrupts.

SwoopX commented 3 years ago

That's my VM's data:

kernel.perf_cpu_time_max_percent = 25
kernel.perf_event_max_contexts_per_stack = 8
kernel.perf_event_max_sample_rate = 100000
kernel.perf_event_max_stack = 127
kernel.perf_event_mlock_kb = 516
kernel.perf_event_paranoid = 3
MrWGT commented 3 years ago

That's my VM's data: kernel.perf_event_max_sample_rate = 100000

Looks like the vm never decreases the sample rate. Maybe I should run deconz in a vm 😅

But maybe due to running in a vm the "normal os" in background is fast enough to catch the irqs?

And running directly on Linux blocks hardware/kernel module?

manup commented 3 years ago

Cool, that are interesting findings.

Here is the output on my Arch box and on a Intel NUC i7-6770HQ CPU @ 2.60GHz In this setup various ConBee I and II work flawlessly.

kernel.perf_cpu_time_max_percent = 25
kernel.perf_event_max_contexts_per_stack = 8
kernel.perf_event_max_sample_rate = 32400
kernel.perf_event_max_stack = 127
kernel.perf_event_mlock_kb = 516
kernel.perf_event_paranoid = 2
MrWGT commented 3 years ago

The above mentioned perf parameters might have an influcence. But still had usb disconnects. Now i've solved my problems in my intel NUC8i5BEH.

1) Used thunderbolt connector with USBC -> A adapter. Result was less disconnects 2) Bought good shielded 3m USB3 cable instead of old USB2 cable. Result: no difference 3) Moved conbee 2 further away from wifi ap (2m -> 3m). Result: less disconnects 4) added click on ferrites onto usb cable. Result: no difference 5) connected wireless dongle (2.4GHz) for mouse/keyboard over usb cable (~1m) instead of directly on nuc near usb3 or thunderbold connectors. Result: no disconnects since 3 days!.

So it looks like that the conbee 2 and/or the usb3/thunderbolt ports are sensitive for 2.4GHz signals. As the thunderbold connector is further away from (old position) keyboard/mouse dongle and using thunderbold port reduced the disconnects. The real problem might be the 2.4GHz dongle nearby the usb3 port used for conbee 2.

Maybe someone with disconnect problems could try:

a) Detach keyboard/mouse dongles from computer with cable b) Make sure conbee 2 is as far away from 2.4GHz signals (aps, laptop wifi...) as possible. Detach it with e.g. 3m good USB3 cable. c) if still disconnects: Add clip on ferrites onto USB3 cable used for conbee 2.

SwoopX commented 3 years ago

You probably shouldn't take my setup as any reference, but for what it's worth:

Got the same NUC, the stick is connected to the front USB next to the power switch. Wifi and BT is always on, Mouse/Keyboard is connected at the back (through a USB port replicator right next to the NUC, mouse is wireless). My AP, however, is in another room and this is my dev network only.

MrWGT commented 3 years ago

Hm... Maybe you can try to connect your wireless mouse dongle left from the Conbee2?

I had to detach the conbee with cable because inside my TV lowboard there was a bad reception. And probably 2.4GHz is distorting the usb signal on cable?!?

Anyway... Now it works for me

denwald commented 3 years ago

I'm having a similar problem on the Rapsberry Pi 4 as well as on a Raspberry Pi 3B+, both running the lates stable release of Raspbian 10. I should note that I tested the Conbee II stick without Deconz actually being installed on the Pis. But I can do that this weekend as well if running the stick without Deconz could cause the Stick to loose the USB connection. I started testing the stick because I was having connection problems with Deconz and wanted to rule out hardware issues with the Raspberry USB connection.

Some things I have already tried:

I'm not sure if I should maybe open a new issue. Please let me know.

There is an excerpt from the kern.log output attached which looks very similar to the one shown at the top of this issue.

Feb 13 13:50:16 raspberrypi kernel: [ 9235.383219] usb 1-1.4: USB disconnect, device number 26 Feb 13 13:50:16 raspberrypi kernel: [ 9235.679482] usb 1-1.4: new full-speed USB device number 27 using xhci_hcd Feb 13 13:50:16 raspberrypi kernel: [ 9235.818232] usb 1-1.4: New USB device found, idVendor=1cf1, idProduct=0030, bcdDevice= 1.00 Feb 13 13:50:16 raspberrypi kernel: [ 9235.818243] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Feb 13 13:50:16 raspberrypi kernel: [ 9235.818250] usb 1-1.4: Product: ConBee II Feb 13 13:50:16 raspberrypi kernel: [ 9235.818258] usb 1-1.4: Manufacturer: dresden elektronik ingenieurtechnik GmbH Feb 13 13:50:16 raspberrypi kernel: [ 9235.818265] usb 1-1.4: SerialNumber: DE0000000 Feb 13 13:50:16 raspberrypi kernel: [ 9235.822927] cdc_acm 1-1.4:1.0: ttyACM0: USB ACM device Feb 13 13:50:19 raspberrypi kernel: [ 9239.223709] usb 1-1.4: USB disconnect, device number 27 Feb 13 13:50:20 raspberrypi kernel: [ 9239.519609] usb 1-1.4: new full-speed USB device number 28 using xhci_hcd Feb 13 13:50:20 raspberrypi kernel: [ 9239.668578] usb 1-1.4: New USB device found, idVendor=1cf1, idProduct=0030, bcdDevice= 1.00 Feb 13 13:50:20 raspberrypi kernel: [ 9239.668599] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Feb 13 13:50:20 raspberrypi kernel: [ 9239.668615] usb 1-1.4: Product: ConBee II Feb 13 13:50:20 raspberrypi kernel: [ 9239.668630] usb 1-1.4: Manufacturer: dresden elektronik ingenieurtechnik GmbH Feb 13 13:50:20 raspberrypi kernel: [ 9239.668645] usb 1-1.4: SerialNumber: DE0000000 Feb 13 13:50:20 raspberrypi kernel: [ 9239.673465] cdc_acm 1-1.4:1.0: ttyACM0: USB ACM device

kern.log.txt

MrWGT commented 3 years ago

Used a raspi 4b before and had problems with usb3. Used one of the usb2 ports and a 2m usb2 cable to detach the conbee 2 from raspi. Problems were gone.

Smanar commented 3 years ago

But on you issue description, you have said using the extension cable. With extension and USB 3.0, still have the issue ?

denwald commented 3 years ago

I know about the problems with USB 3 ports. Haven't used them on the Pi 4B. I also tested with a Raspberry Pi 3 which only has USB 2, same problem. Disconnects every 5 minutes.

Smanar commented 3 years ago

Can be the device too. You can make a try on a PC machine ? A windows one ? it s the machine with the less issues. If it don't work on Windows with firmware re-uploaded (made on windows too), there is not a lot of more thing to try.

But the disconnection is faster than 5mn for this kind of issue, on windows you can listen the usb disconnection sound realy faster (on your previous log it s 4s)

denwald commented 3 years ago

I also have a lot of the following errors in Deconz:

11:07:46:450 0x14B457FFFE43A3F6 error APSDE-DATA.confirm: 0xE1 on task

Could be, that the stick is broken somwhow. It's just strange, that it seems to boot up and communicate with deconz-rest-plugin and phoscon.

denwald commented 3 years ago

I'm back to a working setup. I was able to set up the stick from scratch inside a Windows 10 VM using the Deconz software package. After that I tried it again in my Raspberry Pi 4, but this time in the second (upper) USB2 Port. Now it works again, though for some reason I had to reconnect a couple of IKEA lights.

I'm glad it works again. But to be honest I'm still not sure what did the trick. Was it activating the stick in Windows, or just switching to the other USB2 port? It's very mysterious.

Anyways, thanks for the help.

Smanar commented 3 years ago

11:07:46:450 0x14B457FFFE43A3F6 error APSDE-DATA.confirm: 0xE1 on task

Is generaly "perturbations" issue, can come from USB 3.0 (or other devices/wireless output), the extension cable make miracle for it. But it s no more a "USB disconnection issue".

github-actions[bot] commented 3 years ago

As there has not been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.

github-actions[bot] commented 3 years ago

As there has not been any response in 28 days, this issue will be closed. @ OP: If this issue is solved post what fixed it for you. If it is not solved, request to get this opened again.