Neues Plugin: Logikprozessor.pl

[dombn]

Die neuste dürfte die bei Fry auf der Platte sein . Hier im Forum vermutlich die, die auch den modifizierten wiregated benötigt. Also von hier:
https://knx-user-forum.de/319488-post33.html

[mivola]

OK, danke für die Info. Dann warte ich mal auch noch auf die Entscheidung bzgl. der Integration von Frys Patchen... Aber vor Weihnachten passiert da bestimmt nicht mehr viel oder?

VG
Micha

[johnnychicago]

Wert behalten

Hallo --

Ich wollte mit dem Logikprozessor den Tagesstromverbrauch erfassen (der Zähler hängt an einer Tasterschnittstelle).

Die Rechnung ist ja an sich einfach, die krieg´ ich auch hin: (Zählerstand(aktuell)-Zählerstand(Mitternacht))/Impulse.

Das Problem liegt darin, wie ich den Zählerstand(Mitternacht) speichern kann.

Ich habe eine Rule gebaut, die um Mitternacht läuft und den aktuellen Zählerstand in eine andere GA für den Zählerstand(Mitternach) reinkopiert, dann noch eine Memory-Rule (memory => { transmit=>'a/b/c' },) auf diese GA reingetan, damit der Wert nicht verloren geht.

Dann ist mir aufgefallen, dass das so nicht geht: der Wert in der Mitternachts-GA geht verloren, wenn der Cache vom Eibd ihn vergessen hat. Ich nehme mal an, dass es daran liegt, dass der Logikprozessor sich nicht selbst aufrufen kann, um den Wert zu erhalten.

Die Frage ist also:

Wie kann ich innerhalb des Logikprozessors einen Wert unbegrenzt lange vorhalten, um ihn Stunden später wieder zur Verfügung zu haben? Muss ja nicht unbedingt in einer GA sein...

[mivola]

myrrd => { receive=>'1/2/3', rrd=>'myrrd' }

@Fry: könnte man das evtl (optional) noch mehr verkürzen:

myrrd => { receive=>'1/2/3', rrd }

Der Name des rrd sollte dann dem Namen des Config-Eintrags (hier: myrrd) entsprechen.

Grad bei copy&paste ist mir es heute ab und an passiert, dass ich zwar den Namen des Eintrags aber nicht den des rrd geändert habe...

VG
Micha

[kingolli]

Hallo!

Ich habe eine Frage, zu einer Logik die ich implementieren möchte, es geht um Folgendes: ich habe eine Zentrale GA für Fenster offen, wenn da eine 1 gesendet wird, soll nach 10 Minuten auf einer Alarm GA eine 1 hinterher gesendet werden, aber nur wenn nicht während der 10 Minuten die Fenster wieder geschlossen wurden. Wenn ich das Delay richtig verstanden habe, hilft mir das nicht weiter, da es die Kommunikation für die angegebene Zeit sperrt, richtig?

Wie bekomme ich jetzt den Alarm wieder aus bzw. das Delay "unterbrochen"?

Hier die Zeile aus der Config:
Fenster_EG_Alarm => { receive=>'1/1/1', transmit=>'1/1/5', delay=>600, translate => sub { return unless $input; 1}, debug=>1},


Danke und Grüße
David

[Obiwan]

Hallo,
was mache ich verkehrt? Wenn ich mir das Plugin aus dem SVN einrichte, kommt folgende Fehlermeldung

config error: syntax error at (eval 53045) line 158, near "}      # Wenn nun auf der GA 1/2/3 ein Wert eingeht wird 'Hello world!' auf die App gepusht. prowl => ... kann auch einen Hash     # entgegennehmen:      hashProwl" Can't use global @_ in "my" at (eval 53045) line 172, near "=@_" syntax error at (eval 53045) line 176, near ";         # oder eben: return (event => 'Rolladen Süd ' . ($context{input} ? 'AB' : 'AUF'));       }" Can't use global @_ in "my" at (eval 53045) line 183, near "=@_" syntax error at (eval 53045) line 194, near "}       }" Can't use global @_ in "my" at (eval 53045) line 212, near "=@_" syntax error at (eval 53045) line 214, near ";       }"

[recal]

Leider ist bei mir noch nicht ganz der Knoten geplatzt, dass ich den Syntax verstehe. Ich stehe auch nach mehrmaligen durchlesen der Anleitung, immer noch auf dem Schlauch und hoffe das Ihr mir helfen könnt. Leider konnte ich auch bislang kein Beispiel finden, wo ich drauf aufbauen könnte.

Folgende Problemstellung würde ich gerne lösen. Abhängig von der Luftfeuchtigkeit in 2 Bädern soll die Zentrale KWL auf 80% laufen, wenn die durchschnittliche Luftfeuchtigkeit aus beiden Bädern über dem Referenzwert aus dem Wohnzimmer liegt. Wenn der Referenzwert wieder in den Bädern erreicht wird, soll die KWL wieder auf 40% laufen.

1/1/1 -> relative Luftfeuchte Bad1
1/1/2 -> relative Luftfeuchte Bad2
1/1/3 -> relative Luftfeuchte Wohnzimmer als Referenzwert
1/2/1 -> Sollwert KWL (1Byte in Prozent 5.001)

(1/1/1+1/1/2)/2 = Durchschnitt der rel. Luftfeuchte in beiden Bädern (DWERT)

Wenn DWERT > 1/1/3 dann 80% auf Adresse 1/2/1
Wenn DWERT <= 1/1/3 dann 40% auf Adresse 1/2/1

Ich wäre euch dankbar, wenn Ihr mir helfen könntet, meine Problemstellung zu lösen.

