Sabotageüberwachung mit dem WG

[makki]

Was geschieht mit den Variabeln die in einem Plugin erzeugt werden, wenn das Programm abgearbeitet wurde? Bleiben die Variabeln bestehen oder werden sie automatisch gelöscht?

Ich erzähle jetzt die Variante, die langfristig sicher funktioniert (aktuell sind richtig definierte Variablen bis zum Prozess-restart auch so persistent); besser als:
$plugin_info{$plugname.'_MEINWERT'} = "abc";
ablegen. Das wird in einem (BDB)-File abgelegt und existiert auch nach einem restart/reboot/whatever noch. Sich an exakt diesen Syntax $plugin_info{$plugname.'_XXX zu halten hat auch den Vorteil, das bei einer evtl. zukünftigen Aufräumaktion erhalten bleibt, was einem wichtig ist (derzeit findet noch kein "cleanup" statt, aber mit der sichtbarkeit der "Leichen" alter Plugins im Webif steigt auch die Frage auf..)

Makki

P.S.: Die Laufzeitumgebung der Plugins wird sich *irgendwann* von dem fetten single-Perl-Daemon ändern und dann läuft das in einer zwar immernoch persistenten Umgebung aber ggfs. wechselnden Thread/Interpreter (damit habe ich übrigens den heutigen Nachmittag verbracht..) %plugin_info wird per Update mit Mutex mit locking sicher rübergerettet, aber der rest an wie auch immer geänderten lokalen Variablen ist über mehrere Aufrufe hinweg dann Zufall bzw. Schall&Rauch.

Die "API" ist sicher nicht perfekt, weil das $plugname_XXX ist z.B. nur der inkontinenz von Tied-Hashes geschuldet, aber das ist halt jetzt so und bleibt ohne massive Proteste auch so wie es ist (das mapped die Laufzeitumgebung zukünftig dann einigermassen kompliziert einfach passend um..)

Makki

[swiss]

Sorry ich hab deine Antwort 3x gelesen und verstehe es immer noch nicht.

Sollte man nun Variabeln, die man bei einem nächsten Aufruf des Plugins wieder braucht besser als:

my $Fensteranzahl = 5;

oder als:

$plugin_info{$plugname.'_Fensteranzahl'} = "5";

erzeugen.

Sorry fürs blöd fragen aber ich möchte gerne sichergehen, dass das Plugin auch in Zukunft noch funktioniert.

[Chris M.]

Sollte man nun Variabeln, die man bei einem nächsten Aufruf des Plugins wieder braucht besser als:

my $Fensteranzahl = 5;

oder als:

$plugin_info{$plugname.'_Fensteranzahl'} = "5";

erzeugen.

Das kommt darauf an

my $Fensteranzahl = 5;

ist die Lösung für eine "Konstante", oder einen Wert, den Du nur im Plugin änderst. Mit einem gemerkten Zustand hat das nichts zu tun.

$plugin_info{$plugname.'_Fensteranzahl'} = "5";

Ist zwar nicht falsch, hängt aber stark vom Kontext ab.

$plugin_info{$plugname.'_Fensteranzahl'} speichert einen Zustand, ist also das Gedächtnis des Plugins. Nur so kannst Du Werte von einem Plugin-Aufruf an den nächsten übergeben.

Ein Beispiel dafür ist bei mir der Zustand "AbAbwesend".
Hier habe ich ein Plugin, dass z.B. die Riegelschaltkontakte der Türen auswertet und mit den Präsenzmeldern plausibilisiert und so ausrechnet, ob jemand zu Hause ist oder nicht. Dieser Zustand wird mit dieser Syntax abgelegt und steht so beim nächsten Aufruf wieder zur Verfügung.

Dazu darf aber $plugin_info{$plugname.'_AnAbwesend'} = Wert natürlich nur ausgeführt werden, wenn sich der Wert ändert.

Das bringt gleich die Schwierigkeit mit sich, wie man zuverlässig diese Werte initialisiert (und ggf. resetet)...


Zusammengefasst:
Bei etwas statischem wie der Anzahl der Fenster, wäre richtig:

my $Fensteranzahl = 5;

[makki]

So:

$plugin_info{$plugname.'_Fensteranzahl'} = "5";

"Reserviert" sind übrigens:
_cycle (Aufrufzyklus)
_last (Zeitstempel letzter zyklischer Aufruf)
_result (Rückgabewert)
_runtime (Laufzeit)
_timeout_err (Anzahl timeout-Fehler)

Makki

[swiss]

Ok. Jetz hab ich es verstanden

Dann lege ich die Zustände der MK's als remanente Variabeln an. Der Rest wird als "normale" Variabeln zur Laufzeit erzeugt und mit Daten befüllt.

[makki]

Richtig so, (auch wenn sich bei oberflächlichem Lesen vielleicht das von Chris und mir widerspricht - ich hatte den Post natürlich mal wieder vorher nicht gesehen)
Hat man acht Fenster (da ändert sich ja nichts): my Fensteranzahl = 8;
Das kostet "nichts", die Variable verbrät für keine 10ms RAM
Will man sich etwas über den Aufruf des Plugins hinaus merken *1):
$plugin_info{$plugname_'FensterXstatus'} = Y;

