Neues Plugin: Logikprozessor.pl

[Fry]

Hi StefanW,
danke für dein Interesse! Hier meine Sicht der Dinge:

Der Logikprozessor ist auf "Logiken" limitiert, d.h. dass er Input von GAs entgegennimmt und seine Antwort (direkt, verzögert, auf Anfrage) auf EINER GA rausschickt.

Diese letzte Limitierung (EINE Output-GA) besteht ganz bewusst, denn dadurch verhält sich jede Logik wie ein eigenes KNX-Gerät, und das zwingt den Anwender, gedanklich weiter in der KNX-Welt zu bleiben.
Gleichzeitig erlaubt die knappe Logikdefinition dem Anwender, sich weiterhin auf sein KNX-System zu fokussieren und nicht mal eben zwischendurch einen ordentlichen Schluck Linux/Perl/Python oder XML zu sich nehmen.

Gegenüberstellung Plugin zu Logik:

1. Wiregate -> Wiregate-Plugin = "Turingmaschine"

"frei programmierbarer Rechner kann mit allem interfacen, u.a. auch mit KNX"

2. Logikprozessor -> Logikdefinition = "finiter Automat"

"Baustein führt klar abgegrenzte Operation im KNX-Subsystem aus (und emuliert damit wohl alle auf dem Markt verfügbaren KNX-Logikbausteine)."

Vorteil ist, dass diese klar abgegrenzten Logikaufgaben sehr viel weniger Definitionstext brauchen, als ein volles Wiregate-Plugin mit gleicher Funktionalität benötigen würde. Damit werden einfache Aufgaben einfacher zu lösen, gerade für Anfänger.

Der Nachteil ist die Limitierung, denn der Logikprozessor ersetzt NICHT das allgemeine Plugin. Beispielsweise könnte man ein Russound-RIO-Interface a la ChrisM nicht als einfachen Logikbaustein formulieren. Muss man aber auch nicht.

Zum Schluss: man _könnte_ eine solche Logikengine auch aus den Plugins rauslösen und in die Wiregate-Kernfunktionalität integrieren. Ich sehe darin allerdings nur dann Vorteile, wenn die Plugins auf alle Ewigkeit hin non-threaded und blocking bleiben würden. Die Logik-Engine ist mit Sicherheit leichter threaded zu implementieren als die Plugin-Engine, weil die Logiken - anders als die Plugins außer über KNX nicht miteinander kommunizieren - zumindest nicht wenn "used as intended".

Ob man auch einen grafischen Editor für solche Logiken schreiben könnte? "Man" sicher, "ich" nicht :-)

VG, Fry

[Plusch]

Hallo,

Habe nun die GA in die eibga.conf eingefügt allerdings funktioniert der Timer immer noch nicht. KNXwrite sollte eigentlich funktionieren da es in anderen (bei mir funktionierenden) Plugins auch genutzt wird.

Gruß
Plusch

[Fry]

Leider ist ein Debugging auf die Entfernung schwierig.

Zur Sicherheit:

* wiregate-Daemon neu starten (entweder auf der Kommandozeile "/etc/init.d/wiregated restart", oder einfach neu booten)

* IMMER nachdem du die Konfiguration änderst, auch das Plugin neu laden lassen, indem du es im Editor kurz aufrufst und ohne Änderung wieder speicherst. Der wiregate-Daemon ruft ein Plugin nach jeder Modifikation neu auf, und der Logikprozessor nutzt genau diesen Aufruf, um das Config-Skript zu lesen und die korrekten GAs zu abonnieren. Ändert man nur die Config und sonst nichts, ruft der Wiregate-Daemon NICHT automatisch das Plugin neu auf. SO kann es passieren, dass du die Config änderst, aber der Logikprozessor gar keine Chance hat, die Änderung mitzukriegen.

Falls auch das nicht hilft:

Sieh doch bitte mal im eibd.log nach, ob das ankommende Telegramm (receive) der Logik auch wirklich ankommt, ob das Plugin daraufhin aufgerufen wird (einfach ein return "Hallo" ganz oben einfügen) und ob das abgehende Telegramm (transmit) tatsächlich ausbleibt.

VG, Fry

[Fry]

@Plusch: habe gerade eine neue Version des Logikprozessors ins SVN gestellt.

