Neues Plugin: Logikprozessor.pl

[johnnychicago]

... innerhalb des LP wäre es %plugin_info zu nutzen

Ich hab' daran gedacht - aber die Werte könnte ich dann nicht auch direkt in ein receive=> oder ein fetch=> legen, sondern müsste sie innerhalb der Logik aus der Variable fischen.

[mivola]

Ich hab' daran gedacht - aber die Werte könnte ich dann nicht auch direkt in ein receive=> oder ein fetch=> legen, sondern müsste sie innerhalb der Logik aus der Variable fischen.

Nein. Denn der LP würde die gespeicherten Werte beim Start auslesen und (initial 1x) auf den Bus senden. Mit einer weiteren Logik könnte man dann dafür sorgen dass der Wert fortan zyklisch gesendet wird.

So war zumindest meine Vorstellung ...

VG
Micha

[Fry]

Was meinst du? %plugin_info ist bereits an eine Datenbank geknüpft und damit persistent.

[Fry]

Gern :-)

Ist im SVN

[mivola]

Was meinst du? %plugin_info ist bereits an eine Datenbank geknüpft und damit persistent.

Ich meine #658

Ist im SVN

Super, Danke!

[johnnychicago]

Nein. Denn der LP würde die gespeicherten Werte beim Start auslesen und (initial 1x) auf den Bus senden. Mit einer weiteren Logik könnte man dann dafür sorgen dass der Wert fortan zyklisch gesendet wird.

So war zumindest meine Vorstellung ...

Das mit dem zyklischen Senden ist halt irgendwo auch nicht immer praktisch, finde ich. Ich hab' hier Werte, z.B. für die Heizungseinstellung, die sind teilweise Wochen, wenn nicht Monate alt. Und alle paar Minuten schiebt der LP sie auf den Bus (und ich nehme an, dass ein Haufen Logiken jedes Mal angekuckt werden, und nur wegen 'execute_on_input_changes_only=>' dann nicht evaluiert werden). Ich find's übersichtlicher, wenn die einfach per read request abgerufen werden können.

[mivola]

Das mit dem zyklischen Senden ist halt irgendwo auch nicht immer praktisch, finde ich. Ich hab' hier Werte, z.B. für die Heizungseinstellung, die sind teilweise Wochen, wenn nicht Monate alt. Und alle paar Minuten schiebt der LP sie auf den Bus (und ich nehme an, dass ein Haufen Logiken jedes Mal angekuckt werden, und nur wegen 'execute_on_input_changes_only=>' dann nicht evaluiert werden). Ich find's übersichtlicher, wenn die einfach per read request abgerufen werden können.

Ich persönlich habe kein Problem mit dem zyklischen Senden. Der Bus und der LP schaffen das locker und der LP ist perfomant genug... Aber jedem das seine.

Bzgl. Read-Requests: das sollte sich mit dem LP doch auch machen lassen, wenn der Wert erstmal initial auf dem Bus ist, oder? Hier hab ich leider (noch) keine Erfahrung...

VG
Micha

[johnnychicago]

Ich persönlich habe kein Problem mit dem zyklischen Senden. Der Bus und der LP schaffen das locker und der LP ist perfomant genug... Aber jedem das seine.

Du hast natürlich recht, von der Performance her ist das überhaupt kein Problem. Es ist oberflächlich Kosmetik. Mich hat es zum Beispiel gestört, als ich ein paar Logiken debuggen wollte, die sich gegenseitig beeinflusst haben: die Logiken wurden bei jedem zyklischen Senden aufgerufen und haben einen Eintrag im Log hinterlassen - auch wenn sie nichts taten.

Bzgl. Read-Requests: das sollte sich mit dem LP doch auch machen lassen, wenn der Wert erstmal initial auf dem Bus ist, oder? Hier hab ich leider (noch) keine Erfahrung...

Das funktioniert mit dem LP sehr gut, dafür gibt's reply_to_read_requests oder so...

Es geht halt nur nicht, wenn eine Logik bei der anderen anfragt.

[mivola]

Es geht halt nur nicht, wenn eine Logik bei der anderen anfragt.

Achso, OK. Jetzt habe ich das Problem verstanden. Man bräuchte also einen zweiten LP oder einen zweiten Thread ;-)

[johnnychicago]

Genau

[Bainit]

Moin,
kämpfe hier mit dem gleichen Problem.
Meine Nachtlogik im LP soll eigentlich einen Dimmwert senden, sobald der PM die Flurbeleuchtung einschaltet und die Nacht-GA auf 1 steht. Das funktioniert allerdings nur dann richtig, wenn kurz vorher der PM die Lampe ausgeschaltet hat.
Ich nehme an der LP wird dadurch getriggert, dass die Lampe ausgeht und holt sich (woher auch immer) den Status der Nacht-GA. Nur das er dass dann scheinbar sehr schnell wieder vergisst.

