Neues Plugin: Logikprozessor.pl

[Fry]

Eine vernünftige Doku (statt der Sample-Config) könnte man ja mal machen (einfach aus der Sample-Config rauskopieren und besser formatieren).

[bluegaspode]

Ein Hinweis von meiner Seite: wenn durch einen dieser Bugfixes das Verhalten des LP verändert wird, sollte explizit darauf hingewiesen werden.

Das betrifft zB den Fall receive==transmit. Ohne "delay" macht das wenig Sinn und wird vom LP abgefangen in der Weise, dass er versucht eine Endlosschleife zu vermeiden. Mit "delay" hat das eine (sogar häufige) Anwendung, nämlcih als "Repeater" für Zustände von Aktoren, die ihren Zustand nicht regelmäßig senden können. Das ist zB bei mir so für die Stellwerte der Heizungsventile.

Explizit Verhalten geändert habe ich nicht. Nur die Doku angepasst auf das von mir beobachtete Verhalten.
Das einfache von dir dokumentierte Treppenlicht-Beispiel

[COLOR=#0086B3][FONT=Consolas]stair[/FONT][/COLOR][COLOR=#333333][FONT=Consolas] [/FONT][/COLOR][COLOR=#A71D5D][FONT=Consolas]=>[/FONT][/COLOR][COLOR=#333333][FONT=Consolas] { [/FONT][/COLOR][COLOR=#0086B3][FONT=Consolas]receive[/FONT][/COLOR][COLOR=#A71D5D][FONT=Consolas]=>[/FONT][/COLOR][COLOR=#183691][FONT=Consolas]'1/2/9'[/FONT][/COLOR][COLOR=#333333][FONT=Consolas], [/FONT][/COLOR][COLOR=#0086B3][FONT=Consolas]transmit[/FONT][/COLOR][COLOR=#A71D5D][FONT=Consolas]=>[/FONT][/COLOR][COLOR=#183691][FONT=Consolas]'1/2/9'[/FONT][/COLOR][COLOR=#333333][FONT=Consolas], [/FONT][/COLOR][COLOR=#0086B3][FONT=Consolas]delay[/FONT][/COLOR][COLOR=#A71D5D][FONT=Consolas]=>[/FONT][/COLOR][COLOR=#333333][FONT=Consolas]600, [/FONT][/COLOR][COLOR=#0086B3][FONT=Consolas]translate[/FONT][/COLOR][COLOR=#333333][FONT=Consolas] [/FONT][/COLOR][COLOR=#A71D5D][FONT=Consolas]=>[/FONT][/COLOR][COLOR=#333333][FONT=Consolas] 0, },[/FONT][/COLOR]

hat bei mir (auch vor meinen Änderungen) zu einer Endlosschleife geführt (obwohl lt. ehemaliger Doku die Endlosschleife abgefangen werden sollte).
Habe beim schnellen überfliegen auch keinen Code (mehr) gefunden, der sich um die Endlossschleife kümmern würde. eibd_backend_address wird z.B. nur noch für Log-Ausgaben mit Warnungen vor einer cycle-Logik verwendet. Das ist möglicherweise so auch korrekt, denn auch alles was von der comet_visu kommt, hat die eibd_backend_address.
Siehe sonst meinen allerersten Post mit Beispiel + Logausgaben: https://knx-user-forum.de/forum/öffe...170#post842170)

[Fry]

Ja, richtig. Das "stair"-Beispiel war veraltet und fehlerhaft.

Unter "zu vermeidender Endlosschleife" habe ich Situationen verstanden, wo der LP immer wieder sich selbst antwortet, und zwar ohne Verzögerung. Sobald ein "delay" drin ist, kann so eine Endlosschleife sehr wohl die Intention des Users sein. Die Doku war in dieser Hinsicht veraltet.

Das Abfangen von (einfachen) Endlosschleifen funktionierte vielleicht mal, ist aber mittlerweile lange nicht mehr getestet worden. Es hat außerdem bei komplexeren Configs gar keine Chance - dazu müsste der LP den Code wesentlich tiefer analysieren, was wieder nicht gewünscht ist - es soll ja einfach bleiben.

Danke für deine Edits!

VG, Fry

[CornholioLU]

Hi, ich bin gerade auch bei den ersten Versuchen mit dem tollen Plugin, jedoch habe ich bei folgender Logik ein Problem:

EZWaldSperren => { receive=>['14/0/40','7/1/1'], fetch=>'6/3/3', transmit=>'6/3/3', translate => sub { (int($input->[0]) && !int($input->[1])) ? 1 : 0 }, debug=>1 },

Die Adressen sind all vom DPT typ 1.001.
Ziel der Logik ist die Jalousie zu sperren (6/3/3 -> 1) (und dementsprechend hoch zu fahren) wenn das Fenster geöffnet (7/1/1 -> 0) wird. 14/0/40 ist ein globaler "Schalter" um dieses Sperren über den Fenstergriff zu erlauben.

Nun funktioniert die Logik aber nicht immer. Meistens geht es erst beim 2. mal öffnen (also: auf -> zu -> auf), so wie hier:

2015-07-05 18:35:50.191,Logikprozessor.pl,1.1.50 7/1/1:0 -> $logic->{EZWaldSperren}{receive}(Logik) -> 6/3/3:0 gesendet; ,0.9s, 2015-07-05 18:35:53.858,Logikprozessor.pl,1.1.50 7/1/1:1 -> $logic->{EZWaldSperren}{receive}(Logik) -> 6/3/3:0 gesendet; ,0s, 2015-07-05 18:35:55.313,Logikprozessor.pl,1.1.50 7/1/1:0 -> $logic->{EZWaldSperren}{receive}(Logik) -> 6/3/3:1 gesendet; ,0s, [COLOR=#111111][FONT=Arial][SIZE=15px][/SIZE][/FONT][/COLOR]

Hat vielleicht jemand eine Idee wieso ich die Logik 2x auslösen muss damit der korrekte Wert übermittelt wird?

Danke,

Emmanuel

Ich antworte mir mal selbst:

Es scheint, als ob die Logiken in denen Werte verwendet werden die nicht im eibd cache sind (oder einfach nur älter als xxx sekunden) nicht richtig funktionieren. Ich dachte das Plugin würde beim auslösen einer Logik für sämtliche Adressen in receive und fetch die Werte anfordern und auch auf die Antwort warten. Scheint aber nicht so. Gibt es da einen Trick um solange mit der Auswertung zu warten bis sämtliche Werte gelesen wurden?
(aktuell sende ich einfach zyklisch, würde das aber lieber nicht tun)

Danke,

Emmanuel

[mivola]

Gibt es da einen Trick um solange mit der Auswertung zu warten bis sämtliche Werte gelesen wurden?
(aktuell sende ich einfach zyklisch, würde das aber lieber nicht tun)

Hi,

erstens: zyklisch senden ist nicht schlimm. Ich finde es sogar besser, da so auch ein Teilnehmer den Status bekommt, der zum initialen Sendezeitpunkt nicht "anwesend" war.
zweitens: schau mal in die conf_sample zum Stichwort eibd_cache, evtl. hilft das.

VG
Micha

[CornholioLU]

Hi,

erstens: zyklisch senden ist nicht schlimm. Ich finde es sogar besser, da so auch ein Teilnehmer den Status bekommt, der zum initialen Sendezeitpunkt nicht "anwesend" war.
zweitens: schau mal in die conf_sample zum Stichwort eibd_cache, evtl. hilft das.

VG
Micha

Hi,

in den allermeisten Fällen ist zyklisch senden ja kein Problem, nur hat es mich halt gewundert, dass nicht auf die Response zum Read gewartet wird bei den Adressen in receive und fetch.

Ich habe jetzt einfach eine Logik die alle 300sekunden im Fetch Teil sämtliche betroffenen Adressen abfragt, so müssen diese Aktoren nicht aktiv zyklisch senden und der eibd-cache bleibt trotzdem frisch:

refresh => { receive=>'14/5/100', transmit_on_startup=>1, fetch=>['6/3/5','6/3/6','6/3/15','6/3/16','6/3/2','6/3/3','6/3/13','6/3/14','6/3/4','6/3/0','6/3/1','6/3/7','6/3/8','6/3/9','6/3/10','6/3/11','6/3/12','14/0/40'], transmit=>'14/5/100', translate=>1, delay=>300 }

[Fry]

Hallo zusammen,
Die letzte Änderung von bluegaspode (das Trennen der Timer-Schleife in zwei Schleifen) hat zwar einen Bug korrigiert, aber auch dazu geführt, dass der Logikprozessor unnötigerweise für "cool"-Timer auch aufgerufen wurde (um dann nichts zu tun außer interne Verwaltung, einmal im Kreis). Das hat bei mir (>1200 Logiken) zu einer signifikanten Verlangsamung des LP geführt. Nun gepatcht und ins Github hochgeladen.
Viele Grüße,
Fry

[Fry]

@CornholioLU: für diese Aufgabe gibt es eine geschicktere Lösung: Dein umfangreicher "fetch" blockiert nämlich den Logikprozessor und damit den Wiregate für jeweils eine Sekunde, falls einer oder mehrere der Aktoren nicht antworten. Geschickter ist da ein "non-blocking-read":

knx_write('6/3/5',0,$eibgaconf{'6/3/5'}{DPTId},2); # die 2 heisst: setze read-request ab, aber warte nicht auf Antwort
...

Dieses lässt du zyklisch alle 300s laufen.

VG, Fry

[alexbeer]

Hallo,
ich habe ein Problem mit einer Logikprozessor-Regel.
Über meine Wetterstation wird bei Windalarm die Raffstore hochgefahren. Leider gibt es kein Objekt, dass bei keinem Windalarm die letzte Position angefahren wird. Daher war der Plan, per Logik auf den Windalarm zu lauschen und eine definierte Zeit später die Raffstore einfach runter zu fahren.

Folgende Logik habe ich im EInsatz:

#  Nach Auslösen des Windalarms wird mit einer Zeitverzögerung von 20 min automatisch die folgenden Raffstore heruntergefahren.
    #    10/1/3: Windalarm
    #    3/1/0:  Raffstore Schlafzimmer auf/ab
    #    3/3/13: Raffstore Wohnen auf/ab
    #    3/3/0:    Raffstore Wohnen Nord auf/ab
    #    3/3/14: Raffstore Küche auf /ab
    #    delay:    1200s = 20 min
    Windalarm_End_Shutter_down => {
                        receive=>'10/1/3',
                        transmit=>['3/1/0','3/3/13','3/3/0','3/3/14'],
                        delay=>1200,    
                        translate => sub { return 1 if $input = 1; return 0;},
                        debug=>1 },

Das läuft jedoch nicht wie geplant.

Zeitlicher Ablauf:

1. Letzter Windalarm heute:

   2015-07-25 21:30:16.786,A_GroupValue_Write,1.1.20,10/1/3,01,1,DPT_Alarm,1.005,0,low,6,T_DATA_XXX_REQ,0

2. LP-Logik wird getriggert:

   2015-07-25 21:30:16.879,Logikprozessor.pl,1.1.20 10/1/3:1 -> $logic->{Windalarm_End_Shutter_down}{receive}(Logik) -> [3/1/0,3/3/13,3/3/0,3/3/14]:1 wird in 1200s gesendet; ,0s,

3. Aktion vom LP:

   2015-07-25 21:50:16.711,A_GroupValue_Write,1.1.20,10/1/3,00,0,DPT_Alarm,1.005,0,low,6,T_DATA_XXX_REQ,0

Auf den Adressen 3/1/0,3/3/13,3/3/0,3/3/14 habe ich danach keine einträge im Protokoll mehr.

Wo ist in meiner Logik der Fehler?
Danke für jegliche Tipps.

VG Alex

[Fry]

$input = 1 ist eine Zuweisung.
Korrekt lautet es $input == 1.
VG, Fry

[alexbeer]

Danke...

[mivola]

Leider gibt es kein Objekt, dass bei keinem Windalarm die letzte Position angefahren wird. Daher war der Plan, per Logik auf den Windalarm zu lauschen und eine definierte Zeit später die Raffstore einfach runter zu fahren.

Und was ist, wenn nach 20min immer noch Wind herrscht? Fahren die Storen dann wieder hoch (weil die Wetterstation wieder Windalarm=Ein sendet)? Solltest du nicht eher auf Windalarm=Aus von der Wetterstation lauschen?

VG
Micha

[alexbeer]

Hallo Micha,
im Zweifel fahren die Raffstoren dann wieder...
das funktioniert aber so auch noch nicht zufriedenstellend, da innerhalb dieser 20 min ein neuer Status auf der lauschenden GA kommt und somit die 20 min von neu starten - hab ich zumindest den Eindruck.

Dein Einwand ist daher mehr als berechtigt.... Ich werde das mal umbauen.
VG Alex

[bluegaspode]

Jetzt benötige ich doch nochmal Hilfe, denn meine Beregnungslogik funktioniert immer noch nicht wie gewünscht
Zur Problemvorstellung, in der Visu habe ich die folgenden 2 Buttons:



"Beregnung Aktiviert" geht direkt auf das Sperrobjekt meines Aktors. Ich kann damit dauerhaft und unbefristet unabhängig von irgendeiner Logik die Beregnung stoppen.
"Einmalig Aussetzen" wird derzeit noch manuell zu Regenzeiten verwendet. Der Button geht auf eine virtuelle GA. Wird der Button aktiviert, wird auch automatisch die Beregnung gesperrt (funktioniert soweit).
An jedem Tag um 09:00 Uhr soll geprüft werden, ob "Einmalig Aussetzen" aktiviert ist. Falls ja, wird die Sperre zurückgenommen. Diese Logik funktioniert aber nicht.

Hier mein aktueller Code:

# wenn einmalige Sperre aktiviert (oder deaktiviert) wird, dieses auf die eigentliche Sperre übertragen
einmalige_sperre_bewaesserung_uebertragen => {
    receive => '15/2/0',
    transmit => '15/0/0', 
    translate => sub {$input}, 
    debug => 1
},

memory_einmalige_sperre => { transmit=>'15/2/0', reply_to_read_requests=>1, debug => 1 },

# wenn einmalige Sperre aktiviert, dann zum gegebenen Zeitpunkt die einmalige Sperre zurücksetzen.
# über die Logik "einmalige_sperre_bewaesserung_uebertragen" wirkt sich das ganze auch auf die Hauptsperre aus
einmalige_sperre_bewaesserung_loesen => {
  fetch => '15/2/0',
  transmit => '15/2/0',
  timer=>{ time=>['09:00'], },
  translate => sub {
    return ($input eq 1) ? 0 : undef;
  }, 
  debug => 1
},

Wie ihr seht, dreht sich alles um die GA '15/2/0'. Diese gehört zum zweiten Button.
'einmalige_sperre_bewaesserung_uebertragen' => funktioniert. Sorgt dafür, dass der zweite Button seine Befehle auf den ersten überträgt.
'memory_einmalige_sperre' => soll den aktuellen Status der virtuellen GA verwalten => Read Request werden korrekt mit dem aktuellen Status beantwortet
'einmalige_sperre_bewaesserung_loesen' => ist mein Sorgenkind.

Der 'fetch' auf 15/2/0 läuft irgendwie ins Leere und ist morgens um 09:00 IMMER '0' (auch wenn der Button aktiviert ist). Interessanterweise bemerke ich dass ein knx_read ausgeführt wird der sogar eine '1' liefert. Aber da scheint die Logik schon längst ausgeführt worden zu sein mit irgendeinem uninitialisiertem Wert?

[mivola]

Der 'fetch' auf 15/2/0 läuft irgendwie ins Leere und ist morgens um 09:00 IMMER '0' (auch wenn der Button aktiviert ist). Interessanterweise bemerke ich dass ein knx_read ausgeführt wird der sogar eine '1' liefert. Aber da scheint die Logik schon längst ausgeführt worden zu sein mit irgendeinem uninitialisiertem Wert?

Ich würde mit zyklischen Telegrammen dafür sorgen dass der Wert auf 15/2/0 immer "frisch" ist. Alternativ könntest du auch mal eibd_cache versuchen (siehe: conf_sample), evtl. hilft das. Zum Debuggen hilft auch immer eine Ausgabe der Werte per plugin_log().

VG
Micha