Hi,
Ich würde mir wünschen und als Anregung im Raum stehen lassen, das FTUI anstatt einer Direktverbindung die Daten per MQTT geliefert bekommt.
FTUI ist mit Abstand das bester Frontend, nur das bei einer sehr komplexen Installation vermehrt freezes in ftui und fhem entstehen.
( ich berichtet bereits von ftui freezes von 130sek, eine Lösung ausser ftui zu reduzieren könnten wir hier im Forum nicht finden)
Als Alternative wäre da MQTT als Datenverbindung. Ev. Ist ja ftui so generisch aufgebaut das man beides implementieren kann.....
Gesendet von meinem Leap mit Tapatalk
Dafür bräuchte man eine MQTT-Implementierung in Javascript. Gibt es so was schon? Dann wäre auch vermutlich eine große Änderung in ftui-Framework notwendig. Als Zwischenlösung könnte man eine (oder auch mehrere) extra FHEM-Instanz für FTUI vorsehen (ggf. per MQTT an das HauptFHEM angebunden). Damit könnte man fieses-Problem etwas entschärfen.
in mir nicht so sicher, ob das wirklich eine gute Lösung ist. Du brauchst ja, um ein flexibles Frontend haben zu können, einen Datenbus, auf dem alle Events/Wertänderungen gesendet werden. MQTT ist das bei FHEM, Stand heute, nicht. Also würde daraus folgen, daß Du entweder einen zusätzlichen MQTT Datenbus in FHEM anlegen musst oder aber FTUI entsprechende Devices dynamisch erstellt.
Ob das unter dem Strich die Sache wirklich performanter und weniger anfällig macht, wage ich zu bezweifeln.
Wobei ich durchaus vermute, daß MQTT mittels des Brokers ein viel performanterer und ressourcenschonender Datenbus wäre, als das jetzige Event-Konzept.
Da ich für FTUI alte iPads verwende (zur Zeit ein iPad 1), ist der Speicherbedarf der Java Widgets ein Problem auf dem Endgerät. Das würde durch MQTT vermutlich nicht wirklich weniger.
Was ich mir vorstellen könnte, wäre ein Frontend-Compiler. Also die Seiten und Funktionen in einer Steuerdatei beschreiben und dann durch einen Compiler jagen, der entsprechende Seiten und Widgets erzeugt und gleichzeitig in FHEM die nötigen Schnittstellen generiert. Dadurch wird viel Aufwand, der auf Grund der Flexibilität nötig ist, zum Einmal-Aufwand und die Laufzeitsysteme würden entlastet. Da könnte man dann auch über MQTT nachdenken.
Oder aber FHEM so umschreiben, daß MQTT als interner Datenbus verwendet wird. Die Idee mag ich wirklich, aber das wäre ein enormer Aufwand.
MQTT gibt es als javascript api: https://github.com/mqttjs
Das die Werte die man per FTUI anzeigen lassen will auf dem MQTT Broker vorhanden sein müssen ist klar... Das klappt per MQTT* Devices und soll ja hier nicht das Problem sein. Ich stelle mir das so vor, das man als data_device einen Schlüsselnamen, bzb "MQTT" und als data_get das Topic angibt.
Update: mit dem Generic MQTT Bridge Modul von Hexenmeister lassen sich ganz einfach alle Werte ins MQTT schieben.
Leider haperts noch an einem FTUI ähnlichem Frontend mit MQTT-Anbindung :( Kennt keiner etwas FTUI ähnliches?
ich suche auch ein FTUI ähnliches Frontend.
Leider habe ich auch noch nichts passendes gefunden.
Hab daher angefangen mich ein wenig nach Frontends zu googeln.
Hier fiel bisher meine Wahl auf folgende Komponenten:
- Vue.js als Javascript Framework https://vuejs.org/ (https://vuejs.org/)
- Vue-Grid-Layout als Gridster https://github.com/jbaysolutions/vue-grid-layout (https://github.com/jbaysolutions/vue-grid-layout)
- MQTT Client https://github.com/mqttjs/MQTT.js (https://github.com/mqttjs/MQTT.js)
- Bulma als CSS Framework https://bulma.io/ (https://bulma.io/)
Leider stehe erst ganz am Anfang und teste die Komponenten erst mal ein bischen.
Und die liebe Zeit.
Vielleicht hat ja schon einer Erfahrung und kann was dazu sagen.
Schaut euch mal den Node-Red Thread an
https://forum.fhem.de/index.php/topic,78512.html
Gerade über diesen "alten" Thread gestolpert :)
Ich bin aktuell auch SEHR STARK am überlegen, ob ich nicht ein MQTT basiertes Dashboard haben will. Vor allem wäre mir wichtig, dass es aufm Handy anständig funktioniert (geringer Ressourcenverbrauch, optimiert für kleine Displays). Mit Vue und MQTT hab ich schon etwas gespielt und die Anbindung klappt per Websocket sehr gut.
Nun die zwei Frage: Gibt es denn mittlerweile etwas brauchbares? Falls nein, hätte jemand Interesse sowas mit mir zu entwickeln? (PS: JavaScript kann ich recht gut, Designer/UXler eher wenig)
eigentlich macvht imho nur Sinn das FTUI Repo zu forken und zusätzlich zu websocket und ajax noch mqtt einzubauen.
Da brauchst kein UX da bereits alles fertig.
Ich bin mir fast sicher das setstate deinen PullRequest annimmt :)
Per mqtt reagiert bei mir eine Anzeige -zig mal schneller als per ajax/websocket.
NodeRed oder andere Frontends sind für meine UseCases keine Alternative