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

[greentux]

Wenns mal in nem Repo wäre. Ein Link wäre ein Anfang.
Youtube Videos sind jetzt nich so mein Ding...

[ctr]

Unklar ist mir, warum jemand an der CometVisu herumbastelt und irgendwelche Erweiterungen macht, die er dann in einem eigenen Repository bereitstellt und um OpenSource-Beteiligung durch andere Entwickler bittet.

Es wäre sicherlich allen Beteiligten geholfen, wenn man, anstatt unnötigerweise ein Projekt zu forken, erstmal versucht, die Anpassungen ins Original einfließen zu lassen. Wenn man damit scheitert, kann man es immer noch auf eigene Faust versuchen.

Full-Ack, finde das sowohl für den "xeib" als auch das CV Derivat sehr unglücklich...

[prz]

Danke fuer Eure Meinung, Antwort etwas verspaetet da mich dieses Forum gestern Nacht irgendwie rausgeworfen hat.


Der Titel dieses von jemand anderen gestarteten threads ist 'Alternatives Protokoll zum Übermitteln und Darstellen von Daten in der CV' und dies ist das Thema unserer Beitraege hier. Wir haben uns diese Arbeit gemacht, weil wir denken, dass die Verfuegbarkeit einer stabilen, einfach zu installierenden Platform sowohl fuer Verbreitung von CV wie auch Popularitaet von xml2eib gut ist.


Comet Visu mit xml2eib & xhttp2eib client code kann gerne aus unserem Depot read-only ausgelesen werden ueber:


svn co http://www.zeta2.ch/svn/depot/misc/comet-visu-xml2eib

Zugriff ueber User/PW anon/anon



Natuerlich alles completely in public domain.


Die mods wurden nicht ins 'hauptdepot' von comet-visu vorgeschlagen, da xml2eib momentan nur auf xEIB unterstuetzt wird und somit vermutlich nicht von unmittelbaren Interesse fuer die 'trunk' Version ist. Der diff ist trivial, alles in eigenen files, wenn es fuer jemand Sinn macht es ins Hauptdepot zu uebertragen. CV wurde von uns gepickt da wir speziell aufgrund dieses Threads interessierten Leuten eine stabile, feature-rich Alternative zu dem 'floating eibd patch' bieten wollten.


Spezifikation von xml2eib etc. fuer Leute, die die Implementation gerne verstehen wollen und daran was machen wollen oder nicht an von uns implementierten 'one-button' installation interessiert sind:


TXT2EIB Specification
XML2EIB Specification
XHHTP2EIB Specification


XML schema unter


http://www.zeta2.ch/xml.specificatio...l2eib.1.00.xsd


Die specs sind open und in GNU Lesser License, es koennte sich also jeder seinen eigenen Server implementieren.


xEIB VMWare Version mit xml2eib fuer kleinere Installationen ist kostenlos (lizenzfrei).


Fuer weitere technische Fragen stehen wir gerne zur Verfuegung.


Viel Spass bei Einsatz und Analyse.

[MicHau]

Nun ist es schon mal verständlicher. Vielen Dank. Leider habe ich nur kurz die verlinkten Dokumente überfliegen können, aber dabei weiß ich nun schon mehr als bisher zu diesem Thema.

Nichtsdestotrotz würde ich empfehlen, die Modifikationen in den Trunk der CometVisu einfließen zu lassen. Erstens ist es dann immer auf dem richtigen Entwicklungs-Stand und zweitens könnte dadurch das Interesse anderer Personen steigen, auf x2EIB aufzubauen.

[prz]

Nun ist es schon mal verständlicher. Vielen Dank. Leider habe ich nur kurz die verlinkten Dokumente überfliegen können, aber dabei weiß ich nun schon mehr als bisher zu diesem Thema.

Nichtsdestotrotz würde ich empfehlen, die Modifikationen in den Trunk der CometVisu einfließen zu lassen. Erstens ist es dann immer auf dem richtigen Entwicklungs-Stand und zweitens könnte dadurch das Interesse anderer Personen steigen, auf x2EIB aufzubauen.

Michael, very well & danke fuer Dein Interesse.

Wie Du gesehen hast ist eine integration aeusserst einfach & wir koennen diese gerne machen wenn Du es fuer richtig haltest und wir etwas Zeit finden. Gib uns kurz einfach die rights fuer trunk vom depot & wir integrieren das bei Gelegenheit. Naechste Sache waeren natuerlich