[Fry]

@recal

kwl => { receive=>['1/1/1','1/1/2','1/1/3'], 
              transmit=>'1/2/1',
              eibd_cache=>1000,    
              translate=>sub { 
                 my $avg=($input->[0]+$input->[1])/2;
                 my $thr=$input->[2];
                 return undef unless defined $avg && defined $thr;
                 return $avg>$thr ? 80 : 40;
              },
},

Wichtig:

* Luftfeuchtigkeit und Grenzwert (1/1/3) zyklisch auf den Bus schicken, mind. einmal pro 800s oder so, damit die Infos auf jeden Fall im Cache stehen.

* alle verwendeten GAs müssen mit DPTSubId korrekt in /etc/wiregate/eibga.conf eingepflegt sein.

Have fun,
Fry

[Fry]

Das Problem liegt darin, wie ich den Zählerstand(Mitternacht) speichern kann.

Wie kann ich innerhalb des Logikprozessors einen Wert unbegrenzt lange vorhalten, um ihn Stunden später wieder zur Verfügung zu haben? Muss ja nicht unbedingt in einer GA sein...

Der Logikprozessor ist ein Wiregate-Plugin wie jedes andere auch. Als persistenter Speicher steht dir daher %plugin_info zur Verfügung.

Du kannst also um Mitternacht mit einer Logik den Zählerstand in $plugin_info{$plugname.'_Zaehlerstand_um_Mitternac ht'} speichern und Stunden später genau da wieder abrufen.

Mit meinen kleinen wiregated.pl-Patches gibt es übrigens auch das schnellere, aber nicht persistente %plugin_cache. Das ist hierfür aber weniger geeignet.

Have fun,
Fry

[Fry]

Fenster_EG_Alarm => { receive=>'1/1/1', transmit=>'1/1/5', delay=>600, translate => sub { return unless $input; 1}, debug=>1},

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

[Fry]

Hi Fry,

ist diese neueste Version schon im SVN? (svn://svn.code.sf.net/p/openautomation/code/wiregate/plugin/generic/Logikprozessor.pl)
Ich habe die verkürzte Schreibweise ausprobiert aber dann kommen keine Werte im rrd an. Eine Fehlermeldung habe ich aber auch nicht gefunden...

Danke,
Micha

Tut mir leid, aber die Installation der neuesten Version supporte ich nicht, solange nicht ElabNet den Daemon gepatcht hat. Sonst gehe ich unter.

Sobald ElabNet die Änderungen eingepflegt hat, werde ich die dann neueste Version des Logikprozessors (sind wieder ein paar kleine Features dazugekommen) ins SVN stellen.

Bis dahin: Bitte Daemon patchen (siehe dombn's Kommentar weiter oben) und good luck! - wird schon klappen. Aber bitte nur, wenn rudimentäre Linuxkenntnisse (Shell-, Editorbedienung) vorhanden sind.

Have fun,
Fry

[mivola]

Tut mir leid, aber die Installation der neuesten Version supporte ich nicht, solange nicht ElabNet den Daemon gepatcht hat. Sonst gehe ich unter.

Kein Problem - verstehe ich voll & ganz! Die andere/alte Schreibweise funktioniert ja ...

Danke
Micha

[johnnychicago]

Der Logikprozessor ist ein Wiregate-Plugin wie jedes andere auch. Als persistenter Speicher steht dir daher %plugin_info zur Verfügung.

Du kannst also um Mitternacht mit einer Logik den Zählerstand in $plugin_info{$plugname.'_Zaehlerstand_um_Mitternac ht'} speichern und Stunden später genau da wieder abrufen.

Fry, kann es sein, dass die $plugin_info-Variablen verfallen, wenn man in der Logikprozessor.conf editiert hat? Kam mir jetzt beim Testen so vor.

Unter den Umständen ist das weniger praktisch, finde ich :-(

[Fry]

@johnnychicago:
Yep, hast (fast) recht, in der Initialisierung des Logikprozessors (also nach Restart des Wiregate oder nach Editieren der Config) werden alle Variablen der Form $plugin_info{'Logikprozessor.pl_...'} gelöscht.
Das erledigen die Codezeilen

    for my $k (grep /^$plugname\_/, keys %plugin_info)
    {
        next if $k=~m/^$plugname\_last/;
        delete $plugin_info{$k};
    }

im Logikprozessor. Sinn und Zweck ist es, das "Vermuellen" von %plugin_info zu vermeiden.

Lösung für dich: entweder die o.g. Zeilen aus dem Logikprozessor auskommentieren, oder besser: eine Variable $plugin_info{'Zaehlerstand'} oder ähnlich zu verwenden, also ohne das vorangestellte $plugname, das ja auch nur zur Ordnungshaltung dient und nicht wirklich nötig ist.

VG, Fry

PS. Edit: habe die o.g. Zeilen bei mir jetzt auch auskommentiert. Sie stammen sowieso aus einer Zeit, wo der Logikprozessor noch stark und oft geändert wurde. Heute sind solche "Bereinigungen" eigentlich nicht mehr nötig.

[johnnychicago]

@Fry, klasse: die Variation mit einer Variable ohne $pluginname davor war mir nicht bewusst. Das ist praktisch.

Ich bau den Zähler jetzt um, dass ich die Werte in $plugin_info-Variablen ablege, und für andere Mitspieler (vor allem die Visu) nutze ich dann auch nicht mehr diese Regel, um Werte auf dem Bus verfügbar zu machen:

memory => { transmit=>'1/2/9' },

sondern nehme ein return $plugin_info... dazu her.

Danke