Wenn ich folgenden Perlcode in ein Userreading eintrage
PerlCode {
sub test1($) {
return 2;
}
}
und danach sub test1 in sub test2 umbenenne, kann ich immer noch
in Telnet mit
{test1("tmp")}
2
noch immer sub test1 aufrufen, obwohl es das eigentlich nicht mehr gibt.
Vielleicht ist das zu kpmplex, etc. aber erwarten würde ich mir dass test1 als nicht mehr definiert gilt.
Aufgetreten ist das Problem, als ich test1 mehrmals abgeändert habe, und die Änderungen ein falsches (altes)
Ergebnis zurücklieferten.
Das ganze Attribut sah schlicht so aus;
attr Testdummy userReadings PerlCode {\
sub test1($) {\
return 2;;\
}\
}
Wenn eine sub einmal im Speicher ist, bleibt sie dort, es sei denn, sie wird gelöscht. FHEM Neustart oder undef dürften helfen.
genau darum geht es in diesem Thread.
Es wäre eben schön, wenn sich die Routine wieder aus dem Speicher entfernen ließe...
In meinem Tests hatte ich unbemerkt über eine Woche 100% CPU-Auslastung durch FHEM,
die dann durch den Neustart verschwunden sind. Ursache waren Tests mit Subroutinen in den Userreadings
und dem mehrmaligen Veränern dieser.
Für mich nehme ich das im Moment als Warnung: Subroutinen in Userreadings können unvorhersehbare Nebeneffekte habe. ;-)
Man legt auch keine Subroutinen in Userreadings / notify / etc an, sondern in 99_myUtils.pm
Oder wenn es wirklich sein muss, dann ohne Namen, als $fn = sub(){}, Aufruf mit &$fn();
Beim Kopieren von Devices in mehrere FHEM-Installationen (und dem Aktuell halten dieser) ist es halt schöner,
diese mitsamt dem Code über "attr" anzulegen.
Subroutinen mit Namen haben den Vorteil, dass ich sie auch in Begleit-Devices (notify, etc...) nutzen kann, da diese auch global verfügbar sind.
Mir ist der Vorteil von 99_myUtils.pm schon bekannt, die Nachteile jedoch auch ;-), und da es mit den Subroutinen funktioniert,
habe ich es auch benutzt.
Vielleicht mach ich (ode rjemand der es besser kann) mal ein Modul zur Verwaltung der 99_myUtils.pm....
Die Nachteile musst du mir mal erläutern. Ich erkenne sie nicht. Es ist immer eine Frage der Perspektive. subs gehören in die myUtils oder eigene Module. Ändere deine Warnung einfach in: subs gehören nicht in ein userReading.