Neues Plugin: Logikprozessor.pl

[Fry]

Hi johnnychicago,
danke für dein Interesse!

"undefined"-Wert im receive: du hast vermutlich recht, die Spezifikation execute_only_if_input_defined=>1 ist überflüssig. Ich programmiere halt manchmal auch mit Sicherheitsabfragen...

Followup und Cancel: ja, ich wüsste aber nicht, wie es mit überschaubarem Aufwand anders ginge...

reply_to_read_requests: naja, um ein wenig Code-Hygiene zu betreiben, sollte bei einer Status-GA doch die Möglichkeit der Abfrage bestehen, oder? Und ja, die Abfrage kommt von der CometVisu.

Warum man "Wert setzen" und "Wert abfragen" generell in zwei GAs trennt: weil es zwei verschiedene Dinge sind. Das Prinzip gibt es in KNX sehr oft, und es ergibt speziell dann Sinn, wenn verschiedene Geräte involviert sind, die per Telegramm miteinander kommunizieren. Denn auf der GA "Wert abfragen" darf nur das Gerät senden und antworten, welches "Eigentümer" des Wertes ist. Die GA "Wert setzen" hingegen darf von jedem Gerät beschrieben werden. CometVisu und Logikprozessor (zwei Prozesse) gelten in diesem Sinne schon als "zwei Geräte".

Have fun,
Fry

[johnnychicago]

Hallo Fry --

Ich hab's grad mal eingespielt - wiregated ersetzt und neu gestartet, und dann den Logikprozessor. Letzterer gibt mir folgende Fehlermeldung:

Can't locate Frontier/Client.pm in @INC (@INC contains: /etc/perl  /usr/local/lib/perl/5.10.0 /usr/local/share/perl/5.10.0 /usr/lib/perl5  /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10  /usr/local/lib/site_perl .) at (eval 31) line 1647. BEGIN failed--compilation aborted at (eval 31) line 1647.

[johnnychicago]

Samurai-Subroute rausgeschmissen, jetzt tut's. Die brauch' ich sowieso nicht.

[Fry]

Ok, sorry. Den Samurai werde ich für eine spätere "Release"-Version auskommentieren.

Und wie bereits gesagt, eine analoge "einfache" Implementierung wünsche ich mir eigentlich auch für prowl - wobei ich die nicht selbst machen werde.

Anyone?

[mivola]

sperreRaffstoreEZ => { 
receive=>['3/1/110', '3/1/117', '3/1/111', '3/1/1', '1/5/3'], 
transmit=>'1/1/10', 
translate => sub { return ($input->[0] || $input->[1] || $input->[2] || $input->[3] || $input->[4]); }, 
debug=>1 },

Damit versuche ich die diversen Alarm/Sperrmeldungen zu "summieren", d.h. wenn auf mind. einer der GAs (Windalarm, Tür offen, manuelle Sperre, ...) in "recieve" eine "1" kommt, wird eine "1" gesendet; anderfalls eine "0". Das funktioniert soweit schon - allerdings ist die Syntax nicht sehr schön und nicht generisch. Ich würde

return ($input->[0] || $input->[1] || $input->[2] || $input->[3] || $input->[4]);

gern durch etwas wie

(sum($input) > 0 ? 1 : 0);

ersetzen. Am liebsten natürlich ohne eine eigene "sum"-Funktion zu schreiben. Gibt es sowas?

2. Teil: ich brauche ein solches Konstrukt nicht nur für eine Tür/Zimmer sondern mehrmals. Für andere Aufgaben habe ich (nach Frys Anleitung) so etwas gebaut:

my %Leckage = (Geschirrspueler => '1/1/13', Kuehlschrank => '1/1/14', Spuele => '1/1/15');
while (my ($name, $ga) = each(%Leckage)) {
	$logic{'Leckage'.$name} = { receive=>$ga, translate=>sub{
		return unless $input;
		sendNma(event=>'Leckage erkannt: '.$name, description=>'bitte Wasserschaden prüfen', priority=>2);
	}, debug=>0 };
}

