CometVisu ohne KNXD/EIBD?

[henfri]

Makki,
den eibd zu forken war nicht zuletzt deine idee...
Da hätte ich mir jetzt eine positivere Einstellung gewünscht.

Davon abgesehen:
alleine der knxd/eibd reicht doch nicht wirklich. Man braucht auch was für die diagramme.

[makki]

Jep, henfri nicht zuletzt ist gut - ich habs gemacht
Und ich bin smurf und allen anderen auch dankbar, das sie übernommen haben!
Anyway bin ich relativ raus, weil ich haupt und nebenberuflich 12h/Tag jetzt einfach ganz was anderes mache und es daher sehr schwer ist "nebenbei" mit C++ und KNX am Ball zu bleiben..

Das Problem ist, da wurden strukturell ein paar Dinge im knxd geändert, die das Prinzip der verwendeten Methodik - zumindest - beeinflussen; Also das kann man IMHO nicht einfach "mal schnell" fixen. Ab Mitte August wirds wieder ruhiger, dann schau mer mal - bis dahin kann ich den Ball nur im Spielfeld halten..

Makki

[Chris M.]

dazu mal ne Frage an:
Chris M.

Die CometVisu macht nen Request mit den Parametern

?t=60&s=SESSION&a=1/2/3&a=3/4/5

und erwartet einen response im Format

{"d": {"1/2/3":"00","3/4/5":"27"},"i":51313}

Request:
t ist der TimeOut, s eine Session ID die nirgends genutzt wird? a ist logischerweise eine Liste der anfragten GAs,

Response:
"d" steht sicherlich für Data und ich schätze die CV erwartet da echtes JSON, also Reihenfolge der Attribute und zusätzliche Informationen sind egal.
aber was ist das "i" und welchen Inhalt erwartet die CV da? "i" und "d" sind sicher auch in der Reihenfolge egal?

Fragen zum Protokoll beantwortet als erst die Spek https://github.com/CometVisu/CometVisu/wiki/Protokoll (und bei Unstimmigkeiten die bindende englische Version: https://github.com/CometVisu/CometVisu/wiki/Protokoll )

Die Session wird aktuell noch nicht genutzt, da es bis auf einen mir bekannten Fall auch so wunderbar geht. Die Session wäre notwendig, wenn man lange GA-Listen nicht mehr in jedem Aufruf übertragen mag und die durch einen kurzen Filter ersetzt (vergleichbar: URL Shortening). Der Nachteil ist jedoch, dass der Server dann nicht mehr zustandslos ist, d.h. die aktuell sehr simple eibread-cgi Lösung ein gutes Stück komplizierter werden muss.

"i" ist ein extrem wichtiger Parameter und eigentlich die ganze Magie hinter dem CometVisu Protokoll, da es dafür sorgt, dass kein für die Visu interessantes KNX Bus Paket verloren geht. Z.B. weil es genau dann gesendet wurde, als der eine "r" schon an den Client zurück geschickt wurde, der neue "r" aber noch nicht gestartet wurde.

Chris M.
kommt die CometVisu mit zusätzlichen Feldern klar?

Ja, die werden vermutlich(!) ignoriert werden. Ist halt unspezifiziertes Verhalten und damit per Definition undefiniert...

die CV läuft hier sauber mit meinem eibread-cgi Ersatz. Ist zwar langsamer und braucht mehr CPU, aber mein Hausserver langweilt sich eh den ganzen Tag.

Ich sag doch immer, dass CV Protokoll zu implementieren ist kein Hexenwerk

# insert "i" key in RESPONSE (no idea why or what this does)
RESPONSE["i"]=4711

Siehe oben, "i" ist sehr wichtig!

ich habe bei GitHub einen issue dafür aufgemacht und es versucht so gut wie möglich zu beschreiben. Ich kann aber ehrlich auch verstehen wenn für so eine CometVisu-Sonderlocke nicht viel Zeit investiert wird. Wenn da was passiert werde ich das natürlich unterstützen. Es kam auch schon ein kurzer Response.

Ich hätte schon Interesse, dass auch mit aktuellen knxd die CV-Anbindung funktioniert. Aber nach dem in meinem Setup damals nicht mal der knxd selbst gelaufen ist und das Interesse am Bug-Fixing seitens Maintainer sehr überschaubar war, habe ich mich halt um für mich relevantere Dinge gekümmert.
Warum aus dem stabilen eibd/knxd etwas nicht mehr funktionierende gemacht wurde weiß ich nicht, verfolge die Entwicklung dort aber auch nur sporadisch.

