Neues Plugin: Logikprozessor.pl

[Fry]

Bitte Perl regular expressions lernen: man perlre .
VG Fry

[jensgulow]

Hat sich erledigt - war ein kompletter Denkfehler .

Lösung funktioniert jetzt über separate Abfragen für $month und $day_of_month.

jalo_west_runter =>             {transmit=>['2/2/5','3/2/45','3/2/55'], translate=>sub{int($month) < 12 && int($month) > 1 ? 1:undef;}, debug=> 1},        # +21 min    Schlafzimmer, Willi_West, Bad OG
jalo_west_runter_januar =>         {transmit=>['2/2/5','3/2/45','3/2/55'], translate=>sub{int($month) == 1 && int($day_of_month) > 6 ? 1:undef;}, debug=> 1},

[jensgulow]

Jetzt noch mal eine Verständnisfrage:

Wenn ich folgende Logik:

jalo_schlafzimmer_runter_januar =>    {transmit=>'2/2/5', timer=>{time=>['22:00'], date=>'01/01-01/06'},translate=>1,debug=>1},

dann würde ich doch erwarten, dass sie vom 1. Januar an bis zum 6. Januar ausgeführt wird. Nun bekomme ich heute am 05.01. schon die Meldung:

2015-01-05 22:00:01.739,Logikprozessor.pl,Naechster Aufruf der timer-Logik 'jalo_schlafzimmer_runter_januar'  in 361 Tagen, am 1.1.2016, um 22:00.

Soll das so sein und es wird als Ende des Zeitraumes der 06.01. "0 Uhr" angenommen? Oder ist das ein Fehler?

[Fry]

Herzlichen Glückwunsch, du hast einen Bug gefunden.

Der Fix ist relativ trivial (und noch ungetestet :-), um die Zeile 1110 rum stand ein $d1<$d2, wo ein $d1<=$d2 stehen sollte.

Neue Version des LP im SVN.

Danke und VG
Fry

[jensgulow]

eibpa.conf ???

@fry:

Da ich den LP schon länger begeistert benutze und zumindest teilweise versuche dahinter zu kommen, wie er funktioniert, habe ich mir den code mal angeschaut. Dabei bin ich ab Zeile 80 des aktuellen "svn-LP" auf folgendes gestossen:

    # eibpa.conf - falls existent - einlesen
    my %eibpa=();
    if(open EIBPA, "</etc/wiregate/eibpa.conf")
    {
 $/="\n";    
 while(<EIBPA>)
 {
     next unless /^(.*)\s+([0-9]+\.[0-9]+\.[0-9]+)\s*$/;
     
     $eibpa{$2}=$1;
     $eibpa{$1}=$2;
 }
 close EIBPA; 
    }
    $plugin_cache{$plugname}{eibpa}=\%eibpa;

was ist denn eibpa? Geht es hier nicht um die eibga.conf?

[Fry]

Die eibga wird ja auch eingelesen (vom Wiregate-Daemon selbst).

Ich habe bei mir eine Datei /etc/wiregate/eibpa.conf eingerichtet. Die ist sehr einfach formatiert und sieht etwa so aus (Ausschnitt):

P_WZ_unter_Galerie 1.1.24
P_G 1.1.25
P_WF 1.1.26
P_SZ_Ankleide 1.1.34
T_G_Tuer 1.1.35
T_G_Werkbank 1.1.36
T_WZ_u_Galerie 1.1.48
T_WZ_zentral1 1.1.49
T_WZ_zentral2 1.1.50

Hier sind alle _physikalischen_ Adressen mit Namen hinterlegt. Der Logikprozessor decodiert für jedes eintreffende Telegramm den Eintrag des Sender ($msg{src}) und schreibt in $msg{sender} den zugehörigen Namen. Den kann ich dann per Pattern-Matching abfragen.

Zum Beispiel in folgender Logik:

# Knopf Licht-aus an Eingangstuer bewirkt Szene global-aus
$logic{ZZ_GL_aus}={ trigger=>'LI_GL==0', transmit=>'ZZ_GL',
                    translate => sub { return $msg{sender} eq 'T_E' ? scene(1) : undef; },
                    transmit_changes_only=>1,
};

Die GA "LI_GL" ist dabei eine Kurzbezeichnung (erstes Wort des GA-Namens $eibgaconf{...}{name}, diese steht auch in $eibgaconf{..}{short}).

Ich mag einfach keine Zahlen...

VG, Fry

[martinb07]

Hi

Ich möchte die aktuelle Leistung meines Hauses anzeigen lassen. Der Zähler spuckt nur den aktuellen Zählerstand aus, den ich mir auf eine GA schicken lasse.
Kann ich mit dem LP diesen Wert speichern und bei Änderung die Differenz ermitteln? Die Änderung findet minütlich statt.

