Neues Plugin: Logikprozessor.pl

[Fry]

Hm. Ich verstehe nicht, was daran neu sein soll.

Mit reply_to_read_requests=>1 geschieht genau das: transmit-Werte der Logik werden in %plugin_info gespeichert (zB Logikprozessor Zeile 1484), auch welche, die von write-Telegrammen außerhalb dieser Logik kommen (Zeile 538), und spätere read-requests werden mit dem gespeicherten Wert beantwortet (Logikprozessor Zeile 498ff).

Falls mehrere Logiken die gleiche Adresse speichern und beantworten wuerden, wird auch das korrigiert (im Logikprozessor Zeile 188ff).

reply_to_read_requests=>1 wird ignoriert, wenn die Logik mehrere transmit-Adressen hat (Logikprozessor Zeile 208). Der Fall war mir zu komplex - nicht zum Implementieren, sondern zum Debuggen der späteren Fehlermöglichkeiten und Nebeneffekte.

Das Feature ist auch in der Sample-Conf beschrieben ("Memory"-Logik) Also was fehlt da?

Eine Sache, die möglicherweise fehlt, ist: response-Telegramme anderer Logiken oder KNX-Devices werden nicht bemerkt, weil man die nicht "subscriben" kann. Da aber sowieso immer nur ein Gerät einen Status speichern und responses schicken sollte, ist das mE kein Bug, sondern ein Feature.

Vg, Fry

[mivola]

Hm. Ich verstehe nicht, was daran neu sein soll.

Mit reply_to_read_requests=>1 geschieht genau das: transmit-Werte der Logik werden in %plugin_info gespeichert (zB Logikprozessor Zeile 1484), auch welche, die von write-Telegrammen außerhalb dieser Logik kommen (Zeile 538), und spätere read-requests werden mit dem gespeicherten Wert beantwortet (Logikprozessor Zeile 498ff).

Hm, dass "reply_to_read_requests" so mächtig ist und auch nach Neustart des LP funktioniert, war mir nicht bewusst. Und zugegebenermaßen hatte ich vor kurzem auch Probleme mit einem Read-Request auf eine GA auf die der LP eigentlich antworten sollte (per reply_to_read_request): es kam halt einfach kein Response. Abhilfe schaffte dann das einmalige Senden eines Wertes auf diese GA (per Visu). Hier die entsprechende Logik - evtl vertragen sich die verschiedenen Parameter nicht?

$logic{'memory'.$name} = { receive=>$ga, transmit=>$ga, reply_to_read_requests=>1, translate=>sub{return $input}, delay=>300, debug=>0},

Ich möchte mit der Logik folgendes Erreichen:
- periodisches Senden auf die Transmit-GA
- Erhalt des GA-Werts auch nach LP/wiregated/eibd-Neustart
- die GA wird ausschließlich in der Visu und im LP benutzt
- evtl fehlt hier noch ein transmit_on_startup damit nach einem Neustart initial der Wert gesendet wird und das periodische Senden anstößt?


Hier noch eine Beschreibung von johnnychicago, was er eigentlich gern erreichen möchte: https://knx-user-forum.de/456993-post656.html. Aber evtl. ist das auch einfach eine "falsche" Benutzung des LP?

Danke,
Micha

[Fry]

Hm, dass "reply_to_read_requests" so mächtig ist und auch nach Neustart des LP funktioniert, war mir nicht bewusst.

Den Neustart haben die Resultate bisher nicht überlebt, weil sie bei Initialisierung geloescht wurden. Das war aber ein Bug bzw. Relikt aus alten Tagen. Sinnvoll ist, dass die Werte überleben. Gerade im SVN angepasst. (Logikprozessor Zeile 115ff)

Und zugegebenermaßen hatte ich vor kurzem auch Probleme mit einem Read-Request auf eine GA auf die der LP eigentlich antworten sollte (per reply_to_read_request): es kam halt einfach kein Response. Abhilfe schaffte dann das einmalige Senden eines Wertes auf diese GA (per Visu).

Das ist ja dann einfach zu erklären: es war vorher kein Wert gespeichert, bzw. wurde bei Neustart gelöscht. Sollte ab jetzt dann klappen. Wie auch deine angehängte Logik.

Der Haken bisher war einfach, dass bei einem Neustart/Neukonfiguration die entsprechenden Variablen in %plugin_info geloescht wurden (Zeile 115ff), um %plugin_info nicht zuzumüllen. Wenn das aber keine Sorge ist, kannst du den Block um Zeile 115 sogar auskommentieren.

VG, Fry

[johnnychicago]

Hm. Ich verstehe nicht, was daran neu sein soll.

Mit reply_to_read_requests=>1 geschieht genau das: transmit-Werte der Logik werden in %plugin_info gespeichert (zB Logikprozessor Zeile 1484), auch welche, die von write-Telegrammen außerhalb dieser Logik kommen (Zeile 538), und spätere read-requests werden mit dem gespeicherten Wert beantwortet (Logikprozessor Zeile 498ff).

