Alternatives Protokoll zum Übermitteln und Darstellen von Daten in der CV

[netsrac]

Moin Jungs,

Ich würde gerne mal etwas Brainstorming betreiben: Im Moment sendet mein Rechner Werte auf den KNX Bus, die nur von der CV gelesen werden (beides auf dem selben Rechner). Ich "verschmutze" mir also meinen Bus unnötig (ja, ich habe PowerNet). Nicht, dass es im Moment Probleme bereitet, aber mit zunehmender Datenflut will ich gerne etwas vorbeugen :-)

Es geht mir dabei um Daten wie aktueller Stromverbrauch, Zählerstände, Verbrauch im aktuellen Monat, Verbrauch im Vormonat, angelaufene Kosten. Ja, selbst Temperaturen messe ich mit einem CUNO, schreibe sie in ein RRD und für die CV auf den Bus. Alles das ist ja unnötig, weil niemand außer der CV die Daten braucht.

Wenn man nun Alternativen zu den Adressen erlauben würde, dann müsste doch eigentlich nur das CGI entsprechend wissen, das es die Daten nicht vom Bus, sondern aus anderer Quelle lesen muss, oder?!

Bei einem anderen Projekt nutze ich zur Zeit memcached und bin von der Funktion ganz angetan. Prinzipiell ist das ein daemon, der im Hintergrund läuft und Daten zusammen mit einem "Key" über eine vorgegebene Zeit speichert.

Das coole daran ist, dass es eigentlich für jede Sprache (Perl, PHP, C) entsprechende Implementierungen gibt und der Zugriff applikationsübergreifend funktioniert. Ich kann also von Perl aus einen Wert ablegen und ihn mit dem CGI wieder lesen.

Würde man jetzt in der CV eine zusätzlich Adressangabe erlauben wie "mc:keyword", dann könnte man hier ein zusätzliches Protokoll erlauben. Der Zugriff auf memcached via CGI sollte einfach zu implementieren sein.

Klar könnte man die Daten auch in einer eventuell laufenden Datenbank ablegen, aber ich finde die Idee mit dem memcached irgendwie "charming", da es auch einfacher ist, als irgendwelche SELECTs zu bauen.

Was denkt Ihr?! Alternative Ideen?!

Fände es schön, wenn man sich auf eine Idee einigen könnte, die dann auch offiziell zur CV gehört....

Grüße aus dem verschneiten Berlin....

Netsrac

[Chris M.]

Diese Überlegungen sind grundsätzlich richtig (und daher auch nicht komplett neu... ).

Die CometVisu selbst (also nach CometVisu/Overview - Open Automation das Protokoll, der Client und die Anwendung / Visualisierung) haben bewusst keine Ahnung vom KNX. Die wollen nur unter einer Adresse (ein relativ beliebiger String) Werte bekommen bzw. senden, die dann noch einer übertragenen Form in eine dargestellte umgewandelt werden (das mach bei KNX die DPT-Angabe, ist aber bewusst für neue Anwendungen offen gestaltet). Dank Namespace werden auch mehrere Datenquellen gleichzeitig unterstützt.

Dass die Daten z.Zt. über den KNX gespiegelt werden müssen, hängt nur mit dem aktuell verwendeten Backend ab. Ein anderes könnte das prinzipiell anders lösen. Wie z.B. GrAF, was ja eine ganze Logik-Engine werden soll und quasi nebenbei auch noch die Werte am Bus auf die CV bringt.

Bei OpenHAB gibt's ja inzwischen auch schon ein Backend für die CV. Was das alles kann, ist mir aktuell unklar.

So gibt's nun ein paar Möglichkeiten:

• Du könntest ein Backend schreiben, dass auch noch memchached o.ä. parallel unterstützt
• Du könntest bei GrAF mitmachen
• <... ganz viele verschiedene weitere Möglichkeiten ...>

[netsrac]

Bei OpenHAB gibt's ja inzwischen auch schon ein Backend für die CV. Was das alles kann, ist mir aktuell unklar.

So gibt's nun ein paar Möglichkeiten:

• Du könntest ein Backend schreiben, dass auch noch memchached o.ä. parallel unterstützt