Jetzt würde ich das gern entsprechend übertragen, allerdings fehlt mir das Verständnis wie ich die zwei Variablen (Liste der recieve-GAs und eine transmit-GA) in den Hash und im while-loop wieder heraus bekomme... Jemand eine Idee? Oder muss ich zwei Hashes (je einen für recieve und einen für transmit) bauen?

Danke!!
Micha

Hallo Chris,

wenn du grad hier liest und schreibst: könntest du mir bzgl. meines Problems einen Tipp in die richtige Richtung geben?

Danke,
Micha

[johnnychicago]

Followup und Cancel: ja, ich wüsste aber nicht, wie es mit überschaubarem Aufwand anders ginge...

Ja, das wird mir schon klar: die Alternative wäre halt, mit GA's von einer Funktion auf die andere zu triggern. Auch eher nicht elegant Man muss halt mehrere Male durchlesen, bis man raus hat, welche Funktion von welcher aufgerufen wird.

reply_to_read_requests: naja, um ein wenig Code-Hygiene zu betreiben, sollte bei einer Status-GA doch die Möglichkeit der Abfrage bestehen, oder? Und ja, die Abfrage kommt von der CometVisu.

Warum man "Wert setzen" und "Wert abfragen" generell in zwei GAs trennt: weil es zwei verschiedene Dinge sind. Das Prinzip gibt es in KNX sehr oft, und es ergibt speziell dann Sinn, wenn verschiedene Geräte involviert sind, die per Telegramm miteinander kommunizieren. Denn auf der GA "Wert abfragen" darf nur das Gerät senden und antworten, welches "Eigentümer" des Wertes ist. Die GA "Wert setzen" hingegen darf von jedem Gerät beschrieben werden. CometVisu und Logikprozessor (zwei Prozesse) gelten in diesem Sinne schon als "zwei Geräte".

OK, ich hatte beim oberflächlichen Lesen nur gesehen, dass es für die Dezimalzeit wohl nur den Slider gibt - ich spare mir die Status-GA meistens, wenn ich die GA an sich nur an einer Stelle manipuliere.

Läuft, btw, und sieht klasse aus. Ich mag den Ansatz, per Slider die Alarmzeit einzustellen (wobei ich im Hinblick auf Touch-Devices eher zwei Slider bauen werde: einen für die Stunden und einen für die Minuten)

[Fry]

Micha -
ich kenne da leider auch keine Abkürzung. Nur die Fussgängerlösung.
Meine Fensterlogiken sind leider auch recht länglich.
VG, Fry

PS. Mein Wiregate (auf schnellere fit-PC2-Hardware "umgezogen") fährt mittlerweile 950 Logiken parallel. Ohne Probleme. Viele davon extrem trivial. Aber trivial ist oft besser als kompliziert (auch wenn das manchmal "elegant" beim Schreiben erscheint, ist es 2 Jahre später nicht mehr verständlich...)

[johnnychicago]

PS. Mein Wiregate (auf schnellere fit-PC2-Hardware "umgezogen") fährt mittlerweile 950 Logiken parallel. Ohne Probleme. Viele davon extrem trivial. Aber trivial ist oft besser als kompliziert (auch wenn das manchmal "elegant" beim Schreiben erscheint, ist es 2 Jahre später nicht mehr verständlich...)

950 ist ja schon beeindruckend.

Ob das auch mit der Standard-WG-Hardware geht? Ich bin jetzt bei 50 oder 60, eigentlich unmerklich.

[Fry]

Mein fit-PC2 hat eine Belastung von typischerweise 1-1,3. Bei 2 Prozessoren also alles im grünen Bereich.

Beim originalen Wiregate lag die Belastung höher, das war aber, bevor ich die drei entscheidenden Patches (if/while, "Vorkompilieren" und %plugin_cache) drin hatte.