Danke.

[Fry]

Ja klar.
Das Ergebnis dürfte allerdings unbefriedigend ausfallen, wenn die Auflösung des Zählers und die Abfragefrequenz nicht zusammenpassen. Wenn zB der Zähler alle 5 Minuten einen Schritt nach oben macht und du aber minütlich die Differenz ermittelst, bekommst du als "Leistungswerte" viermal eine Null und einmal einen viel zu hohen Wert.
VG
Fry

[martinb07]

Ja klar, die beiden Zeiten muss man natürlich aufeinander abstimmen. Da der Zähler den Verbrauch nicht ausgibt, muss ich mir es eben anders zusammenstellen. Noch weiß ich nicht, wie schnell mein Zähler die Werte übergibt. Irgendwo habe ich mal gelesen, dass er alle 2 Sekunden werte übermittelt. Meiner will allerdings angestoßen werden. (Das ist anscheinend etwas schüchterner Zähler, dem man alles aus der IR-Schnittstelle ziehn muss :-) )

Wie könnte diese Logik denn aussehen?

[Fry]

in etwa so:

diff => {    receive=>'9/5/207', transmit=>'9/5/208', state=>{lastval=>undef, lasttime=>undef},            
                 translate => sub { 
                     my $valdiff=$input-$state->{lastval}; $state->{lastval}=$input;
                     my $timediff=$systemtime-$state->{lasttime}; $state->{lasttime}=$systemtime; 
                     return $valdiff/$timediff;  } 
},

Ungetestet.

VG, Fry

[johnnychicago]

Linknx als Helfer für den Logikprozessor

Hallo --

Ich nutze den Logikprozessor mittlerweile recht ausgiebig und falle immer wieder über ein Problem: ich brauche, um eine Logik evaluieren zu können, ganz schnell mal den Wert einer GA - z.B. will ich beim Rollo-Fahren z.B. wissen, ob grad wer zu Hause ist oder ob es gerade Nacht ist. Diese GA's wurden irgendwann mal gesetzt, aber halt nicht unbedingt 'gerade eben'.

Nun gibt es mehrere Möglichkeiten, die GA's verfügbar zu machen.

Man kann den Logikprozessor selber anweisen, auf read requests zu antworten. Das funktioniert gut, wenn wer anders die GA braucht. Der LP selber hat da nix von, weil die Logik, die auf den request antwortet, halt erst nach der requestenden Logik abgearbeitet wird.

Man kann die GA sonstwo in einem Gerät ablegen, das auf einen read request antwortet. Das geht, wenn man halt so ein Gerät, z.B. einen Taster bei Hand hat. Wenn die GA aber per CometVisu gesetzt wird, ist's auch blöd.

Man kann die GA regelmässig per LP auf den Bus schicken, und sie in der Logik dann per eibd-cache verfügbar machen. Das hat den Nachteil, dass alle Logiken, die die GA brauchen, bei jedem 'Refresh' durch den LP getriggert werden - das muss man dann geeignet verhindern (execute_on_changes_only etc). Ausserdem müllt es den Bus etwas zu, vor allem mit Einstellungswerten, die u.U. nur alle Jubeljahre mal ändern, und nicht zuletzt gehen die Werte bei einem Stromausfall oder einem Restart des Wiregate/eibd verloren.

Um das Problem zu lösen, habe ich mir vor Kurzem einen linknx aufgesetzt. Dessen einziger Job ist es, auf Read Requests zu antworten - er macht also selbst keinerlei Logiken, sondern hört nur auf einige GA's, erfasst die Werte, und antwortet. Er überlebt einen Reboot, weil die Werte lokal auf der Platte gespeichert werden. Beim Wiregate kann der linknx problemlos nachinstalliert werden.

Hier ist eine Beispiel-Config, die auf 4 unterschiedliche GA's hört (mit dem 'object'-Tag definiert). Andere GA's können analog zugefügt werden.

<?xml version="1.0" ?>
<config>
<logging output="/var/log/linknx.log" format="%d{%Y-%m-%d %H:%M:%S,%l} %5p &gt; %c %x - %m%n" level="INFO" maxfilesize="10000" maxfileindex="2"></logging>
<services>
<knxconnection url="ip:127.0.0.1" />
<persistence type="file" path="/var/lib/linknx/persist" />
</services>
<objects>

<object type="1.001" id="0_0_2" gad="0/0/2" init="persist" flags="crw" />
<object type="1.001" id="0_0_5" gad="0/0/5" init="persist" flags="crw" />
<object type="1.001" id="0_1_2" gad="0/1/2" init="persist" flags="crw" />
<object type="1.001" id="0_1_3" gad="0/1/3" init="persist" flags="crw" />