Okay...das ist ja schonmal gut! Wie sieht das denn aus, kann die CV denn mit mehreren Backends parallel arbeiten, oder ist es immer das Eine, was die ganzen Protokolle kennen muss.

Muss mal nach dem OpenHAB backend schauen...habe da bis jetzt immer einen Bogen drum gemacht, da ich JAVA kategorisch verweigere :-)

[netsrac]

Muss mal nach dem OpenHAB backend schauen...

Nutzt das Backend hier jemand?! Wenn ja, wo finde ich es?! Die Suche hate leider nix ergeben...

[JuMi2006]

Ich möchte hier nur ein +1 hinzufügen.
Die Geschichte hat die smarthome.py mit dessen Visu einfach der CV voraus ... mithelfen kann ich da aber sicherlich nur sehr begrenzt.

Grüße

[netsrac]

Du kannst ja schon alleine dadurch mithelfen, dass Du mal erzählst, die das smarthome.py gelöst hat :-)

[netsrac]

kann die CV denn mit mehreren Backends parallel arbeiten, oder ist es immer das Eine, was die ganzen Protokolle kennen muss.

Mal etwas quergelesen. Wenn ich es so richtig sehe, dann wird ja nur ein Backend unterstützt. Da ich denke, das eine Architektur eines Backends mit Plugins viel zu kompliziert ist und dann auch wieder verlangt, dass man die Anpassung in dieser einen Programmiersprache vornimmt, müsste man eigentlich dazu kommen, dass man unterschiedliche Backends unterstützt.

Mit einem zusätzlichen Parameter kann man dann angeben, welches Backend genutzt werden soll. So gesehen kann das backend in einer beliebigen Programmiersprache erstellt werden.

Macht das Sinn?!

[Chris M.]

Nutzt das Backend hier jemand?! Wenn ja, wo finde ich es?! Die Suche hate leider nix ergeben...

Wie hast'n gesucht? Wenn Du dieses Forum nach OpenHAB suchst kommt:
https://knx-user-forum.de/cometvisu/...s-openhab.html

Muss mal nach dem OpenHAB backend schauen...habe da bis jetzt immer einen Bogen drum gemacht, da ich JAVA kategorisch verweigere :-)

Dacher bin ich ja auch an GrAF dran. Das ist perfekt schnelles C++
Wenn das nächste CV Release draußen ist, geht's bei GrAF weiter

Ich möchte hier nur ein +1 hinzufügen.
Die Geschichte hat die smarthome.py mit dessen Visu einfach der CV voraus ...

Der CV: Nein. Die ist von Anfang an darauf ausgelegt, das zu können.
Dem aktuellen Backend: Ja.

Aber das aktuelle Backend ist trivialer C-Code. Das lässt sich leicht ändern, erweitern, etc. pp.

[JuMi2006]

So wie ich es verstanden habe:

Jeder darstellbare Wert ist erstmal ein "item". Dieses erhält seinen string, bool, float whatever von smarthome.py. Über die dortigen Plugins kommt dann z.B. die Temperatur direkt aus dem owfs, ein String aus deiner geparsten Website, ein Status vom KNX und ein Termin aus dem google-Kalender.

Die items werden dann in der Visu dargestellt.

Eigentlich ganz schlau ... andererseits ist dort das Backend smarthome.py und natürlich etwas umfassender als lediglich ein eibd. Im Backend gibt es dann eben Plugins.

[Chris M.]

Mal etwas quergelesen. Wenn ich es so richtig sehe, dann wird ja nur ein Backend unterstützt.

Aktuell: ja.
Könnte man ändern, war aber bisher nicht notwendig.

Das ist eine Design-Frage, ob man nur eine Verbindung offen halten will (und dafür im Backend bündelt), oder spezialisierte Backends haben möchte und dafür mehrere Verbindungen offen hält.

Ohne tiefe Analyse und aus dem Bauch heraus, finde ich es besser, wenn das Backend bündelt.

Da ich denke, das eine Architektur eines Backends mit Plugins viel zu kompliziert ist und dann auch wieder verlangt, dass man die Anpassung in dieser einen Programmiersprache vornimmt, müsste man eigentlich dazu kommen, dass man unterschiedliche Backends unterstützt.

