Neues Plugin: Logikprozessor.pl

[mivola]

Und da aller guten Dinge 3 sind, noch eine Frage: Kann man das "execute_on_input_changes_only" auf bestimmte Input-Werte beschränken? Z.B.:

receive=>'5/2/5', fetch=>'3/2/5', transmit=>'3/2/14', execute_on_input_changes_only=>1

Hier will ich eigentlich dass die Logik nur dann ausgeführt wird, wenn sich der Wert der receive-Adresse geändert hat. Der fetch-Wert soll für die Überprüfung ob die Logik ausgeführt wird oder nicht, gar nicht betrachtet werden. Also etwas wie "execute_on_receive_changes_only" wäre hilfreich. Oder etwas generischer a la trigger-style: " receive=>'5/2/5==changed' "?

Danke,
Micha

[Bainit]

Moin Micha,

fetch triggert die Logik grundsätzlich nicht. Egal ob sich ein Wert einer Fetch-Adresse ändert oder ohne Änderung empfangen wird. Dafür gibt es ja die Unterscheidung zwischen Receive und Fetch.

Gruß, Sebastian

[mivola]

fetch triggert die Logik grundsätzlich nicht.

Das stimmt. Aber trotzdem: mal angenommen:
=> auf der receive-Adresse kommt ein Telegramm
=> die Logik wird getriggert
=> der Wert der fetch-Adresse wird gelesen
=> der Wert auf der receive-Adresse hat sich nicht geändert
=> der Wert auf der fetch-Adresse hat sich geändert
=> die Logik wird ausgeführt, obwohl ich das eigentlich nicht möchte, da sich ja der Wert der receive-Adresse nicht geändert hat

Ist das so verständlich und nachvollziehbar?

Danke,
Micha

[Bainit]

=> auf der receive-Adresse kommt ein Telegramm
=> die Logik wird getriggert

so soll es sein.

=> der Wert auf der fetch-Adresse hat sich geändert
=> die Logik wird ausgeführt

Das sollte AFAIK nicht sein. Da fetch ja (eigentlich) nicht triggert.

Ist das so verständlich und nachvollziehbar?

Ja, ich verstehe, was du meinst. Wenn du das Verhalten so beobachten kannst, dann klingt das für mich nach einem Fehler des Logikprozessors.
Da scheint "execute_on_input_changes_only" nicht nur auf das Receive sondern auch auf das fetch zu wirken.

Gruß, Sebastian

[mivola]

Das sollte AFAIK nicht sein. Da fetch ja (eigentlich) nicht triggert.

das fetch triggert ja auch nicht. Der Trigger für die Logik kam ja von der receive-Adresse...

Ja, ich verstehe, was du meinst. Wenn du das Verhalten so beobachten kannst, dann klingt das für mich nach einem Fehler des Logikprozessors.
Da scheint "execute_on_input_changes_only" nicht nur auf das Receive sondern auch auf das fetch zu wirken.

Ich denke nicht, dass es ein Fehler ist. So ist es halt (momentan) spezifiziert. Sowohl receive als auch fetch füllen $input. Und mit "execute_on_input_changes_only" wird eben diese Variable/Hash/whatever auf Änderungen überprüft.

Mal schauen was Fry dazu sagt...

Danke
Micha

[Bainit]

Der Trigger für die Logik kam ja von der receive-Adresse...

Ahh, jetzt hat es bei mir klick gemacht.
Irgendwie dachte ich, dass du einen Beitrag weiter oben mehrere Ausführungen der Logik beschrieben hast.

Dann musst du in der Logik auf die Änderung von einer Receive -GA prüfen. Man kann ja in der Logik einen Wert auch in eine persistentes Objekt speichern. Und gegen diesen bei vorheriger Ausführung gespeicherten Wert kann man dann prüfen.
Das ist in diesem Thema in Beitrag 253 beschrieben:
https://knx-user-forum.de/code-schnipsel/19912-neues-plugin-logikprozessor-pl-13.html#post347413

Gruß, Sebastian

[mivola]

Dann musst du in der Logik auf die Änderung von einer Receive -GA prüfen. Man kann ja in der Logik einen Wert auch in eine persistentes Objekt speichern. Und gegen diesen bei vorheriger Ausführung gespeicherten Wert kann man dann prüfen.
Das ist in diesem Thema in Beitrag 253 beschrieben:
https://knx-user-forum.de/code-schnipsel/19912-neues-plugin-logikprozessor-pl-13.html#post347413

