KNXD Cometvisu Caching Ladezeiten

[larsknx]

Hallo zusammen. Ich betreibe seit 11 Jahren ein Communitygate.

Ursprünglich kommend von wheezy haben eigentlich bis auf kleinere Probleme Updates auf Jessie, Strech bis hin zu aktuell Buster geklappt.

Nun musste ich eibd durch knxd ersetzen und der Daemon wird so gestartet

/usr/local/bin/knxd -e 0.0.1 -E 0.0.2:8 -c -D -T -R -S 224.0.23.12:3671 -u /tmp/eib -b ipt:192.168.2.101

Es klappt alles hervorragend, ich kann auf den Bus schreiben, auf die ganzen Logiken vom Logikprozessor.pl etc laufen einwandfrei.

Auch Schreiben auf den Bus mit zB

/usr/bin/groupswrite local:/tmp/eib 2/1/11 1

klappt super. Das einzige, was nicht gut funktioniert, ist die Cometviusu.

Ich habe mit knxd (selbst kompliert) neue eibread/write-cgi erhalten -> die symlinks aktualsiert (usr/lib/cgi-bin). Sobald Adressen nicht zu lesen sind, läd sich die Visu tod .

Verkleinere ich meine visu_config.xml auf nur lesbare GA's (zB nur Status Lampen) lädt die Visu relativ schnell alle Stati ein, aber beim aktualisieren dauert es wieder die gleiche Zeit. Das war vor dem Update anders. Einmal wiregate neugestartet, hat er ca. 5 Minutenm zum laden im Browser gebraucht, aber danach beim F5 zB die Daten schnell wieder geladen.

Also grundsätzlich kann ich alles über die Visu machen, wenn ich die config auf lesbare GAS verkleinere. Wenn ich wieder die GAs zB vom Russound mitreinnehme, lädt er er nie das alle GAs und entsprechend kann man in der Cometvisu auch nichts mehr machen. Ich hoffe, ihr versteht, was ich meine.

[Chris M.]

Beim knxd wurden vor einiger Zeit ohne Rücksprache und Absicherungen Änderungen eingeführt, die mit der CometVisu nicht kompatibel waren. Ob die zwischenzeitlich gefixt wurden weiß ich leider nicht.

Praktisch bin ich - und damit auch die offiziellen CometVisu Docker Container - daher auf der wunderbar stabil funktionierenden Version 0.0.5.1 geblieben.

Ich schätze, dass ein Fix für den aktuellen knxd nicht sonderlich schwer ist. Aber es hat sich bisher halt noch niemand dafür interessiert...

[Smurf]

"Beim knxd wurden vor einiger Zeit ohne Rücksprache und Absicherungen Änderungen eingeführt" -- mit Verlaub, das ist Quatsch. Die 0.14 war ein Jahr lang parallel zur 0.12 verfügbar und alles beim Alten zu belassen war schlicht nicht möglich. Ich verlasse mich doch nicht auf ein Library, das ungepflegt ist und mit sämtlichen modernen Entwicklungswerkzeugen nicht zusammenarbeitet. Dass sich dabei Fehler einschleichen ist leider nicht immer zu vermeiden, aber wenn sie keiner meldet, kann ich sie nicht beheben.

Das Nicht-Melden darf ein geneigter CometVisu-Benutzer gerne mit einem brauchbaren Fehlerreport nachholen, idealerweise hier: https://github.com/knxd/knxd/issues/493

"Brauchbarer Fehlerreport" heißt in diesem Zusammenhang: stelle das Problem nach, indem du die knxd-Anfragen, die der CometVisu durchführt, via Shellscript quasi zu Fuß machst und es so reproduzierst, und zwar bitte gegen die aktuelle knxd-Version. Ohne Docker und ohne Visu davor.

[Chris M.]

Mein letzter Test ist nun schon einige Zeit her (habe gerade ein Issue im knxd von mir zu dem Thema von 2015 gefunden). Anscheinend hat sich hier auch am knxd-Code bei eibread-cgi / eibwrite-cgi etwas getan.

Ich kann gerne mal die neueste knxd-Version testen.

[larsknx]

Bin am verzweifeln. Bin wieder zurück trotz Buster zu eibd 0.05. Kann das von smurf überhaupt nicht bestätigen, mit der Cometvisu und KNXD klappts nur mit ganz wenigen Adressen. Ob das nun an Cometvisu oder KNXD liegt, kann ich nicht beurteilen. Fakt ist, mit der alten 0,05 und Cometvisu wurde alles nach dem ersten Mal danach flott geladen.

Sobald ich jetzt mit KNXD meine komplette visu config reisetze, kommt nichts mehr. Kann mich todwarten .Und ich hatte knxd in der neusten Verison selbst kompiliert. Nur mit ganz wenigen Adresssen geht es. Sobald man zB Heizungs mit vielen STatusmeldungen reinnimmt, geht nichts mehr.

Also bin ich wieder zurück zum guten alten eibd 0.05.


Es klappt alles. Geladen mit

