Ankündigung

Einklappen
Keine Ankündigung bisher.

Neues Plugin: Logikprozessor.pl

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    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.:

    Code:
    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

    Kommentar


      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
      Baustelle 2.0 (Detailprogrammierung und Restarbeiten)
      Ruhri? -> Komm zum Stammtisch

      Kommentar


        Zitat von Bainit Beitrag anzeigen
        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

        Kommentar


          Zitat von mivola Beitrag anzeigen
          => 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
          Baustelle 2.0 (Detailprogrammierung und Restarbeiten)
          Ruhri? -> Komm zum Stammtisch

          Kommentar


            Zitat von Bainit Beitrag anzeigen
            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...

            Zitat von Bainit Beitrag anzeigen
            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

            Kommentar


              Zitat von mivola Beitrag anzeigen
              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
              Baustelle 2.0 (Detailprogrammierung und Restarbeiten)
              Ruhri? -> Komm zum Stammtisch

              Kommentar


                Zitat von Bainit Beitrag anzeigen
                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

                Kommentar


                  Zitat von Fry Beitrag anzeigen
                  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

                  Kommentar


                    Zitat von kingolli Beitrag anzeigen
                    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:
                    Code:
                    #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

                    Kommentar


                      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:

                      Code:
                      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
                      Gruß
                      Andi

                      Kommentar


                        Zitat von kingolli Beitrag anzeigen
                        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.

                        Kommentar


                          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:

                          Code:
                          # 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
                          Gruß
                          Andi

                          Kommentar


                            Prowl mit neuem Logikprozessor.pl

                            Zitat von zitterfritz Beitrag anzeigen
                            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.
                            Baustelle 2.0 (Detailprogrammierung und Restarbeiten)
                            Ruhri? -> Komm zum Stammtisch

                            Kommentar


                              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:
                              Code:
                                  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:
                              Code:
                              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

                              Kommentar


                                Setz mal die Transmit Adresse in eckige Klammer!


                                Ich hatte jetzt keine Zeit den Code anzuschauen, aber heute folgendes rausgefunden:
                                Code:
                                  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:
                                Code:
                                2014-08-24 10:46:06.973,Logikprozessor,$logic{szene_delayedtrigger_gartenlicht_lang}{transmit}(Logik) -> 2/1/7:1 gesendet (delayed);  ,0s,

                                Kommentar

                                Lädt...
                                X