</objects>
</config>

Auch wenn's die Standard-WG-Umgebung etwas verlässt, ich finde das recht praktisch so. Vielleicht gibt's ja eine smartere Methode, mein Problem zu lösen, da würd' ich gerne dazulernen.

[mivola]

Die Option "transmit_on_startup" führt eine Logik bei der Initialisierung des Logikprozessors einmalig aus (also Neustart des Wiregates, des Daemons, oder Änderung der Config).

- wobei ich aber an der Option noch rumgebastelt habe. Ich habe aktuell nicht mehr ganz den Überblick über die Unterschiede der Logikprozessor-Versionen:

* die (mittlerweile ältere) SVN-Version,
* die im Thread "Vorkompilieren" gepostete Version und
* die Version, die ich selbst heute nutze.

Ordnung im Chaos wird dann kommen, wenn der offizielle wiregated.pl die Features Vorkompilieren, %plugin_cache und den if/while-Patch enthält. Dann werde ich den neuesten Logikprozessor posten und ins SVN einstellen.
Vg, Fry

Hallo Fry,

ich habe letzte Woche zum ersten Mal mit "transmit_on_startup" experimentiert. Und ich musste feststellen, dass meine Logik nur beim Neustart des Plugins (zb durch Änderung an Logikprozessor.pl) und nicht bei Änderung der Config ausgeführt wird.

Hier meine Logik:

xmasTimerAnAus => { transmit=>'2/0/3', transmit_on_startup=>1, translate => sub { plugin_log($plugname, "=== xmasTimerAnAus!"); ( ($month == 12 || $month == 1) ? 1 : 0 ) }, debug=>1 },

Und hier die Logausgabe bei Änderung des Plugins (ich habe nach der Bedingung "if($event=~/restart|modified/)" (Zeile 440) eine Ausgabe mittels plugin_log ("---") eingefügt):

2015-01-27 13:28:43.597,Logikprozessor.pl,compiled in 0.1s
2015-01-27 13:28:44.118,Logikprozessor.pl,--- transmit_on_startup: xmasTimerAnAus
2015-01-27 13:28:44.121,Logikprozessor.pl,Followup 'xmasTimerAnAus' folgt sofort.
2015-01-27 13:28:45.158,Logikprozessor.pl,=== xmasTimerAnAus!
2015-01-27 13:28:45.228,Logikprozessor.pl,253 initialisiert;  $logic->{xmasTimerAnAus}{transmit}(Logik) -> 2/0/3:1 gesendet (followup);  ,1.5s,

Die Zeilen bzgl. "xmasTimerAnAus" fehlen im Log komplett wenn ich nur etwas an der Config ändere:

2015-01-27 13:29:20.658,Logikprozessor.pl,253 initialisiert;  ,1.5s,

Die Lösung scheint mir sehr einfach: die oben genannte if-Anweisung (Zeile 440) ändern zu:

if($event=~/restart|modified/ || $config_modified)

Gab es Gründe diese Bedingung nicht mit einzufügen? Was meinst du dazu?

Danke und VG
Micha

[mivola]

eine smartere Methode

... innerhalb des LP wäre es %plugin_info zu nutzen, siehe: https://knx-user-forum.de/406109-post438.html

Am schönsten wäre es natürlich wenn man das nicht "selbst" in jeder Logik machen müsste, sondern mit einer Anweisung, zB:

persistValueExample => { transmit=>'2/0/3', translate => 1, persist => 1, debug=>1 },

Daraus sollte dann etwas wie "%plugin_info{Logikprozessor.pl_persistedValues_2_ 0_3} = 1" werden....

Die Werte aus %plugin_info{Logikprozessor.pl_persistedValues_*} müssten beim Start dann natürlich wieder ausgelesen und auf den Bus geschrieben werden...

Nur so als Gedankenanstoß...

VG
Micha

[Fry]

@mivola: zum Thema transmit_on_startup. In der Tat gibt es mal Gründe dafür, nur den Neustart des Daemons zuzulassen - nämlich wenn man an der Config ständig rumschraubt, wie ich das tue :-)

Denkbar wäre eine zweite Option "transmit_on_config". Ist trivial zu implementieren. Soll ich?

VG, Fry

[mivola]

Denkbar wäre eine zweite Option "transmit_on_config". Ist trivial zu implementieren. Soll ich?

Gern :-)

Wenn du grad dabei bist: was hältst du von der Persistierung von Werten in %plugin_info ?

Danke,
Micha