- √ - Backend -- Wie arbeitet die CometVisu mit wiregate, mh & Co zusammen????

[aggie89go]

Ich nutze mh, und mir ist leider nicht klar wie ich die CometVisu nutzen kann.

Ich hatte die Frage ja bereits im Visubeispiele-Beitrag angefragt, aber hier noch mal separat:

Muß es nicht noch irgendeinen Prozeß geben, der sich den Zustand der einzelnen Gruppenadressen merkt und mit den Clients kommuniziert also zwischen eibd und Client sitzt?

Welches ist denn der Prozess der Serverseitig läuft -- doch nicht nur eibd und das erwähnte read & write Script, oder?

Bodo würde ich jetzt so verstehen, dass die CometVisu beim Start (sowie danach) "read" Kommandos für alle verwendeten Gruppenadressen zum eibd schickt (mit Hilfe der read/write Skripts), und eibd antwortet wenn sich der Status geändert hat (und erst dann) --- wenn ich den Unterschied zum polling richtig verstanden habe.

Es können dann also nur der Zustand der Gruppenadressen zwischen eibd und dem Client ausgetauscht werden?
Selbst definierte Variablen aus mh (oder dem wiregate) stehen in der Visu nicht zur Verfügung?
Wo werden dann z.B. Messgrößen gespeichert, um einen Plot zu erzeugen?

Ich hab's irgendwie nicht verstanden...

[Bodo]

Hoi

Der Eventgetriebene KNX Bus wird über die CV live abgebildet.
Wie das beim Start läuft kann ich Dir nicht genau sagen.
Kann sein, dass der eibd dann den Bus abfragt?
Die rrd's zum aufzeichnen der 1-Wie Temperaturen und deren Graphen sind unabhängig von der Visu. (round-robin-database)

[greentux]

Je nach Developer Knowhow steht hier
SourceForge.net: CometVisu/Protocol - Open Automation
ne ganze Menge drin...

[aggie89go]

Ich weiß leider nicht wo ich anfangen muss.
Ein flowchart mit dem Zusammenspiel der Programme auf dem wiregate würde mir wahrscheinlich schon helfen.

Ich lese von eibd (ggf. modifiziert), einem read u. write program, einem backend "that runs typically on a web server system" und einem Client.

Weiter steht auf der Protokoll Doku Seite, dass das backend typischer Weise in PHP oder Perl geschrieben ist. Welches php oder Perl Script ist dies im Falle des wiregates?

[swiss]

Also auf dem WG läuft die Cometvisu AFAIK folgendermassen:

Frontend: JQuerry bzw. JSON auf einer HTML-Seite.
Backend: Webserver mit read/write Script und eibd.

Etwas wie eine Serverapplikation gibt es AFAIK nicht. Das läuft alles über den Webserver des WG.

[Chris M.]

Man muss hier trennen zwischen was alles möglich ist und wie es aktuell konkret am Wiregate läuft.

Da ich vermute, dass Dich letzteres interessiert, die Zusammenfassung:
Der eibd (ein normaler, unveränderter; darf aber nicht zu alt sein) hat zum einen einen Cache der letzten Pakete / Zustände auf dem Bus, als auch einen Ringpuffer der letzten Pakete. Der muss laufen.

Dann gibt es nur noch das read und write (+ ein lächerlich simples login). Die reden mit dem eibd. Der write schickt einfach ein KNX Paket los, sobald er aufgerufen wurde.
Der read kann entweder alle Stati aus dem Cache holen (wird beim ersten Aufruf verwendet) oder auf ein neues KNX Paket warten. Dazu wird der aktuelle Index des Ring-Puffers mitgegeben, um sicher zu stellen, dass nicht in der Zwischenzeit schon ein neues Paket eingetroffen ist.

Der ganze Rest ist dann im Browser. Da gibt es auch den "CometVisu Client", was eine JavaScript-Bibliothek ist, die sich (nur) um die Verbindung kümmert. Die ganze darstellung machen andere JavaScript Programme.

=> Wenn auf einer Kiste die CometVisu bereit gestellt werden soll, braucht's nur den eibd, read, write und login neben einem Webserver.

[tht]

Da die Frage schon mitkam:
Auf dem WG werden die Messwerte der Sensoren in RRDs gespeichert, auf die das entsprechende Widget der CV zugreift.

Zur Darstellung der Diagramme brauchst du also noch die Messwerte in RRDs gespeichert. Hier greifen die beiden Systeme hält schön Hand in Hand...

[makki]

Korrekt, es ist alles notwendige im eibd (normalem 0.0.5 release), die Clients allerdings nicht, weil sie gewissen Qualitätsanforderungen wohl nicht genügen, liegen aber trotzdem in einschlägigem Repository.
Vom Rest ist dazu nichts notwendig..

Beim RRDtool ists anders, das wäre mittlerweile (so ähnlich) upstream, das genügt allerdings meinen Qualitätsanforderungen nicht, weil es zwischen 1.3 und 1.4 leider Faktor 10 langsamer geworden ist und ich mir deswegen keine 750 neue CPUs kaufen mag und daher unseren ursprünglichen Weg bevorzuge

Makki

[greentux]

Sollten die Patches nicht trotzdem ins rrd upstream?
Vl. wirds ja mit 1.5 wieder schneller...

[makki]

rrdtool / rrdfetch

Schreib ich so undeutlich ? Es ist (so ähnlich) upstream, bringt bloss nix..

Makki

[greentux]

Sorry. Ich hatte "das wäre" als Konjunktiv interpretiert. Mundartlich wird das "schon lange erledigt" heissen