the backend did send an invalid response to a read request missing i value

[robertmo]

Hi, ich versuche CV auf meinem Rapi3 mit lighttpd und knxd zu installieren. Anscheinen funktioniert die Verbindung zu knxd, denn ich kann über die cgi w "Seite" die Beleuchtung an und ausschalten. Aber

wenn ich die Demo aufrufe, meldet CV "the backend did send an invalid response to a read request missing i value". Außerdem wird mir im Editor nichts angezeigt.
Hat jemand einen Tip für mich? Danke

[robertmo]

Hatte gestern noch mal probiert und ein cgiread bringt nur "{"d": {},"i":0}". Da fehlt doch etwas?

[robertmo]

cv.io.transport.LongPolling: CometVisu protocol error: backend responded to a read request without an "i"-parameter
SyntaxError: JSON Parse error: Single quotes (') are not allowed in JSON

[Chris M.]

Was steht denn im Netzwerk-Reiter bei dem ersten(!) "r" Aufruf (also kurz nach dem "l"-Aufruf) in der URL - und was kommt als Antwort?

[robertmo]

Aufruf und Antwort wie folgt:

http://10.0.1.171/cgi-bin/l
{"v":"0.0.1", "s":"SESSION"}

http://10.0.1.171/cgi-bin/w?s=SESSION&a=2/1/101&v=81
{'success':1}

http://10.0.1.171/cgi-bin/r?t=0&s=SESSION&a=14/2/88
{"d": {},"i":0}

[robertmo]

Habe jetzt auch mal SmartVisu ausprobiert. Das geht leider gar nicht. Ich bekomme immer einen Fehler "Error writing item!" Warum ist das eigentlich so kompliziert ... schade, dass die Anleitungen nicht aktuell sind 😇

[robertmo]

Habe jetzt mal lighttpd entfernt und apache2 installiert. Zumindest wird mir im Editor nun etwas angezeigt. Entweder kann cometvisu nicht mit lighttpd oder ich muss noch etwas installieren, was nicht in der doku steht? Die Meldung bekomme ich leider trotzdem

[Chris M.]

Aufruf 1 und 2 sehen i.O. aus.
Auch die Rückmeldung auf das "r" ist gar nicht so falsch. Zumindest wenn das knxd die GA "14/2/88" noch nie gesehen hat und folglich die nicht in dessen Cache drinnen ist.
Aber: wenn ich das bei mir mit nur einer GA teste, und die sicher auch nicht (im ansonsten vollen) Cache ist, dann kommt gar keine vollständige Antwort. D.h. es kommt eine mit Status 200, die aber nie fertig wird.

Daraus folgen die Fragen:
1) Ist diese GA sicher schon im knxd Cache?
2) Wie lange dauert es bis das "{"d": {},"i":0}" zurück kommt? Quasi sofort oder erst nach etlichen Sekunden (z.B. 1 oder 5 Minuten)?
3) Welche knxd-Version nutzt Du?
4) Warum nutzt Du nicht die Docker-Version der CometVisu, da ist alles bereits so zusammengestellt, dass es zusammenpasst?

[robertmo]

Chris, danke für deine Antwort. Gut möglich, dass ich da etwas nicht verstanden habe. Wie bekomme ich die Adresse in den Cache? Ich nutze die aktuellste knxd Version von git. Docker? Eigentlich möchte ich nicht extra Docker auf dem pi installieren. Aber wenn das so weitergeht, werde ich wohl keine Wahl haben.

[Chris M.]

Wie das Cache aktiviert wird steht in der knxd-Doku, vgl. https://github.com/knxd/knxd/blob/main/doc/inifile.rst

Ob die aktuelle knxd-Version immernoch kaputt ist bzgl. dem Verhalten gegenüber der CometVisu weis ich nicht, da müsste ich mal wieder schauen. Kann aber gut sein.
Daher nutzt der offizielle CometVisu Docker Container die Version 0.0.5.1 des knxd, bei dem diese Schnittstelle eben noch nicht kaputt war.

Docker hat den Vorteil, dass es sehr leichtgewichtig ist, d.h. quasi keinen Overhead erzeugt und ein Container somit auch als eine Art Software-Paket gesehen werden kann, dass alle Abhängigkeiten intern kapselt.
Somit ist die Pflege der Installation damit auch sehr einfach, da es eben nicht an irgend welchen nicht vorhandenen oder nicht korrekt initialisierten Verbindungen scheitern kann.

