Plugins auslagern - eBus/KNX Daemon

[mivola]

Das "Ding" soll ja nicht nur aufm WG laufen oder? Dann würde ich "wiregate" im Name auch vermeiden. Wie wäre es mit

yak(p)d: yet another knx (plugin) daemon

[greentux]

tintwd - this is not the wiregate daemon.
yawd - yust another wiregate daemon

[kleinklausi]

jetzt mal so aus der Hüfte geschossen: plugind

Gruß

[JuMi2006]

Ich wollte jetzt mal "sed -i s/knxd/??????/g" durchs Repo fliegen lassen, aber mir fehlt ein passender neuer Name ... any ideas ?

[JuMi2006]

Ich würde einen neuen Namen vorschlagen. In sen nächsten Wochen werde ich das github Repo entsprechend ändern, bzw. den Daemon umbenennen. Die Startscripte werde ich entsprechen anpassen.

Der Name passt besser zu den Jungs vom eibd Fork.

[ctr]

Ich meinte das eher in die andere Richtung: Wir sollten uns mal angucken, was beim Wiregate-Update genau gemacht wurde. Ob da nur die vorgeschlagenen Änderungen eingeflossen sind oder vielleicht noch ein paar (andere) Verbesserungen oder bessere Implementation der Änderung. Also eher einen neuen knxd (oder unter anderem Namen?) basierend auf dem aktuellen wiregated (ggf. mit den weiterhin nötigen Änderungen/Verbesserungen)

[XueSheng]

Ich weiss jetzt nicht was sich hinter dem Punkt "erweiterte Syntax für das Aufrufen von Plugins in Abhängigkeit von KNX/EIB-Telegrammen" verbirgt, aber grundsätzlich sollte das aktuelle wiregated.pl in der Lage sein das ebus plugin des knxd auszuführen.

Die Frage ist nur, ob man tatsächlich auf knxd verzichten will. Das knxd von damals enthält im Prinzip alle wichtigen Features, die es für einen stabilen Betrieb benötigt. Die Unabhängigkeit von wiregated.pl hat für mich den wesentlichen Vorteil, dass im Fehlerfall zeitkritische Plugins des wiregated.pl unberührt bleiben.

Aktuell beobachte ich nur am Rande, in welche Richtung sich der Daemon ebusd entwickelt. Hier könnte man ggf. ansetzen und das eigentlich ebus Plugin optimieren. Wie gesagt, mittlerweile sollte es keine Rolle mehr spielen, ob man es mit wiregated.pl oder knxd benutzt (kleinere Anpassungen bzgl. Laden der config o.ä. sind evt. notwendig).

[ctr]

Wenn ich das richtig sehe, sind einige der knxd Features in das Original-Wiregate gewandert. Gäbe es da evtl. potential für Anpassungen?

knxd

Der knxd ist im Kern der gleiche Daemon der auch auf dem original WireGate läuft. Es wurden einige Veränderungen und neue Funktionen hinzugefügt, weiterhin wurden Abhängigkeiten gelöst:

• Counter-RRDs werden besser unterstützt
• erweiterte Syntax für das Aufrufen von Plugins in Abhängigkeit von KNX/EIB-Telegrammen
• vollständig anpassbare: Logfiles+Pfade, Plugin-Pfade etc.
• interne Speicherüberwachung da es ggf. Memleaks gibt (Plattformabhängig)

-- 2014-10-10 : WireGate Development <devel@wiregate.de>

Patchlevel: 38

* Abhaengiges Plugin-Subscribe (danke an JuMi2006)
$plugin_subscribe - abonniert das Plugin auf jede Art von Telegrammen
$plugin_subscribe_read - abonniert das Plugin nur bei Read-Telegrammen
$plugin_subscribe_write - abonniert das Plugin nur bei Write-Telegrammen
* RRD Counter Feature (danke an JuMi2006/dombn)

Außerdem wollte ich am Rande darauf hinweisen, dass hier ein eibd Fork diskutiert wird, der wohl auch knxd genannt wurde. (Habe aus dem Thread auch mal hierhin gelinkt)

[mivola]

@Mirco,

