[wiregate] Hinweis zum löschen der Perl Plugins

[vlamers]

Hallo,

dies ist nur ein Hinweis zu den Perl Plugins, kein Wirklicher Bug.
Evtl. könnte man dass in die WG Doku mit aufnehmen?

Erstmal die Vorgeschichte:

Ich hab ein Hörmann Garagentor mithilfe eines Perl Plugins an den Bus angebunden. (Schaltaktor schaltet auf-stop-zu-auf....usw, die Stati werden über 3 Reed's gemeldet Zu,Auf,Lüften)

Dann hab ich das Plugin umgestellt da die Ausführdauer >0,5sek war.

Ich hatte beide Plugins Parallel laufen, das neue sendete ins leere auf eine Fake-GA um zu testen ob es wirklich geht.
Als es endlich funktionierte, löschte ich das alte Plugin im Webmin.

Es hat ein paar Wochen ohne Probleme funktioniert. Bis zu einem Reboot des Wiregates...

Jede Nacht um 2:30 ist das Garagentor aufgefahren. Da ich in der Arbeit zur Zeit gut ausgelastet bin, blieben mir immer nur ca 1 Stunde pro Tag um dass Problem zu finden.

- ich hab fast jede Rule in Linknx die mit dem Garagentor zu tun haben neu geschrieben (ca 13 Stück)
- ich hab das Perl Plugin von 0 nochmal geschrieben
- Den Aktor Resettet und neu verknüpft
- eibd, linknx, perl komplett vom WG entfernt und neu installiert

Nach knapp 3 Wochen spielerei hab ichs endlich gefunden und es wäre nichtmal schwierig gewesen:

Anscheinend werden die Plugins wenn man sie im Webmin löscht, nicht komplett entfernt. Es bleibt anscheinend irgendwelche "Leichen" zurück.

Erst nachdem ich das emx_cleanup Plugin mit den Zeichenfolgen "garage" "Garage" "Garagentor" "Garage" "Tor" "tor" ausgeführt habe (natürlich löschen "Y') hörte der Spuk auf. (Das waren meine Bezeichnungen aus dem 1.Garagentor Plugin).

Ich ärger mich gerade über mich selbst dass ich nicht bei den Plugins angefangen hab zu suchen .

Evtl hilfts jemandem bei dem es auch Spukt!

Gruß vlamers

[makki]

Ich habs mir mal aufgeschrieben aber eigentlich kann das nicht sein, mir fällt zumindest spontan keinerlei Erklärung dafür ein, wie ein Plugin nach einem Restart von den toten auferstehen sollte!?
Hinweise (Original-Plugin?) werden angenommen..

Klar, die Daten in $plugin_info bleiben persistent, nicht perfekt und wird irgendwann anders, aber das hat eigentlich keine Laufzeit-Auswirkungen..

Makki

[Chris M.]

Was ich mir vorstellen kann:

Manche Editoren (nicht der im WG eingebaute!) legen automatisch Sicherheitskopien an. Gerne man mit einer Tilde am Ende o.ä.

=> Wenn so ein "Backup" im Plugin-Verzeichnis ist, kann's Probleme geben!

[NetFritz]

Hallo
Kann man die Plugins auch deaktiven ?
Habe dazu nichts gefunden.
Gruß NetFritz

[greentux]

Das wäre auch ein Wunsch von mir.
Plugins einfach mal disablen für ne Weile...
Geht natürlich auf der Kommandozeile, aber im Webmin wärs für alle brauchbar.

[daviid]

Naja einfach in die Erste Zeile ein return; und gut is, zwar nich besonders komfortabe, aber es geht ...

[greentux]

ja das ist schon klar

[NetFritz]

Hallo
Habe schon gemacht, ist aber eine Notlösung.
Gruß NetFritz

[vlamers]

Hallo,

also Backups mach ich immer in "/home/plugins/" also weit weg vom normalen Verzeichniss.

Ich hätte so gut wie möglich darauf geachtet die Namen nicht doppelt zu vergeben (in beiden Plugins nicht die selben definitionen) also müsste das plugin_info... egal sein!?

es wurde auch nicht das Tor alleine geschalten, sondern die Stati der Reed's auch kurzzeitig auf "0" gesetzt.(aber nur paar sekunden).
Falls die Stati verloren gehen hab ich ne linknx Logik mit "time-counter". Wenn die Stati länger als 5min gleich sind, oder länger als 5min alle "0" dann hat er das Tor gefahren um die Position wieder zu finden.
Aber linknx hab ich im Debug Modus laufen gehabt, und laut dem Log ist die Rule nicht ausgelöst worden. (ist auch immer noch drinne und das Tor fährt nicht mehr)
Ich hab ewig gesucht warum dass mit den Perl Plugin so schief gelaufen ist. Bei jedem Schritt ein plugin_log geschrieben, nur leider war daran auch nichts zu sehen.

Laut eib.log hab ich aber nur die Telegramme dass das Tor offen ist nachvollziehen können (und den schaltvorgang davor). Es war immer im größeren (auch immer unterschiedlichen) Zeitabständen nach dem die Stati kurzzeitig auf "0" gesetzt wurden(mehrere Minuten).

Das Ursprüngliche Plugin ist leider nicht mehr zu finden, ich geh mal alle Backup Platten durch ob ich es noch irgendwo finde.
Aber im Grunde hat es am Anfang alle Stati gelesen, und je nach ist zustand auf die Soll-Zustände reagiert. Warum das erste Plugin so lange zum Ausführen gedauert hat??? War eigentlich ein sehr einfach aufgebautes Plugin.

Gruß

[makki]

Manche Editoren (nicht der im WG eingebaute!) legen automatisch Sicherheitskopien an. Gerne man mit einer Tilde am Ende o.ä.

*~ wird ab nächstem Update (PL30) ignoriert..

Jedenfalls, ich könnte mir nicht erklären, wie auch immer ein gelöschtes Plugin (oder was-auch-immer) in Plugin_info etwas auslösen kann (ausser durch ein vorhandenes anderes Plugin das das absichtlich liest vielleicht.
Der Code ist an der Stelle einfach: Lese Datei, mache eval() -> Keine Datei, kein eval

Das mit dem deaktivieren von Plugins hatten wir ja schon oft genug: es wäre aufwändig das konsistent zum implementieren: was ist wenn jemand - durchaus üblich, möglich und beabsichtigt -mal mit dem Webif und mal mit ssh/scp arbeitet; etwas umbenennt, kopiert, löscht, .. wie geht man dann damit um, so das es noch jeder versteht und nachvollziehen kann?
Ein return; in die erste Zeile ist IMHO einfach, praktikabel und verständlich

Fürs "Cleanup" der $plugin_info poste ich noch ein Plugin, da es für einen globalen zu spät ist, da würden zuviele ins Messer laufen denke ich..

Makki

[Chris M.]

*~ wird ab nächstem Update (PL30) ignoriert..

Hm, evtl. auch noch die ".*" (<- keine RegEx, sondern Bash) und "*.swp"?