Neues Plugin: Logikprozessor.pl

[kingolli]

Doch, müsste so funktionieren. Wenn während der delay-Zeit eine neue Kommunikation kommt, wird der zu sendende (verzögerte) Wert durch den neu berechneten ersetzt und die Verzögerung (Delay) beginnt von neuem.

Schöner ist übrigens

return $input ? 1 : undef;

return undef bewirkt einfach, dass gar nichts gesendet wird.

Have fun, Fry

Danke für deine Antwort, aber das zurücksetzen des Wertes (was ja das löschen des Alarms ist) sollte sofort erfolgen. Theoretisch müsste ich ja dann nur eine eigene Logik einbauen, wenn alle Fenster zu sind den Alarm-Wert wieder zurück zu setzen. Ich probiere es heute Abend mal aus und geb Bescheid...

Grüße
David

[johnnychicago]

@Fry, nach den ersten kleinen Logiken für meine Zähler versuche ich gerade, mich da etwas reinzudenken. Der Logikprozessor liegt mir irgendwie näher als linknx - ich bin zwar kein Perl-Junkie, aber es liest sich doch einigermassen verständlich.

Ein Ding, bei dem ich jetzt ein paar mal drübergestolpert bin, ist die Tatsache, dass sich der Logikprozessor nicht selbst aufruft. Diese memory-Logik wäre sehr praktisch, wenn man sie innerhalb der etwas komplexeren Logiken aufrufen könnte.

Gibt's da keinen 'hübschen' Weg?

Laufen Plugins eigentlich sequentiell, oder können sie parallel ablaufen? Vielleicht könnte man einfach zwei Kopien des Logikprozessors laufen lassen...

[wuestenfuchs]

Hallo!

wir haben den Logikprozessor schon recht extensiv im Einsatz. Dank der vielen guten Beispiele hier und der sehr guten Unterstützung von Fry haben wir bisher alle Anforderungen lösen können. Was wir bisher hier nicht gefunden haben, war die Addition von Werten - vielleicht hilft unsere Lösung ja jemandem weiter:

Schaltaktoren mit Strommessung. Man will den Stromverbrauch aller drei Phasen eines Elektroherdes addieren und als Summenwert ausgeben:

herd_gesamt_stromverbrauch => { receive=>['6/5/1','6/5/2','6/5/3'], transmit=>'6/5/200', translate => sub { $input->[0] + $input->[1] + $input->[2]; }, debug=>1 },

Will man ein Telegramm absetzen, wenn der Herd, egal wieviele Phasen, in Betrieb ist, hilft folgender Code (vorausgesetzt, der Aktor unterstützt eine "In Betrieb"-Erkennung, was eigentlich bei allen Aktoren mit Strommessung der Fall ist):

herd_gesamt_in_betrieb => { receive=>['6/5/10','6/5/11','6/5/12'], transmit=>'6/5/201', translate => sub { limit(0,$input->[0] + $input->[1] + $input->[2],1); }, debug=>1 },

'limit' bewirkt, dass trotz Addition der 'In Betrieb'-Telegramme aller drei Phasen ausschließlich entweder eine '0' oder eine '1' gesendet wird.

Kleiner Tipp am Rande, weil das für uns anfangs ein unentdeckter Stolperstein war: Unsere MDT-Aktoren lieferten für bestimmte Kommunikationsobjekte keine korrekten Datentypen mit, z.B. für den Stromverbrauch, die Strommessung und die Betriebsstunden. Die muss man in der ETS manuell festlegen - ohne die korrekte Festlegung der Datentypen in der ETS funktioniert die Berechnung nicht.

[mivola]

ohne die korrekte Festlegung der Datentypen in der ETS funktioniert die Berechnung nicht.

Wären dafür nicht eher die korrekten Einträge in der eibga.conf ausschlaggebend? Der Logikprozessor kennt doch die Werte in der ETS nicht?!

VG
Micha

[wuestenfuchs]

Klar, prinzipiell schon. Wenn ich das allerdings richtig in Erinnerung habe, hat der Gruppenaddressen-Editor des Wiregate zwar die DPTSubId geändert, aber den DPT_SubTypeName nicht richtig eingetragen und somit hat der Logikprozessor nur eine Null ausgespuckt.

