|
 |
|

10.05.2012, 18:21
|
|
Erfahrener Benutzer
|
|
Registriert seit: 14.12.2011
Ort: Hessen
Beiträge: 1.011
|
|
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
|

10.05.2012, 22:08
|
|
Benutzer
|
|
Registriert seit: 05.09.2010
Beiträge: 304
|
|
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
Geändert von Plusch (28.05.2012 um 10:18 Uhr)
|

12.05.2012, 00:15
|
|
Erfahrener Benutzer
|
|
Registriert seit: 14.12.2011
Ort: Hessen
Beiträge: 1.011
|
|
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
|

12.05.2012, 10:27
|
|
Erfahrener Benutzer
|
|
Registriert seit: 14.12.2011
Ort: Hessen
Beiträge: 1.011
|
|
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.
Code:
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
|

12.05.2012, 10:30
|
|
Erfahrener Benutzer
|
|
Registriert seit: 14.12.2011
Ort: Hessen
Beiträge: 1.011
|
|
...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
Geändert von Fry (12.05.2012 um 15:12 Uhr)
|

12.05.2012, 10:35
|
|
Erfahrener Benutzer
|
|
Registriert seit: 14.12.2011
Ort: Hessen
Beiträge: 1.011
|
|
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:
Code:
zeitansage => { transmit=>'WA_Uhrzeit', timer=>{ time=>['08:00+1h-20:00'] }, translate => sub { $time_of_day } },
Have fun,
Fry
Geändert von Fry (12.05.2012 um 10:46 Uhr)
|

17.05.2012, 23:02
|
|
Erfahrener Benutzer
|
|
Registriert seit: 14.12.2011
Ort: Hessen
Beiträge: 1.011
|
|
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.
Code:
(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
|

18.05.2012, 01:17
|
 |
Benutzer
|
|
Registriert seit: 04.10.2010
Beiträge: 451
|
|
Zitat von Fry
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
|

18.05.2012, 07:16
|
|
Erfahrener Benutzer
|
|
Registriert seit: 14.12.2011
Ort: Hessen
Beiträge: 1.011
|
|
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
|

18.05.2012, 10:02
|
|
Benutzer
|
|
Registriert seit: 05.03.2010
Ort: Karlsruhe
Beiträge: 413
|
|
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
|
| Themen-Optionen |
|
|
| Ansicht |
Linear-Darstellung
|
Forumregeln
|
Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.
HTML-Code ist aus.
|
|
|
Alle Zeitangaben in WEZ +2. Es ist jetzt 07:33 Uhr.
|