[wiregate] Erweitertes WG Logging von KNX_Write für Debugging

[ctr]

Wäre es möglich im EIB oder Wiregate Log oder sonstwo zu loggen "wer/was" auf dem WG einen knx_write veranlaßt hat?
Potentielle Kandidaten sind da command-line, Comet-Visu und WG-Plugins (mit Name des Plugins!!!). Kann man das am eibd überhaupt unterscheiden? Ein Anfang wäre schonmal die Möglichkeit schön, zu sehen welches WG-Plugin etwas geschrieben hat... Würde sich dafür das "return" des jeweiligen Plugins anbieten? Wenn ja sollten wir mal über eine einheitliche Syntax nachdenken (Info, Error, Debug).

Ich habe im Moment ein unerklärlichen Phänomen und weiß nicht warum ein bestimmter knw_write ausgeführt wird. Alle Plugins verschieben und sukzessive wieder reinbringen ist natürlich eine Option, aber schön ist anders...

[Chris M.]

Ich hatte mir für so etwas auch schon mal gewünscht mehrere verschiedene physikalische Adressen angeben zu können (z.B. eine pro Visu-Client; eine Zuordnung verschiedener PA zu den Plugins wäre aber auch nicht schlecht...)

Das Problem ist dabei - so habe ich es verstanden - dass der eibd dass zur Zeit noch nicht unterstützt.

[makki]

Am eibd kann man es nicht unterscheiden, das (Angabe der PA z.B.) gibt die API schlicht nicht her.

return ist die gängige und einfachste Debug-Methode, sieht man auch gleich in der Übersicht usw.
Ebenso kann man die Helper-funktion plugin_log auch im Plugin direkt aufrufen:

plugin_log($plugname,'Zwischenstand: ' . $meinWert);

Nun, beim knx_write wäre das natürlich möglich und vermutlich auch sinnvoll zum debuggen, Standardmässig loggen hielte ich aber für etwas übertrieben, also müsste man es - so dann implementiert - im Plugin auch wieder irgendwie "einschalten" o.ä. Habs mir mal auf die Feature-request Liste geschrieben..
Ein Quickhack wäre in die sub knx_write einfach eine Zeile:

INFO("knx_write from $plugname to $dst with $value using DPT $dpt") if defined $plugname;

landet dann in /var/log/messages

Nun zur CometVisu: das einfachste ist im Webserver das Logging zu aktivieren (ist standardmässig aus, weil eine Menge Sums):
in /etc/lighttpd/lighttpd.conf die Zeile
accesslog.filename = "/var/log/lighttpd/access.log"
(man muss nur die Raute am Zeilenanfang entfernen, die Logs werden automatisch wöchentlich gepackt und rotiert)

Dann ein
/etc/init.d/lighttpd restart
und im Log suchen (geht auch mit dem view_log im Webif, einfach den Pfad zum access.log in der URL ändern) nach "cgi-bin/w"

Makki

[Chris M.]

Am eibd kann man es nicht unterscheiden, das (Angabe der PA z.B.) gibt die API schlicht nicht her.

Wäre evtl. mal wieder Zeit MKögler drauf hinzubitten...

Nun zur CometVisu: das einfachste ist im Webserver das Logging zu aktivieren (ist standardmässig aus, weil eine Menge Sums):

Da sollten wir mal das Thema der Filter angehen, ist ja schließlich im Protokoll schon definiert... (Hab's bisher nicht gemacht, da es noch kein Bottle-Neck ist. Aber wenn jetzt die Installationen immer größer werden, die die CV nutzen wird's wichtiger)

[makki]

Naja, das ist ein bisschen schwierig, wenn mans im Detail durchdenkt:
a) so mal rein KNX "Standard-technisch": ein Gerät hat mal nicht auf mehreren PA's zu labern. Betrachtet man die CV-Instanz als sep. Busteilnehmer ists wieder Ok
b) das ganze geht technisch wenn überhaupt NUR mit TP-UART oder IP-Routing als Backend. Bei allen anderen ist die PA vom Gerät vorgegeben, was aus verschiedenen Gesichtspunkten auch dringend Sinn macht.
Ich sehe die Gefahr, das der AW da sonst eine Menge murks mit macht, ohne sich letztlich der Konsequenzen klar zu sein.. Wer Acked es etc.pp..
Bitte nicht böse nehmen, aber ich halte alleine die Möglichkeit eine PA anzugeben für, sagen wir mal, nicht die beste Idee..