sag mal, ich kann mich dunkel erinnern, dass es mal ein Package vom knxd für Debian gab. Ich kann es leider nicht mehr finden. Gibt es das noch und von welchem SVN-Stand ist es? Würde das für Raspbian passen?

Danke,
Micha

Um mir mal selbst zu antworten: hier ist es: https://github.com/JuMi2006/knxd/blo...xd-1.0_all.deb. Es müsste lt Zeitstempel auch dem aktuellen SVN-Stand entsprechen.
Alternativ kann man mit diesem Script lokal ein neues .deb erstellen: https://github.com/JuMi2006/knxd/blo...ke_knxd_deb.sh. Das hat auf meinem Raspbian auch gut funktioniert.

VG
Micha

[perf]

I benutze knxd unter Raspbian. Ich habe so gemacht:

apt-get install libmath-round-perl libmath-basecalc-perl librrds-perl libproc-pid-file-perl libproc-daemon-perl

svn co svn://svn.code.sf.net/p/openautomation/code/tools/knxd
Copy files to /
Permissions for /etc/init.d/knxd
Permissions for /usr/sbin/knxd.pl

(Ich habe auch einen Wiregate...)

/Per

[mivola]

@Mirco,

sag mal, ich kann mich dunkel erinnern, dass es mal ein Package vom knxd für Debian gab. Ich kann es leider nicht mehr finden. Gibt es das noch und von welchem SVN-Stand ist es? Würde das für Raspbian passen?

Danke,
Micha

[JuMi2006]

Hallo Sten,
schöner Einstieg!
Ich hab nur mal grob draufgeschaut, es fehlt einfach die Zeit. Fehlende Zeit und der Umstieg auf ein anderes System ist auch der Grund weshalb ich knxd und das ebus-plugin nicht länger supporten kann. Für die alte Variante stehe ich natürlich gern gerade, aber eine neue ist bei mir aufgrund des Systemwechsels leider nicht mehr in Planung.

Die Community wird sich aber sicherlich über Dein neues Plugin freuen und auch bald benutzen. Spätestens mit dem nächsten Patch-Level des wiregated wird auch der knxd für mich nicht mehr supportbar. Persönlich ist das dann einfach tote Zeit. Ich gehe davon aus dass Elabnet den ein oder anderen Patch übernimmt und das Plugin damit auch ohne knxd leben kann. Im einzelnen wäre das was mir auf Anhieb einfällt Counter-RRDs und plugin_subscribe_read/write.
Dagegen spricht Dein Vorgehen alle Werte auf einmal abzuholen, das verlängert die Laufzeit des Plugins ... schau Dir einfach mal das Log an wie schnell ein Wert aktualisiert werden kann. Diesen Punkt würde ich nochmal überdenken damit das Plugin auch ohne knxd verwendet werden kann.

Gruß Mirko

[sten123]

Was JuMi2006 mit dem knxd da auf die Beine gestellt hat ist schon echt Klasse. Damit konnte ich auf Anhieb meine Heizungssteuerung über linknx realisieren. Einmal auf den Geschack gekommen wollte ich jetzt eine ganze Reihe an Parametern meiner Wärmepumpe auslesen. Jedoch ändern sich manche dieser Werte nur sehr selten, andere hingegen sehr oft, wie z.B. die Temperaturen in den einzelnen Kreisen und die Statusinformationen der Wärmepumpe bzw. der Heizkreise. Nun bestand für mich das Ziel, über die Konfigurationsdatei durch die Angabe eines Periodenwertes steuern zu können, welche Werte in welchem zeitlichen Intervall ausgelesen werden sollen. Bei eingehenderer Beschäftigung mit dem ebus-Plugin mit dem Ziel dort meine Erweiterung unterzubringen, sind mir ein paar Sachen aufgefallen, die sich denke ich verbessern lassen. Bei der Umsetzung dieser Dinge ist eine neue Version des Plugins entstanden, die ich Euch hiermit zum Testen gebe.