Das gleich in die ETS einzutragen hat für mich zwei Vorteile:

1. es ist der technisch sauberere Weg und
2. werden deine manuellen Änderungen an der eibga.conf beim nächsten ETS-Export überschrieben. Wenn du das allerdings direkt in die ETS einträgst, bleiben diese Infos bei jedem zukünftigen Export erhalten.

[mivola]

ETS-Export

Dieses Stichwort hat mir im vorherigen Post gefehlt... ;-)
Manch andere machen es allerdings anders: Pflege der DPT/GA-Daten extern (z.B. Excel) und dann Export in die ETS _und_ in die eibga.conf. Vorteil (zumindest für mich): ich kann jederzeit/überall etwas an der Struktur ändern/anpassen ohne Zugriff auf die ETS/WG zu haben. Und sobald ich wieder zu Hause bin, kann ich mit 2 kleinen Handgriffen ETS und WG auf den aktuellen Stand bringen.

VG
Micha

[wuestenfuchs]

Ja stimmt, habe ich natürlich vergessen zu erwähnen Mea maxima culpa!

[mikeeyy]

Guten Abend zusammen und kurze Frage. Hat einer von euch das Logigprozessor UND das email_triggered_by_ga Plugin ZUSAMMEN am laufen? Bei mir klappt das arbeitet das email_triggered_by_ga Plugin nicht mehr, sowie ich das Logikprozessor Plugin am laufen habe. Lösche ich das Logikprozessor Plugin, werden die Mails wieder versendet. Allerdings gibt es keine Meldungen im Protokoll. Ich lasse über das Logik Script eine Meldung auf einen GA versenden, auf die das EMail Plugin reagieren sollte. Trigger wird auch erkannt, aber mehr passiert nicht. sende ich manuell auf der GA über die ETS eine 1 wird der Trigger auch erkannt, aber keine Mail versendet. Lösche ich das Logik Plugin und löse den Trigger manuell über die ETS aus, wird die Email versendet. Irgend eine Idee hinsichtlich des Zusammenhangs???

Danke im Voraus und guten Rutsch in das neue Jahr!

Mike

[mivola]

Ich habe auch mal wieder eine Frage: gibt es eigentlich die Möglichkeit den Sender eines Telegramms zu ermitteln? Ich habe eine Logik, die nur Sender kommt. Kann mich da jmd in eine Richtung schubsen oder hat evtl. sogar ein Beispiel parat?

Danke,
Micha

[Fry]

@mikeey: keine Ahnung, aber eine Interaktion zwischen den Plugins halte ich für sehr unwahrscheinlich.

@mivola: in $mrg{src} steht die physikalische Adresse des Senders drin.

VG, Fry

[mikeeyy]

Hallo Fry. Danke für die schnelle Rückinfo. Einen echten Zusammenhang kann ich auch nicht erkennen. Allerdings ist das ganze bei mir reproduzierbar. Vielleicht hat ja noch jemand hier das gleiche Problem.
Grüße
Mike

Gesendet von meinem GT-P7501 mit Tapatalk

[Ziegelstein]

Hallo!

- vielleicht hilft unsere Lösung ja jemandem weiter:

Schaltaktoren mit Strommessung. Man will den Stromverbrauch aller drei Phasen eines Elektroherdes addieren und als Summenwert ausgeben:


Kleiner Tipp am Rande, weil das für uns anfangs ein unentdeckter Stolperstein war: Unsere MDT-Aktoren lieferten für bestimmte Kommunikationsobjekte keine korrekten Datentypen mit, z.B. für den Stromverbrauch, die Strommessung und die Betriebsstunden. Die muss man in der ETS manuell festlegen - ohne die korrekte Festlegung der Datentypen in der ETS funktioniert die Berechnung nicht.

zu diesem Punkt könnte ich einen Tipp gebrauchen:

ich hab das aufgeführte Beispiel für mich wie folgt angepasst:

