Plugins auslagern - eBus/KNX Daemon

[XueSheng]

Heute Abend hatte ich mal das eBus plugin gelöscht. Siehe da, kein nennenswerter Anstieg des Speicherverbrauchs. Nachdem ich das eBus Plugin wieder in den plugin Ordner kopiert hatte, stieg der Speicherverbrauch wieder. Das angefügte png zeigt das beschriebene nochmals (21:40-22:45 war ohne Plugin!).

[JuMi2006]

o.k. - Danke, aber ich verstehe es nicht.

[XueSheng]

Ich habe eine Frage bzgl. der rrd Erstellung.

Der Energieertrag ist im Beispiel mit counter und Zeitraum 0.5h angegeben.

0/5/206;12;c;0.5;get;mv yield_sum;Energieertrag

Wenn ich nun verschiedene Zeiträume erfassen möchte, muss/darf man dann diese Zeile mehrfach verwenden? Oder werden dann die rrds überschrieben? z.B:

0/5/206;12;c;0.5;get;mv yield_sum;Energieertrag
;;c;24;get;mv yield_sum;Energieertrag 24g
;;c;168;get;mv yield_sum;Energieertrag 7d

Bevor ich das am laufenden System teste und mir die Daten der rrds zerschieße, frage ich besser .

[JuMi2006]

AW: Plugins auslagern - eBus/KNX Daemon

Momentan würde das schief gehen. Lösung hab ich ad hoc keine parat.
Workaround:
Zusätzlich eines der zahlreichen rrd-plugins nutzen.

Baustelle 2.0

[XueSheng]

Der Speicherverbrauch von knxd hat mir keine Ruhe gelassen. Durchschnittlich musste knxd vier mal am Tag neustarten, da das 20MB Limit so schnell überschritten wurde.

Nachdem ich sehr positive Erfahrungen mit der Umstellung auf das Vorkompilieren von wiregated.pl Plugins gemacht habe (https://knx-user-forum.de/code-schni...-memleaks.html), wollte ich dies auch für knxd.pl testen.

Lange Rede, kurzer Sinn: Patches für die Umstellung "Vorkompilieren" von knxd.pl und zugehöriges eBus plugin sind angefügt (basierend auf svn1880).

Dies habe ich zwar erst einen Tag getestet, jedoch bin ich bislang sehr positiv überrascht. Der Speicherverbrauch der letzten 24h lag lediglich bei wenigen KB (anstatt 80MB).

@JuMi: Bitte schau Dir doch mal die Patches bei Gelegenheit an. Das Laden der Config (eBus_plugin.pl) habe ich mit "do" umgeschrieben. Gab es einen Grund, warum die Config mit "eval" ausgewertet werden sollte?

[JuMi2006]

Vielen Dank ... sehe ich mir die Tage mal an und werde das dann ins SVN stellen.

[Fry]

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

[JuMi2006]

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

[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]

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

[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

[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

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

[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)

[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).