HMLAN und HMLGW deaktivieren

[hugomckinley]

Hallo,
gibt es eine Möglichkeit ein definiertes HMLAN und einen HMLGW so zu deaktivieren, dass die xyz_Ready Funktion dafür nicht mehr ausgeführt wird?
Ein disable Attribut gibt es ja leider nicht.

Hintergrund: Ich habe aus Redundanzgründen in einer VCCU mehrere Interfaces definiert, aber nur eines ist eingeschaltet. Wenn dieses defekt ist, reicht das aktivieren eines bereitliegenden Interfaces und es sollte wieder alles funktionieren.
Ich habe aber derzeit das Problem, dass irgendwo eine Speicherloch dazu führt, dass mir FHEM nach ein paar Tagen den ganzen RAM angefüllt hat und der OOM-Killer mir dann alles mögliche und als eines der ersten FHEM abschießt.

Ich habe ein paar Verdächtige bereits ausschließen können (soweit das möglich ist) und der nächste und letzte Kandidat ist nun diese Funktion, da diese extrem oft (ca. 5-10/sec) ausgeführt wird und manchmal lt. apptime auch ein paar Sekunden läuft.
siehe: https://forum.fhem.de/index.php/topic,123036.msg1175895.html#msg1175895

Wenn ich die HM Gateways aus dem IODev der VCCU entferne, bekomme ich als state HMLAN1:UAS,HMLGW2:UAS,HMLGW1:ok aber FHEM versucht anscheinend ständig die Interfaces zu erreichen.

Ich möchte die Definitionen nicht einfach komplett löschen, da an diesen Devices einiges dranhängt und ich ansonsten evtl. einiges zerstöre, was mir jetzt gar nicht (mehr) bewusst ist.

Grüße,
Hugo

[Otto123]

Hallo Hugo,

ich bin nicht sicher, ob es das ist was Du suchst.
Es gibt set close und es gibt attr dummy 1 - letzteres überlebt den Neustart.

Gruß Otto

[Pfriemler]

Ich hänge mich mal hier herein, weil mich das Resultat interessiert. Aber:
Ich hatte monatelang ein HMLAN (Ufo) in der VCCU definiert, das offline war und es gab nullkommaniente Probleme. Ich mache so in der Regel alle 2-3 Monate einen Neustart, was nur Folge eines Neustarts des ganzen Raspis ist, etwas nach Wartungsarbeiten. Inzwischen ist das Ufo separat definiert und per dummy stillgelegt. Die RAM-Belegung des Raspi war stets gleich unauffällig.

[hugomckinley]

@Otto: Danke, das set close hat das gemacht was ich wollte.

@Pfriemler: Nein, FHEM hat kein Problem, sondern meine Perl Version(5.32.1). Ich habe jetzt alle offensichtlich Verdächtigen ausgeschlossen und muss nun leider aufgeben, da ich nicht mehr wüsste, woher der Speicherverbrauch kommt.
Somit werde ich auf ein Upgrade der Perlversion warten, bzw. schauen, wie ich die Version möglichst schmerzfrei wechseln kann.