Neues Feature: wenn du "debug=>1" einfügst - entweder in %logic oder in einzelnen Logikdefinitionen (also zB mylogik => {receive=>..., transmit=>..., translate=>...., debug=>1} ), dann erhältst du im Wiregate_plugin-Log entsprechende Informationen.

Wieder mal mit heißer Nadel gestrickt, also lass mich gerne wissen, ob dir das hilft.

VG
Fry

[makki]

..und ich gestern Abend eine neue Version des wiregated, es könnte gut sein das plusch da in was ganz anderes reingelaufen ist
-> Mal den Update-Knopf bemühen, das sollte sich rentieren..

Makki

[Fry]

Just for the record: nach einem online-"Supporteinsatz" bei Plusch funktioniert die Logikengine dort. Ein paar kleinere Bugs wurden dabei behoben, sowie ein Loggingfeature (debug=>1) hinzugefügt. Aktueller Code siehe SVN.
VG,
Fry

[Plusch]

Ja, durch den tollen Support von Fry haben wir den Logikprozessor zum laufen bekommen.
Danke noch mal dafür.

Plusch


Sent from my iPad using Tapatalk

[Fry]

Wieder ein neues Feature:

cool=>10

als Klausel in einer Logik bewirkt, dass während der Delay-Zeit und nach dem Senden des Ergebnistelegramms für 10s die Ausführung dieser speziellen Logik blockiert ist.

Nützlich, um Zirkellogiken einzudämmen.

Neueste Version der Engine und des dokumentierten Beispielkonfigurationsfiles im SVN

Gute Nacht,
Fry

[Fry]

Weiteres Feature: Periodische Zeitschaltuhr ebenfalls moeglich.

Als Beispiel hier eine Timer-Logik, die immer

* am jeweils zweiten Dienstag jedes Monats

* um 08:00,
* um 10:00,
* zwischen 09:00 und 09:30 alle 2min
* zwischen 18:00 und 20:00 zu jeder vollen Stunde

eine 1 auf Transmit sendet.

wecker => { transmit=>'10/1/15', timer=>{ time=>['08:00','10:00','09:00+2m-09:30','18:00+1h-20:00'], day_of_month=>[(8..14)], day_of_week=>'Di' }, translate => 1 },

Wären hier übrigens receive-Adressen spezifiziert, so würden diese NICHT abonniert und die Logik würde durch Telegramme auf receive auch nicht ausgelöst (immer so bei "timer=>..."). Aber diese receive-Adressen würden beim eingeplanten Aufruf abgefragt und die Ergebnisse in $input (bei einer receive-Adresse) bzw. @input (bei mehreren) geschrieben, bevor die Logik aufgerufen würde.

Have fun
Fry

[Fry]

...und noch was: beim Experimentieren ist mir aufgefallen, dass die von Makki bemerkten Memleaks bei Perl-eval anscheinend einzudämmen sind, indem globale Hashes vor dem return gelöscht werden (siehe Zeile vorm return). EDIT: kann sein, dass ich mich da irre. Das Löschen der Hashes bleibt aber jetzt erst mal drin, zur weiteren Beobachtung.

Der Logikprozessor ruft übrigens eval nicht häufiger auf als die meisten Plugins. Genau einmal - beim Einlesen des Konfigskriptes. Die Logiken selbst werden NICHT über eval aufgerufen, sondern sind Subroutinen-Referenzen.

Aktueller Code im SVN.

Have fun,
Fry

[Fry]

In Kombination mit dem Ansagen-Plugin kann der Logikprozessor bspw. jede Stunde die Zeit durchsagen. Bei entsprechender Pflege des /etc/wiregate/eibga.conf und mit meinem DPT10-Patch geht das mit dem Logikprozessor wieder in einer einzigen Zeile:

zeitansage => { transmit=>'WA_Uhrzeit', timer=>{ time=>['08:00+1h-20:00'] }, translate => sub { $time_of_day } },

Have fun,
Fry

[Fry]

Neue Features: Bei Timer-Logiken kann man als Einschränkungen der GeltungsTAGE nun auch Bereiche nennen (day_of_week=>'Mo-Mi', month=>'9-11'), die Einschränkungen weekday=>1 oder weekend=>1 spezifizieren und als besonderes Feature sogar holiday=>1 oder auch workingday=>1 (workingday == !weekend && !holiday) spezifizieren.