[makki]

Kann ich nur beipflichten, wir haben uns damals schon die Köpfchen zerbrochen und etwas m.E. bis heute sehr gutes, Ressourcen-schonendes und effizientes ausgedacht.
aber es ist das "i" wie Chris schrub, das ist von vorn bis hinten essentiell, also bis zum groupcachelastupdates im eibd, sonst wird das nix..

Makki

[MGK]

Fragen zum Protokoll beantwortet als erst die Spek https://github.com/CometVisu/CometVisu/wiki/Protokoll (und bei Unstimmigkeiten die bindende englische Version: https://github.com/CometVisu/CometVisu/wiki/Protokoll

verstehe.... ich dachte eibread-cgi wäre eine REST Implementierung. Push macht natürlich schon mehr Sinn an der Stelle.

P.S. die CV macht den ersten Request mit t=0, das zwingt das Backend laut Spec dazu alles vom Bus zu lesen... was bei nicht lesbaren GA passiert ist aber nirgends spezifiziert... das das aktuelle eibread.-cgi.c dann einfach gar nix liefert wegen irgendeinem Timeout ist natürlich unglücklich.

[Chris M.]

Das "t=0" besagt ja, ein TimeOut von 0 Sekunden - also eine sofortige Antwort.

Die zeitliche Abfolge ist dann:

• Daten die im Cache liegen werden damit übertragen, Daten die nicht im Cache liegen werden per Read-Telegram am Bus angefragt.
• Die sofortige Antwort (die ja noch keine Antwort auf die Read-Telegramme haben kann) wird per CV-Protokoll übertragen, mit einem "i" das dem aktuellen Stand der Daten im Cache entspricht (der jetzt immer noch keine Antwort auf die Read-Telegramme haben kann)
• Der Client im Browser kann die Antwort nun darstellen lassen und öffnet sofort wieder ein neues "r", diesmal ohne Timeout aber mit dem "i" das ihm gerade mitgeteilt wurde
• Der Server schaut nun nach, ob seit diesem "i" neue, relevante Werte in den Cache eingetragen wurden. Wenn ja: sofortige Antwort damit. Wenn nein: warten bis welche kommen (-> COMET-Pattern)

Was passiert nun mit Daten die initial nicht im Cache vorgelegen sind? Sobald diese über den Bus eintröpfeln kommen die, wie jedes andere normal gesendete Bus-Paket, in den Cache. Und der wird ja per "i" auf dem Client synchron gehalten.

Was passiert wenn Daten nicht lesbar sind (also es z.B. keinen Bus Teilnehmer gibt, der auf eine angefragte GA antwortet)? Nichts.
Diese Daten werden nie im Cache ankommen können und folglich auch nie an den Client weiter gereicht werden können.
Hier gibt es auch kein Timeout das irgend etwas für irgend eine Zeit blockieren wird.

[henfri]

Hallo,

Nochmal die Frage:
Wie sollen denn die Diagramme funktionieren, wenn man kein größeres Backend hat?

Gruß,
Hendrik

[Chris M.]

Gar nicht?

Das CometVisu-Protokoll kann keine Diagramme, dafür ist es nicht gedacht und es ist auch nicht notwendig (zumindest so lange Du kein Realtime Streaming da drüber machen möchtest).
Die Diagrammen sind "nur" in Plugin der CometVisu, d.h. die sind ein optionaler Bestandteil. Wenn der Server die nicht unterstützt ist das i.O. und weiterhin mit der Spek kompatibel.

Um Diagramme darstellen zu müssen, kann der Server nicht mehr zustandslos sein - der muss sich die Vergangenheit der Werte ja irgendwie merken können. Auf meiner FritzBox vor 10 Jahren konnte ich einen eibd laufen lassen, statische Web-Seiten konnte die und das bisschen eibread-cgi/eibwrite-cgi wäre auch noch irgendwie gegangen. Aber dort irgend etwas zu implementieren, dass nun noch persistent Daten speichert hätte dieses Kistchen (und mein Zeit-Budget) arg strapaziert.

Wenn man aber eine "dicke Kiste" hat - einen Raspberry Pi beispielsweise - dann ist das schon was anderes. Der kann locker Daten persistent speichern und per JSON verfügbar machen. Also genau das, was die Diagramme nutzen. (Auch hier ist es egal was da dahinter steht, es muss kein RRD sein. Diagramme aus MySQL-Daten sind durchaus denkbar)