/usr/bin/eibd -e 1.1.243 -c -S -D -i -T -d -u --pid-file=/var/run/eibd.pid ipt:192.168.2.101


Ich kann alles schalten zB mit
groupswrite ip:localhost 2/1/11 0
groupswrite local:/tmp/eib 2/1/11 1

Auch cachign wird korrekt angezeigt.

grouplisten local:/tmp/eib 2/2/11

/var/log/apache2# groupcacheread local:/tmp/eib 2/2/11
Write from 1.1.21: 00


Selbst an meinen Schaltern kann ich Musik zB an und aus machen. Nur in der Cometvisu kommt immer :


{'error': 'Open failed'}

Sieht so aus als ob eibread.cgi und eibwrite.cgi irgendwie nicht mehr funktiionieren. Habe die sowohl aus dem alten Wiregate nochmal drüber gebügel sowie selbst nochmal neu kompiliert. Alles aud dem Server funktioniert mit dem alten eibd 0.05 trotz Buster. Nur die Cometvisu nicht. Jetzt hab ich dort nen riesen Aufwand gemacht alles einzurichten. Gibts noch ne Chance für mich ? Alternative ?

Auch neu kompiliert nach

Additional eibd-clients for CV-Backend (eibread/write-cgi)

Mini-Howto:

Option 1)
* Install gcc and libeibclient-dev (or Distribution-specific package containing libeibclient.a)
.....

Ich hab schon chmod 0777 /tmp/eib gemacht

ls -la


-rwxr-xr-x 1 root root 92 Mär 3 2016 l
lrwxrwxrwx 1 root root 20 Dez 6 13:36 r -> /usr/bin/eibread-cgi
lrwxrwxrwx 1 root root 21 Dez 6 13:36 w -> /usr/bin/eibwrite-cgi

[Chris M.]

Ich bin gerade dabei die neuste knxd Version mal Stand-Alone nach Docker zu bringen und danach in den CometVisu-Docker Container. Dann kann ich mal schauen, wie der aktuelle knxd sich bei einer realen Installation verhält.
Ein paar einfache Versuche (mit nur einer PA) an der Kommandozeile sahen aber schon mal i.O. aus.

[larsknx]

KAnnst du mir vielleicht mal so einen Kommandozeilen request nennen ? Wenn ich auf der console ./r a .... eingebe, kommt zB

Content-Type: text/plain

{'error': 'No data'}


Naja, und wie gesagt, mit wenigen GA's lief es bei mir auch, aber halt nicht mit vielen.

[Chris M.]

KAnnst du mir vielleicht mal so einen Kommandozeilen request nennen ? Wenn ich auf der console ./r a .... eingebe

Das sind CGI Programme, d.h. die musst Du so aufrufen wie es der Webserver macht.

Um z.B. den Wert 0x1525 (also die Bytes auf dem KNX "80 15 2e") an die PA 12/7/90 zu schreiben brauchst Du

export REQUEST_METHOD=GET QUERY_STRING='s=SESSION&a=12/7/90&v=80152e' && eibwrite-cgi

Für den initialen Read (also aus dem Cache)

export REQUEST_METHOD=GET QUERY_STRING='t=0&s=SESSION&a=12/7/90' && eibread-cgi

und für die dann folgenden (also das COMET), dann natürlich mit jeweils angepassten Wert für "i":

export REQUEST_METHOD=GET QUERY_STRING='i=597&s=SESSION&a=12/7/90' && eibread-cgi

[larsknx]

Danke Chris, das hat mir schon mal zum Testen sehr viel weiter geholfen. Ich habe jetzt mal die eibwrite-cgi selbst kompoiliert und manuell einfach statisch

*eiburl = "local:/tmp/eib";

gesetzt. Zumindest kriege ich jetzt auf der console nicht mehr


{'error': 'Open failed'}, sondern


lars-multihome:/usr/src/cv-eibd-clients# export REQUEST_METHOD=GET QUERY_STRING='t=0&s=SESSION&a=2/2/11' && /usr/bin/eibread-cgi
Content-Type: text/plain

{"d": {"2/2/11":"01"},"i":45812}

lars-multihome:/usr/src/cv-eibd-clients# export REQUEST_METHOD=GET QUERY_STRING='t=0&s=SESSION&a=2/2/11' && /usr/bin/eibread-cgi
Content-Type: text/plain

{"d": {"2/2/11":"00"},"i":45863}


Die Werte stimmen, wenn ich das Licht anmachen ist 01 , bei aus 00. Jetzt stellt sich die Frage, warum klappt das in der Cometvisu nicht. Die eibread-cgi und eibwrite-cgi funktionieren auf der console mit deinen commands.

Auch groupwrizte-cgi funktioniert auf der commanline in der shell:

export REQUEST_METHOD=GET QUERY_STRING='s=SESSION&a=2/1/11&v=80' && /usr/bin/eibwrite-cgi
Content-Type: text/plain

{'success':1}

