bin gerade am Überlegen wie man eine Homegear GUI hinbekommt. Ich möchte vor allem von den vorhandenen EQ3 Windows Programmen wegkommen, da diese bei mir sehr unzuverlässig laufen und ich ausserdem fasst kein Windows mehr einsetze.
Anforderungen:
Web GUI mit Javascript
Nutzbar auch als Adapter in ioBroker.
Gerne einfache WebGUI, die auch von “interessierten Laien” erweiterbar ist.
Erste Ansätze gibt es wohl schon:
Homemanager von Hobbyquaker, wird aber nicht mehr weiterentwickelt
Auch von Sathya gibt es wohl was.
Openhab, scheint mir aber sehr Java/OSGi lastig zu sein.
Gibt es sonst noch Möglichkeiten? Also ich möchte nicht das Rad neu erfinden.
ich denke eine GUI über WebSockets macht am meisten Sinn. Diese kann dann über Homegears eingebauten Webserver bereitgestellt werden (kann auch PHP im Backend). Mit Hilfe von Bootstrap ließe sich da eine individuelle Seite mit sehr wenig Aufwand realisieren. Das ist nur natürlich nichts für den normalen Endnutzer. Eine schnelle Abhilfe wäre zum Beispiel fertige Bausteine (Schalter, Temperatur, Fenster, …) in ein Content-Managementsystem zu integrieren, welches Inhaltselemente unterstützt (z. B. das neue Typo3 Neos). Damit könnte dann jeder nach dem Baukastenprinzip seine eigene Seite basteln.
In etwa zwei Wochen werden wir mal ein kleines HowTo zu Bootstrap ins Wiki stellen.
evtl. macht es auch Sinn über den eingebauten Homegear Webserver eine GUI zu basteln unter Verwendung eines Frameworks wie z.B. Symfony2 + Bootstrap, JS und Websockets. Leider bin ich noch nicht im Detail mit allen Homegear Komponenten vertraut um so etwas sinnvoll umsetzen zu können.
Meine eigene Gui/Framework hat ein Java/Spring-MVC Backend.
Client-seitig nutze ich derzeit jQuery. Bootstrap hatte ich auch noch vor einzusetzen.
SVG nutze ich ebenfalls noch für Grundrisse.
Ist aber noch alles im Alpha Stadium
Hallo ribb3r,
ja mein Framework kapselt die XMLRpc Aufrufe zu Homegear.
Damit alles ein wenig einfacher aufrufbar ist.
Es beinhaltet für jedes (im Moment nur Homematic Devices welche ich selber nuzte) Device eine Wrapperklasse.
Derzeitig sind für folgende Homematic Devices Klassen implementiert:
HM-CC-RT-DN, HM-TC-IT-WM-W-EU, HM-WDS10-TH-O, HM-ES-PMSw1-Pl
Über Spring wird dann das Framework aufgerufen.
Will mal nachfragen wie weit du bist.
Ich bin sehr interessiert, da ich von Openhab weg will. Openhab ist mir einfach zu instabil.
Aktuell habe ich aus Stabilitätsgründen die kompletten Logiken in php Script durch Homegear getriggert gelöst.
Openhab ist bei mir nur noch die GUI und History Datenbank für schöne Grafiken
Habe gesehen das du in JS schon was gebaut hast auf GitHub.
Sehe ich das richtig, dass dies direkt von JS auf Homegear verbindet?
Weil ich sehe hier ein grossen Nachteil in Verbindung mit Zugriff über Proxies oder Firewalls. Da wäre vermutlich den Umweg über ein PHP Web-Socket flexibler.
Für meine Bedürfnisse, habe ich eine PHP Homegear Klasse angefangen mit einer “HomegearProxy” Klasse im Hintergrund, welche automatisch alle RPC-Methoden 1:1 an Homegear weiterreicht. Ev. kannst du sowas gebrauchen?
Habe extra auf möglichst grosse Flexibilität und Ausbaubarkeit geachtet, auch wenn noch nicht alles komplett ist.
Wäre schön wenn du uns mal updaten kannst über den aktuellen Stand, dann könnten wir ev. noch was beisteuern und helfen.
Ich würde gerne so schnell wie möglich Openhab los werden.
PS: hast du dir schon mal Gedanken gemacht, ob überhaupt und wie du mal in Zukunft eine History anbieten willst?
Falls du Interesse am Code hast, du kannst mich auch per Mail erreichen (gehe davon aus, dass du die im Forum sehen kannst .
Kleiner Nachtag:
Ev. würde es Sinn machen, ein bereits bestehendes GUI zu benutzen anstatt das Rad neu zu erfinden.
Momentan würde ich persönlich smartvisu mal anschauen. Bin auch gerade dabei. Pro:
[ul][li]wirklich schönes GUI, eines der optisch besten meiner Meinung nach und gut bedienbar[/li][li]auch Chars sind schön und interaktiv, was leider oft vernachlässigt wird[/li][li]unterstützt bereits diverse Projekte in dem Umfeld[/li][li]Scheint die Einbindung über driver zu lösen, was so aussieht als könnte man dann einfach ein Homegear driver bauen.[/li][li]PHP, was Homegear auch entgegen kommt[/li][/ul] Contra:
[ul][li]Sie tun sich ein wenig schwer mit Doku… (ist wollen Spende für Doku Zugang, haben vermutlich in der Vergangenheit schlechte Erfahrungen gemacht[/li][/ul]
Ich sehe das mit der Doku nicht so eng, denke wenn man das Projekt mal genau angeschaut hat, sollte es auch gut Pflegbar sein, bzw. ev. bekommst du als Supporter dann sogar ohne Spende die Doku.
Wenn ich Zeit finde schaue ich mir dass mal an, wie man Homegear da einbinden könnte. Soweit ich schon gesehen habe, scheinen die Variante mit direkten JS-Calls sowie auch den Umweg von JS über PHP zu unterstützen. Hat da ein JSON -> PHP Treiber drin. Werde ich mir mal genauer anschauen.
Genau und zwar über Websockets. Die Authentifizierung vorher kann über PHP stattfinden, der Login kann dann über die SID erfolgen. Alternativ geht auch Basic Auth.
Hmm, WebSockets hatte ich eingebaut, um den Umweg über ein “Proxy-Skript” zu vermeiden. Die Verbindung baut ja der Client zum Server auf übers Internet natürlich mit TLS und Authentifizierung. Die vom Client aufgebaute Verbindung wird dann in die andere Richtung genutzt, so dass beim Client kein Port geöffnet werden muss. Warum denkst du, dass das problematisch sein könnte?
Klar, auf jeden Fall! Das ist relevant, wenn das Skript auf einem separaten Webserver laufen soll - das brauche ich tatsächlich relativ häufig. Ich würde das der bestehenden PHP-Klasse hinzufügen? Am einfachsten wäre es natürlich, du machst einen entsprechenden Pull-Request in GitHub - dann sieht auch jeder, dass du der Urheber bist ! Aber ich baue es natürlich auch gerne ein. So oder so, vielen, vielen Dank!!!
Homegear hat ab Version 0.6 (und zum Teil auch bereits in 0.5) einen eingebauten vollwertigen (und sicheren) Webserver mit PHP-Unterstützung. In den PHP-Skripten kannst du die RPC-Methoden direkt über “hg_invoke” aufrufen. Dadurch hast du vor allem sehr geringe Ausführzeiten. Das heißt, so lange du Homegear als Webserver verwendest, benötigst du keine Proxy-Klasse. Allerdings war ich auch hier bisher zu faul, alle RPC-Methoden über Direktaufrufe zu implementieren (also hg_list_devices, hg_get_peer_id, …).
Wenn du Lust hast zu helfen, wären wir dir sehr, sehr dankbar! Es gibt viele Baustellen! Wenn du helfen magst, such dir eine aus, an der du selbst am meisten Spaß hast (eine Riesenhilfe wärst du zum Beispiel bei der GUI-Entwicklung).
Auf jeden Fall!!! Das geht aber sogar schon und zwar über MQTT mit zum Beispiel InfluxDB und Grafana.
Liebe Grüße
Sathya
Nachtrag zu deinem zweiten Post: Klar, macht absolut Sinn!!! Bin gespannt auf deinen “Bericht” .
Hmm, WebSockets hatte ich eingebaut, um den Umweg über ein “Proxy-Skript” zu vermeiden. Die Verbindung baut ja der Client zum Server auf übers Internet natürlich mit TLS und Authentifizierung. Die vom Client aufgebaute Verbindung wird dann in die andere Richtung genutzt, so dass beim Client kein Port geöffnet werden muss. Warum denkst du, dass das problematisch sein könnte?
[/quote]
Korrigiere mich wenn ich falsch liege, bin mit mit meinem Wissen über WebSockets noch nocht so upToDate, aber viele Proxies können damit noch nicht umgehen, da müsste es sowieso ein Fallback geben, damit die Funktion gewährleistet bleibt (auch wenn mit erheblichen Timing nachteilen). Ebenso ist oft so, das Proxies alles blocken was nicht Standard HTTP Protokoll ist und nicht über die üblichen Ports gehen. Leider geht dies oft soweit, dass sogar das Protokoll analysiert wird. Das heisst z.B. Port 80 geht nur wenn es das HTTP Protokoll benutzt wird. HTTPS wird in Büros oft auf dem Proxy entschlüsselt und dann mit einem eigenen Zertifikat an den Client weiter gegeben. Dies kann ebenfalls die Verbindung stören.
Soweit mir ist, um möglichst flexibel zu sein, müsste der Client nach folgender Reihenfolge die Mögliche Verbindung aufbauen:
[ol][li]WebSocket direkt auf den Socket von Homegear ohne Umwege[/li][li]WebSocket mit Umweg über PHP (Standard Web-Port wo die Seite auch erreichbar ist (je nach Einstellung auch verschlüsselt)[/li][li]Stink normale HTTP Requests über PHP (ohne WebSocket) so dass es für ein Proxy ein normaler Seitenaufruf ist, der halt nur Daten überträgt, kann HTTP oder HTTPS sein)[/li][/ol]
Kannst du eine Instanz von einer PHP Klasse “vor laden” und als Variable zur Verfügung stellen? Wenn ja, könnte man doch meine Proxy Klasse als Object zur verfügung stellen, dann sind immer automatisch alle RPC Funtionen auch direkt erreichbar. Oder gehen dadurch die Geschwindigkeitsvorteile wieder Verloren?
Wenn du erlaubst, mache ich mal ein Issue in Github wo wir dies einzeln diskutieren können. Da kann ich dir auch mal den Code zeigen.
Ich schaue mir das mit dem SmartVISU mal an und gebe dann Feedback. Ev. haben die obiges Problem ja bereits gelöst mit den Verbindungen etc.
Will nur vermeiden, dass mehrere gleichzeitig in verschiedene Richtungen arbeiten
Muss ich mir mal anschauen, habe mich ehrlich gesagt mit dem Thema noch überhaupt nicht auseinandergesetzt.
.
! Aber ich baue es natürlich auch gerne ein. So oder so, vielen, vielen Dank!!!