Das an sich habe ich getestet, das funktioniert auch. Aber es löst nicht mein Problem.

Mein Problem ist es, dass der read-request, der von einer Logik kommt, erst durch den Logikprozessor beantwortet wird, wenn die fragende Logik abgearbeitet wurde. Der reply_to_read_requests ist also nur sinnvoll, wenn der read-request von woanders als dem Wiregate kommt.

Nun könnte ich in Logiken halt nicht mit der GA operieren, sondern mit %plugin_info - aber das wird dann sehr schnell hässlich: immerhin müsste ich dann auf die GA hören (mit receive oder trigger), aber den Wert aus plugin_info holen, und ausserdem hoffen, dass die Logik, die aus der GA nach %plugin_info schreibt, vor meiner Logik abgearbeitet wird.

Da ist mir die linknx-Lösung momentan doch einfacher. In meiner Logik ist das einfach das designierte Gerät, das diese GA besitzt und auf read requests antwortet. So wie ein Schaltaktor halt den Zustand eines seiner Relais besitzt und darauf antwortet.

[mivola]

Den Neustart haben die Resultate bisher nicht überlebt, weil sie bei Initialisierung geloescht wurden. Das war aber ein Bug bzw. Relikt aus alten Tagen. Sinnvoll ist, dass die Werte überleben. Gerade im SVN angepasst. (Logikprozessor Zeile 115ff)

Ahhhh. Gut, dann macht das alles einen Sinn und ich probiere mal die neue Version aus.

Danke!!
Micha

[Dirk42]

Hallo Fry,

