Ankündigung

Einklappen
Keine Ankündigung bisher.

CometVisu meets openHAB

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    CometVisu meets openHAB

    Da ich vor einiger Zeit auf openHAB (openhab - empowering the smart home - Google Project Hosting) umgestiegen bin, habe mich mal daran gemacht das CometVisu Protokoll in openHAB zu implementieren, damit ich das als Backend nutzen kann und somit auch die bisherige Beschränkung der CometVisu auf KNX zu umgehen.

    Die Änderungen für die CometVisu liegen bereits im SVN Rev.#1108. Auf openHAB Seite muss man das REST-Plugin tauschen mit der JAR-Datei aus dem Anhang (einfach die pdf Dateiendung entfernen).
    Wer sich an dieser Stelle fragt wie man das REST-Plugin denn austauscht sollte am besten garnicht weiter lesen, denn dies ist im jetzigen Stadium nur was für Leute die wissen was sie tun.

    Ausserdem muss man die aktuelle Revision der CV in den Webapps Ordner von openHAB packen (den Ordner dort nicht cv nennen, da dies der Pfad des Backends ist und somit vermutlich zu einem Konflikt führen wird).

    Zum Schluss muss man natürlich noch seine Config anpassen. Im Wesentlichen muss man hier die address Einträge ändern. z.B.

    Code:
    <address transform="OH:dimmer" variant="">Light_Bedroom</address>
    Das Prinzip sollte klar sein, transform erhält den Namespace OH: und dann den Typ des Items (kleingeschrieben, z.B: dimmer, switch, number, string, usw.). Light_Bedroom ist in dem Fall der Name des Items in openHAB.

    Zuguterletzt muss man in der Config noch festlegen, dass openHAB als Backend benutzt werden soll mit
    Code:
    <pages...backend="oh">
    Und dann sollte das laufen.

    Folgende Probleme sind bereits bekannt:

    Problem 1) Die Rückmeldung nachdem man eine Aktion ausgeführt hat ist langsamer als beim nativen Backend, d.h. wenn man eine Lampe einschalten, dann wird dies zwar sofoert ausgeführt, aber es dauert etwas bis sich der Status der Lampe in der Visu ändert.
    Ich habe leider viel zu wenig Ahnung von dem in openHAB genutzten Atmosphere Geschichte. Da lässt sich sicher vieles optimieren. Ich habe es z.B. erst über Websockets probiert und da kann die Geschwindigkeit dem nativen Backend gleichziehen (ich habs jetzt nicht gemessen, aber gefühlt war es genauso schnell). Nur habe ich bei Websockets mehrere andere Probleme gehabt und keine Ahnung wie ich die lösen sollte. Die beiden Hauptprobleme dabei waren:
    1.1. scheinbar konnte sich nur ein Client gleichzeitig verbinden, d.h. wenn man in einem Browser schaltet, wird dem anderen Browser die Statusänderung nicht angezeigt
    1.2. der Websocket reagiert allergisch auf ein Reload der Seite oder Neustart des Backends danach halt manchmal nur noch den kompletten Browser neu zu starten
    Beides sicherlich lösbar wenn man sich damit auskennt. Sourcen findet Ihr in meinem openHAB clone tbraeutigam-openhab - CUPS-Binding, MaryTTS, Pulseaudio-Binding, Cometvisu Backend - Google Project Hosting

    Problem 2) bis jetzt funktionieren nur die grundlegenden Dinge + das Diagramm Plugin. Mehr hab ich noch nicht getestet. Es handelt sich hier also um eine absolute Alpha-Version.


    So das wärs fürs erste. Ich hab mir gedacht, das die Ankündigung hier am besten aufgehoben ist, da sich ja hier sowohl openHAB als auch CometVisu Leute tummeln. Ob ich jetzt besser im openHAB Unterforum gepostet hätte anstatt hier, mag vielleicht sein aber für eins musste ich mich ja entscheiden

    Dann viel Spass beim probieren und ich bin für jeden Experten-Tipp/Patch zum Sourcecode dankbar.

    Gruß
    Tobias
    Angehängte Dateien
    Gruß
    Tobias

    #2
    interessante Sache Tobias.

    Was meinst Du mit "Beschränkung der CometVisu auf KNX zu umgehen"?

    Gruß
    Derzeit zwischen Kistenauspacken und Garten anlegen.
    Baublog im Profil.

    Kommentar


      #3
      Zitat von greentux Beitrag anzeigen
      Was meinst Du mit "Beschränkung der CometVisu auf KNX zu umgehen"?
      Das war ein wenig unglücklich formuliert. Damit meine ich, dass ich über das bisherige Backend der CometVisu nur KNX Befehle senden/empfangen kann. Ich weiß aber das ich z.B. über die Wiregate Plugins auch nicht KNX-Geräte erreichen kann.

      Das ist aber auch garnicht der Ausschlag gebende Punkt warum ich o.g. implementiert habe: Ich brauchte einen Ersatz für Misterhouse, weil Perl und ich in diesem Leben keine Freunde mehr werden und bin bei openHAB gelandet. Dort gibt es zwar auch mehrere Visu´s zur Auswahl aber als Gewohnheitstier wollte ich auf meine CV nicht verzichten. Mehr steckt da nicht hinter.

      Gruß
      Tobias
      Gruß
      Tobias

      Kommentar


        #4
        Zitat von peuter Beitrag anzeigen
        habe mich mal daran gemacht das CometVisu Protokoll in openHAB zu implementieren, damit ich das als Backend nutzen kann
        Sehr schön!
        Zitat von peuter Beitrag anzeigen
        Die Änderungen für die CometVisu liegen bereits im SVN Rev.#1108.
        Hab bisher nur das Commit-Log quergelesen, sieht aber gut aus
        Zitat von peuter Beitrag anzeigen
        Folgende Probleme sind bereits bekannt:

        Problem 1) Die Rückmeldung nachdem man eine Aktion ausgeführt hat ist langsamer als beim nativen Backend, d.h. wenn man eine Lampe einschalten, dann wird dies zwar sofoert ausgeführt, aber es dauert etwas bis sich der Status der Lampe in der Visu ändert.
        Da ich gerade das Backend für einen anderen Zweck auch neu implementiere, bin ich da auf etwas gestoßen:
        Schau mal wie schnell das Backend den Wert bei einem "w" an den gerade offenen "r" (rück)meldet.

        Ich bin mir noch nicht ganz sicher, ob ich diese Rückmeldung zwingend haben möchte (dann müsste das Backend dafür sorgen, dass die unmittelbar kommt), oder eher nur als Schmutzeffekt bei einer simplen Implementierung sehen sollte (dann müssten wir vermutlich in der templateengine eine Art internes Echo einbauen)
        Meinungen zur Entscheidungsfindung sehe ich sehr gerne!
        Zitat von peuter Beitrag anzeigen
        Ich habe leider viel zu wenig Ahnung von dem in openHAB genutzten Atmosphere Geschichte. Da lässt sich sicher vieles optimieren. Ich habe es z.B. erst über Websockets probiert und da kann die Geschwindigkeit dem nativen Backend gleichziehen (ich habs jetzt nicht gemessen, aber gefühlt war es genauso schnell).
        Technisch gibt es keinen Grund, warum ein Web-Socket schneller sein sollte als eine Rückmeldung über einen bereits offenen und wartenden HTTP-Request.
        (Über Möglichkeiten und Unmöglichkeiten seitens des Backendes kann ich nicht mal spekulieren)
        Zitat von peuter Beitrag anzeigen
        So das wärs fürs erste. Ich hab mir gedacht, das die Ankündigung hier am besten aufgehoben ist, da sich ja hier sowohl openHAB als auch CometVisu Leute tummeln. Ob ich jetzt besser im openHAB Unterforum gepostet hätte anstatt hier, mag vielleicht sein aber für eins musste ich mich ja entscheiden
        Hier wird's sicherlich mehr Feedback ab Protokoll bis zum Client geben.
        Die Menge des Feedbacks zum Backend kann ich nicht einschätzen, da...
        Zitat von peuter Beitrag anzeigen
        Dann viel Spass beim probieren
        ... ich mangels OpenHAB nicht wirklich mitmachen kann. In diesem Thread wäre aber auch eine Backend-Diskussion sicher On-Topic.
        Zitat von peuter Beitrag anzeigen
        und ich bin für jeden Experten-Tipp/Patch zum Sourcecode dankbar.
        Ab Protokoll gerne. Und da ich ja selber gerade an einem Backend bin (s.o.) können wir hier evtl. gemeinsam das Thema weiter stabilisieren.
        TS2, B.IQ, DALI, WireGate für 1wire so wie Server für Logik und als KNX Visu die CometVisu auf HomeCockpit Minor. - Bitte keine PNs, Fragen gehören in das Forum, damit jeder was von den Antworten hat!

        Kommentar


          #5
          Zitat von Chris M. Beitrag anzeigen
          Da ich gerade das Backend für einen anderen Zweck auch neu implementiere, bin ich da auf etwas gestoßen:
          Schau mal wie schnell das Backend den Wert bei einem "w" an den gerade offenen "r" (rück)meldet.
          Die Ursache meine ich mittlerweile gefunden zu haben, bzw. den Unterschied zwischen Websocket und vorhandener Variante. Über Websocket verhält sich das Backend wie gewünscht und gibt nur den geänderten Wert zurück. Bei der zur Zeit benutzten Variante werden bei jeder Änderung alle Werte neu übermittelt. Da das zur Zeit etwa 100 sind, kann das durchaus die halbe Sekunde Zeitverzögerung verursachen.
          Ursache liegt also vermutlich klar im Backend, eine Lösung habe ich bisher nicht nicht gefunden, mangels Kenntnissen von der Materie.

          Zitat von Chris M. Beitrag anzeigen
          Ich bin mir noch nicht ganz sicher, ob ich diese Rückmeldung zwingend haben möchte (dann müsste das Backend dafür sorgen, dass die unmittelbar kommt), oder eher nur als Schmutzeffekt bei einer simplen Implementierung sehen sollte (dann müssten wir vermutlich in der templateengine eine Art internes Echo einbauen)
          Meinungen zur Entscheidungsfindung sehe ich sehr gerne!
          Rein vom Bauchgefühl her bevorzuge ich die jetzige Variante, damit habe ich eine direkte Rückmeldung vom Backend welche Auswirkungen meine Aktion bewirkt hat. Gerade wenn dahinter eine LogicEngine sitzt, kann z.B. das Betätigen eines Switches auch Auswirkungen auf andere Items haben. Konkreter Anwendungsfall bei mir: Wenn ich den MPD einschalte, gehen automatisch zwei Steckdosen an denen Verstärker hängen. Damit brauche ich sowieso eine schnelle Rückmeldung vom Backend, da die Visu ja nicht wissen kann was sich sonst noch so alles ändert. Bei der aktuellen Geschwindigkeit zwischen Klicken und Rückmeldung sehe ich da erstmal keinen Handlungsbedarf.

          Zitat von Chris M. Beitrag anzeigen
          Ab Protokoll gerne. Und da ich ja selber gerade an einem Backend bin (s.o.) können wir hier evtl. gemeinsam das Thema weiter stabilisieren.
          Dazu fällt mir direkt mal ne Frage ein über die ich beim Rumspielen mir den Websockets gestoßen bin: Ist die Trennung der verschiedenen Backend Funktionen auf unterschiedliche Pfade (l: login, r: read, w: write) aus einem bestimmten Grund so gewählt oder könnte man das nicht auch zu einem zentralen Zugangspunkt zusammenfassen. Zumindest für die Read/Write Endpunkte würde es Sinn machen, da man das prima in einem Websocket Serverdienst zusammenfassen könnte.
          Wie hast Du das bei Deinem Backend vor?
          Gruß
          Tobias

          Kommentar


            #6
            Zitat von peuter Beitrag anzeigen
            Rein vom Bauchgefühl her bevorzuge ich die jetzige Variante, damit habe ich eine direkte Rückmeldung vom Backend welche Auswirkungen meine Aktion bewirkt hat.
            Hinter der aktuellen Lösung steckt ja auch die Idee, dass es 2 GAs geben kann, eine zum Schreiben und eine für die Rückmeldung. Mit read und write ist das auch etwas weiter formalisiert worden.

            Es lohnt sich aber, immer mal wieder einen Schritt zurück zu treten und solche Design-Entscheidungen mit aktuellem Wissen zu überprüfen.
            (Kommt dabei eine Bestätigung heraus, um so besser )
            Zitat von peuter Beitrag anzeigen
            Dazu fällt mir direkt mal ne Frage ein über die ich beim Rumspielen mir den Websockets gestoßen bin: Ist die Trennung der verschiedenen Backend Funktionen auf unterschiedliche Pfade (l: login, r: read, w: write) aus einem bestimmten Grund so gewählt oder könnte man das nicht auch zu einem zentralen Zugangspunkt zusammenfassen. Zumindest für die Read/Write Endpunkte würde es Sinn machen, da man das prima in einem Websocket Serverdienst zusammenfassen könnte.
            Wie hast Du das bei Deinem Backend vor?
            Eine URL ist nur Schall und Rauch, die sagt nichts über das, was dahinter liegt. Ob nun l, r und w lauter eigene Progrämmchen sind (wie aktuell) oder alle vom selben gehandelt werden ist für's Protokoll und folgendes völlig egal.

            Konkret ist's bei der Implementierung, an der ich gerade dran bin, ein einziger Deamon, der alles gleichzeitig bereitstellt und per SCGI an den Web-Server angebunden ist.
            So spare ich mir ständiges Starten und Beenden von Prozessen, d.h. es ist dramatisch Ressoucen sparender als die aktuelle Lösung (die aber auf dem schwachen Wiregate bereits auch schon sehr gut skaliert)
            TS2, B.IQ, DALI, WireGate für 1wire so wie Server für Logik und als KNX Visu die CometVisu auf HomeCockpit Minor. - Bitte keine PNs, Fragen gehören in das Forum, damit jeder was von den Antworten hat!

            Kommentar


              #7
              Kurze Frage zum neuen Backend-Feature:

              Das wollte ich gerade mal nutzen um hier auf mein SCGI-Backend umzuschalten.

              Dabei habe ich allerdings gesehen, dass das relativ komplex implementiert ist.
              Eigentlich würde es ja reichen nur die Variable "backend" zu haben, die einfach den Pfad zu l/r/w festlegt (also per Default "cgi-bin", oder bei Dir halt dann auf "cv" übersteuert).
              Implementiert ist das ja nun mit einem zusätzlichen Objekt, etc. pp.

              Steckt da mehr dahinter als hier offensichtlich ist?

              (Hintergrund: hab's mal bei mir vereinfacht um halt schnell mal auf "/scgi/" wechseln zu können, dabei habe ich natürlich gemerkt, dass er jetzt rrdfetch auch unter /scgi/ erwartet, was ich aber so nicht möchte... => bin noch auf der Suche nach der optimalen Lösung)
              TS2, B.IQ, DALI, WireGate für 1wire so wie Server für Logik und als KNX Visu die CometVisu auf HomeCockpit Minor. - Bitte keine PNs, Fragen gehören in das Forum, damit jeder was von den Antworten hat!

              Kommentar


                #8
                Zitat von Chris M. Beitrag anzeigen
                Dabei habe ich allerdings gesehen, dass das relativ komplex implementiert ist.
                Eigentlich würde es ja reichen nur die Variable "backend" zu haben, die einfach den Pfad zu l/r/w festlegt (also per Default "cgi-bin", oder bei Dir halt dann auf "cv" übersteuert).
                Implementiert ist das ja nun mit einem zusätzlichen Objekt, etc. pp.

                Steckt da mehr dahinter als hier offensichtlich ist?
                Ursprünglich hatte ich das wesentlich aufwändiger implementiert mit einer eigenen Implementierung für den CometVisu-Client. Dazu brauchte ich mehr Konfigurationsparameter als nur den Pfad. Daher kommt das. Nachdem dem ich das Backend soweit angepasst hatte, dass es auch mit dem vorhandenen CometVisu-Client funktionierte habe ich nur die zusätzlichen Konfigurationsparameter aus dem backendConfig Objekt gelöscht. Daher ist das jetzt so wie es ist und könnte auf durch eine Variable ersetzt werden. Zumindest für den Pfad zum rrdfetch bräuchten wir dann aber noch eine zweite Variable und das in einem Objekt zusammenzufassen finde ich da etwas aufgeräumter.

                Die Kapselung der Initialisierung des Client in der Funktion initBackendClient(backend) ist nur dazu da, damit ich beim Einlesen der Config auf einen dort eventuell vorhandenen Backend-Parameter reagieren kann und den Client erst dann dementsprechend initialisiere.
                Gruß
                Tobias

                Kommentar


                  #9
                  Nur in Stichworten bitte nicht übel nehmen

                  Also für den nächsten Daemon werden Perl und ich auch keine Freunde mehr, Java aber noch weniger.. Ist halt so, bin alt und verbohrt C(++) wird lagńgsam mein Freund..

                  Das polling der stati darf eben kein Polling sein sondern "long polling" aka "Comet" - request abschiessen, warten bis was passiert, erst dann antwortet der Server.. Das geht ohne Websockets und sicher auch in Java im backend..

                  Namespaces hätte ich jetzt gerade (optional!) "KNX:" im hinterkopf, also so wirds fürs eib/CV-Backend vermutlich werden, nur warum den Java-Umweg für KNX (andere NS können ja..)? das macht der eibd perfekt und und unter 100ms für tausende GAs und hunderte clients..

                  Makki
                  EIB/KNX & WireGate & HS3, Russound,mpd,vdr,DM8000, DALI, DMX
                  -> Bitte KEINE PNs!

                  Kommentar


                    #10
                    Zitat von makki Beitrag anzeigen
                    Nur in Stichworten bitte nicht übel nehmen

                    Also für den nächsten Daemon werden Perl und ich auch keine Freunde mehr, Java aber noch weniger.. Ist halt so, bin alt und verbohrt C(++) wird lagńgsam mein Freund..
                    Keine Angst, ich lese lange genug hier im Forum mit, um Deine Meinung zu Java zu kennen und hatte auch fest mit einem Kommentar in der Richtung gerechnet

                    Zitat von makki Beitrag anzeigen
                    Das polling der stati darf eben kein Polling sein sondern "long polling" aka "Comet" - request abschiessen, warten bis was passiert, erst dann antwortet der Server.. Das geht ohne Websockets und sicher auch in Java im backend..
                    Das ist auch bereits so und der Server schickt auch erst eine Antwort, wenn es eine Änderung gab. Das Problem ist halt nur, das diese Antwort leider alle Items mit Werten enthält und nicht nur die geänderten. Über Websockets enthält die Antwort, wie gewünscht nur die geänderten. Ich muss halt hier nur den Unterschied rausfinden und dann den Fehler im Backend beheben.

                    Zitat von makki Beitrag anzeigen
                    Namespaces hätte ich jetzt gerade (optional!) "KNX:" im hinterkopf, also so wirds fürs eib/CV-Backend vermutlich werden, nur warum den Java-Umweg für KNX (andere NS können ja..)? das macht der eibd perfekt und und unter 100ms für tausende GAs und hunderte clients..
                    Wenn ich ein reines KNX-System hätte, wäre der Umweg sicherlich Quatsch und ich könnte eine Logicengine und die CV prima unabhängig voneinander, mit dem KNX-Bus als Kommunikationsschnittstelle, betreiben. Ist aber nun mal nicht so und in dem Falle bleiben IMHO nur 3 Möglichkeiten:

                    1. alle nicht KNX-Items auf "virtuelle"-GA´s legen und der Logicengine beibringen die Wertänderungen an den KNX-Bus zu senden. Stößt aber z.B. bei langen Strings an seine Grenzen.
                    2. CV dazu bringen direkt mit der Logicengine zu sprechen + neuer Namespace für die Logicengine
                    3. Neue Namespaces für alle anderen Dinge die ich einbinden möchte + ein oder mehrere Backends, welche mit den Systemen kommunizieren können. (das macht openHAB ja bereits für mich)

                    Ich hab mich halt für den 2. Weg entschieden. Nicht das ich mit Variante 1 nicht auch klargekommen wäre, aber Nr.2 ist für mich der konsistentere Weg und ein klein wenig gings sicher auch darum, herauszufinden ob ich das hinbekomme und wie schwer das geht.

                    Zur Geschwindigkeit: Das der vorhandene eibd schneller und deutlich Ressourcen schonender ist als eine Java-basierte Lösung will ich gar nicht bestreiten. Aber ich glaube nicht, dass ich als normaler Anwender davon was merke, selbst wenn ich mir die Wände mit Touchscreens tapeziere. Da bei mir der Backend-Server deutlich mehr Power als die Clients hat, stellt der erhöhte Ressourcenverbrauch auch kein Problem dar.

                    Gruß
                    Tobias
                    Gruß
                    Tobias

                    Kommentar


                      #11
                      Zitat von peuter Beitrag anzeigen
                      Das ist auch bereits so und der Server schickt auch erst eine Antwort, wenn es eine Änderung gab. Das Problem ist halt nur, das diese Antwort leider alle Items mit Werten enthält und nicht nur die geänderten. Über Websockets enthält die Antwort, wie gewünscht nur die geänderten. Ich muss halt hier nur den Unterschied rausfinden und dann den Fehler im Backend beheben.
                      Was aber nur ein Bug in der Implementierung ist und kein Problem mit dem Protokoll ff.
                      => Sollte lösbar sein
                      Zitat von peuter Beitrag anzeigen
                      2. CV dazu bringen direkt mit der Logicengine zu sprechen + neuer Namespace für die Logicengine
                      3. Neue Namespaces für alle anderen Dinge die ich einbinden möchte + ein oder mehrere Backends, welche mit den Systemen kommunizieren können. (das macht openHAB ja bereits für mich)

                      Ich hab mich halt für den 2. Weg entschieden. Nicht das ich mit Variante 1 nicht auch klargekommen wäre, aber Nr.2 ist für mich der konsistentere Weg und ein klein wenig gings sicher auch darum, herauszufinden ob ich das hinbekomme und wie schwer das geht.
                      2. und 3. sind die richtigen Lösungen. Dinge die bereits direkt in openHAB eingebunden sind machen sicher keinen Sinn die für 3. noch einmal einzubinden.
                      TS2, B.IQ, DALI, WireGate für 1wire so wie Server für Logik und als KNX Visu die CometVisu auf HomeCockpit Minor. - Bitte keine PNs, Fragen gehören in das Forum, damit jeder was von den Antworten hat!

                      Kommentar


                        #12
                        Hallo,

                        ich wollte die Cometvisu auch mal mit dem etwas unkannteren Bussystem HAP verbinden. Die Funktion der beiden Programme eibread-cgi und eibwrite-cgi habe ich auf Perlbasis so nachgebildet, dass die Anfragen auf die HAP-Umgebung umgeleitet werden. Write funktioniert auch, allerdings stehe ich gerade beim read mit den Werten von index und timeout auf dem Schlauch.
                        Der Client setzt trotz Antwort ca. alle zwei Sekunden ein read ab.
                        Die aktuellen Zustände der Devices stehen bei HAP schon direkt in einer MySQL-Datenbank, weshalb ich mich nicht weiter um die Aktualität der Daten kümmern muss.
                        Kann mir jemand beim Cometvisu-Protokoll auf die Sprünge helfen, wie ich index und timeout richtig setzten muss?

                        Kommentar


                          #13
                          Probier als erstes mal die Doku: CometVisu/Protokoll (Deutsch) - Open Automation

                          Wenn die nicht hilft, haben wir wohl einen Bug in der Doku....
                          TS2, B.IQ, DALI, WireGate für 1wire so wie Server für Logik und als KNX Visu die CometVisu auf HomeCockpit Minor. - Bitte keine PNs, Fragen gehören in das Forum, damit jeder was von den Antworten hat!

                          Kommentar


                            #14
                            Die Doku habe ich schon gelesen. Ich habe noch zusätzlich die Anfragen mit dem Demozugang der Cometvisu verglichen. Prinzipiell passt alles.
                            Die Kommunikation klappt bei mir auch schon, nur dass etwa alle zwei Sekunden ein neuer read abgesetzt wird, was natürlich auf dem Server eine unnötige Last erzeugt.

                            Kommentar


                              #15
                              r (eibread-cgi) darf nichts antworten/zumachen, solange es nichts neues gibt, vielleicht liegt da das Problem? Timeout im Webserver/CGI?

                              Makki
                              EIB/KNX & WireGate & HS3, Russound,mpd,vdr,DM8000, DALI, DMX
                              -> Bitte KEINE PNs!

                              Kommentar

                              Lädt...
                              X