Das folgenden Konfigurationszeilen senden an Arbeitstagen um 7:30 eine 1 an die GA '1/2/3', an sonstigen Tagen erst um 9:00.

(in conf.d/Logikprozessor.conf)
%logic=(
...
    wecker1 => { transmit=>'1/2/3', timer=>{ time=>'07:30', workingday=>1 }, translate => 1 }, 
    wecker2 => { transmit=>'1/2/3', timer=>{ time=>'09:00', workingday=>0 }, translate => 1 }, 
);

Als "Holiday" (=Feiertag) wird momentan genommen: Neujahr, 1. Mai, 3. Oktober, Weihnachten/Ostern/Pfingsten, Christi Himmelfahrt und Fronleichnam.

Aktuelle Versionen des Logikprozessors im SVN.

VG,
Fry

[amaridian]

Der Nachteil ist die Limitierung, denn der Logikprozessor ersetzt NICHT das allgemeine Plugin. Beispielsweise könnte man ein Russound-RIO-Interface a la ChrisM nicht als einfachen Logikbaustein formulieren.

Mal rein zum Verständnis:

Prinzipiell funktioniert doch jede Logik/Plugin/sonsteine Funktion die man haben möchte nach dem Grundprinzip:

1) Hör auf irgendwas
2) Verarbeite das irgendwie
3) Sende irgendwas

Wobei vor allem "irgendwas" bei 1 und 3 ein recht weites Feld umfassen können (z.B. Zeitpunkte, GAs, Socket-Ereignisse, sonstwas)

Besteht das "Problem" der universelleren Funktionsweise des Plugins nicht eigentlich nur darin, dass man alle Nicht-KNX Ereignisse momentan einfach nicht abfragen/senden kann?
Viele Plugins tun doch eigentlich nichts anderes außer irgendein Fremdprotokoll sinnvoll per Befehl nutzbar zu machen und das dann irgendwie mit KNX zu verheiraten.

Würde es dann evtl. sinnvoll sein, der Logik-Engine quasi einen Protokoll-Übersetzer zur Seite zu stellen, der die Ein- und Ausgaben (auf KNX) normiert um diese dann in der Logik-Engine weiterzuverarbeiten?

Oder übersehe ich da irgendwas?

Schöne Grüße
Christian

[Fry]

Hi Christian,
danke für dein Interesse am Logikprozessor; freut mich.

Grundsätzlich hast du schon recht, und man könnte den Prozessor natürlich auch in Richtung Sockets erweitern (wobei ich selbst das momentan nur bei der Russound brauche, und da hab ich ja ChrisMs Russound-RIO-Plugin).

Vielleicht treiben wir das auch noch weiter in diese Richtung. Vorher würde ich aber gerne erstmal übers Konzept sprechen.

Denn: eigentlich war der Logikprozessor nicht als "gesattelte und eierlegende Wollmilchsau" gedacht, sondern als durchdachte Logikengine zum Ersatz eines bestimmten Typs von KNX-Device: Schaltuhren und Logikbausteine. Und die ersetzt er ganz gut, sogar Hunderte davon gleichzeitig.

Die Einschränkung auf nur eine transmit-Adresse ist daher auch Absicht. Ich fürchte, wenn man das noch weiter aufbohrt, wird die Konfiguration so kompliziert, dass Konfig-Einträge bald wieder aussehen wie komplette Plugins.

Siehe dazu auch meine Antwort auf StefanWs Frage weiter oben.
Gerne aber Diskussion dazu!

Vielleicht ist (so Makki will) so ein Logikprozessor auch Teil eines zukünftigen wiregate-Daemons? Ein Vorteil ist nämlich, dass die Logiken oft in einer einzigen Zeile konfiguriert sind - schon wesentlich kürzer als das typische Plugin...

VG,
Fry

[kleinklausi]

Feature Request Sonnenstand

Hi Fry,

wenn Du jetzt noch die Sonnenstandsberechnung einbauen würdest (siehe verschiedene Beschattungs-Plugins), könnte ich meine Beschattung hier mit bahandeln... Nur ein Vorschlag.

Gruß Moritz