[robertmo]

Hi Chris. Danke cache ist jetzt aktiviert. Woran erkenne ich, was im cache ist?

werde am Wochenende dann mal Docker ausprobieren. Ich hatte Docker auch deshalb nicht genutzt, weil ich eine python app geschrieben habe, die auf den bux schreibt. Wie kann ich diese dann nutzen? Muss ich die in das Docker Image packen? Eigentlich kann ich ja auch von außerhalb des images auf knxd zugreifen? Docker nutze ich auch, bin aber kein Experte. Danke sehr

[Chris M.]

Du kannst vermutlich den knxd-Socket per Volume aus dem Docker heraus exportieren und dann auch von außen nutzen (habe ich nie ausprobiert, sollte aber eben theoretisch gehen).

Bei Docker soll man immer nur einen Dienst (Prozess) pro Container laufen lassen. Alleine deshalb sollte schon die Python App dann nicht darinnen laufen, gibt aber noch ein paar Gründe mehr.
Du könntest aber problemlos die in einen anderen Container packen und parallel dazu laufen lassen. Spart langfristig Administrationsaufwand

[robertmo]

JA du hast recht, ein Dienst pro Image. Ich kann aber den port nach außen freigeben und dann ist knxd auch erreichbar. Ich probiere am Wochenende mal damit rum und berichte.

[robertmo]

so ich habe mich gestern Abend noch einmal drangesetzt. Auf einmal geht es! Habe den Linienkoppler neu geladen, aber weiß nicht, ob es daran lag. Außerdem knxd mit groupcache gestartet.

Im log erscheint immer folgende Meldung "Layer 6 [21:A.unix/local 2624.919] not up" Was heißt das?

Ich habe jetzt mal eine visu erstellt. Mir ist folgendes aufgefallen: Sobald die visu Webseite geöffnet wird, baut die "Seite" fast sekündlich eine neue client Verbindung zu knxd auf! Wenn dann die freien client Verbindungen aufgebraucht sind, kommt sofort die obige Fehlermeldung. Habe jetzt mal die Clients auf +49 gesetzt, dass geht grundsätzlich gut, aber irgendwann kommt dann die Fehlermeldung. Im log von knxd kann ich zusehen, wie eine client Verbindung nach der anderen aufgebaut wird ... alle 1 bis alle paar Sekunden. Soll das so sein?

Achso, wenn ich dann die visu auf einem 2. Rechner öffnet, werden halt noch mehr Verbindungen aufgebaut und dann komm auch zwischendurch "Layer 4 [ 5:kc.cache/G 2903.080] GroupCache reread timeout".

[Chris M.]

Den knxd nutze ich auch nur, was da welche Meldung bedeutet weiß ich auch nicht, da müsstest Du mal dort fragen.

Grundsätzlich Funktionierte die Kommunikation mit dem knxd so:

• Der erste Lese-Zugriff ("r" mit Parameter "t=0" und ohne "i" als Parameter) möchte sofort eine Antwort mit allen dem knxd-Cache bekannten letzten Werten. Dazu wird ein "i" zurück geliefert, dass die Index-Position im Ring-Speicher des Cache angibt.
• Sobald die CometVisu eine Antwort auf ein "r" bekommt wird ein neues "r" gestartet (mit dem Parameter "i" der in der letzten Antwort vom "r" drinnen war)
• Hat der knxd noch keine relevanten neuen Pakete seit dem letzten "i" bekommen verzögert der die Antwort bis so ein Wert vorhanden ist

Damit ist auch klar, dass es normal ist, wenn öfters ein "r" aufgebaut wird - einfach jedes mal wenn neue Daten über den Bus angekommen sind. Da gehen aber auch keine Ressourcen bei aus, so etwas kann über Jahre hinweg stabil laufen.
Sollte einfach kein neues Paket kommen, so wird irgend eine Seite in ein Timeout laufen. Das ist aber nicht schlimm, da wird dann einfach sofort eine neue Verbindung aufgemacht.

D.h. sowohl häufige Verbindungen als auch timeouts sind normales Verhalten.