HMLAN (HMCFGUSB) zeitweise deaktivieren - Best practice

[karl0123]

Hallo,

ich habe eine sehr umfangreiche FHEM-Installation mit verschiedenen IODevs und vielen Komponenten.

Um meine HM-Komponenten zuverlässig zu schalten, setze ich 2 HMLANs ein. Zusätzlich habe ich noch einen USB-Konfigurationsadapter (alles mit der selben HMID und einer virtuellen CCU). Der USB-Adapter hängt an einem RaspberryPi und ist über hmland eingebunden. Dieser ist für die Funkabdeckung nicht zwingend nötig, da ich ihn für Updates aber ohnehin habe, setze ich ihn auch ein. Dieser genannte  Raspi ist nicht immer im Netz (Funktion: Bad Radio - bei Abwesenheit aus). Das führt dazu, dass die Hauptinstallation, offenbar durch den disconnect des HMUSB, ständig Aussetzer hat (Perfmon). Erscheint der HMUSB wieder (=Raspi an), sind auch die Freezes weg. Das ist nicht ganz optimal.

Meine Frage: Da ich den Raspi im Bad über die Hauptinstallation an und aus schalte, könnte ich das gleiche notify verwenden, um den HMUSB für die Zeit der Abwesenheit zu deaktivieren. Leider haben IODevs aber kein disable Attribut. Wie wäre hier der beste Weg? Reicht es, den Adapter aus der IOList der VCCU zu entfernen um den ständigen Zugriff und damit die Hänger zu vermeiden? Hat jemand schon Erfahrung mit so einer Konstellation gesammelt?

[betateilchen]

Du brauchst den doch gar nicht aus der vccu entfernen, denn die vccu registriert den disconnect normalerweise automatisch.

Bei mir gibt es übrigens keine freezes, wenn einer der drei definierten USB Sticks nicht verfügbar ist.

[martinp876]

prüfe doch einmal, wer die Zeit verbraucht. FHEM wartet gerne und regelmäßig 3 sec auf disconnected Devices - hat nichts mit vccu zu tun, war schon immer so.
apptime sollte genaueres liefern.
was bedeuted freeze? Wie lange dauert es?

[karl0123]

Dass ich EIGENTLICH nichts aus der vccu entfernen muss, ist mir klar. Ich frage hier nach Möglichkeiten.

Eigentlich habe ich ja danach gefragt, wie man ein HM-IODev am besten deaktiviert. Die Analyse habe ich nämlich schon gemacht und es liegt definitiv daran, dass FHEM ständig auf das nicht verbundene Device wartet und es dann 2-3 Sekunden Aussetzer gibt in denen FHEM nicht reagiert. Es geht hier also nicht mehr um das Herausfinden WARUM es Wartezeiten gibt, sondern darum ,wie ich die Ursache beseitigen kann (also als Workaround das IODev zeitweise deaktivieren bzw. entfernen).

Mein Workaround sieht aktuell so aus, dass ich tatsächlich das IODev im Zuge des Abschaltens des Raspis komplett per delete lösche, bei der VCCU ein update triggere und das IODev bei wieder anschalten des Raspis wieder neu anlege und wiederum ein "set vccu update" mache.

[martinp876]

ich denke, man kann es nicht abschalten - aber die 3 sec sind lästig, sehe ich auch so.

Ich werde einmal nach einem Weg suchen