Neues Plugin: Logikprozessor.pl

[mivola]

Ja, am besten ist es, solche Werte einmal alle 5min auf den Bus zu schreiben.
VG, Fry

Also irgendwie ist bei mir da noch immer der Wurm drin. Der Wert wird aus irgendeinem Grund weder gespeichert noch wiederholt auf den Bus geschrieben.

Folgende Config:

memoryRaffstoreAutomatischHochNachZeit => { transmit=>'9/4/1', timer=>{ time=> '00:00+3m' }, debug=>1 },

Führt zu folgenden Log-Ausgaben:

2014-07-08 07:15:55.320,Logikprozessor.pl,Naechster Aufruf der Timer-Logik 'memoryRaffstoreAutomatischHochNachZeit' um 07:18.
2014-07-08 07:16:18.490,Logikprozessor.pl,9/4/1:Lesetelegramm -> $logic{memoryRaffstoreAutomatischHochNachZeit}{transmit}(memory) -> 9/4/1: gesendet;  ,1.8s,
2014-07-08 07:17:20.089,Logikprozessor.pl,Naechster Aufruf der Timer-Logik 'memoryRaffstoreAutomatischHochNachZeit' um 07:18.
2014-07-08 07:18:21.516,Logikprozessor.pl,Naechster Aufruf der Timer-Logik 'memoryRaffstoreAutomatischHochNachZeit' um 07:21.
2014-07-08 07:21:21.120,Logikprozessor.pl,Naechster Aufruf der Timer-Logik 'memoryRaffstoreAutomatischHochNachZeit' um 07:24.
2014-07-08 07:24:21.742,Logikprozessor.pl,Naechster Aufruf der Timer-Logik 'memoryRaffstoreAutomatischHochNachZeit' um 07:27.
2014-07-08 07:27:22.215,Logikprozessor.pl,Naechster Aufruf der Timer-Logik 'memoryRaffstoreAutomatischHochNachZeit' um 07:30.
2014-07-08 07:30:23.819,Logikprozessor.pl,Naechster Aufruf der Timer-Logik 'memoryRaffstoreAutomatischHochNachZeit' um 07:33.
2014-07-08 07:30:30.016,Logikprozessor.pl,9/4/1:Lesetelegramm -> $logic{memoryRaffstoreAutomatischHochNachZeit}{transmit}(memory) -> 9/4/1: gesendet;  ,1.2s,
2014-07-08 07:33:23.215,Logikprozessor.pl,Naechster Aufruf der Timer-Logik 'memoryRaffstoreAutomatischHochNachZeit' um 07:36.
2014-07-08 07:36:24.100,Logikprozessor.pl,Naechster Aufruf der Timer-Logik 'memoryRaffstoreAutomatischHochNachZeit' um 07:39.
2014-07-08 07:39:24.046,Logikprozessor.pl,Naechster Aufruf der Timer-Logik 'memoryRaffstoreAutomatischHochNachZeit' um 07:42.

und:

2014-07-08 07:16:16.592,A_GroupValue_Read,1.1.254,9/4/1,00,0,,1,0,low,7,T_DATA_XXX_REQ,0
2014-07-08 07:16:31.179,A_GroupValue_Response,1.1.254,9/4/1,00,0,,1,0,low,7,T_DATA_XXX_REQ,0
2014-07-08 07:19:34.364,A_GroupValue_Write,1.1.254,9/4/1,01,1,,1,0,low,7,T_DATA_XXX_REQ,0
2014-07-08 07:30:28.869,A_GroupValue_Read,1.1.254,9/4/1,00,0,,1,0,low,7,T_DATA_XXX_REQ,0
2014-07-08 07:31:02.247,A_GroupValue_Response,1.1.254,9/4/1,00,0,,1,0,low,7,T_DATA_XXX_REQ,0

Der Timer für "memoryRaffstoreAutomatischHochNachZeit" wird zwar immer wieder neu gesetzt, aber irgendwie wird nie etwas ausgeführt bzw gesendet; es gibt kein knx_write auf dem Bus. Das einzige knx_write um 07:19:34.364 resultiert aus einem Klick in der Visu (Wert: 1). Die Einträge von knx_read resultieren aus einer weiteren Logik, die '9/4/1' als fetch-GA benutzt. Der jeweils 30sek verzögerte Response ist wahrscheinlich durch einen Timeout des Read-Requests zu begründen?

Was mache ich (oder mein System) falsch?

Danke,
Micha
PS: ich nutze noch die Version ausm SVN und einen den original wiregated (noch...)

[Fry]

Na woher zum Geier soll die Logik denn wissen, WAS sie senden soll?

Andersrum gefragt: was möchtest du eigentlich erreichen?

Und: ich empfehle dir DRINGEND ein Update des wiregated.pl und Logikprozessors, wenn du ihn intensiv nutzt. Die Geschwindigkeitsvorteile sind erheblich. Und die Stabliität ist auch besser.

[mivola]

Na woher zum Geier soll die Logik denn wissen, WAS sie senden soll?