Makki

*1) genau damit habe ich den heutigen Tag verbracht, hier eine "API-kompatibilität" herzustellen, aber wenn sich da in der Laufzeitumgebung was ändert, dann muss/wird das (kompatibel) der Fall sein, das Problem muss ich dann wohl einfach lösen Das tut zwar weh, aber nur mir, damit will ich euch nicht belasten..

[swiss]

Soo...

Das speichern und einlesen von Daten funktioniert jetzt. Nun habe ich aber das nächste Problem...

Ich kann bei einem Aufruf die übermittelten Daten nicht einlesen. Beim nachsehen im Quelltext weiter vorne habe ich folgendes gelesen:

# $msg{'value'} Dekodierter Klartext-Wert (nur falls ESF importiert!)

Hier könnte das Problem liegen. Wenn sich ein Status änder, wird automatisch das Plugin aufgerufen. Wenn ich nun die neuen Werte speichern möchte, ist die Variabel $msg{'value'} immer leer.

Wie kann ich das Problem lösen? Und was ist ESF?

[makki]

Meint: value gibts nur, wenn die Gruppenadresse auch durch import oder mit dem shiny neuen Gruppenadressen-Editor bekannt ist. Sonst "weiss" das WG ja nicht, wie es den Wert dekodieren soll.

Das CSV für den Import muss man leider mit dem ETS(3*)-Exporttool erstellen, weil sonst in eben jenem ESF fast keine verwertbaren Datenpunkttypen (DPT) stehen, man also wieder nicht weiss was in den Bytes drin ist..
Zu ESF sage ich sonst lieber nichts

Also am einfachsten die GA im GA-Editor sauber mit richtigem DPT anlegen, importieren oder eben die rohen bytes aus $msg{'data'} verwenden.

Makki

*ETS4-Import gibt's noch nicht, weil ich da wiederum ernsthafte Probleme hatte, diesem Haufen XML in Schnitzeljagd-Manie die DPT's zu entlocken wenn diese in der ETS nicht *alle* händisch eingestellt sind (was wiederum vermutlich fast keiner macht)

[swiss]

EDIT: Hab den Fehler doch gefunden...

Nun wieder zu meinem Probelm wegen den Werten der GA's. Da muss ich mir noch ersthaft was überlegen.

[makki]

ohne gewähr aus dem Bauch:

my @schluessel_MK_oben = keys(%MKs_oben);
usw. liefert die keys nicht in der Reihenfolge wie es erwarten würdest (sondern in irgendeiner!)

eher
.. = sort keys(%MKs_oben)

Ich weiss zwar nicht genau was Du bezweckst aber ich würde mir einfach pro Fenster ein
$plugin_info{$plugname.'_FensterStatus8Bit'.$i}
machen statt dem ganzen (de)serialisieren (*).

