CV + OpenHAB: Live-Updates?

[tuxedo]

Kennt sich jemand mit dem OpenHAB Backend aus?

Bin gerade am testen wie sich CV an OpenHAB verhält.

Im ersten kleinen Beispiel kann ich auf die Wetterdaten aus den OpenHAB Items zugreifen/diese anzeigen.

Während aber in der ClassicUI von OpenHAB z.B. die Anzeige der aktuellen Windgeschwindigkeit sich immer mal wieder ändert, bleitb die Anzeige in der CV konstant bei dem Wert den es beim Aufruf der Seite gegeben hat stehen.

Hab mal nach "backend" im Source von CV ge-grep-t und bin auf folgendes gestoßen:

 if (thisTemplateEngine.backend=="oh") {
      // the path to the openHAB cometvisu backend is cv
      thisTemplateEngine.backend = '/services/cv/';
      thisTemplateEngine.visu = new CometVisu(thisTemplateEngine.backend);
      thisTemplateEngine.visu.resendHeaders = {'X-Atmosphere-tracking-id':null};
      thisTemplateEngine.visu.headers= {'X-Atmosphere-Transport':'long-polling'};
    }

long-polling... Im Zeitalter von Websockets etc. ist das ja eher suboptimal.

Meine Fragen:

1) Müsste nicht auch mit Long-Polling der Wert nach Zeit-X sich mal auf den aktuellen Stand der Dinge anpassen?
2) Kann man hier irgendwie auf Websocket umstellen? Oder ist das gar nicht erst implementiert?
3) Ist die OpenHAB Backendanbindung in CV "hart codiert", oder ist da eine Art Plugin-Komzept dahinter um ein externes Backend wie OH anzubinden? Aktuell sieht's eher nach "hart codiert" aus...

- Alex

[peuter]

1) Müsste nicht auch mit Long-Polling der Wert nach Zeit-X sich mal auf den aktuellen Stand der Dinge anpassen?

Ja auch mit Long-Polling muss das gehen, manchmal hilft ein openhab neustart, vor allem, wenn an den items was geändert wurde scheint der Update-Mechanismus irgendwie nicht mehr zu funktionieren und ein openhab Neustart ist nötig. Normalerweise wird jede Statusänderung in Echtzeit an die CV übertragen. Zur Fehlersuche kannst Du Dir die Requests der CV z.B. in Firebug ansehen.

2) Kann man hier irgendwie auf Websocket umstellen? Oder ist das gar nicht erst implementiert?

Ist nicht implementiert.

3) Ist die OpenHAB Backendanbindung in CV "hart codiert", oder ist da eine Art Plugin-Komzept dahinter um ein externes Backend wie OH anzubinden? Aktuell sieht's eher nach "hart codiert" aus...

Nicht die CV ist an openhab angepasst sondern umgekehrt. Die einzige Anpassung auf CV-Seite ist eine geänderte URL für die Kommunikation, ansonsten spricht das CV backend das CV-Protokoll.

[tuxedo]

Ja auch mit Long-Polling muss das gehen, manchmal hilft ein openhab neustart, vor allem, wenn an den items was geändert wurde scheint der Update-Mechanismus irgendwie nicht mehr zu funktionieren und ein openhab Neustart ist nötig. Normalerweise wird jede Statusänderung in Echtzeit an die CV übertragen. Zur Fehlersuche kannst Du Dir die Requests der CV z.B. in Firebug ansehen.

Hmm, das "scheint der Update-Mechanismus irgendwie nicht mehr zu funktionieren" hat irgendwie einen fahlen Beigeschmack. Macht die Verwendung nicht gerade attraktiv :-(
Items hab ich keine geändert. Nur die CV Config XML.
Werde dann mal den Debugger auspacken...

Ist nicht implementiert.

Schade.

Nicht die CV ist an openhab angepasst sondern umgekehrt. Die einzige Anpassung auf CV-Seite ist eine geänderte URL für die Kommunikation, ansonsten spricht das CV backend das CV-Protokoll.

Ah, jetzt geht mir ein Licht auf. Deshalb das IO-Addons für OH ... Danke für die Erleuchtung.

Gruß
Alex

[Chris M.]

long-polling... Im Zeitalter von Websockets etc. ist das ja eher suboptimal.

Wo ist hier das Problem? Fehlendes Kreuzchen im Buzzword-Bingo?

Die CometVisu verwendet - wie könnte es anders sein - das COMET Pattern. Also Long-Polling.
Das hat mit normalen Polling nichts zu tun. Im Gegensatz dazu ist es sehr performant und trotzdem Ressourcen schonend. Ohne jeglichen Ärger mit Proxies.

1) Müsste nicht auch mit Long-Polling der Wert nach Zeit-X sich mal auf den aktuellen Stand der Dinge anpassen?

Ja, und zwar so schnell, dass Du es nicht mal merkst. Daher gibt's auch das Label: Echtzeit.

2) Kann man hier irgendwie auf Websocket umstellen? Oder ist das gar nicht erst implementiert?

S.o. - wieso?
Implementiert ist das seit fünf Jahren stabile CometVisu-Protokoll: CometVisu/Protokoll (Deutsch) - Open Automation