Andersrum gefragt: was möchtest du eigentlich erreichen?

Und: ich empfehle dir DRINGEND ein Update des wiregated.pl und Logikprozessors, wenn du ihn intensiv nutzt. Die Geschwindigkeitsvorteile sind erheblich. Und die Stabliität ist auch besser.

Naja, ich möchte einen Wert der zu keinem physischen KNX-Gerät gehört (sondern zb zur Visu oder den Plugins) "speichern", und zwar so, dass bei einem knx_read immer der zuletzt gesendete/geschriebene Wert zurückgegeben wird. In meinem log sieht man ja zb ein WRITE-Telegramm mit Wert "1" (initiiert durch die Visu). Und nun möchte ich, dass der Logikprozessor auf den folgenden READ-Request mit "1" antwortet.

Und: ich werde das Update des wiregated.pl demnächst in Angriff nehmen. Bisher habe ich mich immer noch dagegen gesträubt da ich die Hoffnung hatte, dass es "bald" das neue offizielle PL gibt... Gibt es mit einem lokal geänderten wiregated.pl dann Probleme wenn es das neue PL gibt? Oder werden die lokalen Änderungen einfach überschrieben?

Danke,
Micha

[johnnychicago]

OK, die Art, wie ich das mache ist, dass eine Logik halt alle 5 Minuten den Wert wiederholt - d.h., nachdem die Visu den Wert einmal gesetzt hat, nimmt die Logik ihn, schickt ihn nach 5 Minuten neu, und ruft sich dadurch selber auf.

Damit ist der Wert halt immer im eibd-Cache, das heisst, eine andere Logik kann ihn von dort finden.

Also so:

ga_erhaltung=>{receive=>'1/2/3',transmit=>'1/2/3',translate=>sub{return $input},delay=>300}

Die Logik triggert sich halt immer wieder neu.

Eine Antwort auf einen read request innerhalb des Logikprozessors habe ich noch nicht fertiggebracht. Das beisst sich auch mit meinem Verständnis, dass sich der Logikprozessor ja nicht selbst aufrufen kann. Wenn ich in einer Logik eine GA lesen will, müsste der Logikprozessor ja durch sich selbst neu aufgerufen werden.

Mir gefiele es besser, wenn man innerhalb des Logikprozessors einen Read Request auf GA's machen könnte. Für einige davon würde ich nämlich viel lieber den Status im Plugin speichern als eine GA dauernd am Bus zu refreshen. Die Refresherei hat nämlich den Nachteil, dass sie natürlich stirbt, wenn der Logikprozessor kurzzeitig ausfällt oder das Wiregate kurz weg ist.

[mivola]

OK, die Art, wie ich das mache ist, dass eine Logik halt alle 5 Minuten den Wert wiederholt

Das funktioniert bei mir leider auch nicht. Und es wundert mich, dass es bei dir funktioniert. Denn zb in der Sample-Conf steht:

   # * Damit im Fall transmit==receive der Translator nicht auf sein eigenes Schreibtelegramm immer wieder antwortet, 
    # wird nur dann gesendet, wenn Ergebnis!=Input oder Sender des empfangenen Telegramms!=$eibd_backend_address (Wiregate).

Welche Version des Logikprozessors nutzt du?

Bei mir sehe ich trotz debug=>1 von dieser Logik nur folgendes im Log:

2014-07-08 22:09:14.520,Logikprozessor.pl,$logic{memoryRaffstoreAutomatischHochNachZeit}: Warnung: 9/4/1 sowohl Receive- als auch Transmit-GA.

Ich werde mich wohl demnächst erstmal mit den Patches für den wiregated.pl beschäftigen...

VG
Micha

[Fry]

@Micha: bitte update deinen Logikprozessor.

[mivola]

@Micha: bitte update deinen Logikprozessor.

Das bedingt ja die diversen Patches am wiregated.pl - muss ich dann zwangsläufig auch alle anderen Plugins irgendwie umstellen? Stichwort PRECOMPILED?

Danke,
Micha

[Fry]

Don't worry. Solange du den Kommentar # COMPILE_PLUGIN nicht in deine anderen Plugins reinschreibst, werden sie so ausgeführt wie bisher. Keine Änderung.

Und wenn du das doch reinsetzt, sind nur einige wenige Dinge zu beachten, die ich in dem anderen Thread beschrieben habe.

[mivola]

Hallo Fry,

danke für deine unermüdliche Hilfe. Noch eine letzte Bitte: ich finde einfach nicht den einen Post in dem du letztens (innerhalb der letzten 10-14 Tage?) den aktuellen Stand deines gepatchen wiregated.pl gepostet hattest. Könntest du mir da auf die Sprünge helfen? Und bestenfalls gleich noch die aktuellen/angepassten Versionen deiner Plugins (Logik, Szenen, Abwesenheit, Alarm, ...) Evtl. wäre es sinnvoll diese auch irgendwo im SVN/Git abzulegen?

Danke,
Micha