DPT für 8Bit-Fensterstatus konnte ich auf die schnelle keinen finden aber letztlich würde ich mir "oben" ins erste Bit, "unten" ins zweite Bit o.ä. legen
Wäre dann dezimal 0 = zu, 1 = gekippt, 3 = offen (hoffe das war verständlich..)

Makki

*Richtig, $plugin_info ist ein tied hash, worin man, warum zum Henker auch immer genau, keine tieferen Strukturen oder Referenzen ablegen kann.

[swiss]

Ich weiss dass die Reihenfolge immer wieder auf's neue gemischt wird Das ist aber nicht weiter tragisch, da immer ein Schlüsselpaar abgelegt wird. Daraus kann ich dann den haupt hash in beliebiger Reihenfolge aktualisieren. Das funktioniert soweit ganz gut. hatte nur einen kleinen Fehler im Plugin, der jetzt aber behoben ist.

Wesshalb ich nicht für jedes Fenster eine "remanente Variabel" anlegen wollte ist:

1.) Es soll ohne grossen Aufwand von jedem der will, auf seine eigenen gegebenheiten angepasst werden können.

2.) Jeder Eintrag in $plugin_info{'irgendwas'} wird separat auf der Pluginseite aufgelistet... Das bedeutet, dass bei 10 Fenster à 2 MK einfach zusätzlich 20 Einträge aufgelistet werden. (gefällt mir persönlich nicht so)


Nun muss ich noch eine Lösung für die Aktualisierung der Werte über die aufrufende GA finden...

Das einfachste wird es vermutlich sein, wenn ich die aufrufende GA einfach dazu verwende auf dem BUS den aktuellen Status zu lesen. Das setzt aber wieder voraus, dass bei jeder GA mindestens ein KO eingetragen sein muss, bei dem das "Lesen" Flag gesetzt ist. Um diesen "Unsicherheitsfaktor" auszuschliessen, wollte ich die Werte lieber durch $msg{'value'} aktualisieren.

[makki]

Deswegen kanns ja auch jeder machen wie es beliebt

Wenn Du einen

knx_read("1/2/3",[COLOR="Red"][B]0[/B][/COLOR],1)

machst, was auch die eempfohlenste Variante ist, wird der Wert aus dem Cache gelesen, egal ob er dort durch ein Schreib oder Antwort-Telegramm landete.
Solange der Wert dann zyklisch/bei Änderung auf den Bus gesendet wird, sollte das in 99% der Fälle tun.
Nur wenn der Wert nicht im Cache ist, wird einmalig ein Lesetelegramm losgeschickt.
(es gibt übrigens eine rudimentäre Hilfe-Seite unter Plugins oben links, wo diese Sache auch stehen sollte)

Makki

[swiss]

(es gibt übrigens eine rudimentäre Hilfe-Seite unter Plugins oben links, wo diese Sache auch stehen sollte)

Oo. Sorry. Die hab ich noch nicht gesehen

Dann werde ich das mit knx_read lösen

[swiss]

Sooo...

Nun habe ich noch ein letztes Problem, bevor das Plugin den Beta status erlangt.

Wenn sich nun der Zustand eines MK's ändert, wird in einer einfachen if() prüfung der neue Status ermittelt und danach auf den BUS gesendet. Das Problem das ich nun habe ist, dass ich beim senden ein 8bit Wert übermitteln möchte. Leider wird im BUS Monitor immer Müll angezeigt.

Das senden geschieht statisch. z.B. so:

knx_write($Status_8bit[$i],0,5);

Hier stimmt die Anzeige im BUS Monitor ($00)

Wenn ich nun aber für gekipt eine 2 auf den BUS senden will, geschieht folgendes:

knx_write($Status_8bit[$i],2,5);

Hier bekommme ich auf dem BUS immer ($05).

Was mache ich da falsch? Stimmt etwas im Code nicht? Die angegebenen Werte, die der BUS Monitor liefert sind rohdaten. Es sollte also nicht am DPT in der ETS liegen??

[makki]

5 wird als 5.001 - also 0-100% (auf dem Bus 0-255) interpretiert
Dann wird aus 2% 0x05 am Bus
-> Bei DPT "5.010" reinschreiben, dann sollte das klappen.

Makki