Neues Plugin: Logikprozessor.pl

[Fry]

Hallo Fry,

anbei die Logs. Ich hoffe, da sind die richtigen bei?!

Gruß und v.a. Danke!

Hendrik

Ok, und jetzt bitte noch die Logikprozessor.conf-Datei.
VG, Fry

[henfri]

Klar, sorry :-(

#!/usr/bin/perl
#
# Logikprozessor.pl - Konfiguration
#

$eibd_backend_address='0.0.0'; # eigene Adresse zur Vermeidung von Zirkellogiken, ist oft auch '1.1.254'

%logic=(
    #Fensterkontakte
    #Gäste 
    und => { receive=>['8/1/30','8/1/31'], transmit=>'8/1/32', translate => sub { 2* $input->[0] + $input->[1]; }, debug=>1 },
    #Gästebad
    und => { receive=>['8/1/8','8/1/9'], transmit=>'8/1/38', translate => sub { 2* $input->[0] + $input->[1]; }, debug=>1 },
    #Schuppen Fenster 1
    und => { receive=>['8/1/1','8/1/2'], transmit=>'8/1/36', translate => sub { 2* $input->[0] + $input->[1]; }, debug=>1 },
    #Schuppen Fenster 2
    und => { receive=>['8/1/3','8/1/4'], transmit=>'8/1/37', translate => sub { 2* $input->[0] + $input->[1]; }, debug=>1 }
);

[Fry]

Hendrik,

%logic ist ein Hash, d.h. braucht eindeutige Keys. Du hast viermal "und" als Namen vergeben, damit ist nur der letzte überhaupt gelesen worden.

Nimm stattdessen "und1", "und2", "und3"..., dann wird es funktionieren.

Ein Hinweis ist auch die Log-Meldung "1 initialisiert". Das bedeutet, nur eine einzige Logik ist aktiv.

VG,
Fry

[henfri]

Verdammt!
Ich hatte vorhin noch kurz daran gedacht!

Danke. Ich werde es gleich probieren und berichten.

Edit
Initialisiert: 4
:-)

[Fry]

Und, klappt jetzt alles?
Fry

[timov]

Prowl Erweiterung

Hi zusammen!

Auf Basis des Prowl-Plugin von makki habe ich den Logikprozessor erweitert und will das ganze hier zur Verfügung stellen. Der Code ist im Plugin-Repository eingecheckt, siehe SourceForge.

Prowl ist eine iPhone/iPad/i*-App zum Empfang von Growl-Kurznachrichten via Push. Da Prowl auch über eine Web-API Nachrichten entgegennehmen kann, ist eine Kopplung an eigene Anwendungen möglich. Für einen Minimalbetrieb ist Growl oder ein Mac nicht erforderlich: Es reicht die App auf dem Zielgerät und die Einrichtung von sog. API-Keys. Über prowl => ... lassen sich dann über den Logikprozessor Nachrichten per Push auf die App schicken.

Zur Vereinfachung der einzelnen Aufrufe können in der Konfigurationsdatei des Logikprozessors zentral Standardwerte hinterlegt werden. Dazu ist neben den %logic Hash noch ein %settings Hash zu legen, der folgende Einstellungen unterstützt:

%settings=(
  prowl => {
    apikey => "*** hier eigenen API-Key eintragen***", 
    application => 'WireGate KNX',
    priority => 0,
    event => '[unbenanntes Ereignis]',
    description => '',
    url => ''
  }
);

Der Versand von Prowl-Nachrichten erfolgt nach der Verarbeitung von "translate", falls vorhanden. In der einfachsten Form erfolgt die Definition direkt mit dem gewünschten event-String (was die beschriebene Vergabe von Standardwerten voraussetzt):

%logic=(
  simpleProwl => {
    receive => '1/2/3',
    prowl => 'Hello world!'
  }
);

Wenn nun auf der GA 1/2/3 ein Wert eingeht wird 'Hello world!' auf die App gepusht. prowl => ... kann auch einen Hash entgegennehmen:

%logic=(
  hashProwl => {
    receive => '1/2/4',
    prowl => {
      application => 'Beschattung'
      event => 'Südseite AB'
    }
  }
);

Für komplexere Fälle kann auch eine sub übergeben werden, die dann einen passenden Hash zurückgeben muss. In die sub wird der Aufrufkontext übergeben, der den "input", das "result" und den "state" umfasst.