[Fry]

Voila. Modifizierter wiregated.pl, Plugins Logikprozessor, Szenencontroller, Anwesenheitssimulation und Ansagen.
Have fun,
Fry

PS Außerdem füge ich ein paar Tools bei, die allerdings meist auf meiner Art der KNX-GAs beruhen: Ich verwende kein besonders striktes GA-Schema, sondern jede GA hat als erstes Wort der Bezeichnung ein eindeutiges Kürzel ("short"). Zum Beispiel sind die GAs zum Licht anschalten/ausschalten: LI_G (Garage), LI_WZ (Wohnzimmer) und so weiter. Alle meine Plugins akzeptieren diese shorts anstelle der numerischen GAs, und ich verwende das, um alles lesbarer zu machen (nackte Zahlen sind schwer zu debuggen).

PS2. Nochmal der Hinweis: der modifizierte wiregated.pl unterstützt leider nicht die neuen Sensoren, die ElabNet rausgebracht hat. Ich warte darauf, dass ElabNet diesen wiregated.pl mit dem hauseigenen mergt. Ab dann pflege ich meine Plugins auch wieder ins SVN ein (wo ist das eigentlich? Immer noch auf Sourceforge?)

[mivola]

OK, daran könnte es liegen - ich habe den wiregated vom Fry.

Rentiert sich nicht, lange nach dem Problem zu suchen - immerhin funktioniert es ja.

Hi johnnychicago,

Ich nutze nun auch den wiregate von Fry - und habe damit auch das "URL must be absolute"-Problem. Wie hast du dies gelöst? Die Ursache glaube ich mittlerweile verstanden zu haben. Durch das PRECOMPILE ist es nicht mehr möglich "globale" Variablen (zb %settings) in subs zu verwenden.

Danke,
Micha

[mivola]

Hi johnnychicago,

Ich nutze nun auch den wiregate von Fry - und habe damit auch das "URL must be absolute"-Problem. Wie hast du dies gelöst? Die Ursache glaube ich mittlerweile verstanden zu haben. Durch das PRECOMPILE ist es nicht mehr möglich "globale" Variablen (zb %settings) in subs zu verwenden.

Danke,
Micha

Ich habs jetzt folgendermaßen hinbekommen: ich habe die sub einfach aus der .conf in den eigentlichen Logikprozessor verschoben. Also dorthin wo es hingehört. Allerdings: dadurch laufe ich natürlich Gefahr beim nächsten Update von Fry diese Änderungen versehentlich zu verlieren...

@Fry: das offizielle SVN liegt hier: Open Automation / Code / [r2210] /wiregate/plugin/generic

VG
Micha

[Fry]

don't worry Micha, der Logikprozessor ist mittlerweile ziemlich stabiler Code. Er kann einfache Empfangs-Sende-Operationen, Logiken, Triggern durch Telegrammsequenzen, Senden von Sequenzen und Timerfunktionen.

Ich ändere kaum noch was.

Übrigens wurde mit deinem letzten Update das Defaultverhalten von Logiken auf Lesetelegramme geändert: früher gab es "ignore_read_requests=>1", normalerweise wurde geantwortet. Jetzt gibt es "reply_to_read_requests=>1", normalerweise werden sie ignoriert.

Lies im Zweifelsfall die Beispiel-Config, da ist vieles beschrieben.

VG, Fry

[mivola]

Lies im Zweifelsfall die Beispiel-Config, da ist vieles beschrieben.

Das ist seit je her die beste Doku und auch eine gute Quelle für Inspirationen ;-)

Danke!
Micha

[mivola]

in der neuesten Version des Logikprozessors reicht übrigens
myrrd => { receive=>'1/2/3', rrd=>'myrrd' }

Das habe ich heute mal ausprobiert und muss leider feststellen, dass es (bei mir) nicht funktioniert :-(

Dies:

testRRD => { receive=>'6/5/51', rrd=>'testRRD', debug=>1 },

führt bei mir dazu dass
a) kein neues rrd angelegt wird
b) kein bereits existierendes rrd weitergeführt wird
c) folgenden Einträgen im Log:

2014-07-14 21:03:15.468,Logikprozessor.pl,1.1.200 6/5/51:883.84 -> $logic->{testRRD}{receive}(Logik) -> nichts zu senden;  ,0s,
2014-07-14 21:04:15.467,Logikprozessor.pl,1.1.200 6/5/51:838.4 -> $logic->{testRRD}{receive}(Logik) -> nichts zu senden;  ,0s,
2014-07-14 21:05:15.477,Logikprozessor.pl,1.1.200 6/5/51:810.88 -> $logic->{testRRD}{receive}(Logik) -> nichts zu senden;  ,0s,

Die "alte" Syntax funktioniert weiterhin problemlos:

testRRD=> { receive=>'6/5/51', translate=>sub{update_rrd('testRRD','',$input)}, debug=>1 },

Funktioniert die neue Syntax bei euch? Mache ich etwas falsch?

Danke,
Micha