Noch eine: knxd auf zweitem Server

[snowdd]

Nachdem sich meine erste Frage ja glücklicherweise durch eigenes Recherchieren lösen konnte (was ich nach 1 1/2 Tagen schon fast aufgegeben hatte), nun noch eine vielleicht etwas vertracktere:

Mein knxd läuft auf einem anderen Server. D.h. will ich etwas schalten, gebe ich den Server immer mit, z.B. bei knxtool groupswrite ip:192.168.178.212 1/3/5 1 - das geht auch problemlos. Nur wie teile ich dem cgi-Ding eibread-cgi mit, dass es sich nicht um "localhost" handel?

Danke und Gruß
Raoul

[snowdd]

Ich glaube die Antwort ist "nicht".
Ich habe nun eine zweiten knxd installiert und gestartet, der im Hintergrund mit dem produktiven verbunden ist (via multicast) und so den lokalen UNIX socket anbietet.

Das geht jetzt zwar, aber jetzt kommen die Probleme mit dem neuen knxd, die hier schon mehrfach beschrieben wurden, hoch - die Antworten passen nicht zur Read-Anfrage.

Ich überlege, ob es nicht besser wäre, ein Backend zu schreiben, dass einen Puch-Mechanismus anstelle der ständigen READs unterstützt und aktiv den Browser informiert, sobald sich etwas ändert.

Ich stell emir das so vor: Der Browser (cometvisu front end) schickt eine Anfrage an z.B. /watch?ga=(1/2/3,2/3/4) und bekommt nach und nach alle Änderungen gestreamed - siehe Beispiel hier: https://www.binarytides.com/ajax-bas...thout-polling/

Wäre das nicht etwas?

Gruß
Raoul

[peuter]

Zu dem ganzen KNXD/EIBD Thema kann ich nicht viel sagen, weil ich das nicht nutze. Aber die CometVisu unterstützt bereits Server-Sent-Events. Das openHAB-Backend für die CometVisu macht das nämlich genau so wie Du das beschrieben hast.

[snowdd]

Hallo Tobias,
das klingt interessant. Vielleicht kann ich in den nächsten Wochen mal versuchen ein Mini-Backend zu schreiben, dass die SSE-Schnittstelle verwenden kann, ohne gleich einen openhab auch noch auf den Server zu schmeißen. Mein Server ist nämlich auch nur ein Raspberry, und da gilt small is beautiful.