-> Eher noch ein logging im eibd, über welchen "Kanal" (Socket/Prozess,IP) was reinkam.

Das mit dem Logging der knx_writes aus Plugins ist aufgenommen, macht Sinn, ich überlege nur noch wie man es sinnvollerweise einschaltet.
Für die CV gibts eben das access.log, das ist "natürlich" und für mich auch ein-eindeutig, da steht IP&Useragent drin, darf sich jeder aktivieren soweits die Plattform hergibt..

Filter: ich sehe da ehrlichgesagt derzeit keinen Bedarf, gefiltert wird ja in Form der abgefragten GA's.. Das Konzept ist zwar sinnig, spart eine einstellige Anzahl ms oder uA aber es addiert auch Overhead und vor allem Komplexität: der Server muss sich das ja merken. Auf dem WG kein Problem, auf kleinerem evtl. schon, man muss ne Menge Stoff handeln, Reload, Verbindungsunterbrechnung, da schlummern dann gleich 10 Bugs und die gesparten 5ms sind am Server wieder verbraten..

Makki

[Chris M.]

a) so mal rein KNX "Standard-technisch": ein Gerät hat mal nicht auf mehreren PA's zu labern. Betrachtet man die CV-Instanz als sep. Busteilnehmer ists wieder Ok

Ich sehe auch jede CV-Instanz eigentlich als eigenen Bus-Teilnehmer.

b) das ganze geht technisch wenn überhaupt NUR mit TP-UART oder IP-Routing als Backend.

Wir müssen ja nicht die Welt retten. Aber im Rahmen der Möglichkeiten für Klarheit zu sorgen wäre sicher nicht verkehrt.

Filter: ich sehe da ehrlichgesagt derzeit keinen Bedarf, gefiltert wird ja in Form der abgefragten GA's.. Das Konzept ist zwar sinnig, spart eine einstellige Anzahl ms oder uA aber es addiert auch Overhead und vor allem Komplexität: der Server muss sich das ja merken. Auf dem WG kein Problem, auf kleinerem evtl. schon, man muss ne Menge Stoff handeln, Reload, Verbindungsunterbrechnung, da schlummern dann gleich 10 Bugs und die gesparten 5ms sind am Server wieder verbraten..

Ich hab's ja auch erst mal hinten angestellt:

Premature optimization is the root of all evil

Aber ab einer gewissen Visu-Komplexität wird's notwendig werden. Dann werden wir wohl auch "r" und "w" durch eine FastCGI Implementierung ersetzen, so dass nicht jedes mal ein neuer Prozess gestartet werden muss - das sollte gerade auf Winz-Systemen was bringen. Außerdem dürfte man dann hoffentlich ziemlich einfach Werte aus den Plugins direkt für die Visu bereit stellen können.

[makki]

Ich sehe auch jede CV-Instanz eigentlich als eigenen Bus-Teilnehmer.

Hmm, eine Definitions-Frage
Der TLN ist für mich (nach Konnex-lesart, die nicht unbedingt der Weisheit letzter Schluss sein muss!) hier der eibd, in einer virtuellen Welt ist das schwer zu definieren..

Aber ab einer gewissen Visu-Komplexität wird's notwendig werden. Dann werden wir wohl auch "r" und "w" durch eine FastCGI Implementierung ersetzen, so dass nicht jedes mal ein neuer Prozess gestartet werden muss

Das glaube ich ehrlichgesagt nicht. Das starten eines Prozesses ist vergleichsweise "billig", das tracken von Stati kostet dagenen richtig..
FastCGI macht das alles (mal von Webseiten mit zig-Millionen zugriffen pro Minute) alles nur komplizierter und unübersichtlicher, nicht zwangsweise schneller.
In meinen Tests hat das auf der "Worst-case-plattform" (MIPS24k, 266 Bogomips, 32MB RAM, Kaufpreis: 12€ netto ohne Versand) - mit 100 Clients (Testscript) recht gut perfomed, <100ms, was gibts daran zu tunen?

Außerdem dürfte man dann hoffentlich ziemlich einfach Werte aus den Plugins direkt für die Visu bereit stellen können.

Anderes Thema, das muss ich lösen

Makki