Ja ich weiß. So hatte/habe ich das ja bisher auch am laufen. Ist ja aber schon recht komplex und viel Boilerplate-Code. Ich dachte mit der neuen Version des LP könnte man das etwas eleganter lösen...

VG
Micha

[mivola]

Die Alarmanlage stelle ich dann auch ein, wobei (i) das ein recht simples Plugin ist, das eben auf alle Präsenzmelder und alle Fensterkontakte hört und (ii) ich das erst selbst richtig austesten möchte. Aktuell ist meine Alarmanlage noch nicht scharf, insbesondere die Tröte außen am Haus noch nicht aktiviert, weil ich nicht Software auf Kosten meiner Nachbarn testen möchte :-)

Hallo Fry,

wie ist der aktuelle Stand und dein Testfortschritt bzgl Alarmanlage?? Bei uns in der Umgebung gab es kürzlich wieder 2 "Vorkommnisse" ...

Danke,
Micha

[kingolli]

Da muss ich nochmal einhaken...

Ich habe bei mir auch auf Basis des Sonnenuntergangs die Rollläden gesteuert, einer 10min nach Sonnenuntergang, einer 20min usw alles per emx_uhr. Jetzt hätte ich aber gerne eine feste Zeit, wann der Rollladen definitiv runter gehen soll (bspw 21 Uhr) - das habe ich bisher per LP nicht hinbekommen.

Folgendes habe ich versucht:

#bei Sonnenuntergang, spätestens aber 21:00 Uhr runter
EG_Wohnen_Jalousie_ab           => { transmit=>'1/1/4', timer=>{ time=>'00:00+5m' }, eibd_cache=>86400, transmit_changes_only => 1, translate =>  sub { return unless &sonnUntOderZeit(0.4, '21:00'); 1}, debug=>1},

#bei Sonnenaufgang, frühestens aber 07:00 Uhr rauf 
EG_Wohnen_Jalousie_auf          => { transmit=>'1/1/4', timer=>{ time=>'00:00+5m' }, eibd_cache=>86400, transmit_changes_only => 1, translate =>  sub { return unless &sonnAufUndZeit (0.2, '07:00'); 0}, debug=>1},

Funktion "sonnUntOderZeit" prüft, ob die Sonnenuntergangszeit plus Parameter1 (AdditionalTime) oder den Parameter2 (LastTime) bereits erreicht sind und gibt dann entsprechend 0 oder 1 zurück, "sonnAufUndZeit" aber genauso nur anders ;-)

Problem dabei ist, dass ich nach 21 Uhr nicht mehr aufmachen kann, weil dann immer wieder ein Telegramm mit Runter geschickt würde. Was ich also bräuchte wäre eine Logik die "timer=>{time=>'SonneruntergangOder2100'}" heißt oder eine Logik die sich für den Rest des Tages selbst deaktiviert.

Jetzt habe ich versucht zu verstehen, was du mit "followup" gemeint/gemacht hast, hat aber nicht geklappt

Kannst du mir mal einen Denkanstoß dazu geben.

Grüße
David

Hat vielleicht noch jemand eine Idee zu o.g. Problem?

Danke und Grüße
David

[tger977]

Hallo,

ich stehe irgendwie auf dem Schlauch. Ich möchte gerne eine Triggerung für An/Abwesend Szenen über den Haustürriegelkontakt und den Präsenzmelder hinter der Tür realisieren.

Dazu habe ich den PM nun so eingestellt daß er nur bei geschlossenem Riegelkontakt aktiv ist und nach 40s geschlossenem Kontakt wieder per Zwangsführung auf 0 gesetzt wird, d.h. wenn nicht innerhalb von 40s eine Bewegung (nach Reigelkontakt == 1) erkannt wird kann man davon ausgehen daß die Türe von Aussen geschlossen wurde. Damit ist nun sichergestellt daß der PM nicht direkt vor dem Riegelschliessen noch den Zustand 1 hat vom "rausgehen".

Damit benötige ich nun folgenden Ablauf:

Triggerung über 4/1/1 (Riegelkontakt) == 1 und dann gibt es zwei Fälle:
1) PM (0/0/10) meldet nochmal bewegung (=1) innerhalb 30s --> Anwesend
2) PM meldet keine Bewegung innerhalb 30s (bleibt 0) --> Abwesend

9/1/0 ist dabei die Info ob An- (0) oder Abwesend (1) die gesendet werden soll.

Nur wie löse ich das mit dem Logikprozessor?