Naja, GrAF macht genau das. Das geht auch jetzt schon. Wenn Du da neben dem KNX z.B. noch einen memchached Zugriff haben möchstest, dann schreibst Du dafür einen kleinen Deamon, das CV-Backend von GrAF würde den dann ohne jegliche Änderung bereit stellen.

Mit einem zusätzlichen Parameter kann man dann angeben, welches Backend genutzt werden soll. So gesehen kann das backend in einer beliebigen Programmiersprache erstellt werden.

Macht das Sinn?!

Nein - zumindest nicht so, wie ich das verstehe (wobei es auch daran liegen kann...)
Der CV kannst Du jetzt schon per Parameter sagen, unter welcher Adresse das Backend auf dem Server zu finden ist. (Das kam mit der OpenHAB-Unterstützung rein, das GrAF Backend nutzt das aber auch)
Die Sprache des Backend ist dabei völlig egal.
(CV-Backends sind inzwischen schon in PHP, Python, C und C++ implementiert worden. Also die, die ich persönlich kenne. OpenHAB wird's auch noch in Java implementiert haben...)

[NetFritz]

Hallo

Ich sehe ein Problem darin das man ja nicht nur einen backend haben will wo man drauf zugreift, sondern mehre.

Die CV holt sich mit "http://wiregatexxx/cgi-bin/r?s=SESSION&a=5/0/0&a=15/0/7&a=15/0/8" die Daten von KNX.
Sollen die Daten aber von einer DB kommen , könnte man z.B. Gruppenadressen einsetzen die mit 100 anfangen.
Schaltet man hinter "http://wiregatexxx/cgi-bin/" ein Auswahlscript das diesen höheren Adressbereich kennt, kann es eine Auswahl treffen ob die Daten von KNX oder DB kommen.

Mit rrdfetch habe ich so was schon durchgeführt.

Gruß NetFritz

[Chris M.]

Die CV holt sich mit "http://wiregatexxx/cgi-bin/r?s=SESSION&a=5/0/0&a=15/0/7&a=15/0/8" die Daten von KNX.
Sollen die Daten aber von einer DB kommen , könnte man z.B. Gruppenadressen einsetzen die mit 100 anfangen.

So einen Missbrauch der Adressen (wie der HS) hat die CV doch gar nicht nötig!

Wie im Protokoll seit Anbeginn dargestellt (CometVisu/Protocol - Open Automation) haben die Adressen eigentlich ein Namespace, d.h. einen String der per Doppelpunkt von der eigentlichen Adresse getrennt ist.

=> Das Backend muss nur alle Anfragen nach "KNX:a/b/c" auf die GA a/b/c mappen und "foo:bar" auf die Quelle foo mit der Adresse bar.

[peuter]

Nutzt das Backend hier jemand?! Wenn ja, wo finde ich es?! Die Suche hate leider nix ergeben...

Aktuell bin ich wohl der einzige der die Verbindung openHAB<->CometVisu nutzt.
Eine Übersicht mit welchen Systemen openhab kommunizieren kann (das geht dort über eine Art Plugin, die werden Binding genannt) findest Du hier:
Features - openhab - Feature Overview - empowering the smart home - Google Project Hosting

Wenn Du interesse hast das mal zu probieren kann ich gerne helfen und auch meine aktuelle Version des CV-Backends zur Verfügung stellen. Das funktioniert an sich ganz gut bis auf ein Problem das immer Auftritt, wenn sich mehrere Werte gleichzeitig ändern. Das hab ich bisher noch nicht lösen können. Liegt an meinem persönlichen Unvermögen ein gescheites Backend Java/Atmosphere umsetzen zu können.

[netsrac]

Sind das eigentlich immer noch die aktuellen backend clients?!

openautomation/tools/bcusdk/eibd/examples/eibread-cgi.c
openautomation/tools/bcusdk/eibd/examples/eibwrite-cgi.c

[Chris M.]

Gut möglich, an denen hat sich seit Ewigkeiten nichts getan.