3) Ist die OpenHAB Backendanbindung in CV "hart codiert", oder ist da eine Art Plugin-Komzept dahinter um ein externes Backend wie OH anzubinden? Aktuell sieht's eher nach "hart codiert" aus...

Hier müssen andere helfen, die sich mit OpenHAB auskennen.

[tuxedo]

Wo ist hier das Problem? Fehlendes Kreuzchen im Buzzword-Bingo?

Hey, nur kein Stress. Musst dich nicht gleich auf den Schlips getreten fühlen. Websockets haben ihre Vorteile gegenüber long-polling. Das ist so, und das kann man nicht wegdiskutieren.

Die CometVisu verwendet - wie könnte es anders sein - das COMET Pattern. Also Long-Polling.
Das hat mit normalen Polling nichts zu tun. Im Gegensatz dazu ist es sehr performant und trotzdem Ressourcen schonend. Ohne jeglichen Ärger mit Proxies.

Ich weiß was long-polling ist. Danke.

Ja, und zwar so schnell, dass Du es nicht mal merkst. Daher gibt's auch das Label: Echtzeit.

Meine "blöde Frage" rührt von dem Umstand her, dass sich hier nix tut und mir das eben seltsam vor kam...

S.o. - wieso?
Implementiert ist das seit fünf Jahren stabile CometVisu-Protokoll: CometVisu/Protokoll (Deutsch) - Open Automation

Gegenfrage: Wieso sollte man mit einem Elektroauto fahren wollen? Ein Auto mit Verbrennungsmotor tut's doch auch? Und das seit mehr als 100 Jahren.

Ein einfaches: "Nein, ist noch nicht implementiert." hätte mir gereicht. Diese "Abwehrhaltung" versteh ich jedoch nicht so ganz.

Hier müssen andere helfen, die sich mit OpenHAB auskennen.

Ist denn der Maintainer für das Openhab->CV Addon bekannt? im OpenHAB WIKI hab ich nix gefunden, im CV Wiki steht ebenso nichts dazu. Und Commiter für das AddOn gibt's offenbar einige.

[peuter]

Ist denn der Maintainer für das Openhab->CV Addon bekannt? im OpenHAB WIKI hab ich nix gefunden, im CV Wiki steht ebenso nichts dazu. Und Commiter für das AddOn gibt's offenbar einige.

Der bin ich. Wenn Du weitere Fragen hast, helfe ich gerne weiter.

[Chris M.]

Websockets haben ihre Vorteile gegenüber long-polling. Das ist so, und das kann man nicht wegdiskutieren.
[...]
Ein einfaches: "Nein, ist noch nicht implementiert." hätte mir gereicht. Diese "Abwehrhaltung" versteh ich jedoch nicht so ganz.

Nun, Du weckst hier eine Erwartungshaltung die IMO nicht gerechtfertigt ist.
Dem theoretischen Vorteil eines WebSockets (bisschen Weniger Daten übertragen) steht ein ganz wichtiger Grund entgegen - die aktuelle Implementierung läuft. Sehr stabil. Seit Jahren. Auf vielen verschiedenen Systemen erprobt. Stationär und mobil. Intranet, VPN, Reverese-Proxy und Internet. Das alles mit mehr als ausreichender Performance und Ressourcen-Verbrauch.

Wieso sollten wir hier irgend etwas ändern wollen?

Gegenfrage: Wieso sollte man mit einem Elektroauto fahren wollen? Ein Auto mit Verbrennungsmotor tut's doch auch? Und das seit mehr als 100 Jahren.

Schlechtes Thema - da bin ich zufälliger Weise ganz nah an der Quelle...