export REQUEST_METHOD=GET QUERY_STRING='s=SESSION&a=2/1/11&v=81' && /usr/bin/eibwrite-cgi
Content-Type: text/plain

{'success':1}


In der Cometvisu kommt dennoch weiterhin beharrlich


{'error': 'Open failed'}, sowohl bei read als auch write zugriffen. Irgendwie muss das dann ja an den Rechten vom Webserver liegen oder ? Kann überhaupt perl ohne Dateiendung so vom Wevserver interpretiert werden ? Muss das vielleicht noch in einen Wrapper ? Oder fehlt dem Webserver User die Berechtigung, mit dem socket in der Verbindung zu treten ? Der eibd läuft unter root ?

eibd -e 1.1.243 -c -S -D -i -T -d -u --pid-file=/var/run/eibd.pid ipt:192.168.2.101

[Chris M.]

Beim aktuellen knxd musst Du erst mal schauen, ob der überhaupt sein Socket anlegt, das ist aber nicht mehr /tmp/eib sondern /run/knx. Dies geht aber nur, wenn der knxd mit entsprechenden Rechten gestartet wurde, wenn Du das als normaler User machst geht das aufgrund fehlender Schreib-Berechtigung in /run/ nicht.
Dem knxd kannst Du zwar per Config auch einen anderen Pfad vorgeben - aber im eibread-cgi / eibwrite-cgi ist der halt fest einprogrammiert...

Wenn ich bei Tests ein "{'error': 'Open failed'}" bekommen habe, lag es eigentlich immer daran, dass der Socket nicht da war.

Der Webserver selbst braucht nur die Dateien eibread-cgi und eibwrite-cgi unter den Namen "r" und "w" in seinem CGI-Verzeichnis. Ein symbolischer Link ist dafür ausreichend.
Von den Rechten ist da nur entscheidend, dass die für den Webserver auch ausführbar sind (das "x" im "ls -l").

Mit Perl hat das alles nichts zu tun.
Bemerkung am Rande: Linux braucht keine Dateiendungen um zu wissen was das für eine Datei ist. Damit ein (Perl-)Skript direkt läuft braucht es auch das Execute-Flag (das "x") und in der ersten Zeile ein "Shebang" - also bei Perl ein "#!/usr/bin/perl".
Dies ist für die dritte Datei im Bunde, das "l", aber relevant, da diese Datei ein winziges Skript ist.

[Chris M.]

Was ich gerade gesehen habe: der knxd legt seinen Socket so an, dass nur der Owner (root) schreiben darf, das gibt auch die Meldung "{'error': 'Open failed'}".
Wenn Du den Socket per "chmod a+w /run/knx" für jeden zum Schreiben freigibst, sollte auch der Aufruf von "r" und "w" aus dem Web-Server heraus funktionieren.

[larsknx]

Hab den den socket immer mit chmod 0777 /tmp/eib geschrieben, daran liegts nicht. Hab den knxd mit user www-data gestartet, geht auch nicht. Intetressant ist folgendes. Habe nun einen Wrappper gemacht und den übers Internet aufgerufen:

write.pl

#!/usr/bin/perl -w
print "Content-type: text/html\n\n";

system 'export REQUEST_METHOD=GET QUERY_STRING="s=SESSION&a=2/1/11&v=81" && /usr/lib/cgi-bin/w';

Das geht komischerweise. Ich teste mal weiter aus.


Ok. Read geht leider nie. kommt immer


{'error': 'Read failed'}

[larsknx]

Also kriege bei write nen success hin, aber bei read kommt immer
{'error': 'Read failed'}

ich weiss nicht mehr weiter.

[Chris M.]

Ich bin noch dran und berichte, wenn ich mehr weiß.

Leider ist hier unser Setup mit Docker und den Autobuilds nicht für ein interaktives Entwickeln optimal, da ich nach Änderungen einige Zeit warten muss, bis ich testen kann. Und der Umstieg beim knxd von 0.0.5.1 auf das neueste Release geht nur mit einigen Änderungen in der Docker Infrastruktur.

[Chris M.]

Ein Problem mit dem knxd 0.14.39-4-g9929ed6 habe ich gerade gefunden:
Der gibt jedem Write eine neue PA aus seinem Pool!?!

Am Anfang hatte ich den Pool nur sehr klein (wozu auch größer machen? Es hängt ja nur die Visu an diesem knxd, und der arbeitet hier ja nicht als Router oder stellt mehrere Tunnel bereit...), weshalb dann die Schreibzugriffe nach 1-2 erfolgreichen mit "Connect failed" abgebrochen sind.
=> Bug Report: https://github.com/knxd/knxd/issues/495

Mit vergrößertem Pool läuft der 0.14 knxd nun in meinem Docker mit der CometVisu, sowohl schreibend als auch lesend. Aber es fühlt sich noch etwas hakelig an - d.h. ich suche noch wo es nicht ganz rund läuft.

larsknx Der knxd 0.0.5.1 ist extrem stabil, d.h. wenn da etwas nicht läuft muss es an deinem Setup liegen.