Neues Plugin: Logikprozessor.pl

[mivola]

Notify My Android

Hallo Fry,

ich bin die Tage über NMA (eine Android-Alternative zu Prowl) gestolpert und dachte, das wäre doch sicher eine schicke Erweiterung für den Logikprozessor.

Im Prinzip ist es ganz einfach Notifications zu verschicken:
Wie hier beschrieben: https://www.notifymyandroid.com/api.jsp#notify muss man lediglich die URL korrekt zusammensetzen und schon wird die Nachricht verschickt:
https://www.notifymyandroid.com/publicapi/notify?apikey=<myApiKey>&application=Logikprozesso r&event=Wasserschaden&description=WaserschadenInKu eche&priority=2

Ich denke das könnte man ähnlich der Prowl-Integration implementieren. Allerdings traue ich mich wirklich nicht das in deinen 1a-Code reinzufrickeln. Evtl kannst du oder ein anderer Fähiger mal schauen ob das machbar ist?
Alternativ könnte man die URL sicher auch direkt in translate => sub { } mittels wget oä zusammenbauen? Aber schick ist das sicherlich nicht...

Danke,
Micha

[Fry]

Hi Micha,
prima Idee, leider kann ich aber nicht helfen.

Ich nutze weder Prowl noch NMA, und die Version des Logikprozessors, die bei mir zu Hause läuft, ist gegenüber der hier bekannten bereits wieder weiterentwickelt und hängt von den wiregated-Modifikationen ab, die ich hier gepostet habe (if/while, Vorkompilieren, %plugin_cache) und von denen ich erstmal abwarte, dass ElabNet sie in die Hauptlinie übernimmt. Ich müsste, um deine gewünschte "Auftragsentwicklung" vorzunehmen, erstmal die hier verfügbare Logikprozessor-Version nehmen, die Ergänzung einbauen UND TESTEN und dann wieder posten. Sorry, das ist mir zu viel Aufwand dafür, dass ich es selbst nicht brauche.

Ich bin aber gern bereit, falls du die Erweiterung einbaust und mir einen Patch lieferst, den Code zu reviewen und in meinen Hauptzweig zu übernehmen und das Ergebnis dann hier zu posten. Das mache ich auch, wenn die Implementation vielleicht nicht "perfekt" ist oder etwas aus meinem Schreibstil rausfällt.

Auch werde ich deinen Gedankenanstoss zum Anlass nehmen, mir bei Gelegenheit mal NMA anzusehen, denn das klingt eigentlich nicht schlecht.

Bei Gelegenheit werde ich mir vielleicht auch noch Prowl ansehen.

Nochmal sorry, aber viele Grüße und Have Fun!
Fry

[dirk13]

Hallo Fry, hallo mivola,

ähnlich der Gedanken zu NMA hatte ich mir kürzlich 'Pushover' genauer angesehen und erste Versuche gemacht, dies statt Prowl in den Logikprozessor zu integrieren. Leider bin ich in Perl nicht recht fit und über die Feiertage ist mir auch die Zeit ausgegangen, aber mir scheint, dass es cool wäre, solche 'Notifier-Dienste' sogar noch generischer in den Prozessor einzubinden.
Falls ich es die Tage schaffe, hier weiterzukommen, melde ich mich dazu nochmal, aber garantieren kann ich das nicht.

[Fry]

So, jetzt wäre ich an einem Punkt, wo ich sowas brauchen kann, und zwar für genau eine Funktion: die Alarmanlage (Einbruch+Brand).

Nur: damit ich keine spezielle Software auf dem Mobilteil brauche, hätte ich am liebsten einen SMS-Versand. Wie geht denn sowas? Mal googeln...

Wäre gut, wenn jemand einen Tipp hätte.

VG, Fry

[mivola]

für genau eine Funktion: die Alarmanlage (Einbruch+Brand).
...
hätte am liebsten einen SMS-Versand

Hallo Fry,