%logic=(
  subProwl => {
    receive => '1/2/5',
    prowl => sub {
      my (%context) = @_;
      return (event => 'Rolladen Süd ' . ($context{input} ? 'AB' : 'AUF'));
    }
  }
);

Der Versand an mehrere Empfänger ist durch die Definition von "apikey" als Array möglich:

apikey => [ "*** key 1 ***", "*** key 2 ***", ... ]

Mein konkretes Einsatzszenario ist aktuell das "Debugging" meine Wetterstationsprogrammierung: Ich lasse mir Nachrichten schicken, um auch wenn ich nicht zu Hause bin zu sehen, wann die Beschattung wie gefahren wird -- und kann dann schnell mal aus dem Fenster sehen, um das Geschehen zu plausibilisieren. Für später plane ich die Nutzung als "WaMa fertig", "Post ist da" etc. Nachrichtensender.

Über Rückmeldungen würde ich mich freuen! Viel Spaß beim pushen

Besten Gruß,
Timo

[Fry]

Super Engagement, Timo!

Eine kleinere Verbesserung rege ich noch an: Dein %context-Hash bei "prowl" entspricht ja ungefähr meinem @input-Array bei "translate". Nur dass ich das "my @input=@_;" nicht brauche, weil ich es durch einen Trick einfüge (Regex-Search & Replace beim Einlesen des Logikfiles). Sieh dir das doch bitte mal im Logikprozessor-Source an und mach es genauso, das vereinfacht die Benutzung für Nicht-Perl-Experten nochmals ein wenig.

Ich würde es ja selbst machen, habe aber momentan weder ein Wiregate zum Testen (meines steht offline auf der Baustelle) noch Zeit.

VG,
Fry

[timov]

Verinfachung in der Prowl Funktionalität

Hi Fry!

Ja, gute Idee. Ist angepasst im SVN. Damit kann in einer prowl sub nun die Zeile "my ..." entfallen. Stattdessen kann %context direkt genutzt werden. Zusätzlich stehen auch direkt die Skalare $input, $state und $result zur Verfügung.

Damit kann das o. g. Beispiel wie folgt vereinfacht werden:

%logic=(
  subProwl => {
    receive => '1/2/5',
    prowl => sub { return (event => "Rolladen Süd $input"); }
  }
);

Besten Gruß,
Timo

[Fry]

Timo!

Prima, danke.

Ich würde es zwar vorziehen, wenn "translate" und "prowl" völlig identische Interfaces hätten, und die Lösung mit %context ist zwar besser gekapselt aber dafür auch wieder ein bisschen ressourcenverbrauchend (außerdem ist die ganze Plugin-Geschichte nicht gekapselt) - aber gut! Meine Meinung ist auch nur eine unter vielen...

Danke nochmal für dein Engagement, hoffe andere finden es auch hilfreich. Jetzt muss ich nur noch rausfinden, warum mein USB-Interface plötzlich nicht mehr tut...

LG, Fry

[timov]

suppress_repetitions oder andere Idee?

Hi zusammen!

Ich überwache im Bad die Temperatur der Kopfbrausezuleitung (direkt hinter dem Mischer), um darüber zu erkennen, ob die Dusche im Betrieb ist. Das brauche ich, um das Licht zwangsführen zu können. Mit den vorhandenen Mitteln des Logikprozessors geht das grundsätzlich gut. Nun ist der Temp-Sensor ein 1-Wire Sensor, den das WG zyklisch sendet. Ich möchte aber das Logikergebnis "Dusche_in_Betrieb" nicht alle 30s auf den Bus senden sondern nur dann, wenn sich der Wert geändert hat. Das würde dann etwa so aussehen:

  logik_regenbrause_in_benutzung => {
    receive => '4/1/71',
    transmit => '6/1/0',
    state => { oldstate => undef },
    translate => sub {
      my $newstate = ($input gt 25) ? 1 : 0;
      if ($newstate ne $state->{oldstate}) {
        $state->{oldstate} = $newstate;
        return $newstate;
      }
      else {
        return undef;
      }
    }
  },

Da das nicht so intuitiv ist, kann habe ich mir einen weiteren Schalter eingefügt, so dass das Ergebnis wie folgt aussieht:

  logik_regenbrause_in_benutzung => {
    receive => '4/1/71',
    transmit => '6/1/0',
    suppress_repetitions => 1,
    translate => sub {
      return ($input gt 25) ? 1 : 0;
    }
  }

