Hallo liebe Hausautomatisierer.
Im Rahmen eines Forschungsseminars in der Uni bin ich dabei ein neues Frontend für Fhem zu erstellen. Das Ganze soll dabei auf PHP mit Silex, Bootstrap, jQuery und Flotchart basieren.
Würde an sowas Interesse bestehen oder gibt es bereits Frontends die massentauglich sind? Ich habe bei meinen Recherchen nichts gefunden. Dennoch möchte ich mich hiermit nochmal rückversichern, um am Ende nicht für die Katz zu arbeiten. Wenn gewünscht würde ich demnächst noch einige Informationen über die geplante Umsetzung und erste Screenshots Posten.
Vielen Dank im Voraus :-)
Screenshots 12.11.2014:
Login-Screen:
(http://www.zimagez.com/miniature/screenshot-12112014-203629.php) (http://www.zimagez.com/zimage/screenshot-12112014-203629.php)
Overview (soll später so werden, dass dort Platzhalter sind und man sich aussuchen kann, ob man dort Schalter oder Diagramme anzeigen lassen möchte):
(http://www.zimagez.com/miniature/screenshot-12112014-203841.php) (http://www.zimagez.com/zimage/screenshot-12112014-203841.php)
Nutzerverwaltung:
(http://www.zimagez.com/miniature/screenshot-12112014-203917.php) (http://www.zimagez.com/zimage/screenshot-12112014-203917.php)
Beispiedialog:
(http://www.zimagez.com/miniature/screenshot-12112014-204002.php) (http://www.zimagez.com/zimage/screenshot-12112014-204002.php)
VG
Respig
Hallo Respig, es gibt schon ein anderes Frontend, siehe
http://www.fhemwiki.de/wiki/Neues_Charting_Frontend
Hört sich aber trotzdem gut an und Interesse an neuem besteht immer
Gesendet von meinem GT-I9505 mit Tapatalk
Es gibt einige Frontends, aber so wie auch das von heti001 genannte, ist keines davon bisher wirklich vollständig oder wirklich massentauglich ist. Einen guten Ansatz gibt es hier:
http://forum.fhem.de/index.php/topic,27291.0.html (http://forum.fhem.de/index.php/topic,27291.0.html)
Dort sieht es auch so aus, als würde das ganze durchgezogen.
Auch gibt es schon eines, das YAF (Yet Another Floorplan) heißt. Auch dazu findest du hier einiges im Forum.
Danke für die Links! :) Das "neue Charting Frontend" habe ich mir schon angesehen und bin dann zu der Entscheidung gekommen, dass ich das meiner Freundin bspw. nicht zeigen möchte ;) Für uns als Bastler super, für den normalen Bürger eher weniger geeignet meiner Meinung nach.
Ich bin auch schon auf das Hoanoho gestoßen. Das sah sehr vielversprechend aus, allerdings wenn man sich den Quelltext ansieht findet man dort keine richtige Architektur wieder (html mit php vermischt etc.). Das soll hier besser werden (MVC Architektur dank Silex).
Kurz zu mir vielleicht:
Informatik Student im 2. Semester Master, habe schon ein kleines Verwaltungsprojekt gestemmt mit einem Kumpel (Pensionsverwaltung für seine Mutter - die findet sie Spitze ;-) und kommt gut damit klar obwohl keine Ahnung von PC's) und arbeite nebenbei als Webentwickler.
Das andere YAF habe ich auch schonmal kurz angesehen. Bei dem von mir geplanten YAFF sollen erstmal Statistiken visualisiert werden (ähnlich zu dem "neuen Charting Frontend") und Aktoren (Licht etc.) gesteuert werden können von einer Webanwendung, welche für Handys, Tablets und PC's entsprechend optimiert ist.
Ich fänd's prima, wenn es endlich ein Webfrontend gäbe. Das kann von mir aus auch gerne "nur" eine Art Framework sein.
Sprich für einzelne Devices gibt es Widgets, die man dann nach Lust und Laune in sein eigenes Design integrieren kann. Da die meisten FHEMs ohnehin auf irgendwie gearteten Linux-Kist(ch)en laufen werden, sollte es durchaus möglich dort eine LA(M)P-Umgebung zu schaffen.
Es gab vor einigen Jahren mal ein Projekt, allerdings in Verbindung mit einer CCU, welches sich schlichtweg "Homematic Webcontrol" http://homematic-forum.de/forum/viewtopic.php?f=19&t=4901 geschimpft hat. Dort gibt es auch einen Demo-Link.
Auch wenn es heutzutage sicherlich deutlich "sophisticatedere" Möglichkeiten gibt, hat mich das damals ziemlich überzeugt. Man konnte mit relativ wenig programmierischem Aufwand neue Funktionen hinzufügen und diese "Widgets" frei auf einem planen Hintergrundbild oder einem Grundriss platzieren. Nun ja, etwas PHP/HTML/CSS-Kenntnisse waren vorausgesetzt. Aber man hatte dann echt bedienbare Ergebnisse, gerade in Verbindung mit einem Tablet.
Und täglich grüßt das Murmeltier...
Ich wünsche bei deinem Plan einer massentauglichen, eierlegenden Wollmichsau viel Erfolg.
Kleiner Tip: Nimm dir nicht zu viel vor.
Ich persönliche fände es sinnvoller, anstatt tatsächlich dem X-ten Frontend mal an der Basis zu arbeiten.
Sehr schöne Entwicklungen in die m.M.n. richtige Richtung finden sich z.B. hier:
http://forum.fhem.de/index.php/topic,28634.0.html
Und noch ein schönes Zitat zum Schluss:
Zitat von: rudolfkoenig am 17 Juni 2014, 07:53:36
Und ueber das Thema "Wieso hat von 30 FHEM-Frontend Projekten keiner es geschafft, alle zu ueberzeugen" koennte man vermutlich eine Diplomarbeit schreiben.
Vielleicht wäre das ja eher was? ;-)
Johannes, da geb ich Dir Recht. Eine vernünftige Schnittstelle ist sicherlich eine der besten Voraussetzugen für ein gutes Frontend. Ich wusste ehrlich gesagt bislang auch gar nicht, dass longpoll so viele Probleme macht (zumindest bei einigen Szenarien) und es bislang die vermeintlich einzige systemweite Möglichkeit ist Stati in RT auszugeben. Aber ich habe mich mit dem "unter der Haube" noch nicht arg beschäftigt.
Nichts desto Trotz fehlt ein Frontend. Und wenn's nur um den WAF geht.
Norbert scheint ja schon was in Richtung websocket auf die Beine gestellt zu haben.
Beides miteinander könnte aber ein allgemeinheitsverträgliches Frontend werden. Und ich persönlich finde den Ansatz eines Framworks nicht schlecht. Damit kann sich jeder "sein" Look&Feel selber zusammenbauen und muss nicht mosern. Geschmäcker sind eben verschieden.
Danke Johannes ;) Die wirds wohl niemals geben. Allerdings habe ich (und mein Kommilitone) uns als Ziel gesetzt, es relativ nahe an Communitywünschen zu entwickeln. Das Projekt wächst dann mit der Zeit, genauso wie die Pensionsverwaltung (also keine Angst - ich bin zuversichtlich, dass wir das durch ziehen weil in dem anderen Projekt stecken auch über 200 unvergütete Arbeitsstunden).
Ich würde mich über Anregungen freuen, welche Funktionalitäten eine GUI mindestens mitbringen müsste damit ihr sie einsetzen würdet (wenn auch nur Anfangs als statistische Übersicht über Sensoren etc.).
An der Basis würde ich etwas ändern, wenn ich Perl programmieren könnte. Mangels Erfahrung in diesem Bereich lasse ich es allerdings und konzentriere mich auf das, was ich am Besten kann. Das schöne ist, dass, selbst wenn sich die Basis ändern sollte, bei diesem Projekt nicht großartige Anpassungen nötig sind damit diese Änderungen unterstützt werden.
So, jetzt erstmal genug geredet und hier mal ein paar erste Screenshots von dem, was wir in 2 Wochen gebastelt haben (editiere ich in den Startpost) :) Ich freue mich über Feedback (der Screenshot mit den Diagrammen ist allerdings nur ein erster Democase - das wird noch erweitert).
Zitat von: tomster am 12 November 2014, 20:27:49
Nichts desto Trotz fehlt ein Frontend.
Allein auf der Homepage von fhem sind 10! Frontends genannt. Und das sind längst nicht alle.
Es ist meiner Meinung nach vergebene Mühe, mit einem neuen Softwarestack zu versuchen wieder alles zu erschlagen.
Ich verstehe auch nicht, und das ist vielleicht das Kernproblem, warum sich hier mal nicht ein paar Leute zusammenraffen können und bestehendes verbessern, statt immer einzeln von vorne anzufangen. Ich habe zig Stunden in das chartingfrontend investiert, von Anfang an offen diskutiert und den Code online gestellt, aber keiner ist mit aufgesprungen. Es liegt wohl am selbstverwirklichungsdrang... :-/
Zitat von: Respig am 12 November 2014, 20:34:44
Ich würde mich über Anregungen freuen, welche Funktionalitäten eine GUI mindestens mitbringen müsste damit ihr sie einsetzen würdet (wenn auch nur Anfangs als statistische Übersicht über Sensoren etc.).
Alles schonmal dagewesenen
http://forum.fhem.de/index.php/topic,12910.0.html
So, der Nörgler ist dann mal raus
Zitat von: Johannes am 12 November 2014, 21:04:38
Ich habe zig Stunden in das chartingfrontend investiert, von Anfang an offen diskutiert und den Code online gestellt, aber keiner ist mit aufgesprungen. Es liegt wohl am selbstverwirklichungsdrang... :-/
Nö, ich vermute, es liegt schlichtweg daran, dass einigen Usern Dinge wie z.B. das Charting im Alltagsgebrauch völlig sekundär sind. Die suchen ein Frontend mit dem sie eine Übersicht über das gesamte System haben, den Springbrunnen und die Gartenbeleuchtung schalten können oder and die Leerzeiten der Mülltonne erinnert werden und dabei per Webcam das Gartentor im Blick haben. Da solche Displays im Haus meist an prominenter Stelle hängen, MUSS das Frontend so gestaltet sein, dass die bessere Hälfte diesen Fremdgegenstand akzeptiert oder zumindest toleriert und - im Extremfall - sogar selbst benutzt. Sei mir nicht bös, aber detailliertere Charts gehören, zumindest in meinem Haushalt, nicht zu den Dingen mit denen ich meine Frau nennenswert beeindrucken kann. Was ich mit den Werten dann abends im stillen Kämmerlein anfange, ist ihr hingegen herzlich egal ;-)
ich erwarte nicht, das du oder sonst jemand den gesamten Beitrag zum chartingfrontend gelesen hat. Aber achte vielleicht mal auf den Titel und lies dir den ersten! Beitrag durch.
Letzten Endes hats am Feedback und der Unterstützung gehapert...
Es hat sich rausgestellt, das den meisten fhem für die wesentlichen Aufgaben eigentlich reicht und das charting am interessantesten war / ist.
Zitat von: Johannes am 12 November 2014, 21:07:45
Alles schonmal dagewesenen
http://forum.fhem.de/index.php/topic,12910.0.html
So, der Nörgler ist dann mal raus
Das Konzept von den Jungs habe ich gesehen ;) Ich bin nämlich an der gleichen Hochschule und ihr Nachfolger. Sorry, aber die beiden dort wollten wirklich ALLES neu machen (die einzige Bibliothek die verwendet werden sollte war jQuery). Sorry, die Lösung war nicht so knorke und auch der Prototyp nicht mMn.
Das ChartingFrontend ist zu technisch, das müsste einfacher werden. Weiterhin fehlt dort die Optimierung für mobile Endgeräte (war auf meinem Tablet nicht nutzbar). Außerdem wird dort eben nur das Charting abgehandelt. Bei YAFF ist das Ziel sämtliche Funktionalitäten in eine optisch ansprechende und minimalistische Oberfläche zu überführen ohne dafür FHEM anfassen zu müssen.
Ich würde gern etwas verbessern, wenn irgendwo eine Basis ist bei der ich der Meinung bin, dass sie in die richtige Richtung geht. Das ist leider niergends der Fall :( Außer bei diesem weiter oben von mir erwähnten und dort ist der existierende Quellcode einfach unglaublich schlecht wart- und erweiterbar meines erachtens nach.
Zitat von: Respig am 12 November 2014, 21:44:19
die einzige Bibliothek die verwendet werden sollte war jQuery
Finde daran nichts verwerflich, im Gegenteil, je weniger Frameworks bzw. libs, desto aufgeräumter.
Ich kann dir jetzt schon verraten, dass du übrigens php nicht brauchst und am besten direkt über Bord werfen solltest.
Schau dir doch mal Extjs 5 examples auf deinem Tablet an, die laufen super.
Die Ziele die du hast hatte ich auch schon. Und Mvc hab ich seit Tag 1 dabei. Vielleicht wär ne Zusammenarbeit sinnvoll? Anstelle von alles von vorne und neu und doppelt machen...
Ich verstehe gar nicht, warum die Plots so wichtig sind.
Im täglichen produktiven Einsatz sind die Anforderungen ganz andere:
- Schalten: Licht, HVAC, Türöffner, Musik, TV
- Überwachen: Haustechnik, Sicherheit, Webcam
- Informieren: Anrufe, Wetter, Fahrplan, Müllkalender
Die Liste kann individuell sehr unterschiedlich sein, aber die meisten nicht programmierenden User brauchen keine Charts. Die wollten mit einem Blick oder Tipp etwas aus der Liste oben erreichen.
Seit ich einen relativ primitiven Floorplan mit drei Seiten gebastelt haben und der auf einem Tablet dargestellt wird ist die Akzeptanz und Nutzung explodiert.
Zum Einrichtung und Warten der fhem Installation reicht die derzeitige Oberfläche. Einen ansprechenden Floorplan zu bauen ist ein bisschen die Reise in die 90er mit Pixelschubsen und so.
Ich denke, dass die Bedienung zweigeteilt sein müsste: eine Wartungsoberfläche und eine saubere Schnittstelle zu einer graphischen Oberfläche, die Dashboard, Floorplan und gutes Design vereint.
Was ich wirklich nicht brauche ist eine weitere Plotlösung.
Herr 3x
Eine weitere Plot Lösung soll es auf jeden Fall nicht werden! Allerdings hätten wir damit angefangen, weil es am einfachsten umsetzbar ist und man so am schnellsten etwas zeigen kann. Es soll definitiv möglich sein auch mit Schaltern etc. Interagieren zu können. So wie du es beschreibt wollen mein Kommilitone und ich es bauen :-)
@Johannes gibt es dein Projekt auf Github? Ich würde mir gerne den Quelltext dazu mal ansehen wollen.
Bzgl. der Bibliotheken muss ich dir wieder sprechen: Es kann auch mit vielen Bibliotheken sehr aufgeräumt sein ;-) Wer Interesse an unserem Quelltext hat kann ihn sich hier gern mal ansehen: https://github.com/developerrespig/YAFF
Der wird dann Stück für Stück erweitert. Nimm es mir nicht übel Johannes, aber ich würde gerne den Versuch hier starten. Falls es nichts wird kann man ja auch nochmal über eine Zusammenarbeit nachdenken. Was ich cool fände wäre wenn ich eventuell Teile deines Quelltextes verwenden könnte sofern ich welche brauche? Das wäre eventuell eine super Hilfe und man könnte so deine Arbeit und unsere irgendwie fusionieren ;-) Den ich finde deins nicht schlecht! Nur empfinde ich es als praktischer eine Anwendung zu bauen welche nur auf die Funktionalitäten von Fhem zugreift und es quasi administriert.
Vielleicht könnte an auch den Floorplan von Herr mit integrieren. Den müsste ich mir dann allerdings auch ersteinmal ansehen :-)
Zitat von: Respig am 12 November 2014, 22:39:21
Vielleicht könnte an auch den Floorplan von Herr mit integrieren. Den müsste ich mir dann allerdings auch ersteinmal ansehen :-)
Schau dir einfach das Floorplan-Modul von fhem an. Das habe ich benutz, dazu etwas css, das Modul Readingsgroup und webviewcontrol auf einem Android-Tablet. Mehr nicht. Das läuft jetzt auch ganz leidlich. Nur jede Änderung, jedes Icon, jede Schriftfarbe ist eben mühsam von Hand zu machen.
Zum Herzeigen ist es aber nicht schön genug. Da gibt es hier bessere Beispiele.
Herr 3x
OK danke Herr :-)
@johannes: vergiss die Frage nach deinem quelltext. Der Link zum Subversion befindet sich ja in deinem Thread ;) sorry.
Zitat von: Respig am 12 November 2014, 22:37:36
Bzgl. der Bibliotheken muss ich dir wieder sprechen: Es kann auch mit vielen Bibliotheken sehr aufgeräumt sein ;-)
Ja, aber ihr setzt ja aktuell schon parallel 2 Backends ein durch PHP und Perl, was meiner Meinung nach unnötig ist. Schreckt auch den Enduser ab, da mehr Abhängigkeiten nachinstalliert werden müssen auf den "leistungsstarken" Raspberrys, die hier gern verwendet werden..
Zitat von: Respig am 12 November 2014, 22:37:36
Nimm es mir nicht übel Johannes, aber ich würde gerne den Versuch hier starten.
Ich habe auch garnichts anderes erwartet
Zitat von: Respig am 12 November 2014, 22:37:36
Was ich cool fände wäre wenn ich eventuell Teile deines Quelltextes verwenden könnte sofern ich welche brauche? Das wäre eventuell eine super Hilfe und man könnte so deine Arbeit und unsere irgendwie fusionieren
Greif zu, ist ja OpenSource
Zitat von: tomster am 12 November 2014, 21:17:38
Nö, ich vermute, es liegt schlichtweg daran, dass einigen Usern Dinge wie z.B. das Charting im Alltagsgebrauch völlig sekundär sind. Die suchen ein Frontend mit dem sie eine Übersicht über das gesamte System haben, den Springbrunnen und die Gartenbeleuchtung schalten können oder and die Leerzeiten der Mülltonne erinnert werden und dabei per Webcam das Gartentor im Blick haben. Da solche Displays im Haus meist an prominenter Stelle hängen, MUSS das Frontend so gestaltet sein, dass die bessere Hälfte diesen Fremdgegenstand akzeptiert oder zumindest toleriert und - im Extremfall - sogar selbst benutzt. Sei mir nicht bös, aber detailliertere Charts gehören, zumindest in meinem Haushalt, nicht zu den Dingen mit denen ich meine Frau nennenswert beeindrucken kann. Was ich mit den Werten dann abends im stillen Kämmerlein anfange, ist ihr hingegen herzlich egal ;-)
Du hast es auf den Punkt gebracht :-)....
So ist es.
Wobei ich meine Frau bereits soweit habe, dass sie sich hin und wieder auch mal die plots ansieht. :D
Zu einem modernen Frontend gehört meiner Meinung nach auch eine gescheite Darstellung der Messwerte. Am besten so, dass man schnell zoomen kann. Meine bessere Hälfte schaut sich die durchaus an.
schöne Grüße
Jo
Hallo zusammen,
ich beschäftige mich seit paar Woche etwas intensiver mit dem Thema FHEM und bin gerade auf der Suche nach einem Frontend für das Tablet an der Wand. Ich bin mal gespannt was ihr da auf die Beine stellt und werde es auf jeden Fall verfolgen.
Als Tipps für die Entwicklung kann ich nur sagen, dass die ganzen Bastlerlösungen schlecht zu bedienen sind und auch von den Nutzern im Haus nicht angenommen werden.
Wenn meine Frau es bedienen kann und auch nutzt(!), dann ist es gut gelungen und ich bin auch zufrieden.
Zitat von: Herr 3x am 12 November 2014, 22:28:06
Ich verstehe gar nicht, warum die Plots so wichtig sind.
Im täglichen produktiven Einsatz sind die Anforderungen ganz andere:
- Schalten: Licht, HVAC, Türöffner, Musik, TV
- Überwachen: Haustechnik, Sicherheit, Webcam
- Informieren: Anrufe, Wetter, Fahrplan, Müllkalender
Das kann ich absolut unterstreichen! Aus keinem anderen Grund möchte ich in der Zukunft FHEM produktiv nutzen.
Beste Grüße
So, ich bins mal wieder und ich bräuchte etwas Hilfe von euch ;) Derzeit gibt es einen Login und ein Dashboard, in dem man sich Widgets hinzufügen und konfigurieren kann (dort werden dann graphische Auswertungen vom jeweiligen Gerät und Messwert erzeugt und angezeigt). Derzeit beschäftige ich mich mit der Implementierung des "Party Modes", d.h., dass bspw. die Temperatur der Thermostate auf einen bestimmten Wert bis zu einem bestimmten Zeitpunkt gesetzt wird (wenn man bspw. in den Urlaub fliegt für 2 Wochen oder übers WE nicht da ist). Um das ganze so allgemeingültig wie möglich zu entwickeln, bräuchte ich von jemandem die Ausgabe von dieser URL (am Besten jemand mit MAX! Geräten ;) Homematic habe ich selbst - ihr müsst bitte noch die IP von eurer FHEM Installation ergänzen):
http://IPVONFHEM:8083/fhem?cmd=jsonlist2&XHR=1
Falls Interesse besteht, könnte ich mal wieder ein paar Screenshots hochladen. Würde mich über eure Unterstützung freuen! :)
Hallo respig,
vergiss jsonlist/jsonlist2!
Bei einer haushaltsüblicher Anzahl von Devices, dauert die Abfrage einfach zu lange. Für ein GUI sind >2Sekunden Responsezeit einfach zuviel.
Mit nur 'list' bist du besser dran. Optimieren kann man das evtl. sogar mit einer Deviceliste und den Readingsnamen als Abfrage-Parameter.
Ich lasse mich natürlich auch gerne eines Besseren überzeugen.
Danke für den Tipp! Das die Laufzeit davon nicht sehr optimal ist, ist mir auch schon aufgefallen. Das jsonlist verwende ich derzeit nur zum fetchen der devices. Ich schaue mir aber auch nochmal deinen Vorschlag bei Gelegenheit an und suche eventuell auch noch nach einer besseren Lösung :) Muss allerdings erstmal Funktionalität rein bekommen und andere Leute außer mir finden, die es verwenden ;D
Ich bins mal wieder mit einer neuen Frage:
Ich versuche derzeit ein neues Widget für das Dashboard zu erstellen, in dem man Räume verwalten kann (also bei der Heizung eine Temperatur einstellen, Steckdosen schalten). Hierfür versuche ich mir bei FHEM mittels "jsonlist2 ROOMS" eine Liste aller Räume zu holen. Dabei bekomme ich folgende Antwort:
{
"Arg":"ROOMS",
"Results": [
],
"totalResultsReturned":1
}
Ist das ein Fehler bei FHEM oder warum kommen bei mir keine Räume zurück? Den Thermostaten sowie der Schaltsteckdose habe ich jedem einen Raum zugeordnet. Die müssten doch dort jetzt auftauchen, richtig?
Und zum Schluss mal noch ein aktueller Stand vom Frontend:
(http://en.zimagez.com/miniature/dashboarddemo120415.png) (http://en.zimagez.com/zimage/dashboarddemo120415.php)
Kurze Frage: besteht hier bei irgendjemandem Interesse oder sollte ich das Thema hier abhaken und nur für mich weiter entwickeln? :)
Hi,
Interesse besteht sicherlich, allerdings, wie von vielen schon erwähnt, ist eine einfache und leicht bedienbare GUI erstmal das, was im Vordergrund stehen sollte. Charting brauch ich selbst auch nur sekundär. Das Frontend, welches mir vom Ansatz (optisch) bisher am besten gefällt ist Hoanoho. Allerdings geht es auch da nur langsam voran, so dass ich befürchte, dass es irgendwann ebenso wie viele andere Versuche im Sande verläuft.
Mein Rat werft alle Ressourcen zusammen und entwickelt an einem Frontend zusammen weiter, dann steigen die Chancen für ein erfolgreiches Projekt. Sobald ich mich besser mit FHEM auskenne, werde ich mich sicher auch anschließen. Kenntnisse in PHP, PERL, Python, CSS, HTML usw. sind vorhanden. Und selbst wenn ich nicht aktiv entwickle, benötigt solch ein Projekt auch Leute zum Testen mich dem nötigen technischen Hintergrund.
Um eine breite Akzeptanz zu schaffen, sollte solch ein Frontend auch für "Laien" mit überschaubarem Aufwand aufzusetzen sein und auf vielen Systemen lauffähig sein. Auf den Raspberry-Support würde ich definitiv großes Augenmerk legen, da wir hier von einer sehr großen Benutzerbasis sprechen. Mit wenig finanziellem Einsatz hat man einen FHEM Server mit geringem Stromverbrauch, der eigentlich alles leisten kann, was die Mehrheit der User auch benötigt/sich vorstellt.
Kontaktiere doch mal die Leute von Hoanoho, die sind über Hilfe sicher dankbar und im Zweifel baust Du eben das Thema Charting direkt mit ein.
VG
F.
Das Projekt Fronthem und SmartVisu stockt in keiner Weise und ist schon so weit entwickelt, dass man es ohne Bedenken und mit vielen Features produktiv einsetzten kann. Das ist auch alles deutlich transparenter als dieses undurchsichte und seltsame Hoanoho Projekt. Ein Klicki Bunti System für alle "Laien" wird es sicher nie aber zumindest nicht so schnell geben. Das macht auch keinen Sinn. Das würde die Flexibilität von FHEM adsbsurdum führen. Etwas Arbeit ist es immer....
Ich wollte niemandem auf den Schlips treten :) Ich denke nur, die Kräfte zu bündeln und in bereits existierende Ansätze zu stecken macht mehr Sinn, als ein weiteres Frontend zu entwickeln. Hoanoho war nur ein Beispiel, das von Dir genannten Projekt ist ebenso geeignet, da schon weit fortgeschritten.
Ein System für Laien muss nicht sein, es würde aber schon reichen, wenn man sich auf einen Aspekt, wie beispielsweise die FHEM Konfiguration beschränken könnte. Erstmal überhaupt ein lauffähiges System zu bekommen, mit dem man dann beginnen kann zu automatisieren, ist eben sehr zeitaufwendig und nicht trivial. Jemand, der nicht unbedingt in der IT zu Hause ist, steht erstmal vor einer großen Herausvorderung.
Fertige Images würden dabei schon enorm helfen.
VG
F.
Naja. FHEMWEb ist soo schlecht auch nicht. Das Aussehen kann man anpassen und es gibt aktuell auch dort eine Entwicklung in Richtung JavaScript, die es zu einem brauchbaren Frontend macht.
Es wird immer mehrere Optionen geben, da jeder seinen eigenen Geschmack und auch andere Bedürfnisse hat. Aus der Erfahrung kann ich nur sagen, dass die Bedienung einfach und intuitiv sein muss, damit der Haussegen nicht schief hängt ;)
Apple macht es vor. Dass selbst meine 2-jährige Tochter schon ein iPhone bedienen kann, zeigt, dass die alles richtig gemacht haben. Wie man dahin kommt ist erstmal egal, micht nervt es aber auch immer wieder, wenn ich was testen will, dass man erstmal Tagelang Dokus wälzen, Abhängigkeiten aulösen und Probleme klären muss, bevor man überhaupt erstmal erste Ergebnisse sieht. Und ich habe jahrelange Erfahrungen im Bereich IT. Ich mag mir nicht vorstellen, wie das jemand ohne den entsprechenden Background hinbekommen soll, ohne beizeiten frustriert aufzugeben.
Deshalb lieber erstmal nur Basics, die aber dafür richtig und für jederman (der sich zumindest damit auf versucht auseinanderzusetzen) nutzbar. Alle aktuellen Ansätze haben alle gemeinsam, dass es immer noch Gefrickel ist, bis man ein funktionierendes System hat. Bitte jetzt nicht in den falschen Hals bekommen, aber genau ist es doch. Schaut Euch mal an, wieviele Schritte notwendig sind bis dahin. Ich weiß nicht wieviele Notizen ich mir schon immer anlegen musste, weil eine Anleitung auf meinem System eben doch nicht 100% funktioniert hat und ich erst herausfinden musste warum.
Das hat mit dem Endergebnis noch nicht einmal was zu tun, welches selbst Top sein kann. Vielleicht nimmt das mal jemand als Anregung mit, ich unterstütze gern, wo ich kann.
PS: Deshalb übrigens vorhin auch der Hinweis zu Hoanoho, dort gibt es zumindest schon fertige Images, mit denen man direkt testen kann, obwohl das Raspberry Image auch defekt war, das aber nur am Rande. Sowas würde ich mir für andere Lösungen auch wünschen.
FHEM ist ein sehr flexibles System ohne jegliche Gängelung und andere Fallstricke für Fortgeschrittene. Das kann nicht so sein, wie ein Apple Klicki Bunti Gängelungssystem. Auch im Hausautomationsbereich gibt es einige Systeme, die einem nicht viel abverlangen. Man muss eben entscheiden, was man möchte. Große Flexibilität und wenig Gängelung (+ keine Cloud, alles in eigener Hand) oder Klicki Bunti und dafür wenig Flexibilität und oft Gängelung und/oder Cloud. Beides geht selten bis gar nicht zusammen. Dass Apple alles richtig gemacht hat, daran aufzuhängen, dass ein Kind das Handy bedienen kann, ist übrigens...sagen wir...komisch gedacht. Hin und wieder lohnt sich ein Blick dahinter. Deine Definition von "Gefrickel" verstehe ich auch nicht wirklich. An Fronthem und SmartVisu ist erstmal nichts "Gefrickel" in dem Sinn, wie ich das Wort verstehe. Das hat alles Hand und Fuß. Es ist eher so, dass man sehr flexibel in der Gestaltung seines Frontends ist. Genau das IST FHEM: Flexibilität. Will man es anders, ist FHEM nicht das Richtige. Das muss man ganz klar so sagen...aber wir sind hier sehr OT und sollten das an der Stelle beenden.
Zur Ursprungsfrage des TE: naja, ich lese hier nicht raus, dass es großes Interesse gibt. Ich konnte hier allerdings auch nicht rauslesen, wo Dein "unique selling point" ist, wie man so schön sagt. Tatsächlich yet another one, ggf. mit einfacher Nutzerverwaltung.
Off-/Neartopic:
Ich persönlich hab nun schon bissl was durch, mit fhemweb begonnen, Dashboard ausprobiert, viel mit Floorplan gemacht. Hat alles irgendwo seine Berechtigung. Ein interessanter Ansatz ist die neue TabletUI - da kriegt man mit wenig Aufwand und wenig Kenntnissen schon was echt Schönes hin, ich glaube, das wird meine erste Produktivoberfläche werden (weil das, was ich so in Floorplan mache, einfach viel zu bunt und hässlich ist - das bietet zu viel Freiraum für meine Designfähigkeiten). Wenn ich dann mehr will, schaue ich mir den SmartVisu Ansatz an - das hat m.E. viel Potential. Charting ist eher was für die Erfahrenen, am Anfang will man ja erstmal Licht, Rollo, Musik schalten können.
Mit Hoanoho (oder so) bin ich nicht warmgeworden, irgendwie: entweder es geht gut oder es geht gar nicht, zwischendrin gibts nix; mag ein valider Ansatz sein, wenn ich HW&SW im Paket weitervertickern will, geht aber m.E. in Richtung geschlossenes System, was FHEM ja eben nicht sein soll.
Was ja wirklich mal gut wäre, wäre ein FHEM-GUI-Einsteiger-pdf - eine kurze Beleuchtung der verschiedenen GUI-Ansätze: Architektur, Features, benötigte Vorkenntnisse, was geht/was nicht, Beispiele, etc.
Mutmaßlich entstehen viele GUI-Totgeburten hier aus einer Denke "das gefällt mir nicht, das mach ich mal selber komplett anders mit der Programmiersprache, die ich beherrsche". Ein paar dieser Ansätze könnte man m.E. schon vermeiden.
Danke erstmal für das Feedback. Ich nehme das alles erstmal so mit und werde die Entwicklung vorwärts treiben und melde mich erst wieder, wenn ordentlich Funktionalität vorhanden ist.
Die USP meiner GUI wären die folgenden:
- Läuft Out of the Box
- geringer Konfigurationsaufwand (Großteil wird über ein geführtes Setup erledigt - somit Einsteigerfreundlich (FHEM muss trotzdem noch konfiguriert werden - allerdings beschränkt sich das Ganze dann auf das hinzufügen von Geräten))
- Responsive Design (sieht überall gut aus, egal ob Tablet, PC oder Smartphone)
- Bequemes Steuern von Heizungen sowie Funksteckdosen
- Visualisierung von Messdaten
Wäre das erstmal was, wo sich jemand bereit erklären würde, es dann mit mir zusammen zu testen und weiterzuentwickeln oder ist es dann noch immer "uninteressant"?
Meine Gründe warum ich bei Hoanoho (oder so @Doggiebert ;)) nicht mitarbeiten möchte, hatte ich schon früher erläutert.
Bei zwei Kleinkindern und einem anstehenden Bauprojekt fehlt mir zum Entwickeln momentan einfach die Zeit. Testen sehr gern, da ich immer noch die für mich passende Lösung suche.