Wie lange bleibt der Wert einer GA eigentlich im eibd Cache? Theoretisch müsste er da ja bis Neustart bleiben. Mein Rolloaktor merkt sich einen Sperrstatus ja auch über mehrere Wochen. Damit, dass Werte nach einem Neustart weg sind, kann ich gut leben.
Da KNX keine zyklisch getriebene SPS, sondern eventgetrieben ist, halte ich das zyklische Senden einer GA, abgesehen von Sicherheitsfunktionen, für Murks.

Gruß, Sebastian

[Fry]

Warum soll zyklisches Senden Murks sein? Der Bus kann das locker ab - selbst wenn 100 Geräte jeweils 10 Telegramme zyklisch jede Minute senden würden. Und zyklisches Senden erleichtert sogar das Debuggen - weil durch Betrachten der letzten 15min des eib.log jeder Zustand jedes Aktors bekannt wird.
Was mich nervt, ist dass manche Geräte manche Zustände nicht zyklisch senden können (nicht parametrierbar). Weswegen das dann bei mir entsprechende Logiken übernehmen.
VG; Fry

[Bainit]

Moin Fry,
natürlich hat es auch Vorteile. Aber eben auch Nachteile.
Wenn ein Gerät, hier namentlich vor allem das WG, alle Zustände einfach behält, ist zyklisches Senden unnötig. Ich sehe auch keinen Grund dafür eine GA 15 min zu puffern, aber nicht 30 Tage. Vom Reboot rede ich explizit nicht.

Es fällt mir besonders beim Nachtmodus auf.
Wenn ich ins Bett gehe, schalte ich das Haus vom Bett aus in den Nachtmodus.
Dann gehen alle Lampen aus, die Rollos runter und der PM im SZ wird gesperrt.
Wenn ich nachts nochmal kurz aufstehe und ins Bett zurückkehre, will ich, dass die Lampen wieder ausgehen. Wenn ich zyklisch sende, gehen die Lampen aus, bevor ich wieder im Bett bin. Wenn ich zyklisch sende und der LP nur auf Änderungen reagiert, geht das Licht nicht aus, wenn ich im Bett erneut auf den Taster drücke.

Abgesehen davon ist da aber auch so noch etwas verquer bei mir. Ich verstehe nicht, wo der LP den Nachtmodus herholt und ihn nur sporadisch kennt, bzw. den Wert schnell vergisst.

Gruß, Sebastian

[mivola]

... innerhalb des LP wäre es %plugin_info zu nutzen, siehe: https://knx-user-forum.de/406109-post438.html

Am schönsten wäre es natürlich wenn man das nicht "selbst" in jeder Logik machen müsste, sondern mit einer Anweisung, zB:

persistValueExample => { transmit=>'2/0/3', translate => 1, persist => 1, debug=>1 },

Daraus sollte dann etwas wie "%plugin_info{Logikprozessor.pl_persistedValues_2_ 0_3} = 1" werden....

Die Werte aus %plugin_info{Logikprozessor.pl_persistedValues_*} müssten beim Start dann natürlich wieder ausgelesen und auf den Bus geschrieben werden...

Nur so als Gedankenanstoß...

VG
Micha

Ich hab mal ein Proof-of-Concept dafür erstellt. Es funktioniert folgendermaßen:

persistTest => { receive => '1/2/0', transmit => ['4/4/4', '4/4/5'], persist => 1, translate => sub { $input }, debug => 1 },

Mit dem "persist"-Parameter wird angegeben, dass man den aktuellen Wert der Transmit-GAs (in %plugin_info) persistieren möchte. Das geschieht jedesmal mal wenn die Logik ausgeführt bzw der Wert auf den Bus geschrieben wird. Beim (Re)Start des LP (nicht beim Ändern der Config!) werden die gespeicherten Werte ausgelesen und einmalig auf den Bus geschrieben.

Kombinationen mit anderen Parametern (cool, delay, ...) hab ich noch nicht getestet.

@Jacques, Fry: was haltet ihr von diesem Ansatz?

VG
Micha

[mivola]

Mit dem "persist"-Parameter wird angegeben, dass man den aktuellen Wert der Transmit-GAs (in %plugin_info) persistieren möchte. Das geschieht jedesmal mal wenn die Logik ausgeführt bzw der Wert auf den Bus geschrieben wird. Beim (Re)Start des LP (nicht beim Ändern der Config!) werden die gespeicherten Werte ausgelesen und einmalig auf den Bus geschrieben.

Beim Schreiben kamen mir erste Zweifel ob das so wie gewünscht funktioniert. Das Problem ist nun, dass das Speichern einer GA an eine bestimmte Logik gekoppelt ist, d.h. wenn eine andere Logik den Wert der GA ändert, wird er nicht persistiert. Wahrscheinlich sollte man das persistieren eher an den recieve-GAs machen? Und dann vielleicht sogar in einer dedizierten Logik:

persistTest => { receive => ['4/4/4', '4/4/5'], persist => 1, debug => 1 },

Wäre das ein besserer Ansatz?

VG
Micha