Ich habe schon in den sources der neuen Version (11) folgendes gefunden: /client/source/class/cv/io/transport/Sse.js - sieht so aus als ob Du daran (mit)geschrieben hättest. Ich versuche mal einen kleinen nodejs-Server so aufzusetzen, dass er möglichst viel davon erledigen kann. Gibt es eine Doku zu den SSE-Formaten/Protkoll? Ich habe im Wiki ( https://github.com/CometVisu/CometVisu/wiki/Protokoll ) nur die statuslose Kommunikation gefunden.
Danke
Raoul

[peuter]

Ich habe sowohl die Client- als auch die Server-Seite geschrieben: Die Kommunikation ist bei der SSE-Variante genauso statuslos. Der einzige Unterschied ist, dass der Read-Request permanent ist, daher ist der Index überflüssig, den kannst Du ignorieren. Die CometVisu schickt einen Read-Request mit allen GAs die sie interessieren (als Querystring). Der Server schickt als erste Antwort des Requests einmal alle Stati der angefragten Adressen zurück, danach dann nur noch Änderungen. Das wars schon. Und allgemein zu SSE wird es reichlich Doku im Netz geben.

[snowdd]

Das heißt, ich brauche nur eine Funktion zu implementieren, die /cgi-bin/r implementiert und die Antwort nicht abschließt? Wie kann ich der Cometvisu mitteilen, dass es nicht die „default“ Routinen verwenden soll, sondern die sse-Funktionen?

[peuter]

Das Backend kann der CometVisu die nötigen Informationen selbst mitteilen. Das passiert in zwei Schritten. Zunächst mal muss die CometVisu wissen unter welchem Pfad die Login-Seite (also das /cgi-bin/l) zu finden ist. Das passiert über einen zusätzlichen Header bei der Auslieferung der Config-Dateien, muss also im Webserver eingerichtet werden. Beim Apache geht das z.B. so:

<FilesMatch "visu_config.*xml$">
 Header set X-CometVisu-Backend-LoginUrl /pfad/zum/backend/login
</FilesMatch>

Der Rest wird dann in der Antwort auf die Login-Anfrage gesendet, das openHAB-Backend sendet hier z.B. folgende Antwort:

{
  "v":"0.0.1",
  "s":"0",
  "c": {
    "name":"openhab2",
    "transport":"sse",
    "baseURL":"/rest/cv/",
    "resources": {
      "read":"r",
      "rrd":"rrdfetch",
      "write":"w"
    }
  }
}

Das sagt der CometVisu, dass hier als Transport-Schicht SSE benutzt werden soll und die Endpunkte für die jeweiligen Anfragen setzen sich aus den Werten für baseURL + z.B. resources.read zusammen. Bei openHAB werden die Read-Requests also nach "/rest/cv/r" geschickt, Write-Requests nach "/rest/cv/w" usw.


Im dem Script, welches den Docker-Container der CometVisu einrichtet kann man das auch sehen: https://github.com/CometVisu/Docker/...isu-entrypoint

[snowdd]

Super, danke. Das nächste Wochenende kann kommen!

[snowdd]

Als erstes werde ich mal auf die 11dev wechseln - für die 10.2 erscheint mir das nicht mehr sinnvoll - es sei denn, die Server-Seite sähe genauso aus, das habe ich im git aber nicht gefunden.

[Chris M.]

Mein knxd läuft auf einem anderen Server. D.h. will ich etwas schalten, gebe ich den Server immer mit, z.B. bei knxtool groupswrite ip:192.168.178.212 1/3/5 1 - das geht auch problemlos. Nur wie teile ich dem cgi-Ding eibread-cgi mit, dass es sich nicht um "localhost" handel?

Richtig: gar nicht.
Der knxd ist so klein und harmlos (lief schon auf meiner Fritz!Box vor über 10 Jahren als die noch kein verkappter Server war), der läuft locker nebenbei.

Du könntest eher die "r" und "w" Anfragen (also das eibread-cgi und eibwrite-cgi) auf einen anderen Server umleiten - was der Browser aber schnell wegen Cross Origin Policy bemeckern wird. Also müsste das lokale System einen Proxy für das fremde System spielen.
Was war nochmal das Ziel? "small is beautiful" - äh, nö. Lass lieber den knxd lokal laufen
(Und wie im anderen Thread geschrieben: pass bei der knxd Version auf. Für erste Gehversuche nimm den 0.0.5.1, bei dem ist bekannt, dass sich der richtig verhält)

Aber wenn Du einen SSE-Client für den knxd schreiben willst, dann wäre ich natürlich auch nicht böse
Ziel sollte dann sein, dass der nicht bei jedem Request als neuer Prozess gestartet werden muss, also z.B. als FastCGI an den Web-Server angebunden wird.

[Chris M.]

Als erstes werde ich mal auf die 11dev wechseln - für die 10.2 erscheint mir das nicht mehr sinnvoll - es sei denn, die Server-Seite sähe genauso aus, das habe ich im git aber nicht gefunden.

Zwischen 0.10.2 (und älter) so wie der aktuellen Entwicklungsversion (0.11.0 und dann folgende) gab es in der Code Struktur einen deutlichen Umbruch.

Bei der 0.11 erwarte ich, dass wir bald in die Beta-Tests, Pre-Releases und dann das richtige Release gehen. Wenn es also Stand heute noch nicht produktiv gehen muss und Du mit Source Code umgehen kannst, dann nimm ruhig die 0.11 Entwicklungsversion.

[snowdd]

Bin am Werkeln...

Ein paar Fragen habe ich aber noch:
Bei den Filtern werden im Post JSON Objekte mit Address Arrays verwendet, so etwas wie

[LEFT][COLOR=#24292E][FONT=SFMono-Regular]POST /f?s=SESSION
{
  "a": [KNX:1/2/3,KNX2/3/4,...]
}[/FONT][/COLOR][/LEFT]
[LEFT][COLOR=#000000][FONT=Arial][SIZE=15px][/SIZE][/FONT][/COLOR][/LEFT]

(die Hash-Option habe ich mal weggelassen) - In dem Link von peuter ist leider nicht klar, ob da noch Anführungszeichen reingehören wie "KNX:1/2/3" oder gar KNX:"1/2/3". Als echte JSON-Objekte müssten die Elemente ja eigentlich Strings sein und entsprechend einzeln umschlossen werden, also ["KNX:1/2/3","KNX:2/3/4"], und "KNX" darf nicht als Key davorstehen, denn der wiederholt sich ja.

Werden Filter aus CometVisu wirklich verwendet? Ich habe in den Beispielen nur URLs für read, write, und rrd gefunden, aber nicht für filter

Das führt zur zweiten Frage, beim Lesen werden die Parameter per GET übertragen (warum?) und verwenden wohl auch "nicht-eindeutige" Schlüssel:

[LEFT][COLOR=#24292E][FONT=SFMono-Regular]GET /r?s=SESSION&f=FILTER1&f=...&a=ADDRESS1&a=...&h=ADDRESSHASH1&h=...&t=TIMEOUT&i=INDEX[/FONT][/COLOR][/LEFT]
[LEFT][COLOR=#000000][FONT=Arial][SIZE=15px][/SIZE][/FONT][/COLOR][/LEFT]

Ich stelle mir das dann so vor:

GET /r?s=abcd1234&a=KNX:1/2/3&a=KNX:2/3/4&t=0&i=0

Richtig? Oder sind da noch Anführungszeichen drum? Oder können die Adressen als Liste zusammengefasst werden?

Danke!

[snowdd]

...einen hab' ich noch, eine 'hab ich noch... (Sorry, bin aus dem letzten Jahrtausend, also Otto Waalkes noch durchs Fernsehen lief)

Die Antwort auf ein READ ist mit SSE

 [LEFT][COLOR=#24292E][FONT=SFMono-Regular]{
  "d": {
       "KNX:1/2/3": "01",
       "KNX:2/3/4": "caffe0"
       }
}[/FONT][/COLOR][/LEFT]

und immer weitere Blöcke, sobald Daten eintreffen, richtig?

[peuter]

Filter werden bisher von keinem Backend implementiert. Die kannst Du also erstmal getrost ignorieren. Das selbe gilt meines Wissens auch für die Hash-Werte.

Die vielen "a" Query-Parameter im GET Request dienen dazu ein Array mit diversen Werten zu übermitteln. Normalerweise wird sowas vom Server der Wahl (bzw. einen Query-String-Parser) automatisch in ein Array umgewandelt, d.h. aus /r?a=ADDRESS1&a=ADDRESS2 wird a=["ADDRESS1", "ADDRESS2"]. Und die hängen am Query-String, weil das nun mal der einzige Weg ist Daten mit einem GET-Request zu übermitteln. Und es ist ein GET-Request, weil das zumindest bei SSE so sein muss.

Anführungszeichen brauchst Du im Query-String nicht und bei den Addressen kann das KNX: Präfix weg. Ich mag mich irren, weil ich nur openHAB als Backend nutze und hier sowieso anderen Adressen genutzt werden aber, so sollte es korrekt sein:

 
 GET /r?s=abcd1234&a=1/2/3&a=2/3/4&t=0&i=0

[peuter]

.
Die Antwort auf ein READ ist mit SSE

 [LEFT][COLOR=#24292E][FONT=SFMono-Regular]{
"d": {
"KNX:1/2/3": "01",
"KNX:2/3/4": "caffe0"
}
}[/FONT][/COLOR][/LEFT]

und immer weitere Blöcke, sobald Daten eintreffen, richtig?

Korrekt.