stromverbrauch_heiztechnik => { receive=>['5/1/18','5/2/6','5/0/19','5/0/20'], transmit=>'10/0/1', translate => sub { $input->[0] + $input->[1] + $input->[2]+ $input->[3]; }, debug=>1 },


im logfile sieht es so aus, als wenn die Aufsummierung funktioniert und die Ausgabe in GA 10/0/1 funktioniert. --> ein Infofeld der Cometvisu auf diese GA bestätigt die richtige Ausgabe.

Jetzt soll das Ergebniss über makki's rrd-Creator plugin weiter verarbeitet werden - leider wird in den Graphen nix dargestellt. die DPT habe ich bereits kontrolliert, der eintrag in der confd. des rrd creator plugin sieht wie folgt aus:

push @rrds, { name => "Stromverbrauch_heiztechnik", ga => "10/0/1", dpt => 13.013};

Kann hier jemand sagen, wo evtl. der Fehler liegt?

hier noch die letzten Zeilen aus dem plugin logfile:
2014-01-01 15:57:51.746,Logikprozessor,1.1.22 5/1/18:4 -> $logic{stromverbrauch_heiztechnik}{receive}(Logik) -> 10/0/1:18 gesendet; ,0.3s, 2014-01-01 15:58:40.297,Logikprozessor,1.1.23 5/0/20:0 -> $logic{stromverbrauch_heiztechnik}{receive}(Logik) -> 10/0/1:18 gesendet; ,0s, 2014-01-01 15:58:41.209,Logikprozessor,1.1.23 5/2/6:3 -> $logic{stromverbrauch_heiztechnik}{receive}(Logik) -> 10/0/1:18 gesendet; ,0s, 2014-01-01 15:58:41.410,Logikprozessor,1.1.23 5/0/19:11 -> $logic{stromverbrauch_heiztechnik}{receive}(Logik) -> 10/0/1:18 gesendet; ,0.3s, 2014-01-01 16:08:42.941,Logikprozessor,10/0/1:Lesetelegramm -> $logic{stromverbrauch_heiztechnik}{transmit}(memor y) -> 10/0/1:12 gesendet; ,0s,

was mich hier nur wundert, dass auf ein lesetelegramm mit 12 geantwortet wird, mein info-feld der cometvisu aber richtigerweise 18 anzeigt..?

Vielen Dank!

[MicHau]

Wo das Problem genau liegt, weiß ich auch nicht, aber vielleicht ist es einfacher, für die RRD-Erzeugung auch den Logikprozessor zu verwenden. Ich habe die folgende Config dafür:

%logic=(
  Lux_RRD => { receive=>'3/2/0', translate=>sub{update_rrd('Out_Lux','',$input)} },
  Temp_RRD => { receive=>'3/2/1', translate=>sub{update_rrd('Out_Temp','',$input)} },
  Wind_RRD => { receive=>'3/2/2', translate=>sub{update_rrd('Out_Wind','',$input)} },
);

In Wiregate-Gruppenadressen muss der DPT richtig gepflegt sein und dann klappt es einwandfrei.

Bei dir wäre das dann:

%logic=(
  StromVerbrauch_RRD => { receive=>'10/0/1', translate=>sub{update_rrd('Stromverbrauch_heiztechnik','',$input)} },
);

[wuestenfuchs]

Hi!

Ich verwende zwar den rrd_graph.pl, aber auch bei dir müsste es funktionieren.

Im rrd_graph.pl schaut das so aus:

update_rrd("eg_steckdosen_kueche_herd_gesamt_stromverbrauch","",knx_read("6/5/200",3600,13));

[mivola]

@mivola: in $mrg{src} steht die physikalische Adresse des Senders drin.

Danke Fry! Den kleinen Tippfehler ("mrg" statt "msg") konnte ich schnell finden. Hier das Endresultat, evtl. hilft es ja jemanden...

dimBadEG => { receive=>'11/5/132', transmit=>'11/5/132', delay=>0.3, translate => sub { return unless ($input != 0); return unless ($msg{src} eq "1.2.121"); ($hour>21	|| $hour<5) ? 5 : undef; }, debug=>1 },

VG
Micha