ich bin mir nicht ganz sicher, ob ich die aktuellste LP Version habe (SVN mag mich grade nicht): Bei meinem LP bleiben auch die Results von gelöschten Logiken erhalten (also zB Logikprozessor.pl__Test_Bingo_result von Stefan U's Tests). Wahrscheinlich würde das auch in den Bereich um Zeile 115 gehören...?

Viele Grüße

Dirk

[Fry]

Also bisher war es nie eine Priorität, %plugin_info möglichst klein zu halten - da liegt auch bei mir allerhand Müll drin. Wer nichts Wichtiges dort gespeichert hat - was man sowieso nicht tun sollte - kann auch einfach /etc/wiregate/wiregate_plugin.db und /tmp/wiregate_plugin.db löschen und den wiregated neu starten. Besser aufräumen kann man gar nicht.

Der LP löscht bei seiner Initialisierung (um Zeile 115 rum) deshalb nur Variablen, von denen er _sicher_ ist, dass sie nicht mehr gebraucht werden. Das sind u.a. Resultate von nicht (mehr) existierenden Logiken. Die _sollten_ also eigentlich schon gelöscht werden. Seltsam, wenn das bei dir nicht passiert.

Mach mal svn update, es sollte Revision 2358 rauskommen, dann hast du die aktuelle Version.

Vg, Fry

[Fry]

Die zweiteinfachste Art, Einträge in %plugin_info loszuwerden - neben dem kompletten Löschen der DB - ist ein kleines Plugin "Debug.pl" zu erstellen. In dieses einfach reinschreiben:

for (grep /Logikprozessor.pl__Test/, keys %plugin_info)
{
delete $plugin_info{$_};
}

und abspeichern. Der wiregate-Daemon führt es aus, und dann das kleine Hilfs-Plugin einfach wieder löschen.

VG, Fry

[pbm]

Nabend,

ich hab ne kurze Frage zu einer Logik.

Bisher hab ich Alles hinbekommen, was ich wollte und freue mich jeden Tag aufs neue über den Logikprozessor!

An dieser Logik probiere ich mich schon seit mehreren Tagen, und steh mittlerweile auf dem Schlauch...


Logik (hier mal 2 Versionen davon):

aussenbeleuchtung_strasse_ein_morgens_1 => { fetch=>'9/1/21', transmit=>['1/0/73'], timer=>{ time=>['21:57'] }, translate => sub { if ($input==1) {return 1;} else {return undef;}}, debug=>1 },

aussenbeleuchtung_strasse_ein_morgens_2 => { fetch=>'9/1/21', transmit=>['1/0/73'], timer=>{ time=>['21:58'] }, translate => sub { return (int($input)==1 ? 1 : undef) }, debug=>1 },

9/1/21 ist 1 (wird vom LP in einer anderen Logik ermittelt)

hell_oder_dunkel => { receive=>'9/1/20', transmit=>'9/1/21', transmit_changes_only=>1, translate => sub { return unless $input; $input < 100 ? 1 : 0; } },

(das funktioniert, von 9/1/21 wird auch erfolgreich in andern Logiken gebrauch gemacht)


Das Ergebnis im Log ist nur:
2015-02-18 21:57:02.347,Logikprozessor.pl,Naechster Aufruf der timer-Logik 'aussenbeleuchtung_strasse_ein_morgens_1' morgen um 21:57.
2015-02-18 21:57:02.347,Logikprozessor.pl aussenbeleuchtung_strasse_ein_morgens_1,logic took 1.0s (timer)
2015-02-18 21:58:01.683,Logikprozessor.pl,Naechster Aufruf der timer-Logik 'aussenbeleuchtung_strasse_ein_morgens_2' morgen um 21:58.
2015-02-18 21:58:01.684,Logikprozessor.pl aussenbeleuchtung_strasse_ein_morgens_2,logic took 1.0s (timer)

und auf der 1/0/73 wird nichts geschrieben...


ich hätte jetzt etwas wie
Logikprozessor.pl,$logic->{aussenbeleuchtung_strasse_ein_morgens_1}{transmi t}(Logik) -> 1/0/73:1 gesendet (timer); ,0.3s,

im Log erwartet. Kommt aber nicht... :-(

("fetch" mit "receive" ersetzt, liefert das gleiche Ergebnis)


Hat jemand ne Idee?

(WG Version 1.2)
(LP Version 2358)

[tger977]

eine Vermutung:

Da der Wert in 9/1/21 offensichtlich nur selten geschrieben wird ist der Wert nicht im eibd Cache, d.h. das fetch muss einen KNX read Befehl absetzen. Da kann es sein daß die Antwort zu lange dauert und damit der Wert beim Ausführen der Logik auf undef steht.

Versuche mal die 9/1/21 zyklisch zu senden oder die Cachedauer (geht glaub ich mit einer Option eidbcache oder ähnlichem) zu erhöhen.

[pbm]

die idee ist gut.

es scheint in die Richtung zu gehen.

habe gerade mal mit dem ETS-Gruppenmonitor auf der 9/1/21 versucht zu "lesen". kommt keine Antwort...

auch wenn ich die 9/1/21 schreibe und sofort danach wieder lese: keine Antwort...

die 9/1/21 scheint nicht im eibd-cache vorhanden zu sein.

sollte sie aber eigentlich, oder?

[tger977]

was auch nicht verwunderlich ist wenn die Adresse nur über die oben gepostete Logik geschrieben wird! Da fehlt die Option reply_to_read_requests=>1. Nur dann wird die Logik auf Lesetelegramme der ETS antworten.

Im eibd Cache (und daraus bedient sich der LP als erstes, sprich Logiken können den Wert "sehen", andere KNX Teilnehmer aber nicht) bleibt der Wert auch nur für 300s (falls Du nicht über die eibdcache Option das veränderst...)

[pbm]

jetzt wird auf ein "lesen" geantwortet!

ich hab nochmal die Sample-Config gelesen, da stehts drin...

15. Falls Read-Requests an die transmit-Adresse einer Logik geschickt werden, so wird das normalerweise ignoriert,
es sei denn, reply_to_read_requests=>1 oder transmit_only_on_requests=>1 ist gesetzt...

Wer lesen kann ist klar im Vorteil...


die zweite der beiden Logik-Versionen macht jetzt auch was sie soll.

aussenbeleuchtung_strasse_ein_morgens_1 => { fetch=>'9/1/21', transmit=>['1/0/73'], timer=>{ time=>['22:55'] }, translate => sub { if ($input==1) {return 1;} else {return undef;}}, debug=>1 },
aussenbeleuchtung_strasse_ein_morgens_2 => { fetch=>'9/1/21', transmit=>['1/0/73'], timer=>{ time=>['22:56'] }, translate => sub { return (int($input)==1 ? 1 : undef) }, debug=>1 },

Log:
2015-02-19 22:55:01.542,Logikprozessor.pl,Naechster Aufruf der timer-Logik 'aussenbeleuchtung_strasse_ein_morgens_1' morgen um 22:55.
2015-02-19 22:55:01.543,Logikprozessor.pl aussenbeleuchtung_strasse_ein_morgens_1,logic took 1.0s (timer)
2015-02-19 22:56:00.380,Logikprozessor.pl,Naechster Aufruf der timer-Logik 'aussenbeleuchtung_strasse_ein_morgens_2' morgen um 22:56.
2015-02-19 22:56:00.429,Logikprozessor.pl,$logic->{aussenbeleuchtung_strasse_ein_morgens_2}{transmi t}(Logik) -> [1/0/73]:1 gesendet (timer); ,0s,


Damit ist das Thema erledigt. Vielen Dank.

Aber kann mir jemand erklären, warum der Inhalt von sub {} bei der ersten Logik nicht funktioniert?

[mivola]

Aber kann mir jemand erklären, warum der Inhalt von sub {} bei der ersten Logik nicht funktioniert?

Versuch es mal mit einem "int" um "$input":

int($input)

VG
Micha

[pbm]

danke micha. so geht's!

aussenbeleuchtung_strasse_ein_morgens_1 => { fetch=>'9/1/21', transmit=>['1/0/73'], timer=>{ time=>['22:41'] }, translate => sub { if (int($input)==1) {return 1;} else {return undef;} }, debug=>1 },