genau für diesen Anwendungsfall (+ Leckage) habe ich das auch gedacht. SMS wäre mir auch lieber, aber da habe ich bisher nix passendes/einfaches gefunden :-(

"Pushover" sieht auch sehr interessant aus, da es (relativ) platformunabhängig (Android, iOS) ist...

VG
Micha

[JuMi2006]

SMS gab es doch schon ... Sucht mal im WireGate Forum.

[Fry]

Hallo zusammen,
SMS funktioniert jetzt und war ganz einfach.

Vorbemerkung:

1. der Code unten bezieht sich auf die neueste Logikprozessorversion (insbesondere mit der wiregated.pl-Modifikation %plugin_cache!).

2. ich bin sipgate-Kunde für den Festnetzanschluss. die Wörter user und pass unten stehen für meinen Username und mein Password

Dann geht es so: erstmal das CPAN-Modul Frontier::Client installieren

perl -MCPAN -e 'install Frontier::Client'

Dann am Ende des Logikprozessor-Codes folgende Subroutine ergänzen:

sub samurai
{
    # $target ist die Nummer im Format 49641124, d.h. beginnend mit der Landeskennung (49)                                                       
    # Message ist die zu sendende Nachricht                                                                                                      
    my ($target,$message)=@_;

    use Frontier::Client;       # needed for XMLRPC                                                                                              

    my $samurai=$plugin_cache{$plugname}{settings}{samurai};

    return 0 unless defined $samurai;

    my $xmlrpc_client;
    my $xmlrpc_result;
    eval                                                                                                                     
    {
        $xmlrpc_client = Frontier::Client->new('url'=>$samurai);
        my $args_identify = { ClientName => $plugname, ClientVersion => "1.0", ClientVendor => "Fry" };
        $xmlrpc_result = $xmlrpc_client->call( "samurai.ClientIdentify", $args_identify );
    };

    if($@ || $xmlrpc_result->{'StatusCode'}!=200)
    {
        plugin_log($plugname, "Failed opening samurai client to sipgate.");
        return 0;
    }

    eval
    {
        my $args = { RemoteUri => "sip:$target\@sipgate.net", TOS => "text", Content => $message };
        $xmlrpc_result = $xmlrpc_client->call( "samurai.SessionInitiate", $args );
    };

    if($@ || $xmlrpc_result->{'StatusCode'}!=200)
    {
        plugin_log($plugname, "Failed sending SMS '$message' to +$target.");
        return 0;
    }

    plugin_log($plugname, "SMS '$message' sent to +$target.");
    return 1;
}

und in der Logikprozessor.conf ergänzen:

%settings=(
    samurai => "https://user:pass\@samurai.sipgate.net/RPC2",
);

(ggf. zusätzlich zu Prowl-Einstellungen, die auch in %settings stehen).

Damit steht dann in den Logiken die Funktion samurai() zur Verfügung, die man wie folgt nutzen kann:

    $logic{'SMS-Test'} = {
        receive=>'0/1/2', 
        translate=>sub {
            samurai('491781234567',"Empfangene Daten $input");
        },
    };

Das erste Argument von samurai() ist die Telefonnummer inkl. Ländervorwahl.

Beachte: samurai braucht ca. 1,5 Sekunden, innerhalb derer der Wiregate-Daemon blockiert ist. Außerdem kostet eine SMS per sipgate 9 Cent (oder so). Für meine Zwecke (Alarmanlage) ist das aber akzeptabel.

VG, Fry

[Fry]

Nachbemerkung: die Funktion samurai() steht natürlich dann auch in allen anderen Wiregate-Plugins zur Verfügung. (Meine "Alarmanlage" läuft nicht über den Logikprozessor...).
VG, Fry

[mivola]

Meine "Alarmanlage" läuft nicht über den Logikprozessor...

@Fry,

danke erstmal für das einbauen der SMS-Funktionalität. Werde ich demnächst (wohl erst nach dem nächsten WG PL) auch mal testen...

wg Alarmanlage: würdest du den Code dafür ggf auch veröffentlichen? Kennst du diesen Thread hier: https://knx-user-forum.de/wiregate/2...gsmeldern.html

Danke,
Micha

[Fry]

Ja wie bereits gesagt, sobald die drei Patches %plugin_cache, if/while und Vorkompilieren in den Hauptzweig des wiregated.pl übernommen sind, werde ich auch aktualisierte Fassungen von Logikprozessor und anderen Plugins ins SVN einstellen. (Die Performanceverbesserungen sind wirklich signifikant - der Logikprozessor bearbeitet hier aktuell 712 Logiken ohne Probleme, mit Reaktionszeiten <<1s).

Die Alarmanlage stelle ich dann auch ein, wobei (i) das ein recht simples Plugin ist, das eben auf alle Präsenzmelder und alle Fensterkontakte hört und (ii) ich das erst selbst richtig austesten möchte. Aktuell ist meine Alarmanlage noch nicht scharf, insbesondere die Tröte außen am Haus noch nicht aktiviert, weil ich nicht Software auf Kosten meiner Nachbarn testen möchte :-)

Aber ab sofort teste ich, wobei im Alarmfall eben eine SMS rausgeht...

VG, Fry

PS. bevor die Normenpolizei sich wieder meldet: natürlich ist meine Alarmanlage (Hard+Software) nicht VDS-Konform. Aber wesentlich besser als nix!

[mivola]

Im Prinzip korrekt gedacht. Fast.

Versuch es mal so:

SternenhimmelAlina => { receive=>'3/1/9', 
                 transmit=>'1/1/16', 
                 state => {lastval=>undef}, 
         translate => sub { 
                  my $oldval=$state->{lastval};
                  my $newval=int($input);
                  $state->{lastval}=$newval;
                  return ($oldval>=70 && $newval<70) ? 0 : undef;
          }
    },

Nicht senden geht, indem man undef zurückgibt.

VG,
Fry

Hallo,