950 geht nun bestimmt auch mit standard-WG. Begrenzender Faktor sind andere Dinge, zB Latenzzeiten durch schlecht programmierte Logiken, die auf irgendwas warten. knx_read zum Beispiel ist ganz schlecht, wenn der Wert nicht im Cache steht und vielleicht sogar vom Wiregate selbst gelesen wird. Viel besser ist es, alle Werte werden periodisch gesendet und sind damit im Cache.

Auch relevant ist die Zahl der rrd-Aufzeichnungen. Bei mir ca. 280 Stück.

[Fry]

Ich möchte speziell in Richtung StefanW noch anmerken: seit den drei kritischen Patches habe ich alle Plugins "kompilierbar" gemacht und seitdem auch keinerlei Memleak mehr. Das Wiregate läuft monatelang durch, und den wiregated.pl starte ich wegen meiner Spielereien immer wieder mal, ansonsten läuft er ebenfalls rock solid über Wochen hinweg.
VG, Fry

[JuMi2006]

Das kann u.A. auch am System liegen, dies könnte ich sowohl mit einem Pi als einem Atom Prozessor beobachten (aktuelle Distris).

Die Patches liegen übrigens schon seit mehreren Wochen in einem neuen wiregated.pl auf dem WireGate-Repo-Server. Man kann also davon ausgehen dass irgendwann doch mal was passiert.
http://repo.wiregate.de/trac-wiregate/browser/wiregated/trunk/usr/sbin

[StefanW]

Das wird nicht nur irgendwann, sondern kommt durchaus jetzt mit einer Reihe anderer Änderungen in greifbarer Näher - auch weil wir die Planung abgespeckt haben und die derzeitig geplanten Änderungen in zwei Steps herausbringen.

Zunächst mit PL38 decken wir alles Versprochene zum VOC ab und die vielen Performanceverbesserungen und Vorschläge / Modifikationen von Eurer Seite. Enthalten wird dann auch natürlich die Unterstützung für den neuen Professional Busmaster sein.

@Fry. Wir nehmen dann bald Kontakt auf mit Dir für finale Tests auch hinsichtlich des Logikprozessors.

Bitte nicht irgendwelche Teile aus dem Repo holen, sondern auf das gesamte Paket warten...

[StefanW]

Ich möchte speziell in Richtung StefanW noch anmerken: seit den drei kritischen Patches habe ich alle Plugins "kompilierbar" gemacht und seitdem auch keinerlei Memleak mehr. Das Wiregate läuft monatelang durch,

Danke sehr, das freut uns natürlich. Gerade für die Power-Anwender mit vielen Plugins und Sensoren wird die Leistungsverbesserung gut spürbar sein.

Ein wenig möchte ich allerdings auch relativieren, dass die Mehrzahl der WGs kein Problem mit Memleaks hatte. Wir haben durchaus auch Kunden-WireGates mit mehr als 800 Tagen Laufzeit.

lg

Stefan

[Fry]

@StefanW: prima. Übrigens mein Glückwunsch zu den neuen Sensoren und dem prof. Busmaster. Sieht sehr gut aus - schade, dass meine 1-wire-Anlage schon komplett ist :-)

Ja, ich warte auch auf eure neue Softwareversion. Ich habe ein def. Interesse daran, dass mein WG - auch wenn es mittlerweile auf fit-PC2 und Debian-Wheezy-Basis "umgezogen" ist - in den Kernroutinen (/usr/bin/wiregated* sowie Webmin) kompatibel bleibt.

Ich bin wirklich froh, mein Heimsystem auf WG-Basis und nicht mit Homeserver aufgebaut zu haben. Macht viel mehr Spaß.

Danke euch!
Fry

[mivola]

Ich bin wirklich froh, mein Heimsystem auf WG-Basis ... aufgebaut zu haben. Macht ... Spaß.

Dem kann ich mich nur anschließen! Macht wirklich Spaß, ist zuverlässig und enorm vielseitig (Visu, ebus, Logik, Squeezeserver, VPN, "NAS", ...)!
Einziger (momentaner) Kritikpunkt: die großen Update-Intervalle der Software. Aber das ändert sich ja bestimmt zum Besseren demnächst :-)

Danke