Keine Kommunikation möglich nach Neu-Verbinden des HmIP-RFUSB

[da-mkay]

Hallo zusammen,

ich betreibe an meinem Server einen HmIP-RFUSB, den ich an eine VM durchreiche, in der RaspberryMatic läuft.

Leider verabschiedet sich der Stick hin und wieder. Wie es scheint, bereits am Host-System:

Nov 13 04:01:25 localhost kernel: [    1.957380] usb 1-5: new full-speed USB device number 2 using xhci_hcd
Nov 13 04:01:25 localhost kernel: [    2.111023] usb 1-5: New USB device found, idVendor=1b1f, idProduct=c020, bcdDevice= 1.00
Nov 13 04:01:25 localhost kernel: [    2.111036] usb 1-5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Nov 13 04:01:25 localhost kernel: [    2.111040] usb 1-5: Product: eQ-3 HmIP-RFUSB
Nov 13 04:01:25 localhost kernel: [    2.111042] usb 1-5: Manufacturer: Silicon Labs
Nov 13 04:01:25 localhost kernel: [    2.111045] usb 1-5: SerialNumber: XXXXXXXXXXXXXXXXXXXXXXXX
Nov 13 04:01:39 localhost kernel: [   29.280037] usb 1-5: reset full-speed USB device number 2 using xhci_hcd
...
Nov 19 18:24:30 localhost kernel: [570205.557022] usb usb1-port5: disabled by hub (EMI?), re-enabling...
Nov 19 18:24:30 localhost kernel: [570205.557077] usb 1-5: USB disconnect, device number 2
Nov 19 18:24:30 localhost kernel: [570205.830855] usb 1-5: new full-speed USB device number 3 using xhci_hcd
Nov 19 18:24:30 localhost kernel: [570205.980618] usb 1-5: New USB device found, idVendor=1b1f, idProduct=c020, bcdDevice= 1.00
Nov 19 18:24:30 localhost kernel: [570205.980633] usb 1-5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Nov 19 18:24:30 localhost kernel: [570205.980641] usb 1-5: Product: eQ-3 HmIP-RFUSB
Nov 19 18:24:30 localhost kernel: [570205.980647] usb 1-5: Manufacturer: Silicon Labs
Nov 19 18:24:30 localhost kernel: [570205.980653] usb 1-5: SerialNumber: XXXXXXXXXXXXXXXXXXXXXXXX

Noch konnte ich nicht herausfinden, warum der Stick sich verabschiedet.
Aber immerhin ist er sofort wieder verfügbar, nur als device 3 statt vorher device 2.
Ich habe das device 3 dann erneut zur VM durchgereicht. Und dort wird es auch erkannt, wie die Logs von Raspberrymatic zeigen:

Nov 13 05:01:44 localhost kern.info kernel: [    1.756715] usb 1-1: new full-speed USB device number 2 using xhci_hcd
Nov 13 05:01:44 localhost kern.info kernel: [    1.885727] usb 1-1: New USB device found, idVendor=1b1f, idProduct=c020, bcdDevice= 1.00
Nov 13 05:01:44 localhost kern.info kernel: [    1.885737] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Nov 13 05:01:44 localhost kern.info kernel: [    1.885739] usb 1-1: Product: eQ-3 HmIP-RFUSB
Nov 13 05:01:44 localhost kern.info kernel: [    1.885741] usb 1-1: Manufacturer: Silicon Labs
Nov 13 05:01:44 localhost kern.info kernel: [    1.885743] usb 1-1: SerialNumber: XXXXXXXXXXXXXXXXXXXXXXXX
...
Nov 13 05:01:45 localhost kern.info kernel: [    7.931617] usb 1-1: Found eQ-3 HmIP-RFUSB with serial XXXXXXXXXXXXXXXXXXXXXXXX at usb-0000:02:00.0-1
Nov 13 05:01:45 localhost kern.info kernel: [    7.932509] raw-uart raw-uart: Reset radio module
Nov 13 05:01:45 localhost kern.info kernel: [    7.932515] raw-uart raw-uart: Registered new raw-uart device using underlying device eQ-3 HmIP-RFUSB@usb-0000:02:00.0-1.
Nov 13 05:01:45 localhost kern.info kernel: [    7.933449] usbcore: registered new interface driver hb_rf_usb_2
...
Nov 19 19:24:30 localhost kern.info kernel: [570177.773320] usb 1-1: USB disconnect, device number 2
Nov 19 19:25:05 localhost user.err monit[1746]: 'coProcessorCheck' status failed (2) -- ERROR: eQ-3 HmIP-RFUSB@usb-0000:02:00.0-1 connection lost
...
HIER WURDE DER STICK NEU ZUR VM DURCHGEREICHT
...
Nov 21 20:38:38 localhost kern.info kernel: [747427.141354] usb 1-1: new full-speed USB device number 3 using xhci_hcd
Nov 21 20:38:38 localhost kern.info kernel: [747427.274786] usb 1-1: New USB device found, idVendor=1b1f, idProduct=c020, bcdDevice= 1.00
Nov 21 20:38:38 localhost kern.info kernel: [747427.274841] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Nov 21 20:38:38 localhost kern.info kernel: [747427.274849] usb 1-1: Product: eQ-3 HmIP-RFUSB
Nov 21 20:38:38 localhost kern.info kernel: [747427.274856] usb 1-1: Manufacturer: Silicon Labs
Nov 21 20:38:38 localhost kern.info kernel: [747427.274862] usb 1-1: SerialNumber: XXXXXXXXXXXXXXXXXXXXXXXX
Nov 21 20:38:38 localhost kern.info kernel: [747427.281159] usb 1-1: Found eQ-3 HmIP-RFUSB with serial XXXXXXXXXXXXXXXXXXXXXXXX at usb-0000:02:00.0-1
Nov 21 20:38:38 localhost kern.info kernel: [747427.281555] raw-uart raw-uart1: Reset radio module
Nov 21 20:38:38 localhost kern.info kernel: [747427.281568] raw-uart raw-uart1: Registered new raw-uart device using underlying device eQ-3 HmIP-RFUSB@usb-0000:02:00.0-1.
Nov 21 20:38:55 localhost user.err monit[1746]: 'coProcessorCheck' status failed (2) -- ERROR: eQ-3 HmIP-RFUSB@usb-0000:02:00.0-1 connection lost

Obwohl die Raspberrymatic-VM den Stick erkannt hat, scheint sie ihn nicht automatisch zu verwenden. Denn eine Kommunikation mit den Geräten war immernoch nicht möglich. Die letzte log-Zeile sieht für mich auch so aus, als wenn immernoch device 2 monitored wird.
Nach einem Neustart der VM ging dann alles wieder.

Nun zu meiner Frage:
Kann ich Raspberrymatic von außen irgendwie mitteilen, dass es den "neuen Stick" nutzen soll, damit ich es mir sparen kann die VM neu zu starten? Der VM-Reboot dauert nämlich schon eine Weile.
Dann könnte ich mir eine udev-Regel bauen, die den Stick bei einem Reconnect erneut durchreicht und dann Raspberrymatic anweist den "neuen Stick" auch zu nutzen.
Oder kann ich Raspberrymatic direkt irgendwie konfigurieren, dass er den neuen Stick nutzt? 😉

[jens-maus]

Kann ich Raspberrymatic von außen irgendwie mitteilen, dass es den "neuen Stick" nutzen soll, damit ich es mir sparen kann die VM neu zu starten?

Nein, das geht nicht. Eine CCU bzw. ein RaspberryMatic geht dauerhaft davon aus das das Funkmodul bzw. hier der HmIP-RFUSB immer verfügbar ist. Sobald es hier zu einer Unterbrechung oder "Verschwinden" des gleichen kommt führt an einem Restart der notwendigen Dienste nichts vorbei. Und selbst da ist es wichtig die entsprechenden Dienste in der richtigen Reihenfolge neuzustarten und da geht es einfach am schnellsten einfach die gesamte VM neuzustarten.

Es bleibt also dabei: Suche lieber den Root-Cause warum der HmIP-RFUSB bereits vom Hostsystem verschwindet und beseitige diesen, statt downstream zu versuchen einen Workaround zu finden.

[da-mkay]

Ich danke dir für die schnelle Rückmeldung. Dann werde ich mich mal auf die Suche nach dem Root-Cause machen. Bis dahin wird mein udev-workaround hoffentlich funktionieren.