ich habe dieses Konstrukt benutzt und abgewandelt um das Licht in der Dusche automatisch einzuschalten, wenn die Temperatur am Warmwasserrohr steigt. Das funktioniert prinzipiell auch gut. Allerdings: beim Neustart des wiregated ist oldval nicht gesetzt (oder 0?). Beim obigen Beispiel wirkt sich das nicht aus, aber bei mir schon. Deshalb hier nur als Hinweis für andere Interessierte...

	badEGDuschLichtAn => { receive=>'2/7/15', transmit=>['3/5/130', '1/1/212'], state => {lastval=>undef}, translate => sub { 
		my $oldval=$state->{lastval};
        my $newval=int($input);
        $state->{lastval}=$newval;
		return ($oldval<=25 && $oldval>1 && $newval>25) ? 1 : undef; }, debug=>1 },

VG
Micha

[mivola]

Allerdings: beim Neustart des wiregated ist oldval nicht gesetzt (oder 0?).

Kann es sein, dass der initiale Wert über dieses Konstrukt gesetzt wird?

	badEGDuschLichtAn => { ... , state => {lastval=>undef}, ... },

D.h. wenn ich statt "lastval=>undef" z.B. "lastVal=>100" schreibe, ist "oldval" im ersten Aufruf 100? Ich habe momentan leider kein WG zum Testen in Reichweite...

Danke,
Micha

[dirk13]

Nachbemerkung: die Funktion samurai() steht natürlich dann auch in allen anderen Wiregate-Plugins zur Verfügung. (Meine "Alarmanlage" läuft nicht über den Logikprozessor...).
VG, Fry

Bedeuted das, dass sich alle WG-Plugins einen Namesraum für subs teilen?
Das ist recht interessant und war zumindest mir jetzt neu. Es könnte u.A. die weiter oben genannte frage nach Plugin-Interferenzen beantworten...

[mivola]

Hallo Fry,

ich bin mal wieder am überlegen wie ich diverse Logiken am besten umsetze und hoffe du (oder andere Experten) kannst mir den einen oder anderen Tipp geben :-)

Ich möchte z.B. bei einem Windalarm die aktuelle Position der Raffstores speichern um diese nach Ende des Windalarms wieder anzufahren. Dazu nun Fragen:

• gibt es einen einfacheren Weg um zu prüfen, ob sich der Wert einer GA (hier: Windalarm an/aus) im Vergleich zum letzten Aufruf des Plugins geändert hat? Bisher mache ich das so:
  

  badEGDuschLichtAn => { receive=>'5/7/5', transmit=>['3/3/10', '5/1/12'], state => {lastval=>undef}, translate => sub { 
  	my $oldval=$state->{lastval};
          my $newval=int($input);
          $state->{lastval}=$newval;
  	return ($oldval<=25 && $oldval>1 && $newval>25) ? 1 : undef; }, debug=>1 },

  Könnte man diese Prüf-Logik (die ich wirklich recht häufig brauche) irgendwie in den Prozessor selbst übernehmen und dann nur noch in dieser Art aufrufen:
  

  badEGDuschLichtAn => { receive=>'2/7/15', transmit_only_if_input_changed=>1; transmit=>['3/5/130', '1/1/212'], translate => sub { return ($input>25) ? 1 : undef; }, debug=>1 },

  Jetzt beim Schreiben merke ich, dass dies dem "transmit_changes_only" ähnelt, nur dass es sich eben auf die Eingangswerte bezieht.
  
• Wie sollte ich am besten die Werte der Raffstores speichern und später wieder abrufen?
  
• ich habe einige Fälle, in denen ich eine Logik nur ausführen will, wenn ein Wert auf der GA X empfangen wird. Zur Berechnung des Wertes der daraufhin gesendet werden soll, benötige ich aber noch die Werte aus 1-n anderen GAs. Nun könnte man diese 1-n GAs auch in der "recieve"-Liste angeben, müsste dann aber irgendwo/wie prüfen, welche GA nun der Trigger für die aktuelle Ausführung war. Oder nur GA X in "recieve" eintragen und dann in sub mit knx_read den Wert der anderen GAs abfragen. Beides irgendwie nicht so sehr elegant. Welchen Weg würdest du empfehlen?

Ich weiß dass du die aktuelle WG-Version nicht mehr supportest, aber ich hoffe stark, dass deine Änderungen im nächsten PL enthalten sind (solange würde ich noch warten) - sonst werde ich wohl auch manuell deine Patches einspielen...

Danke,
Micha

[StefanW]

Ich weiß dass du die aktuelle WG-Version nicht mehr supportest, aber ich hoffe stark, dass deine Änderungen im nächsten PL enthalten sind

In der derzeitigen Entwicklerfassung des künftigen PL38 sind die Änderungen alle enthalten. Unsere Test-Plugins laufen bereits 20 fach schneller als zuvor.
Ohne abschließende Regressionstests können wir noch keine Aussage treffen ob alles drin bleibt, aber ich bin zuversichtlich, wurde schließlich auch lange von Early-Adoptern getestet.

lg

Stefan