Umfrage
Frage:
Welches Frontend setzt ihr ein?
Antwort 1: FHEMWEB plain
Stimmen: 27
Antwort 2: RSS
Stimmen: 0
Antwort 3: TabletUI
Stimmen: 35
Antwort 4: SmartVisu
Stimmen: 12
Antwort 5: Dashboard
Stimmen: 1
Antwort 6: YAF - Yet Another Floorplan
Stimmen: 0
Antwort 7: Sonstiges
Stimmen: 2
Antwort 8: Floorplan
Stimmen: 6
Antwort 9: Info Panel
Stimmen: 0
Antwort 10: Kein Frontend
Stimmen: 3
Hallo,
ich eröffne hier mal eine Umfrage bezüglich der von euch verwendeten Frontends.
Die mobilen Varianten habe ich bewusst außen vorgelassen.
Sollte ich dennoch das ein oder andere Frontend übersehen und vergessen haben, so lasst es mich wissen.
Ich denke aber schon, die gebräuchlichsten Varianten aufgelistet zu haben.
Viele Grüße!
FHEMWEB is nicht praezise, ich wuerde stattdessen "FHEMWEB plain" schreiben, da Dashboard ja auch Teil von FHEMWEB ist. Und FLOORPLAN (fehlt uebrigens in der Liste) auch. Und was ist, wenn man mehrere verwendet? InfoPanel fehlt auch.
Und was ist eigentlich der Sinn dieser Umfrage?
"gar kein grafisches Frontend" fehlt übrigens auch.
In der Tat, Floorplan hatt ich total übersehen. Danke für den Hinweis! :)
Der Sinn dahinter ist es einfach mal ganz platt zu erfahren, welches Frontend ihr so benutzt. Also nix Wildes! ;-)
Und wie gewünscht werde ich natürlich auch noch 'Kein Frontend' hinzufügen.
Nutzt wirklich jemand *kein* Frontend? Würde ja bedeuten er bedient ausschließlich über Telnet?!?
Ich nutze durchaus mehrere Frontends parallel.
Das lässt Auswahl leider auch nicht zu. :-\
Warum schaust Du Dir nicht einfach die FHEM Statistiken unter https://forum.fhem.de/index.php/board,11.0.html (https://forum.fhem.de/index.php/board,11.0.html) an? Die Mengen dort sind sicher aussagekräftiger als eine Umfrage wo nur ein paar wenige teilnehmen ;)
Viele Grüße
Klaus
PS: Ich nutze übrigens Floorplan und RSS und das könnte ich bei Deiner Umfrage gar nicht beides ankreuzen 8)
Ja, ja, die liebe Mehrfachauswahl. ;-) Wäre sicher auch eine zusätzliche Option gewesen, lässt sich im Nachhinein aber leider nicht mehr ändern. :-(
Und vielen Dank für den Verweis auf die Statistik. Die ist ganz sicher aussagekräftiger als meine hier im kleinen Kreis. ;-)
Zitat von: Tedious am 07 April 2016, 15:34:18
Nutzt wirklich jemand *kein* Frontend? Würde ja bedeuten er bedient ausschließlich über Telnet?!?
Es gibt sogar Leute, die ein fhem überhaupt nicht bedienen
müssen, weil es nach erfolgter Konfiguration einfach komplett autark und stabil läuft und keinerlei weitere Eingriffe notwendig sind.
Zitat von: MrMaxy am 07 April 2016, 15:43:41
Ja, ja, die liebe Mehrfachauswahl.
Es gibt auch Abhängigkeiten. Zum Beispiel läßt sich RSS oder InfoPanel überhaupt nicht ohne FHEMWEB betreiben.
Ich halte die Umfrage nach wie vor für ziemlich sinnfrei.
Als Nutzer von FHEM nutze ich bspw. kein Frontend. Eine Haussteuerung in der ich manuell eingreifen muss ist meiner Meinung nach nicht optimal auf die eigenen Bedürfnisse ausgerichtet.
Als Entwickler wiederum nutze ich FHEMWEB plain als Frontend um Modulfunktionen einfacher testen zu können.
Just my two cents.
Gruß
Markus
Da stimme ich voll zu: Haussteuerung muss optimalerweise zu 99% automatisch funktionieren und an die individuellen Bedürfnisse angepasst sein.
Nur ist ein UI nicht nur zur Steuerung, sondern auch zur Visualisierung des Systems gedacht:
- "haben die Kinder das Licht ausgemacht, bevor sie hier vorm Fernseher sitzen"
- "okay, ich habe das Fenster im Schlafzimmer aufgemacht"
- "oh je, draussen sind heute morgen nur 4°C, muss ich doch die dicke Jacke anziehen"
- "Lohnt es sich jetzt noch Rasen zu gießen, oder regnet es morgen" (eine vollautomatische Rasenbewässerung ist (noch) nicht vorhanden ;-)
Auch Steuern kann man so einiges noch, manuell, weil spontan und unvorhersehbar:
- starten der italienischen Dinnermusik Playlist
- Musik etwas leiser machen
- Radio Senderwechsel
- Bad oben auf 25°C stellen, für die Wellness Session später
- letzter Check vor dem Urlaub -> Ok alles passt -> Homestatus: "Urlaub" -> Tür zu
Für die Anzahl der Schalter an der Wand gilt ja auch, je weniger, desto besser. Deshalb habe ich lieber 1-2 schmucke Tablets an der Wand zum zentralen Steuern und Visualisieren. -> TabletUI
Zum Einrichten des Systems und Definition der Steuerungslogik ist FHEMWEB ideal.
kannst doch einfach auch alles automatisieren wie es das system hergibt und dich dann nach der automatisierung richten.
dann gehts halt ins bett wenn fhem das licht und den tv aus macht und nicht erstspäter als sonst nur weil du fhem nicht gesagt hast das du morgen daheim bleibst ;)
Zitat von: betateilchen am 07 April 2016, 20:26:48
Es gibt sogar Leute, die ein fhem überhaupt nicht bedienen müssen, weil es nach erfolgter Konfiguration einfach komplett autark und stabil läuft und keinerlei weitere Eingriffe notwendig sind.
Frontend != zwang zur bedienung / umkonfiguration
Sehe ich auch so. Klar, "Komfortfunktionen" automatisiert man, gibt aber 100 Dinge für die ich das Frontend benutze. Sei es wie angesprochen um zu schauen wie warm/kalt es ist, um direkt beim heimkommen zu erkennen ob jemand angerufen hat, etc...
setstates ist mit seinem TabletUI denke ich auf dem richtigen Weg der Bedienung von FHEM ein intuitives und zeitgemässes Gesicht zu geben.
Traditionell ist die Entwicklergemeinde von FHEM eher Kommandozeilen und Techniklastig.
Das gute daran ist, wir haben eine sehr robuste und schlanke Perl-"Engine" als Basis.
Die nur für eingefleischte Terminal-User einleuchtende Bedienung über Kommandozeileneingabe oben rechts neben dem Fhem-Logo, Edit files und Save config im Menu links ist hat eine gute und eine schlechte Seite:
Die gute Seite: Die Entwicklergemeinde bleibt klein und den Profis vorenthalten die sich etwas intensiver damit befassen. das ganze bleibt kommerzentkoppelt und offen.
Die negative Seite davon ist, das dieses System einen visuellen Anwender wie mich zum verzweifeln bringen kann: Tausendmal Änderungen nicht abgespeichert z.B. (dieser Mechanismus mit saveconfig und shutdown restart entzieht sich meinem logischen Verständniss) Wer mit dem Internet gross geworden ist kann sich an die Zeiten erinnern als die Formular-Eingabefelder für das Datum Eingaben in der Form: 2016/04/17 verlangten. Einmal 17.4.2016 eingegeben und die ganze HTML Seite wurde nach der Formularprüfung neu Aufgebaut und das ganze Formular damit gelöscht mit einem Hinweis auf der Seite: Hallo Du Vollidiot von Anwender gib bitte das Datum Korrekt ein. Was genau mit Korrekt gemeint war (Dem Programmierer Sonnenklar) entzog sich meinem Verständniss. Ich habe darauf in den 90'ern angefangen Benutzerschnittstellen für Multimedia-Anwendungen zu Entwickeln. Die ganze Entwicklung der Applikations und Web-Interfaces mitgemacht, von Macromedia Director über Shockwave, Flash bis HTML5 heute.
Ich staune selber wie intuitiv die Handy-Apps heute sind und wie rasant sich alles Entwickelt. Ich bin selber heute nicht mehr so aktiv dabei, ist ein spannendes Hobby geworden.
Zu FHEM:
Ich habe die diversen Ansätze eine GUI zu entwickeln alle grob mitverfolgt. Es sind ein paar gute Ansätze dabei, aber bis jetzt hat sich keine so wirklich durchgesetzt.
Ich hoffe die TabletUI wird nicht das gleiche Schicksal haben.
Ich habe mich gerade etwas damit befasst und mir ist folgendes aufgefallen:
FHEMWEB: Das Standard Web-UI für FHEM (auch pgm2 genannt... nur Historiker blicken hier durch... pgm345.. auf der Strecke geblieben.) hat eine Möglichkeit genannt widgetoverride und die Möglichkeit eigene Stylesheets zu verwenden. Das könnte man eventuell als Updatepfad ausbauen.
Dabei sollte die einfachste Variante möglichst gar keine CSS-Styles und JS-Libraries laden. Für Puristen und schlanke schnelle Anwendungen die ohne GUI auskommen. cfg Dateien bearbeiten und numerische Daten der Geräte anzeigen reicht hier.
Tablet-UI
Guter Ansatz, aber auch hier gibt es einen grossen Haken der eine Weiterentwicklung hindern könnte: Die Verwendung der gridster Library.
Wesshalb mir das so bedeutend erscheint: gridster wird nicht weiterentwickelt, es gibt aber einen freien Nachfolger auf github: gridstack
Das entscheidende an der Weiterentwicklung ist, dass dieses Grid responsive ist. Die Element-Grössen und -Anordnung passen sich an das Medium wie Monitor, Tablet oder Handy an. Das ideale GUI MUSS dies können. Damit hätten wir dann ein GUI für alles, keine Handy-App mehr nötig usw.
( Einzig für die digitalen Bilderrahmen müsste noch ein "Standbild"-Output realisiert werden, wie es aktuell mit dem RSS Hilfsmodul generiert wird)
Wird hier in der Diskussion gerade etwas sinnlos um den Begriff "Haussteuerung" herumdiskutiert? (Also ist das jetzt nur der Automat der die Heizung bei unter 20 Grad einschaltet, einmal Programmiert und auf den Chip geladen, das wars. Oder doch eher das Panel an der Wand das mir neben Wetter, Regen -Fenster zu, Zeit und dem Song der gerade läuft auch noch die Anzahl unbeantworteter Mails oder von mir aus die Facebook-Likes der aktuellen Stunde anzeigt)
Das es eine grafische intuitive Oberfläche für Bedien-Komfort und Übersicht braucht ist Sonnenklar. Ein Bild sagt mehr als tausend Worte (oder tausend quadratzeilen Tabelle)
Die robuste, schlanke Perl-Basis von FHEM vom individuell (nach Bedarf und Geschmack) zuschaltbaren Frontend zu trennen macht Sinn.
Ich bin dafür den Ansatz von setstate weiterzuverfolgen.
ZitatBedienung über Kommandozeileneingabe oben rechts neben dem Fhem-Logo, Edit files und Save config im Menu links
Das ist fuer solche Konfigurationsaenderungen vorgesehen, die sonst nicht grafisch abgedeckt sind, und fuer Kenner, die es so schneller eingeben koennen bzw. anderen einfacher beschreiben koennen. Wie koennte man sowas besser implementieren?
ZitatDas es eine grafische intuitive Oberfläche für Bedien-Komfort und Übersicht braucht ist Sonnenklar.
Ich glaube nicht, dass _eine_ Oberflaeche alle Anforderungen gut erfuellen kann, meine waeren z.Bsp:
- Perfekt in allen Szenarien: FHEM-Konfiguration, -Debugging, Anzeige und Bedienung der FHEM-Komponente.
- Passt zum UI und Bedienungskonzept der gerade verwendeten OS, und das auf allen Mobil- und Desktop-Betriebsystemen.
- Laeuft als Native-, Bildschirmschoner- oder Desktophintergrund-App, ueber Browser, Messanger, Telnet/SSH
- Ist behindertengerecht, mehrsprachig, bedienbar ueber Siri/Alexa/etc.
- Optimal fuer alle FHEM-Module, auch fuer die, die nach Fertigstellen des Frontends gebaut werden.
- Der Benutzer benoetigt keine Konfigurationsarbeit/Programmierung fuer das Frontend.
- Intuitiv fuer Anfaenger, effizient fuer Experten.
FHEMWEB/FTUI/etc deckt einen Teil der Anforderungen ab, und das auch nicht perfekt.
Die, die andere Prioritaeten haben, fangen mit einem neuen Frontend an, und das ist auch gut. :)
Zitat von: rudolfkoenig am 17 April 2016, 08:28:23
Ich glaube nicht, dass _eine_ Oberflaeche alle Anforderungen gut erfuellen kann, meine waeren z.Bsp:
- Perfekt in allen Szenarien: FHEM-Konfiguration, -Debugging, Anzeige und Bedienung der FHEM-Komponente.
- Passt zum UI und Bedienungskonzept der gerade verwendeten OS, und das auf allen Mobil- und Desktop-Betriebsystemen.
- Laeuft als Native-, Bildschirmschoner- oder Desktophintergrund-App, ueber Browser, Messanger, Telnet/SSH
- Ist behindertengerecht, mehrsprachig, bedienbar ueber Siri/Alexa/etc.
- Optimal fuer alle FHEM-Module, auch fuer die, die nach Fertigstellen des Frontends gebaut werden.
- Der Benutzer benoetigt keine Konfigurationsarbeit/Programmierung fuer das Frontend.
- Intuitiv fuer Anfaenger, effizient fuer Experten.
Damit hätten wir dann die ultimativ eierlegende Wollmilchsau definiert ;) :D
...und ja, leider gibt es aber grade einen für mich langsam völlig unübersichtlichen Frontendwildwuchs mit vielen guten Ansätzen: Floorplan, Dashboard, Webview, SmartVisu, das Chartfrontend, TabletUI undundund.
Ich persönlich würde es gerne sehen, wenn sich der TabletUI Ansatz weiterentwickelt. Die Beliebtheit des TabletUI ist für mich einfach zu erklären und liegt im einfach gehaltenen und Begleiteten Einstieg für Anfänger:
ZitatInstall
-------
* copy the whole tree into the corresponding folder of your FHEM server /\<fhem-path\>/www/tablet
* add 'define TABLETUI HTTPSRV ftui/ ./www/tablet/ Tablet-UI' in fhem.cfg
* rename the index-example.html to index.html or create your own index.html
* Tadaaa! A new fhem ui in http://\<fhem-url\>:8083/fhem/ftui/
...Drei Schritte und wie vom Entwickler versprochenen "Tadaa", der Einsteiger hat erst mal ein Erfolgserlebniss :)
So sollte das GUI-Konzept weitergedacht werden.
Zu der konkreten Frage betreffend Kommandozeile oben im FHEMWEB:
Viel braucht es nicht, aber zur Hilfe für Einsteiger könnte so etwas in der fhem.cfg helfen, wobei die Terminal-Eingabe-Zeile auch das Kommandozeilen-Eingabefeld im 01_FHEMWEB.pm ersetzen könnte:
Das Eigabefeld ist ein schnörkelloses HTML5 Input mit Datalist Feld, damit lässt sich ein "freies" Eingabefeld mit einer Auswahlliste verbinden. Perfekt um möglichst flexibel alle Eingaben zu ermöglichen und gleichzeitig zu erlauben aus einer Liste auszuwählen. Diese Kombination könnte in allen Eingabefeldern auch speziell für attribute verwendet werden. ( Die Werte der Optionsfelder werden mit Json Werten befüllt PossibleSets,PossibleAttrs) In vielen Konfigurations-Bereichen im fhemweb sind ja Dropdown-Auswahlmenues bereits vorhanden. Was mir sehr entgegen kommt.
(https://forum.fhem.de/index.php?action=dlattach;topic=51891.0;attach=50723;image)
(Für cmd Profis die automatisch nach jeder Eingabe auf Enter klicken mag der "Ausführen" Button lächerlich erscheinen, genauso wie dem Unerfahrenen ein leeres Eingabefeld (huuh, was soll ich damit?)
define BeginnersTutorial weblink htmlCode <hr>\
Erste Schritte mit FHEM\
<hr>\
<form method="post" action="/fhem" style="display:inline">\
Befehl eingeben:\
<input name="cmd" class"maininput" list="cmd">\
<datalist id="cmd">\
<option value="update+check"> \
<option value="version"> \
<option value="list"> \
<option value="JsonList2">\
<option value="xmllist"> \
<option value="backup"> \
<option value="reload ..."> \
</datalist> \
<input type="submit" value="Ausführen" >\
</form> ; ; ; ; ; \
<form method="post" action="/fhem?cmd=save" style="display:inline"><button type="submit">Konfiguration sichern</button></form>\
<form method="post" action="/fhem?cmd=shutdown+restart" style="display:inline"><button type="submit">Neustarten um Änderungen anzuzeigen</button></form>\
; ; ; ; ;\
<form method="post" action="/fhem?cmd=help" style="display:inline"><button type="submit">FHEM Befehlsübersicht</button></form>\
<form method="post" action="/fhem?cmd=update" style="display:inline"><button type="submit">FHEM Update</button></form>\
<hr>\
Wo finde ich Hilfe?\
<select onChange="window.location.href=this.value">\
<option value="http://fhem.de/HOWTO_DE.html">Mit FHEM beginnen</option>\
<option value="http://www.fhemwiki.de/wiki/Erste_Schritte_in_fhem">Wiki: Erste Schritte in FHEM</option>\
<option value="http://www.fhemwiki.de/wiki/Kategorie:HOWTOS">Wiki: How to?</option>\
<option value="http://fhem.de/faq.html">FAQ</option>\
<option value="http://fhem.de/commandref.html">FHEM Befehle und Geräte</option>\
<option value="http://www.fhemwiki.de/wiki/Hauptseite">Wiki</option>\
<option value="http://www.fhemwiki.de/wiki/Kategorie:Code_Snippets">Wiki: Code Snippets</option>\
<option value="http://www.fhemwiki.de/wiki/Kategorie:Examples">Wiki: Beispiele</option>\
<option value="http://www.fhemwiki.de/wiki/Anwendungsszenarien">Wiki: Anwendungsszenarien</option>\
<option value="https://forum.fhem.de/index.php">Das FHEM Forum!</option>\
</select>\
<hr>
attr BeginnersTutorial room Einfuehrung in Fhem
Die Hilfe ist ein normales klassisches Auswahlfeld ohne Möglichkeit der freien Eingabe und dient nur dazu die FHEM-Einsteiger Seite mit der Benutzerfreundlichen Kommandozeileneingabe noch zu ergänzen
Für Interessierte: Zum Testen den Code einfach in die fhem.cfg kopieren
(https://forum.fhem.de/index.php?action=dlattach;topic=51891.0;attach=50725;image)
Zitat von: Klaus Rubik am 07 April 2016, 15:38:44
Warum schaust Du Dir nicht einfach die FHEM Statistiken unter https://forum.fhem.de/index.php/board,11.0.html (https://forum.fhem.de/index.php/board,11.0.html) an?
Vermutlich, weil er darüber als mehr oder weniger FHEM-Neuling (Mit ein paar mehr Post's als ich) noch gar nicht gestolpert ist. Was leider sehr Schade ist für FHEM, da gibt es so viele tolle Möglichkeiten, aber man muss sie eben erst mal entdecken in der Masse.