Installation:
Aus dem einen Plugin wurden jetzt quasi 2 Plugins. Ein Plugin wird zyklisch aufgerufen und liest die Konfigurierten get- und cyc-Werte aus während das andere Plugin nur auf eingehende Lese- und Schreibanfragen reagiert. Beide Plugins haben den gleichen Code, die Unterscheidung um was es sich für ein Plugin handelt trifft der Name des Plugins. "plugin_ebus_set.pl" ist das Plugin zur Verarbeitung der Lese- und Schreibanfragen. "plugin_ebus_get.pl" wird zyklisch ausgeführt und liest Daten aus den Wärmepumpe aus. Nur eines der beiden Plugins muss als Datei abgelegt werden, das andere kann auch als Symlink realisiert werden. Wie auch immer, letztendlich müssen im Pluginordner 2 Dateien gleichen Inhalts mit den Name "plugin_ebus_set.pl" und "plugin_ebus_get.pl" vorhanden sein.

Folgende Punkte haben sich geändert:

• Unterstützung für das Serialisieren / Deserialisieren komplexer Perl-Datenstrukturen in bzw. aus der Plugin-DB mittels Storable.
• Dadurch muss die CSV-Konfig jetzt nicht mehr bei jedem Plugin-Aufruf geladen und verarbeitet werden sondern nur noch bei einer Änderung an der CSV oder beim Neustart den knxd.
• Durch das Vorhalten der Konfiguration als komplexe Datenstruktur kann auf die Konfigurationswerte ohne aufwändige Iterationsschleifen direkt z.B. mittels der Gruppenadresse zugegriffen werden. Das beschleunigt die Verarbeitung von Lese- und Schreibanfragen.
• Das Auslesen aller konfigurierten get- und cyc-Parameter erfolgt nun am Stück während nur eines Pluginaufrufs.
• Weiterhin konnte - da die Konfiguration nur noch selten aus der CSV-Datei gelesen werden muss - eine umfangreiche Prüfung der Konfiguration umgesetzt werden.
• Das Logging wurde deutlich erweitert.
• Die eingangs beschriebene Möglichkeit der Steuerung des Intervalls der Übermittlung des Wertes durch die Vorgabe eine Periodenwertes wurde umgesetzt.
• Der Filter zur Unterdrückung der Übermittlung unveränderter Werte wurde angepasst. Grundsätzlich greift der Filter nur noch dann, wenn keine konkrete Angabe zur Periode der Übergabe der Wertes gemacht wurde und der Wert somit zu jedem Pluginaufruf auszulesen ist. Außerdem wird künftig ein unveränderter Wert auch dann übermittelt, wenn zuvor mindestens 10 x die Übermittlung unterdrückt wurde. So wird verhindert, dass sich kaum änderende Werte über mehrere Stunden oder gar Tage gar nicht gesendet werden.

Die Steuerung der Häufigkeit des Auslesens eines bestimmten Wertes erfolgt über die neue Spalte 7 "Periode", die vor dem Kommentar in die CSV-Datei eingefügt wird. Folgende Werte sind möglich und wirken wie folgt:

• -1: Das zyklische Auslesen für diesen Wert wird abgestellt. Der Wert wird nur noch als Antwort auf eine Leseanfrage übermittelt.
• LEER oder 0: Der Wert wird bei jedem Pluginaufruf ausgelesen. Je nach Konfiguration wird ein zum letzten Lesen unveränderter Wert nicht auf den KNX-Bus weitergegeben.
• >0: Der angegebene Wert in Sekunden wird mindestens zwischen zwischen zwei Auslesevorgängen gewartet.

Im Anhang meine überarbeitet "eBus_plugin_set.pl" und als Beispiel meine CSV-Datei. Der knxd läuft bei mir ganz brav mit konstant 14 MB. Einen Zuwachs ein Speicherbelegung konnte ich binnen 24h nicht feststellen.


Dann viel Spaß beim Testen.


Sten

[JuMi2006]

Werde ich mal mit aufnehmen, fürs produktive testen brauchts dann jemand anders. Mitte nächster Woche dann im SVN, vielleicht auch Sonntag.

[Fry]

Hallo zusammen,
seht mal hier, das hat große Wirkung. Schlage vor, es direkt in den knxd zu übernehmen...
VG, Fry