Ich habe nun folgendes Versucht mit Trigger Konstrukt was aber zu keinerlei Ergebnis auf dem Bus führt:

AnwesendUeberTuerriegel => { trigger=>['4/1/1==1', '0/0/10==1'], 'within 30s','all_in_order', transmit=>'9/1/0', translate=>0, debug=>1},
AbwesendUeberTuerriegel => { trigger=>['4/1/1==1', '0/0/10<1'], 'within 30s','all_in_order', transmit=>'9/1/0', translate=>1, debug=>1},

Evtl. geht es aber auch irgendwie über Timer? Ich bekomme es einfach nicht auf die Reihe wie man 30s nach Trigger eine zweite GA "beobachten" kann...

Gruß
Andi

[johnnychicago]

Hat vielleicht noch jemand eine Idee zu o.g. Problem?

Schon mal daran gedacht, die Dinge zu trennen?

Z.B. beim Sonnenuntergang: Deine Automatik rechnet aus, was wann passieren soll und triggert respektive die einzelnen Rolläden. Daneben sitzt in einer separaten Logik ein einfacher Timer, der um 21:00 die Zentral-GA aufruft. Was auch immer um 21:00 noch nicht unten ist, fährt dann halt. Der Aktor kriegt dann zweimal den Befehl, herunterzufahren. Da wird er schon mit klarkommen.

[tger977]

An / Abwesenderkennung per Riegelkontakt und PM

so bevor sich hier neben mir noch einer den Kopf zerbricht habe ich nun doch nach etlichem probieren eine funktionierende Lösung gefunden:

# An/Abwesenderkennung
    # ===========================================================================================
    BewegungstriggerUGnachTuerriegelZU => {trigger=>'4/1/1==1', transmit=>'0/0/11', translate=>1, followup=>{'ResetBewegungstriggerUG'=>30}, debug=>1 },
    ResetBewegungstriggerUG => {transmit=>'0/0/11', translate => 0, followup=>{'AbwesendUeberTuerriegel'=>0},debug=>1},
    AbwesendUeberTuerriegel => {fetch=>'0/0/10', transmit=>'9/1/0', translate => sub{return 1 if $input==0;return undef; }, debug=>1},
    AnwesendUeberTuerriegel => {trigger=>'4/1/1==0', fetch=>'9/1/0', transmit=>'9/1/0', translate=>sub{return 0 if $input==1; return undef;}, debug=>1 },

Ist nun halt über den Umweg einer Hilfs-GA 0/0/11 die den Bewegungszeitraum signalisiert. Anders habe ich das mit dem followup nicht hinbekommen da man dafür wohl ein transmit Telegramm benötigt.

Nach erstem kurzen Test funktioniert das nun wie gewünscht: Nur wenn der Riegel zu geht und KEINE Bewegung innerhalb 30s mehr hinter der Türe detektiert wird wird das Haus auf Abwesend gesetzt (mit 9/1/0 aktiviere ich dann entsprechend Szenen Abwesend oder Anwesend)
Mit Riegel auf wird bei gesetztem Abwesend Status entsprechend der Status auf Anwesend gesetzt --> verhindert daß die Szene bei Aufschliessen von innen aufgerufen wird.

Und dann benötigt man am PM (bei mir ein MDT) noch die schon geschriebenen Einstellungen:

HLK Kanal Parameter:
Vollautomat
Nachlaufzeit: 40s
Anzahl Beobachtungsfenster: 1
Länge Beobachtungsfenster: 1s
Zwangsführungsobjekt: Sperrobjekt universal
Bei Sperrobjekt Wert=1: Automatikbetrieb
Bei Sperrobjekt Wert=0: Zwangsführung AUS

Verknüpfungen:
Ausgang HLK Kanal mit 0/0/10 verknüpfen
Eingang HLK Sperre mit 4/1/1 verknüpfen

Rest kann wie bei Default bleiben

Vielleicht hilft es so noch jemand anderem...

Gruß
Andi

[Bainit]

Prowl mit neuem Logikprozessor.pl

Jetzt hab ich versucht die prowl Funktion zu nutzen und bekomme folgende Fehlermeldung wenn versucht wird eine Meldung abzuschicken:

500 Can't locate object method "new" via package "LWP::Protocol::https::Socket"

Hab rausgefunden, dass da libcrypt-ssleay-perl installiert werden sollte.