* optionel BUS request Generierung anfragen bei 'register'. Ist nur ein parameter (B) auf GARs aber es ist viel weniger skalierbar. xEIB generiert die requests nur bei Bedarf natuerlich aber bei neustarts ist sowas nicht sehr foerderlich. CV koennte meiner Meinung drueber nachdenken, ob ein Schalter nicht grundsaetzlich funktionieren sollte BEVOR es ueberhaupt ein Status dafuer gibt wie halt bei KNX auch. Ist eine Philosophiefrage.
* eine 'login-box' fuer CV. Heute, wenn es von x2eib ein 'challenge' sieht, versucht's einfach ueber demo/demo einzugehen, das auf jeder nichtlizenzierter xEIB automatisch verfuegbar ist.
* auslesen aus xml2eib der ganzen Addresskonfiguration (wie aus der g.. Datei auf WireGate). Ein stub ist schon drin, da war aber die Architektur von CV etwas wenig flexibel verglichen mit z.B. register/read, in die aeusserst einfach 'einzuclicken' war.
* Graphen entweder als GIFs direkt von gateway oder aus den XML graphdaten ins Flex, das Ihr habt. Die Architektur von CV scheint aber sehr RR lastig zu sein was fuer vieles genuegt aber auch vieles was ueber x2EIB moeglich ist, ausschliesst.

Alles recht einfach ueber x2EIB zu machen aber wir haben momentan einfach keine Kapazitaet fuer solche Sachen, speziell da CometVisu support bei commercial client auf kein Interesse gestossen hat bei uns, zu Unrecht wie ich denke uebrigens.

Auf xEIB image shippt heute einfach ein tar & der one button install tut in phpcontent (user content account) einfach decompressen. Braucht kein Internet & das ist eine stabile April Version, damit Leute nicht ueber 'newest, hottest but buggy' version stolpern und einen schlechten ersten Eindruck von CV kriegen. Es ist halt fuer die meisten Leute (aus unserer Erfahrung) super, wenn die in 10 Minuten gratis aeusserst einfach erste 'coole' Seite von der Visu sehen und nicht durch zahllose Foren sich durchkaempfen muessen. Wenn man drin ist und sich versteigert, dann pullt man sich dann einfach vom trunk auf phpcontent einen client & arbeitet daran (fuer technische versierte User). Wir haben hier auch strikte automated-test release criteria & stabilisieren so um 500 open-source & eigene packages, damit ein xEIB image in hoher Qualitaet rauskommt. CV hat nichts dergleichen wie ich es gesehen habe (wie ueblich wie meistes open source sind die users die tests machen) & dementsprechend ist jede trunk version auch so bisschen gluecksache. Darum wollen wir auch nicht gerne immer den 'trunk' mit xEIB image updates shippen. Hoffe das ist verstaendlich. Kommerziel ist halt eben nicht so schnell wie open-source dafuer sollte es eben etwas mehr prediktabel fuer Kunden sein.

[netsrac]

Irgendwie muss ich diesen alten Thread mal wieder vorkramen.

Nach einiger Abstinenz vom Forum wegen unserer Babypause habe ich ein wenig den Anschluß verloren :-)

Hat sich hier eigentlich was getan? Kann die CV in der Zwischenzeit auch auf andere Datenquellen zugreifen?

Mir geht es immer noch darum, dass ich Dinge die Zählerstände, aktuelle Kosten und sowas anzeigen will, es aber eigentlich keine Notwendigkeit gibt, diese auf den Bus zu schicken.

Es wäre schön, wenn man in der CV eine alternative Datenquelle angeben könnte, die dann ein anderes CGI aufruft. Damit könnte man dann z.B. das direkte lesen aus eine MySQL Datenbank einbinden. Eventuell sollte man auch das Update Interval eingeben können....

Gruß, Netsrac

[Chris M.]

Der CometVisu Client (das ist die Kommonikations-Lib die die Visu selbst benutzt) kann inzwischen auch auf OpenHAB zugreifen.

Aber die richtige Lösung ist es ein alternatives CometVisu Backend zu haben, auf das der Rest zugreift.

Hier ist aktuell nichts in der Breite verfügbar. Das Projekt GrAF würde das aber durchaus können (es ist aktuell noch nicht in der veröffentlichten Phase; Entwickler sind herzlich eingeladen)

[peuter]

Aber die richtige Lösung ist es ein alternatives CometVisu Backend zu haben, auf das der Rest zugreift.

Dann ist OpenHAB ja die richtige Lösung, den genau sowas bekommt man damit hin