Das finde ich dann deutlich verständlicher. Hab ich was übersehen und das gewünschte Verhalten ginge auch anders elegant mit den vorhandenen Mitteln? Sonst würde ich meine Erweiterung ins SNV einstellen.

Besten Gruß,
Timo

[Fry]

Hi Timo,
ich find's prima, nur die Bezeichnung ist "denglisch", d.h. zu nominal. Ich schlage die Bezeichnung "transmit_changes_only" vor, in Analogie zu "transmit_only_on_request". (Was passiert eigentlich, wenn beide Schalter ausgewählt sind? Und was ist bei Timer-Aufrufen? Mangels Zeit und Testsystem kann ich mir den Code momentan nicht genauer ansehen)
Danke!
VG
Fry

[timov]

Hi Fry!

Ja, der Name ist dann einheitlicher. Ich hab's bei mir jetzt wie folgt umgesetzt: transmit_only_on_request hat Priorität vor transmit_changes_only aber transmit_changes_only sorgt dafür, dass ggf. auch ein späterer Versand unterbunden wird (eben wenn kein change vorliegt).

Passt das auch aus deiner Sicht?

LG, Timo

[Fry]

Passt! Dein spezielles Problem mit der Kopfbrause hätte man aber wohl auch so lösen können, dass der Temperaturversand nur bei Änderung geschieht. Das kann das Wiregate von Haus aus...
VG
Fry

der sich gerade überlegt, doch noch ein TP-UART zu kaufen.... wegen der Misere mit USB

[2ndsky]

Hallo Fry,

habe mich mal an unsere Schlaflogik getraut und komme leider mit der Syntax noch nicht ganz klar... egal was ich versuche, es führt nicht zum gewünschten Ergebnis. Kurz zum gewünschten Ergebnis: Wir haben zwei Taster für Nadine im Bett und Niko im Bett. Nun sollen in den angrenzenden Räumen Ankleide und Bad das Licht nur 5% angehen wenn beide noch schlafen (für den nächtlichen Gang zum Klo). Wenn nur noch einer schläft dann soll im Bad das Licht auf 30% wenn vor 7 Uhr und auf 100% wenn nach sieben Uhr gedimmt werden. Dazu habe ich erstmal einfache AND, OR und XOR gebastelt, um die verschiedenen Zustände zu verwalten:

	# Schlafmodus
	# beide schlafen
	DG_Schl_AND => { receive=>['5/0/0','5/0/1'], transmit=>'5/0/4', translate => sub { $input->[0] && $input->[1]; }, },
	# mindestens einer schläft
	DG_Schl_OR => { receive=>['5/0/0','5/0/1'], transmit=>'5/0/3', translate => sub { $input->[0] || $input->[1]; }, },
	# genau einer schläft
	DG_Schl_XOR => { receive=>['5/0/0','5/0/1'], transmit=>'5/0/2', translate => sub { !$input->[0] != !$input->[1]; }, },

5/0/0 und 5/0/1 sind die Trigger für Nadine bzw. Niko schläft. Dann die Logiken für das gedimmte Lichteinschalten bzw. Lichtwert hinterherfeuern:

	# im Bad, Anleide und Schlafzimmer das Licht nachts nur gedimmt einschalten
	DG_MBad_DIM => { receive=>['7/1/18','5/0/4'], transmit=>'1/4/89', translate => sub { return unless $input->[0]; if ($input->[1]) { return 5; } else { return $day ? 100 : 30; } }, },
	DG_Ankl_DIM => { receive=>['7/1/19','5/0/3'], transmit=>'1/4/95', translate => sub { return unless $input->[0]; if ($input->[1]) { return 5; } else { return $day ? 100 : 30; } }, },

Hier muss ich sagen, dass ich mit dem unless nicht wirklich klar komme, aber auch mit IF hat das nicht ganz geklappt. Übersehe ich hier was?

[Fry]

Niko,
mangels Testplattform (mein WG steht nicht mehr online im Wohnzimmer sondern offline auf der Baustelle) kann ich leider nichts testen.
Ich versuch's mal so: bei Konstrukten wie "return unless $input->[0]" pass bitte auf: eine KNX-Null wird im WG manchmal als String "0" decodiert, und das ist TRUE! versuch vielleicht mal "return unless int($input->[0])".
VG
Fry