operating-system
operating-system copied to clipboard
home-assistant
Hassos in QEMU KVM (virsh): Attached device disappears when Home Assistant core starts
Describe the issue you are experiencing
I've been having an issue for a while that sometimes when Home Assistant Core (re)starts (for instance after installing an Home Assistant OS update or an Home Assistant update), an attached serial device (which is my Conbee II stick) disappears.
The device is registered in kvm-xml like this:
<serial type='dev'>
<source path='/dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2292445-if00'/>
<target type='usb-serial' port='2'>
<model name='usb-serial'/>
</target>
<address type='usb' bus='0' port='5'/>
</serial>
What operating system image do you use?
ova (for Virtual Machines)
What version of Home Assistant Operating System is installed?
10.5
Did you upgrade the Operating System.
Yes
Steps to reproduce the issue
Have a qemu KVM with a serial device attached (like a Conbee II)
- Log onto the console of the OS (
virsh console [domain]) - Restart Home Assistant Core or restart the OS
- As soon as you get control, log in (
root) and runls /dev/serial/by-id. - Note the device node for the serial device is populated
- When Home Assistant Core (or Supervisor, I truly don't know) starts loading eventually the device node disappears, and running
lsyields:ls: /dev/serial/by-id/: No such file or directory
Anything in the Supervisor logs that might be useful for us?
I don't see anything that seems to be correlating to this issue.
Anything in the Host logs that might be useful for us?
# dmesg | grep -i serial
[ 2.165337] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[ 2.499142] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 2.520759] usb usb1: SerialNumber: 0000:00:03.7
[ 2.635744] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 2.647092] usb usb2: SerialNumber: 0000:00:03.0
[ 2.726730] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 2.735359] usb usb3: SerialNumber: 0000:00:03.1
[ 2.811844] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 2.820184] usb usb4: SerialNumber: 0000:00:03.2
[ 2.836887] usbcore: registered new interface driver usbserial_generic
[ 2.841118] usbserial: USB Serial support registered for generic
[ 3.238346] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=4
[ 3.241790] usb 4-1: Product: QEMU USB SERIAL
[ 3.245945] usb 4-1: SerialNumber: 1-0000:00:03.7-5
[ 4.639597] systemd[1]: Created slice Slice /system/serial-getty.
[ 7.339063] usbserial: USB Serial support registered for FTDI USB Serial Device
[ 7.339117] ftdi_sio 4-1:1.0: FTDI USB Serial Device converter detected
[ 7.344009] usb 4-1: FTDI USB Serial Device converter now attached to ttyUSB0
[ 135.274254] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[ 491.723616] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=4
[ 491.723621] usb 2-2: Product: QEMU USB SERIAL
[ 491.723628] usb 2-2: SerialNumber: 1-0000:00:03.7-2
[ 491.725961] ftdi_sio 2-2:1.0: FTDI USB Serial Device converter detected
[ 491.728163] usb 2-2: FTDI USB Serial Device converter now attached to ttyUSB0
### System information
System Information
| version | core-2023.9.2 |
|---|---|
| installation_type | Home Assistant OS |
| dev | false |
| hassio | true |
| docker | true |
| user | root |
| virtualenv | false |
| python_version | 3.11.5 |
| os_name | Linux |
| os_version | 6.1.45 |
| arch | x86_64 |
| timezone | Europe/Amsterdam |
| config_dir | /config |
Home Assistant Community Store
| GitHub API | ok |
|---|---|
| GitHub Content | ok |
| GitHub Web | ok |
| GitHub API Calls Remaining | 4712 |
| Installed Version | 1.32.1 |
| Stage | running |
| Available Repositories | 1284 |
| Downloaded Repositories | 44 |
Home Assistant Cloud
| logged_in | false |
|---|---|
| can_reach_cert_server | ok |
| can_reach_cloud_auth | ok |
| can_reach_cloud | ok |
Home Assistant Supervisor
| host_os | Home Assistant OS 10.5 |
|---|---|
| update_channel | stable |
| supervisor_version | supervisor-2023.09.2 |
| agent_version | 1.5.1 |
| docker_version | 23.0.6 |
| disk_total | 30.8 GB |
| disk_used | 27.2 GB |
| healthy | true |
| supported | true |
| board | ova |
| supervisor_api | ok |
| version_api | ok |
| installed_addons | Samba share (10.0.2), Node-RED (14.5.0), Portainer (1.3.0), File editor (5.6.0), Log Viewer (0.15.1), AdGuard Home (4.8.15), Advanced SSH & Web Terminal (15.0.8), Network UPS Tools (0.12.1), Mosquitto broker (6.3.1), RPC Shutdown (2.4), InfluxDB (4.7.0), Grafana (9.0.3), EMHASS (0.4.0) |
Dashboards
| dashboards | 3 |
|---|---|
| resources | 24 |
| views | 17 |
| mode | storage |
Recorder
| oldest_recorder_run | 11 september 2023 om 14:59 |
|---|---|
| current_recorder_run | 16 september 2023 om 13:27 |
| estimated_db_size | 4336.39 MiB |
| database_engine | sqlite |
| database_version | 3.41.2 |
Additional information
I currently work around this issue as follows:
- I have a separate conbee.xml device config ready:
<serial type='dev'>
<source path='/dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2292445-if00'/>
<target type='usb-serial' port='3'>
<model name='usb-serial'/>
</target>
<address type='usb' bus='0' port='2'/>
</serial>
- When the issue happens again, I run
sudo virsh attach-device hassos --config conbee-serial.xml --live - Then in hassos itself (
sudo virsh console hassos):- I list the new node in
/dev/serial/by-id/ - And symlink it to the location it is supposed to be (
ln -s usb-QEMU_QEMU_USB_SERIAL_1-0000:00:03.7-2-if00-port0 usb-QEMU_QEMU_USB_SERIAL_1-0000:00:03.7-5-if00-port0) - And then I reload the Zigbee integration
- I list the new node in
This issue has been happening for a while now, but I haven't reported it in hoping someone else had 😄
Key in de logging messages seems to be:
[ 7.339063] usbserial: USB Serial support registered for FTDI USB Serial Device
[ 7.339117] ftdi_sio 4-1:1.0: FTDI USB Serial Device converter detected
[ 7.344009] usb 4-1: FTDI USB Serial Device converter now attached to ttyUSB0
[ 135.274254] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
I had hoped it would be related to brltty but that doesn't seem to be included in hassos.
More information: Also happens on some core upgrades, dmesg -W:
[547142.559507] audit: type=1300 audit(1697121742.867:1279): arch=c000003e syscall=321 success=yes exit=15 a0=5 a1=c00018d7f8 a2=78 a3=0 items=0 ppid=1428606 pid=1428617 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="runc" exe="/usr/bin/runc" subj=unconfined key=(null)
[547142.559524] audit: type=1327 audit(1697121742.867:1279): proctitle=72756E63002D2D726F6F74002F7661722F72756E2F646F636B65722F72756E74696D652D72756E632F6D6F6279002D2D6C6F67002F72756E2F636F6E7461696E6572642F696F2E636F6E7461696E6572642E72756E74696D652E76322E7461736B2F6D6F62792F34633964356339363134373832633333653838393633376364
[547142.559833] audit: type=1334 audit(1697121742.869:1280): prog-id=538 op=LOAD
[547142.559914] audit: type=1300 audit(1697121742.869:1280): arch=c000003e syscall=321 success=yes exit=17 a0=5 a1=c00018d590 a2=78 a3=0 items=0 ppid=1428606 pid=1428617 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="runc" exe="/usr/bin/runc" subj=unconfined key=(null)
[547142.559927] audit: type=1327 audit(1697121742.869:1280): proctitle=72756E63002D2D726F6F74002F7661722F72756E2F646F636B65722F72756E74696D652D72756E632F6D6F6279002D2D6C6F67002F72756E2F636F6E7461696E6572642F696F2E636F6E7461696E6572642E72756E74696D652E76322E7461736B2F6D6F62792F34633964356339363134373832633333653838393633376364
[547142.559941] audit: type=1334 audit(1697121742.869:1281): prog-id=538 op=UNLOAD
[547142.560937] audit: type=1334 audit(1697121742.870:1282): prog-id=537 op=UNLOAD
[547142.561367] audit: type=1334 audit(1697121742.870:1283): prog-id=539 op=LOAD
[547142.561481] audit: type=1300 audit(1697121742.870:1283): arch=c000003e syscall=321 success=yes exit=15 a0=5 a1=c00018da50 a2=78 a3=0 items=0 ppid=1428606 pid=1428617 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="runc" exe="/usr/bin/runc" subj=unconfined key=(null)
[547245.758058] kauditd_printk_skb: 1 callbacks suppressed
[547245.758534] audit: type=1334 audit(1697121846.057:1284): prog-id=86 op=UNLOAD
[547272.788019] usb 4-2: USB disconnect, device number 3
[547272.813455] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[547272.813613] ftdi_sio 4-2:1.0: device disconnected
After attaching via virsh:
[550088.215472] usb 3-2: new full-speed USB device number 2 using uhci_hcd
[550088.392672] usb 3-2: New USB device found, idVendor=0403, idProduct=6001, bcdDevice= 4.00
[550088.392704] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=4
[550088.393699] usb 3-2: Product: QEMU USB SERIAL
[550088.395120] usb 3-2: Manufacturer: QEMU
[550088.395681] usb 3-2: SerialNumber: 1-0000:00:03.7-4
[550088.404148] ftdi_sio 3-2:1.0: FTDI USB Serial Device converter detected
[550088.404965] usb 3-2: Detected FT232B
[550088.408480] usb 3-2: FTDI USB Serial Device converter now attached to ttyUSB0
After symlinking and reloading the configuration everything works again.
I think this seems to be resolved with latest stable. I'm investigating further.
I have the same issue with Conbee II disappearing from KVM (device disappears from /dev/serial/by-id).
On HAOS Start (within KVM) dmesg shows: [ 6.188198] usb 4-1: new full-speed USB device number 2 using uhci_hcd [ 6.509470] usb 4-1: New USB device found, idVendor=0403, idProduct=6001, bcdDevice= 4.00 [ 6.525851] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=4 [ 6.532049] usb 4-1: Product: QEMU USB SERIAL [ 6.546725] usb 4-1: Manufacturer: QEMU [ 6.561460] usb 4-1: SerialNumber: 1-0000:00:03.7-5
On HomeAssistant Restart dmesg shows: [ 2853.873667] ftdi_sio ttyUSB0: usb_serial_generic_write_bulk_callback - nonzero urb status: -71 [ 2853.890671] usb 4-1: USB disconnect, device number 2 [ 2853.891772] ftdi_sio ttyUSB0: error from flowcontrol urb
My only working workaround is qemu restart.
Thanks, I thought I was getting crazy. Still, after reboot of the VM I need to re-attach the virtual device.
Still happens on OS v11.4.
Temporary workaround:
fix-conbee.sh
echo "Detaching device"
sudo virsh detach-device hassos conbee-serial.xml
echo "... sleeping"
sleep 1
echo "Attaching device"
sudo virsh attach-device hassos conbee-serial.xml
echo "Please reload Zigbee integration manua
Execute with sudo ./fix-conbee.sh (make executable first with chmod +x and change VM name as necessary)
I have read somewhere that xhci usb emulation is much more robust in qemu than ehci/uhci which seems to be used by default in my virtual machine config.
By default I've had: [ 2.350504] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 6.01 [ 2.354481] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 2.358133] usb usb1: Product: EHCI Host Controller [ 2.360039] usb usb1: Manufacturer: Linux 6.1.71-haos ehci_hcd [ 2.362310] usb usb1: SerialNumber: 0000:00:03.7 [ 2.430748] usb usb2: New USB device found, idVendor=1d6b, idProduct=0001, bcdDevice= 6.01 [ 2.435055] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 2.438883] usb usb2: Product: UHCI Host Controller [ 2.441357] usb usb2: Manufacturer: Linux 6.1.71-haos uhci_hcd [ 2.444154] usb usb2: SerialNumber: 0000:00:03.0 [ 2.513045] usb usb3: New USB device found, idVendor=1d6b, idProduct=0001, bcdDevice= 6.01 [ 2.517262] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 2.521209] usb usb3: Product: UHCI Host Controller [ 2.523699] usb usb3: Manufacturer: Linux 6.1.71-haos uhci_hcd [ 2.526826] usb usb3: SerialNumber: 0000:00:03.1 [ 2.596409] usb usb4: New USB device found, idVendor=1d6b, idProduct=0001, bcdDevice= 6.01 [ 2.600934] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 2.605200] usb usb4: Product: UHCI Host Controller [ 2.607414] usb usb4: Manufacturer: Linux 6.1.71-haos uhci_hcd [ 2.610367] usb usb4: SerialNumber: 0000:00:03.2 [ 2.618121] usbcore: registered new interface driver usblp [ 2.621136] usbcore: registered new interface driver usb-storage [ 2.623994] usbcore: registered new interface driver usbserial_generic [ 2.626980] usbserial: USB Serial support registered for generic [ 2.680829] usbcore: registered new interface driver usbhid [ 2.683574] usbhid: USB HID core driver [ 2.842364] usb 4-1: new full-speed USB device number 2 using uhci_hcd [ 3.026227] usb 4-1: New USB device found, idVendor=0403, idProduct=6001, bcdDevice= 4.00 [ 3.035213] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=4 [ 3.039501] usb 4-1: Product: QEMU USB SERIAL [ 3.041739] usb 4-1: Manufacturer: QEMU [ 3.044049] usb 4-1: SerialNumber: 1-0000:00:03.7-5 [ 9.319813] usbcore: registered new interface driver ftdi_sio [ 9.325599] usbserial: USB Serial support registered for FTDI USB Serial Device [ 9.333765] usb 4-1: Detected FT232B [ 9.338571] usb 4-1: FTDI USB Serial Device converter now attached to ttyUSB0
I was trying to use
<controller type='usb' index='0' model='nec-xhci' ports='15' />
instead of whatever I've had there in the config related to usb emulation.
Conbee was visible in /dev/serial/by-id but it seems ZHA could not communicate with it ( "2024-01-16 19:28:32.882 DEBUG (MainThread) [zigpy_deconz.api] No response to 'CommandId.read_parameter' command with seq 1").
Maybe I'm doing something wrong with this xhci. Maybe someone with more experience with qemu could check if the issue we are experiencing here are not related to the usb emulation used.
Happened again after installing that 2024.1.4 Home Assistant Core update, without rebooting the OS/VM:
[ 1223.340769] usb 4-1: USB disconnect, device number 2
[ 1223.340959] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[ 1223.340990] ftdi_sio 4-1:1.0: device disconnected
I've had this same issue randomly. Initially it would happen on random HA restarts. Then every HA restart. Now even while HA is running randomly it happens.
It does not appear to be an issue with HA or KVM. I see the disconnects/reconnects for my Conbee II in my host /var/log/messages. If HA wasn't virtualized it would recover on it's own from these but since it's not manual intervention is required. It's only my Conbee II doing this, other USB devices aren't disconnecting/reconnecting. This appears to be a commonly reported issue with these Conbee II devices. I tried upgrading the firmware which seems to either made no difference or maybe made the issue worse.
At this point I think the resolution is to replace the Conbee II with a newer Zigbee controller that doesn't have this issue.
I don't have it while HA is running, but there are firmware updates you can try.
Met vriendelijke groet, Sebastiaan Dammann
Van: mlg9000 @.> Verzonden: Wednesday, February 7, 2024 7:54:17 PM Aan: home-assistant/operating-system @.> CC: Sebastiaan Dammann @.>; Author @.> Onderwerp: Re: [home-assistant/operating-system] Hassos in QEMU KVM (virsh): Attached device disappears when Home Assistant core starts (Issue #2756)
I've had this same issue randomly. Initially it would happen on random HA restarts. Then every HA restart. Now even while HA is running randomly it happens.
It does not appear to be an issue with HA or KVM. I see the disconnects/reconnects for my Conbee II in my host /var/log/messages. If HA wasn't virtualized it would recover on it's own from these but since it's not manual intervention is required. It's only my Conbee II doing this, other USB devices aren't disconnecting/reconnecting. This appears to be a commonly reported issue with these Conbee II devices. I tried upgrading the firmware which seems to either made no difference or maybe made the issue worse.
At this point I think the resolution is to replace the Conbee II with a newer Zigbee controller that doesn't have this issue.
— Reply to this email directly, view it on GitHubhttps://github.com/home-assistant/operating-system/issues/2756#issuecomment-1932673247, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAK4FMKNDFDTEXLUFVTLG3DYSPEVTAVCNFSM6AAAAAA422VSFGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZSGY3TGMRUG4. You are receiving this because you authored the thread.Message ID: @.***>
I've been plagued by the same issue with my RFLink. This is rather not a ha but kvm issue (kvm should reattach usb devices if they reappear on the host). But it doesn't if the usb bus or device number changes while the vm is running, e.g. from
# lsusb
Bus 003 Device 003: ID 1915:0000 Nordic Semiconductor ASA Thread Co-Processor
Bus 003 Device 008: ID 2341:0042 Arduino SA Mega 2560 R3 (CDC ACM)
to
# lsusb
Bus 003 Device 005: ID 1915:0000 Nordic Semiconductor ASA Thread Co-Processor
Bus 003 Device 010: ID 2341:0042 Arduino SA Mega 2560 R3 (CDC ACM)
.
After a lot of struggling I came up with a workaround using udev rules which seems to be good enough and is as clean and straight-forward as possible (thanks to @mlg9000 for the hint that disconnects/reconnects actually appear in the log and @Sebazzz how to reattach devices with virsh). I've documented it here: https://gist.github.com/su-ex/4b7a338a25b9dad72075fca3e4cc5b98
Only my RFLink seems to be unstable and not my Nordic otbr-rcp, but I've added it for convenience if I ever replug my usb devices while the server is running.
The ha rflink integration has a reconnect_interval option, thus I've no further needs to restart anything via script.
The otbr addon seems to be a bit more wonky, so if the otbr-rcp would be as unstable as the rflink, I'd probaly need to work around that with restarting the otbr addon. I've left a note where in the script you'd want to do that.
Just a short note about my long-time test with my udev-based workaround, I had zero problems with that anymore ever since, although there are several reconnects each day:
Sat Mar 23 03:02:44 CET 2024: (Re-)attaching Arduino__www.arduino.cc__0042_2433331393035111F092 (2341:0042) ...
Device detached successfully
Device attached successfully
Sat Mar 23 03:02:45 CET 2024: (Re-)attaching Arduino__www.arduino.cc__0042_2433331393035111F092 (2341:0042) ...
Device detached successfully
Device attached successfully
Sat Mar 23 09:45:57 CET 2024: (Re-)attaching Arduino__www.arduino.cc__0042_2433331393035111F092 (2341:0042) ...
Device detached successfully
Device attached successfully
Sat Mar 23 09:45:58 CET 2024: (Re-)attaching Arduino__www.arduino.cc__0042_2433331393035111F092 (2341:0042) ...
Device detached successfully
Device attached successfully
Sun Mar 24 00:43:27 CET 2024: (Re-)attaching Arduino__www.arduino.cc__0042_2433331393035111F092 (2341:0042) ...
Device detached successfully
Device attached successfully
Sun Mar 24 00:43:27 CET 2024: (Re-)attaching Arduino__www.arduino.cc__0042_2433331393035111F092 (2341:0042) ...
Device detached successfully
Device attached successfully
Sun Mar 24 03:02:40 CET 2024: (Re-)attaching Arduino__www.arduino.cc__0042_2433331393035111F092 (2341:0042) ...
Device detached successfully
Device attached successfully
Sun Mar 24 03:02:41 CET 2024: (Re-)attaching Arduino__www.arduino.cc__0042_2433331393035111F092 (2341:0042) ...
Device detached successfully
Device attached successfully
I've been plagued by the same issue with my RFLink. This is rather not a ha but kvm issue (kvm should reattach usb devices if they reappear on the host). But it doesn't if the usb bus or device number changes while the vm is running, e.g. from
# lsusb Bus 003 Device 003: ID 1915:0000 Nordic Semiconductor ASA Thread Co-Processor Bus 003 Device 008: ID 2341:0042 Arduino SA Mega 2560 R3 (CDC ACM)to
# lsusb Bus 003 Device 005: ID 1915:0000 Nordic Semiconductor ASA Thread Co-Processor Bus 003 Device 010: ID 2341:0042 Arduino SA Mega 2560 R3 (CDC ACM).
After a lot of struggling I came up with a workaround using udev rules which seems to be good enough and is as clean and straight-forward as possible (thanks to @mlg9000 for the hint that disconnects/reconnects actually appear in the log and @Sebazzz how to reattach devices with virsh). I've documented it here: https://gist.github.com/su-ex/4b7a338a25b9dad72075fca3e4cc5b98
Only my RFLink seems to be unstable and not my Nordic otbr-rcp, but I've added it for convenience if I ever replug my usb devices while the server is running.
The ha rflink integration has a
reconnect_intervaloption, thus I've no further needs to restart anything via script. The otbr addon seems to be a bit more wonky, so if the otbr-rcp would be as unstable as the rflink, I'd probaly need to work around that with restarting the otbr addon. I've left a note where in the script you'd want to do that.
I used your method and it works like a charm.
There hasn't been any activity on this issue recently. To keep our backlog manageable we have to clean old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant OS version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
I've been plagued by the same issue with my RFLink. This is rather not a ha but kvm issue (kvm should reattach usb devices if they reappear on the host). But it doesn't if the usb bus or device number changes while the vm is running, e.g. from After a lot of struggling I came up with a workaround using udev rules which seems to be good enough and is as clean and straight-forward as possible (thanks to @mlg9000 for the hint that disconnects/reconnects actually appear in the log and @Sebazzz how to reattach devices with virsh). I've documented it here: https://gist.github.com/su-ex/4b7a338a25b9dad72075fca3e4cc5b98
You are right - I never checked the host kernel log buffer, and indeed, on the host the Zigbee device also shortly disappears when rebooting Home Assistant. Which is weird right? Why would a restart of Home Assistant in a VM cause the USB device to shortly disconnect?
[4645529.126472] usb 1-4: USB disconnect, device number 19
[4645529.448574] usb 1-4: new full-speed USB device number 20 using xhci_hcd
[4645529.628540] usb 1-4: New USB device found, idVendor=1cf1, idProduct=0030, bcdDevice= 1.00
[4645529.628550] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[4645529.628554] usb 1-4: Product: ConBee II
[4645529.628556] usb 1-4: Manufacturer: dresden elektronik ingenieurtechnik GmbH
[4645529.628559] usb 1-4: SerialNumber: DE2292445
[4645529.653842] cdc_acm 1-4:1.0: ttyACM0: USB ACM device
Anyway, your solution definitely seems like a good one so I've implemented it now.
BTW: For the Conbee I only need a single udev rule since it is a single logical device:
SUBSYSTEM=="usb", ATTR{idVendor}=="1cf1", ATTR{idProduct}=="0030", RUN+="/opt/home-assistant/fix-conbee.sh"
And in Home Assistant I have it configured from /dev/ttyUSB0 so I never have to worry about any bus changes [as long as this is the only USB device I would attach]. USB passthrough was not stable for me (failed commands etc) so I'm only passing the serial device through as an USB device in KVM.