Moin,
gibt es hierzu schon etwas Neues?
Habe ebenfalls Fry's Version des Logikprozessors und den angepassten wirgated.pl installiert. Seit dem geht Prowl nicht mehr sondern wirft obige Fehlermeldung.
Auf Verdacht diverse Pakete zu installieren traue ich mich aber leider auch nicht.

Gruß, Sebastian

P.S.: die neue Version scheint tatsächlich deutlich schneller zu sein. Danke Fry. Großartige Arbeit.

[chriss1980]

Hallo zusammen,

ich habe leider noch ein kleines Problem mit dem Logikprozessor. Ich habe regelmäßig den Gradienten (also die Änderung) der Luffeuchtigkeit meines Badezimmers auf dem Bus und möchte bei starkem Anstieg (Erkennung: Duschen/Baden - funktioniert eigentlich sehr zuverlässig) die Lüftungsanlage für 30min hochfahren. Dazu habe ich folgende Logik erstellt:

    LueftungBedarfHumidityGradientBadOG => {
        debug => 1,
        receive => '3/4/35',
        transmit => '3/3/201',
        transmit_changes_only => 1,
        translate => sub { return( $input > 2 ) ? 1 : undef }},
    # Nach 1800s = 30min den Lueftungsbedarf zurücknehmen
    LueftungBedarfHumidityGradientDelayBadOG => {
        debug => 1,
        receive => '3/3/201',
        transmit => '3/3/201',
        delay => 1800,
        translate => 0 },

3/4/35 ist der Gradient der Luftfeuchtigkeit, 3/3/201 schaltet die Stoßlüftung.

Mein Problem ist, dass offenbar die erste Logik sehr regelmäßig eine '1' auf den Bus schickt (verifiziert mit dem ETS-Busmonitor; wenn die Logik auskommentiert wird, passiert es nicht) obwohl das Plugin-Log sagt:

2014-08-18 10:29:35.405,Logikprozessor,3/4/35:0 -> $logic{LueftungBedarfHumidityGradientBadOG}{receive}(Logik) -> nichts zu senden ,0.3s,
2014-08-18 10:30:35.025,Logikprozessor,3/4/35:0 -> $logic{LueftungBedarfHumidityGradientBadOG}{receive}(Logik) -> nichts zu senden ,0.3s,
2014-08-18 10:31:47.933,Logikprozessor,3/4/35:0 -> $logic{LueftungBedarfHumidityGradientBadOG}{receive}(Logik) -> nichts zu senden ,0s,
2014-08-18 10:32:39.331,Logikprozessor,3/4/35:0 -> $logic{LueftungBedarfHumidityGradientBadOG}{receive}(Logik) -> nichts zu senden ,0.3s,
2014-08-18 10:33:39.754,Logikprozessor,3/4/35:0 -> $logic{LueftungBedarfHumidityGradientBadOG}{receive}(Logik) -> nichts zu senden ,0.3s,
2014-08-18 10:34:39.893,Logikprozessor,3/4/35:0 -> $logic{LueftungBedarfHumidityGradientBadOG}{receive}(Logik) -> nichts zu senden ,0s,
2014-08-18 10:35:40.231,Logikprozessor,3/4/35:0 -> $logic{LueftungBedarfHumidityGradientBadOG}{receive}(Logik) -> nichts zu senden ,0.3s

Dadurch wird die Stoßlüftungsfunktion natürlich nie zurückgenommen.

Was mache ich falsch?

Danke
Christian

[Wookie81]

Setz mal die Transmit Adresse in eckige Klammer!


Ich hatte jetzt keine Zeit den Code anzuschauen, aber heute folgendes rausgefunden:

  szene_delayedtrigger_gartenlicht_kurz => { receive=>'11/0/200', transmit=>['2/1/7'], translate => 0, delay=>90},
  szene_delayedtrigger_gartenlicht_lang => { receive=>'11/0/201', transmit=>'2/1/7', translate => 0, delay=>300},

Wenn ich die obere Logik schreibe passt alles. Wenn ich sie wie unten ohne Klammer angeben, dann wurde immer eine 1 auf den Bus gesendet. Gruppeadresse ist korrekt exportiert (bei dir auch Christian?) und auch sonst konnte ich keinen Fehler finden.

Hat jemand eine Erklärung für das Phänomen?


edith: Der Vollständigkeit das Log:

2014-08-24 10:46:06.973,Logikprozessor,$logic{szene_delayedtrigger_gartenlicht_lang}{transmit}(Logik) -> 2/1/7:1 gesendet (delayed);  ,0s,