Um es dennoch zu missbrauchen: Wenn Du lange Stecken Überland, evtl. auch noch mit viel Ladung (vgl. LKW), fahren willst, dann ist ein Elektroauto eine ziemlich schlechte Wahl. Systembedingt. Das wirst Du da nie wählen wollen (außer die Verbrenner gibt's nicht mehr...)
Bei anderen Nutzungsmustern kann die Entscheidung aber ganz anders ausgehen...

[Jaccolino]

Ich habe in der letzten Woche mein openhab auf CometVisu umgestellt und bin begeistert. Meine Aktoren: Heizungssteuerung Max!, 9 Stk. Philips Hue, 5 Stk. Philips Living White, 4 Stk. Philips Stecker, 15 Stk. 433 MHz Funksteckdosen, 3 Stk. Wemo, 4 Stk. IP-Kameras, Kalender. Die Schaltreaktionen sowie auch die Anzeige, also Update der Items, sind deutlich schneller geworden. Die Änderung vom Status der Items durch rules werden ohne Zeitverzögerung in der visu aktualisiert. Wetterdaten werden wie vorgesehen aktualisiert. Bei der Einrichtung der visu ist mir allerdings aufgefallen, dass ein Neustart von openhab bei fast allen Änderungen der config notwendig ist, damit die Änderung auch "greift".

[peuter]

Bei der Einrichtung der visu ist mir allerdings aufgefallen, dass ein Neustart von openhab bei fast allen Änderungen der config notwendig ist, damit die Änderung auch "greift".

In der aktuellen Entwicklungversion von openHAB ist ein Fix drin, der das Problem darauf reduzieren sollte, dass man nur noch die Visu im Browser einmal neu laden muss, damit die Status-Updates wieder funktionieren nachdem an der openHAB Items Datei Änderungen durchgeführt wurden. Ist schonmal ein Fortschritt gegenüber dem aktuellen Zustand bei dem openHAB neu gestartet werden muss.

Ansonsten freut´s mich, dass bei Dir alles funktioniert.

[Jaccolino]

Aktuelle Entwicklungsversion von openHAB, also 1.7?! Ich werde das mal probieren, habe aber seit 1.6 erhebliche Schwierigkeiten mit meiner Heizungssteuerung, nach einer Weile werden keine Werte mehr aktualisiert. Allerdings lassen sich die Ventile auch dann über openHAB steuern und führen alle Befehle aus. Die Anzeige des Batteriestatus ist nicht mehr möglich, dabei wird immer der Temperaturwert des Raumes übernommen und angezeigt. Ich habe nun erst mal alle Zimmer zusätzlich mit Netatmo ausgestattet, kann ja nicht schaden, um aktuelle Werte zu erhalten.

Vielleicht hat noch einer einen Tip für mich, ich bekomme einfach kein pagejump ausserhalb von navbar hin.

[Jaccolino]

Nachdem ich jetzt auf das Max!Cube Binding 1.7 gewechselt bin, scheinen die Probleme mit der Batterieanzeige und dem Status der Ventile gelöst. Mal beobachten, ob das dauerhaft ist.

Nur meine Probleme mit dem pagejump ausserhalb navbar hat noch keine Lösung gefunden. Vielleicht hat noch jemand einen Tip.

[peuter]

Versuch mal den Pagejumps außerhalb der navbar ein bind_click_to_widget=true zu spendieren. In der Entwicklerversion der CometVisu ist das bereits gefixt, aber für das Release ist dieser einfache Workaround noch nötig (ich rate aber hiermit ausdrücklich davon ab die Entwicklerversionzu nutzen, da finden zur Zeit größere Umbrüche statt!)

[Jaccolino]

Super, das wars, funzt jetzt. Danke! Irgendwie hatte ich darüber gelesen, aber dann den Ansatz verworfen.

Jetzt brauch ich noch einen Anstoss. Ich habe einen String aus openHAB 2015-03-15T18:11:00 und brauch nur die Zeit. Da ja CV nicht DateTime aus openHAB unterstützt, hat eine Formatangabe da keinen Sinn. Irgendwie habe ich keinen Ansatzpunkt das Problem zu lösen.

[peuter]

Jetzt brauch ich noch einen Anstoss. Ich habe einen String aus openHAB 2015-03-15T18:11:00 und brauch nur die Zeit. Da ja CV nicht DateTime aus openHAB unterstützt, hat eine Formatangabe da keinen Sinn. Irgendwie habe ich keinen Ansatzpunkt das Problem zu lösen.

Entweder löst Du das Problem innerhalb von openHAB, indem Du ein zusätzliches Hilfs-StringItem definierst und dieses über eine Regel mit der Zeit aus dem DateTime-Item fütterst und dieses dann in der Visu anzeigst oder Du musst eine Änderung im CV Code vornehmen, bzw. die Entwicklerversion nutzen.

Ich habe die Unterstützung für DateTime Items in die CV eingebaut:
https://github.com/CometVisu/CometVisu/pull/145/

Im Grunde müsstest Du dafür in die Datei transforms/transform_oh.js folgenden Code einfügen:

 'datetime' : {
    name : "OH_DateTime",
    encode : function(phy) {
      if (phy instanceof Date) {
        return phy.toISOString();
      } else {
        return phy;
      }
    },
    decode : function(str) {
      var date = new Date(str);
      return date.toLocaleString();
    },
  },
  'time' : {
    name : "OH_Time",
    encode : function(phy) {
      if (phy instanceof Date) {
        return phy.toISOString();
      } else {
        return phy;
      }
    },
    decode : function(str) {
      var date = new Date(str);
      return date.getHours()+":"+date.getMinutes()+":"+date.getSeconds();
    },
  },

Und in Deiner Config dann für den entsprechenden Eintrag aus <address transform"OH:string"... ein <address transform="OH:time"... machen. Aber wenn Du die aktuelle Release Version der CV nutzt, wirst Du diese Datei nicht finden, denn da sind alle Javascript Datei zusammen gefasst und komprimiert.

Meine Handlungsempfehlung: Löse das Problem innerhalb von openHAB oder warte auf das nächste CV-Release.

[Chris M.]

Ich habe die Unterstützung für DateTime Items in die CV eingebaut:
https://github.com/CometVisu/CometVisu/pull/145/

Ist gemerged

Meine Handlungsempfehlung: Löse das Problem innerhalb von openHAB oder warte auf das nächste CV-Release.

Wobei das noch bisschen dauern kann, aktuell wird der Code gerade deutlich umgestellt