[Analyse] Anforderungen an eine moderne GUI

[FS_Frank]

Sehr geehrte Damen und Herren, liebe FHEM-Gemeinde,

-----------------
Aktueller Stand [27.01.2014]:

Das Forschungsseminar Sensornetze endet für mich und Rick am 30.01.2014. Es war ein sehr ereignisreiches Jahr und ich möchte der gesamten FHEM-Community für ihre Beiträge danken. Wie versprochen stellen wir unsere Erkenntnisse diesbezüglich nun online und machen sie damit frei zugänglich:
http://www2.htw-dresden.de/~wiki_sn/images/b/b8/Forschungsbericht_Sensornetze_WS_2013_14_Web_Frontend.pdf

Das primäre Ziel für euch war es, eine umfassende Anforderungsanalyse für eine moderne GUI zu entwerfen. Diese Anforderungsanalyse haben wir geschaffen und ich hoffe, dass vielleicht dem Einen oder Anderen geholfen wurde.

In unserem Forschungsseminar selbst haben wir natürlich noch viel mehr erreicht. In unserer Gruppe ist es uns gelungen, einen OpenHardware-Sensor selbst mit Contiki zu steuern und zu programmieren, sowie diesen Sensor via CoAP mit dem FHEM-Server und am Ende mit unserem eigenen Web Frontend zu verbinden und zu steuern. Es ist wirklich spannend gewesen, wie von OSI Schicht 7 bis zur 1 herunter nun alles funktioniert.

Nach uns werden natürlich weitere Studenten in diesem Forschungsseminar weiterarbeiten und vor allem das Web Frontend weiter ausbauen. Laut unseren Schätzungen müssten nachfolgende Studenten noch ein ganzes Forschungsjahr anfügen, bis man es der Öffentlichkeit zeigen kann. Es wäre natürlich auch ein künftiges Ziel von uns, dann ein schönes Web Frontend als Beispiel, was man aus den Anforderungen alles erstellen kann, zu zeigen.

-----------------

Ich (Frank) und mein Kommilitone (Rick) sind momentan im Rahmen eines Forschungsseminares an der Hochschule für Technik und Wirtschaft in Dresden tätig. Unser Themengebiet erstreckt sich weit in die Hausautomatisierung und Sensornetze hinein. Wir verwenden momentan den FHEM-Server und möchten uns da direkt an die Community wenden.

Ich und mein Kommilitone haben die Aufgabe, eine Anforderungsanalyse an eine moderne GUI/Frontend für Hausautomatisierung aufzustellen und danach eine prototypische Implementierung anzustreben, die von unseren Nachfolgern oder vielleicht sogar der FHEM-Community fortgeführt werden kann.

Kurz eine (umgangssprachliche) Erklärung für jene, die nicht wissen, was eine Anforderungsanalyse ist:

Mithilfe einer Anforderungsanalyse  notiert man Anforderungen (z.B. ,,Heizungen sollen bei Sensorwertänderungen gesteuert werden können"), die es später ermöglichen, eine Anwendung zu planen, die auch nachhaltig und langfristig die Erwartungen des Nutzers erfüllen und damit möglichst viel an gewünschter Funktionalität abgedeckt ist.

Da ich bisher auch nach kurzer Suche im FHEM-Forum keine bisher umfassend aufgestellte Anforderungsanalyse gefunden habe (sollte es eine geben, wäre ich über einen Hinweis/Link dankbar), möchte ich hier nun darum bitten, dass wir zusammen Anforderungen an eine (in euren Augen) moderne GUI und ihre Funktionalität sammeln.

Das Ziel ist es, dass wir dann auch diesen Anforderungskatalog (sobald wir genug gesammelt haben) der FHEM-Community in die Hand reichen, damit auch zukünftige Entwickler von Frontends/GUIs es leichter haben, etwas für die FHEM-Community zu entwickeln.

Ich würde daher bitten, dass ihr einfach schreibt, wozu ihr eine Hausautomatisierung im Allgemeinen nutzt und was ihr euch da im Frontend wünschen würdet.

Beispiel:

Ich möchte im Rahmen der Hausautomatisierung eine bewegungsmelder- und zeitgesteuerte Schaltung meiner Lichter nutzen (oder nutze sie bereits), daher sollte auch im Frontend/GUI für mich möglich sein, Regeln für die Lichtsteuerung aufzustellen oder eine manuelle Steuerung der Lampen durchführen zu können.

Sollte es Fragen oder Anregungen geben, ich schaue regelmäßig im Forum vorbei und danke jetzt bereits für jeden konstruktiven Beitrag in diesem Thema, da es uns sehr weiterhelfen würde, wenn sich hieran mehrere Personen aktiv beteiligen würden.

Mit freundlichen Grüßen,
Frank

[Rince]

Entschuldige, ich bin vermutlich der, der am wenigsten Ahnung von FHEM hat :-[

Meinst du mit GUI die Bedienung des Systems, oder die Programmierung?

Das sind meiner Meinung nach verschiedene Baustellen.

Bedienen läßt sich eine Haussteuerung wohl am einfachsten über Sprache.
Oder per Tab.

Programmieren oder Skripte schreiben ist doch eher was für Geräte mit Maus und Tastatur. Ergo: verschiedene Aufgaben, verschiedene optimale Userinterfaces.

Was ich cool fände für die Programmierung, wäre eine grafische. Wo man wie bei einem Puzzle Sachen zusammen stecken kann.

Icon für ne Lampe, daran angedockt Icons mit den Events, die diese Lampe an oder aus machen. Dann ein Icon für nen einstellbaren Timer dranschieben, und ein Icon was noch alles passieren soll. Z.B. was anderes informieren.


Für die Benutzung sieht es anders aus. Der Floorplan ist ein schönes Beispiel.

Auf jeden Fall sollte das Userinterface User unterscheiden können. Mein Einbrecher soll weniger Rechte haben als ich.

Außerdem sollte es auf Informationen schnell reagieren können. Wenn ich an mein Tab gehe weil eine Alarmmeldung kam, hätte ich gerne gleich die Sensordaten und das Kamerabild, ohne erst such zu müssen wo das jetzt war.

[rudolfkoenig]

>  Was ich cool fände für die Programmierung, wäre eine grafische. Wo man wie bei einem Puzzle Sachen zusammen stecken kann.

Sowas ist toll fuer Anfaenger, die eine einfache Aufgabe loesen muessen. Und es nervt tierisch jeden mit Erfahrung, insb. wenn die zu loesende Aufgabe komplex ist, ich spreche hier aus Erfahrung.

Ich will damit sagen, dass ich Rince nicht nur Recht gebe, sondern seine Vorstellung um eine weitere Dimension erweitern will: nicht nur je nach Aufgabe, sondern auch je nach Erfahrung braucht man unterschiedliche Frontends. Und vmtl. auch je nach Geschmack, usw.

Ich habe gehoert, auch bei den Autos gibt es mehrere Modelle, um die gleichen Probleme zu loesen :)

[FS_Frank]

Guten Tag allerseits :)

Entschuldige, ich bin vermutlich der, der am wenigsten Ahnung von FHEM hat :-[

Meinst du mit GUI die Bedienung des Systems, oder die Programmierung?

Das sind meiner Meinung nach verschiedene Baustellen.

Bedienen läßt sich eine Haussteuerung wohl am einfachsten über Sprache.
Oder per Tab.

Programmieren oder Skripte schreiben ist doch eher was für Geräte mit Maus und Tastatur. Ergo: verschiedene Aufgaben, verschiedene optimale Userinterfaces.

Was ich cool fände für die Programmierung, wäre eine grafische. Wo man wie bei einem Puzzle Sachen zusammen stecken kann.

Icon für ne Lampe, daran angedockt Icons mit den Events, die diese Lampe an oder aus machen. Dann ein Icon für nen einstellbaren Timer dranschieben, und ein Icon was noch alles passieren soll. Z.B. was anderes informieren.


Für die Benutzung sieht es anders aus. Der Floorplan ist ein schönes Beispiel.

Auf jeden Fall sollte das Userinterface User unterscheiden können. Mein Einbrecher soll weniger Rechte haben als ich.

Außerdem sollte es auf Informationen schnell reagieren können. Wenn ich an mein Tab gehe weil eine Alarmmeldung kam, hätte ich gerne gleich die Sensordaten und das Kamerabild, ohne erst such zu müssen wo das jetzt war.

Vielen Dank für deine Rückmeldung! Wir meinen bei uns tatsächlich die Bedienung des Systems bzw. den Aufbau der GUI, so wie man es sich als 'Nutzer' (und da gibt es durchaus erfahrene und unerfahrene Personen) vorstellt.

Diese grafische Programmierung erinnert mich ein wenig an das System von RWE - meinst du so etwas?

http://www.youtube.com/watch?v=84RRXyy-AkE
(ab Sekunde 40)

=> Das ist etwas, was ich mir durchaus für den programmierunerfahrenen Nutzer vorstellen kann, quasi als  'Massenlösung' und was eine Ausprägung des Interface sein kann.

Das mit der Rechteverwaltung werden wir auch mit aufnehmen. Es macht zum Beispiel viel Sinn einen Nutzer als Admin mit besonderen Rechten auszustatten und einen normalen Nutzer zu haben, damit wenn zum Beispiel bei einem Haus mit Familie die Kinder auch mal wild auf dem Tablet herumdrücken können, ohne gleich (überspitzt formuliert) alles zu zerstören.

>  Was ich cool fände für die Programmierung, wäre eine grafische. Wo man wie bei einem Puzzle Sachen zusammen stecken kann.

Sowas ist toll fuer Anfaenger, die eine einfache Aufgabe loesen muessen. Und es nervt tierisch jeden mit Erfahrung, insb. wenn die zu loesende Aufgabe komplex ist, ich spreche hier aus Erfahrung.

Ich will damit sagen, dass ich Rince nicht nur Recht gebe, sondern seine Vorstellung um eine weitere Dimension erweitern will: nicht nur je nach Aufgabe, sondern auch je nach Erfahrung braucht man unterschiedliche Frontends. Und vmtl. auch je nach Geschmack, usw.

Ich habe gehoert, auch bei den Autos gibt es mehrere Modelle, um die gleichen Probleme zu loesen :)

Auch vielen Dank für ihre (deine?) Rückmeldung vom Entwickler persönlich ;)
=> Auch ich kenne aus verschiedenen Systemen aus Erfahrung, dass eine rein grafische Programmierung für den sehr erfahrenen Nutzer durchaus nervig sein kann. Man muss da vielleicht auch einfach zwischen einem Status 'Alltag' (im Sinne von: Nutzer kommt nach Hause und möchte unabhängig von einer bestehenden Regelverarbeitung gerade manuell Heizung/Licht im Haus steuern) und einen Status für 'Konfigurieren', wo man ja prinzipiell seltener drin ist, wo dann neben der bekannten Kommandozeile und je nach Erfahrung des Nutzers etwas möglich ist.

Wir werden das auf jeden Fall mit aufnehmen, schon einmal vielen Dank :)

Mit besten Grüßen,
Frank

[FS_Frank]

Wir haben nun momentan mithilfe von Gesprächen mit anderen Personen, Zeitungsartikeln, Fernsehsendungen und Internetseiten eine Analyse der funktionalen sowie nichtfunktionalen Anforderungen begonnen. Neben einer Risikoanalyse und beispielhaften, textuell beschriebenen Anwendungsfällen haben wir auch allgemeine, funktionale Anforderungen für ein Web Frontend im Bereich der Hausautomatisierung abstrahiert.

Sollte jemand diese Anforderungen brauchen oder verwerten, kann er sich den Forschungsbericht der Teilgruppe 'Web Frontend' im Forschungsseminar Sensornetze (Sommersemester 2013) von der HTW Dresden ansehen:

http://www2.htw-dresden.de/~wiki_sn/images/b/ba/Forschungsbericht_Sensornetze_SS_2013_Web_Frontend.pdf

Dabei wären die Anforderungen als komplette Tabelle im Anhang zu finden, eine Erklärung unserer Vorgehensweise und Analyse (die auch auf die Erstellung eines eigenen Web Frontend abzielt) kann man dort ebenso finden.

Sollte es bei den Anforderungen noch Ergänzungen oder Ideen geben, sind wir natürlich gerne für Diskussionen offen.

Mit besten Grüßen,
Frank

[Johannes]

Hallo,

Es freut mich zu sehen, dass immer wieder an Webfrontends zu FHEM gearbeitet wird.
Was ich leider unschön finde ist, dass es mittlerweile viele verschiedene und gute Ansätze gibt, sich aber leider nichts langfristiges und durch die Community unterstütztes daraus ergibt bzw. etabliert.
Es gäbe zum Beispiel noch den YAF (Yet another Floorplan), der einen ähnlichen Ansatz fährt (habe ich glaube ich in eurem Paper nichts drüber gelesen). Oder der Java / Vaadin Ansatz (Link). Oder aber auch wie in eurem Text erwähnt das "Charting Frontend". Ich bin, als Entwickler von letzterem, z.B. gerne bereit an Zusammenarbeit, Erweiterung, Umdenken etc. gemeinsam zu arbeiten (falls das eure Arbeitsaufgabe oder Prof zulässt ;-)

Ohne kritisieren oder schwarzmalen zu wollen befürchte ich (aus bisherigen Beobachtungen aus dem Forum) mit eurem Vorhaben eine neue Entwicklung, die leider im Laufe der Zeit wieder versandet (da entweder nicht mehr gepflegt oder weiterentwickelt, oder aber nicht angenommen durch die Benutzer). Es wäre schade um die geleistete Arbeit!

Das Problem ist derzeit meiner Meinung nach, das die Entwicklungen an Frontends bisher zu versplittert ist. Viele Frontends die von zu wenigen Personen getragen werden und zu wenig Mitarbeit durch die Community bekommen.

Eine Frage noch zu eurem aktuellen Plan:
Warum kommt PHP zum Einsatz? Wenn ich es richtig verstanden habe ist die Arbeitsaufgabe doch ein Webfrontend zur Nutzung von schon bestehenden Funktionen, die FHEM bietet. Damit hat eine zusätzliche, serverseitige Scriptsprache doch erstmal nichts zu tun, oder? Da FHEM in Perl geschrieben ist finde ich es eigentlich sehr naheliegend, bei Bedarf von neuen serverseitigen Funktionen eben FHEM zu erweitern und nicht in einer weiteren Sprache und damit neue Abhängigkeiten und z.B. Installationsaufwände zu schaffen.

Viele Grüße und Erfolg,
Johannes

[FS_Frank]

Hallo,

Es freut mich zu sehen, dass immer wieder an Webfrontends zu FHEM gearbeitet wird.
Was ich leider unschön finde ist, dass es mittlerweile viele verschiedene und gute Ansätze gibt, sich aber leider nichts langfristiges und durch die Community unterstütztes daraus ergibt bzw. etabliert.
Es gäbe zum Beispiel noch den YAF (Yet another Floorplan), der einen ähnlichen Ansatz fährt (habe ich glaube ich in eurem Paper nichts drüber gelesen). Oder der Java / Vaadin Ansatz (Link). Oder aber auch wie in eurem Text erwähnt das "Charting Frontend". Ich bin, als Entwickler von letzterem, z.B. gerne bereit an Zusammenarbeit, Erweiterung, Umdenken etc. gemeinsam zu arbeiten (falls das eure Arbeitsaufgabe oder Prof zulässt ;-)

Ohne kritisieren oder schwarzmalen zu wollen befürchte ich (aus bisherigen Beobachtungen aus dem Forum) mit eurem Vorhaben eine neue Entwicklung, die leider im Laufe der Zeit wieder versandet (da entweder nicht mehr gepflegt oder weiterentwickelt, oder aber nicht angenommen durch die Benutzer). Es wäre schade um die geleistete Arbeit!

Das Problem ist derzeit meiner Meinung nach, das die Entwicklungen an Frontends bisher zu versplittert ist. Viele Frontends die von zu wenigen Personen getragen werden und zu wenig Mitarbeit durch die Community bekommen.

Eine Frage noch zu eurem aktuellen Plan:
Warum kommt PHP zum Einsatz? Wenn ich es richtig verstanden habe ist die Arbeitsaufgabe doch ein Webfrontend zur Nutzung von schon bestehenden Funktionen, die FHEM bietet. Damit hat eine zusätzliche, serverseitige Scriptsprache doch erstmal nichts zu tun, oder? Da FHEM in Perl geschrieben ist finde ich es eigentlich sehr naheliegend, bei Bedarf von neuen serverseitigen Funktionen eben FHEM zu erweitern und nicht in einer weiteren Sprache und damit neue Abhängigkeiten und z.B. Installationsaufwände zu schaffen.

Viele Grüße und Erfolg,
Johannes

Hallo Johannes,

vielen Dank für dein Feedback! Ich versuche einmal ein paar deiner Fragen zu beantworten oder Sorgen zu kommentieren:

- Die Gefahr, dass so ein Projekt im Laufe der Zeit versandet (vor allem wenn das Forschungsseminar beendet ist), ist immer gegeben - wäre auch gelogen, wenn man sich etwas Anderes vormacht. Was ich aber sagen kann ist, dass dieser Forschungsbereich an der HTW recht frisch / neu ist und auch in den nächsten Jahren dort Studenten uns folgen werden. Das heißt, dass auch in Zukunft daran weiter gearbeitet wird und wir das ganze auch so modular aufbauen wollen, dass eine leichte Einarbeitung möglich ist. Das heißt der kritische Punkt wäre eine sehr guter Übergang der 'alten' zu den 'neuen' Studenten, so dass die Begeisterung weiterhin vorhanden ist.

- Den Java/Valaadin Ansatz habe ich mir einmal angesehen, das wäre aber vermutlich erst einmal nicht in unserem Interesse, da wir versuchen möglichst über eine Seite Tablet/PC und später auch Smartphone (wir diskutieren noch wegen WebApp-Technologien) anzusteuern, was ich mir über eine Lösung bei Java (Also theoretisch bräuchte man ja eine App über ADT erstellt, ein Servlet für PC und Tablet) ein wenig komplizierter als es über reine Webtechnologien aufzuziehen.

- Das YAF ist mir vor ca. 3-4 Wochen aufgefallen, aber wir kamen neben den anderen Betrachtungen und Analysen noch nicht zu einer rundumfassenden Analyse, deshalb möchte ich mich erst einmal noch nicht positiv/negativ dazu äußern, aber wir schauen es uns noch einmal natürlich an - danke auch nochmal für den Link zu Java/Valaadin.

Neben den Punkten die wir bei dem Paper zu den technologischen Betrachtungen genommen haben, ist unsere Hochschule auch in den Informatikstudiengängen sehr auf PHP, HTML5,AJAX,CSS3 vorbereitet wurden. Im Vergleich zur Einarbeitung in Perl und den im Paper genannten Punkten ist es damit auch eine Zeitfrage der Entwicklung. Würden wir in Perl anfangen müssten sich Nachfolger darin noch lange einarbeiten und das wäre auch ein großes Zeitproblem. Wir wollen zum einen Funktionalitäten von FHEM nutzen (wir nehmen da zum Beispiel den Telnet Port und holen uns wichtiges via XML), aber zeitgleich auch eine Lösung schreiben, die für programmiererfahrene und programmierunerfahrene Nutzer eine Hilfe ist.

In unseren Augen ist der FHEM-Server von der bisherigen Verwendbarkeit sehr gut handhabbar für Leute, die von Programmierung und Sensoren eine gute Ahnung haben, aber für die 'Masse' an Menschen da draußen, fehlt gewisse Bedienbarkeit und intuitives Verhalten. Wir versuchen ein wenig die Lücke zu schließen und das auch mit zu erreichen.

Gegen eine Zusammenarbeit spricht von meiner Seite aus natürlich nichts dagegen ;) - Aber ich muss da natürlich auch mit dem Professor noch Rücksprache halten und würde mich da melden.

Mit besten Grüßen,
Frank

[oliv06]

Could you have a look at http://www.domoticz.com/ : it is opensource, have a good interface. Would be a good idea to use its interface as a frontend for FHEM

[strauch]

Ich weiß nicht ob ich wirklich was beitragen kann. Ich persönlich finde es krankt primär an einem Benutzbaren Interface für Nutzer. Bei uns in der Familie richte ich FHEM ein, ich habe aber noch 3 Mitnutzer und da krankt es meist an total simplen Sachen:

Nutze ich andFHEM, dann müssen die Leute zwischen FS20 und CUL_HM als Schalter unterscheiden können. Im FHEM Webinterface ist es in Gruppen sortiert (Schalter, Heizung etc.), aber das Webfrontend lässt sich nicht gut mit einem Tablet bedienen und den PC schmeißt niemand dafür an und  mit CUL_FHTTK etc. in andfhem damit kann kaum einer was anfangen.

Für Nutzer Interessant fände ich dann noch eine einfache Möglichkeit Dinge wie Zeitschaltuhr, Urlaubstage, Feiertage, Ferien, Schichtdienste zu konfigurieren. So das man theoretisch seinem Nachbarn die Heimautomation einrichten kann und er dann damit "arbeiten" könnte.

Ein Florplan ist aufwändig, ich persönlich habe aber auch gar nicht das Bedürfnis dazu. Ist wohl erst Interessant wenn man "gleiche" Geräte in verschiedenen Ecken unterschiedlich Schalten will (wohl vor allem Lampen)

Ich denke es fehlt weniger an Programmierern sondern vor allem an GUI Designern. Ich war ja selber mal mit dran an einem jQuery Webfrontend für Tablets, aber ich finde einfach nicht die Zeit da weiter zu machen: http://fhem.webmanufactur.net/

Ich denke auch nicht das ein Zusammenklicktool so auf Fruchtbaren Boden trifft, weil ich glaube da ist schon die Installation eine zu große Hürde für so Leute. Da könnte ich mir eher soetwas wie ein Formeleditor von Excel vorstellen. Man tippt z.B. Notify ein und er fragt die Parameter ab und gibt passende Geräte als Vorschlag, das würde meiner Meinung nach reichen. Das hilft Anfängern durch die Vorschläge und "Profis" können einfach durchtippen.

[Puschel74]

Hallo,

im Anfängerbereich hatte ich es grad mit einem Mit-FHEM`ler.

Eine Anforderung an eine moderne GUI wäre mMn auch das sie von schlechter sehenden bedient werden kann.

Sprich:
Wenn Code eingegeben werden soll müsste diese auch zwischen Groß- und Kleinschreibung unterscheiden können und
Schlüsselwörter entsprechend in die benötigte Schreibweise bringen.

z.B.:
Aus log müsste diese dann selbständig Log machen können wenn der User einen Logeintrag generieren möchte.

Grüße

[oniT]

Hallo,

ich möchte auch mal so meine Sichtweise hier anbringen.

Um es für nicht Programmierer zugänglich zu machen muss es ganz einfach funktionieren.

Ein Beispiel, es werden Rollomotoren oder eben Funkschalter über zum Beispiel das Scannen mittels QR-Codes angelegt. Sind diese angelegt, müssen diese per drag&drop den entsprechenden Räumen zuordenbar sein. Dann gehören diese zur Gruppe von Raum X und können über diese Gruppe gemeinsam geschalten werden. Hat das Fenster des Rollos noch einen Fensterkontakt, muss dieser wieder per drag&drop dem Rollo zugeordnet werden können. In diesem Zusammenhang wird gleichzeitig das Szenario hinterlegt, "ist das Fenster geöffnet - darf Rollo nicht geschlossen werden".

Dies mal auf die Schnelle ein einfaches Beispiel. Ich werde bei Gelegenheit nochmals mehr Beispiele einstellen.

Gruß,
TinoB

[Rince]

Autocreate per QR-Code?

Das klingt nicht unspannend, ist aber vermutlich bei FHEM eher nicht nötig, da Autocreate das ja macht :)
Was aber so gesehen schlau wäre, wäre ein Autocreate Wizzard:

Wenn Autocreate was anlegt, gleich den User Fragen wie das Device denn heißen soll, ob es in einen bestimmten Raum gehört und ob Logfiles angelegt werden sollen, wenn ja, welche Logfiles genau.

Oder aber:
Ein Autocreate für nicht Autocreate fähige Geräte:
Wieder der oben genannte Wizzard:
Welches Gerät willst du anlegen?

=> Liste wird präsentiert von anlegbaren Geräten

User wählt aus, z.B.
=> Samsung TV

Frage:
Welche IP Adresse hat er?

Usereingabe...

Welcher Port? (Hinweistext...)
Usereingabe...

So in etwa könnte ich mir das auch gut vorstellen :)

[FS_Frank]

Hallo allerseits!

Die letzte Woche gab es bei uns sehr viele Belegabnahmen und auch eine erste Verteidigung unseres Forschungsseminares. Momentan lerne ich auch für Prüfungen und melde mich daher erst jetzt einmal. Ich versuche mal auf die Posts nun alle einzugehen ;). Ich habe vor allem noch ein paar Fragen, um Missverständnissen vorzubeugen.

Zuerst aber noch @Johannes:
Ich habe mit meinem Professor gesprochen und gegen eine Zusammenarbeit wäre nichts einzuwenden ;)

Could you have a look at http://www.domoticz.com/ : it is opensource, have a good interface. Would be a good idea to use its interface as a frontend for FHEM

Sure, thank you for your submission! I'll have a look at this later this month (due to my exams). Could you tell me which programming or script language you did used?

Ich weiß nicht ob ich wirklich was beitragen kann. Ich persönlich finde es krankt primär an einem Benutzbaren Interface für Nutzer. Bei uns in der Familie richte ich FHEM ein, ich habe aber noch 3 Mitnutzer und da krankt es meist an total simplen Sachen:

Nutze ich andFHEM, dann müssen die Leute zwischen FS20 und CUL_HM als Schalter unterscheiden können. Im FHEM Webinterface ist es in Gruppen sortiert (Schalter, Heizung etc.), aber das Webfrontend lässt sich nicht gut mit einem Tablet bedienen und den PC schmeißt niemand dafür an und  mit CUL_FHTTK etc. in andfhem damit kann kaum einer was anfangen.

Für Nutzer Interessant fände ich dann noch eine einfache Möglichkeit Dinge wie Zeitschaltuhr, Urlaubstage, Feiertage, Ferien, Schichtdienste zu konfigurieren. So das man theoretisch seinem Nachbarn die Heimautomation einrichten kann und er dann damit "arbeiten" könnte.

Ein Florplan ist aufwändig, ich persönlich habe aber auch gar nicht das Bedürfnis dazu. Ist wohl erst Interessant wenn man "gleiche" Geräte in verschiedenen Ecken unterschiedlich Schalten will (wohl vor allem Lampen)

Ich denke es fehlt weniger an Programmierern sondern vor allem an GUI Designern. Ich war ja selber mal mit dran an einem jQuery Webfrontend für Tablets, aber ich finde einfach nicht die Zeit da weiter zu machen: http://fhem.webmanufactur.net/

Ich denke auch nicht das ein Zusammenklicktool so auf Fruchtbaren Boden trifft, weil ich glaube da ist schon die Installation eine zu große Hürde für so Leute. Da könnte ich mir eher soetwas wie ein Formeleditor von Excel vorstellen. Man tippt z.B. Notify ein und er fragt die Parameter ab und gibt passende Geräte als Vorschlag, das würde meiner Meinung nach reichen. Das hilft Anfängern durch die Vorschläge und "Profis" können einfach durchtippen.

Hallo Strauch! Deine GUI sieht auch aus, als ob sie bei künftiger Entwicklung viel Potential haben könnte. Es erinnert ein wenig an das Konzept von IP-Symcon: http://www.webfront.info/ , aber ein wenig moderner aussehend. Schade, dass du dafür momentan nicht soviel Zeit hast.

Wenn ich das richtig verstanden habe, möchtest du Begriffe wie die CUL-Namen und alles, was Neulinge abschrecken könnte, ausblenden? Das könnte ich mir quasi in so einem 'Alltagsmodus', wo man nur die Lampen, etc. steuert gut vorstellen. Irgendwo, quasi in einem 'Adminmodus' sollten aber sicher auch für die Experten diese Bezeichnungen da sein oder wenigstens so umbenannt werden, dass man noch zuordnend etwas damit anfangen kann. Die Idee mit einem 'Urlaubs/Feiertags'-Modus, den der Nutzer selber konfigurieren kann, finde ich sehr gut!

Mit dem Formeleditor meinst du quasi eine Autovervollständigung beim Tippeln, ähnlich wie wenn ich Suchbegriffe bei Google eingebe? Man könnte quasi im Hintergrund die Liste aller momentanen FHEM-Befehle nehmen und das dann mit Ajax als Vorschläge eingeben.

Hallo,

im Anfängerbereich hatte ich es grad mit einem Mit-FHEM`ler.

Eine Anforderung an eine moderne GUI wäre mMn auch das sie von schlechter sehenden bedient werden kann.

Sprich:
Wenn Code eingegeben werden soll müsste diese auch zwischen Groß- und Kleinschreibung unterscheiden können und
Schlüsselwörter entsprechend in die benötigte Schreibweise bringen.

z.B.:
Aus log müsste diese dann selbständig Log machen können wenn der User einen Logeintrag generieren möchte.

Grüße

Hallo Puschel174,

Ich nehme an das würde sich mit einer Autovervollständigung (siehe im Zitat darüber, was ich beantwortet habe) auch decken?
Man könnte hier auch allgemein das Thema 'Usability' - im Sinne von Menschen mit Behinderungen - ansprechen. Momentan haben wir erst einmal keine Konzeption für Unterschiedliche Behinderungen. Es gibt ja auch Personen mit einer derartigen Sehschwäche, die zum Beispiel sich ihre Website vorlesen lassen können (Mit speziellen Geräten) und es behindertengerechte CSS-Dateien gibt, etc. Verpflichtend ist das für ein WebFrontend natürlich nicht, man müsste aber sicher auch als 'Ausblick' mit betrachten, wie Nutzerfreundlich man es für körperlich 'benachteiligte' Menschen in der Gesellschaft ist.

Hallo,

ich möchte auch mal so meine Sichtweise hier anbringen.

Um es für nicht Programmierer zugänglich zu machen muss es ganz einfach funktionieren.

Ein Beispiel, es werden Rollomotoren oder eben Funkschalter über zum Beispiel das Scannen mittels QR-Codes angelegt. Sind diese angelegt, müssen diese per drag&drop den entsprechenden Räumen zuordenbar sein. Dann gehören diese zur Gruppe von Raum X und können über diese Gruppe gemeinsam geschalten werden. Hat das Fenster des Rollos noch einen Fensterkontakt, muss dieser wieder per drag&drop dem Rollo zugeordnet werden können. In diesem Zusammenhang wird gleichzeitig das Szenario hinterlegt, "ist das Fenster geöffnet - darf Rollo nicht geschlossen werden".

Dies mal auf die Schnelle ein einfaches Beispiel. Ich werde bei Gelegenheit nochmals mehr Beispiele einstellen.

Gruß,
TinoB

Hallo TinoB,

Das mit dem QR-Code klingt sehr interessant! Ich möchte mich da aber meinem Vorredner anschließen, dass Autocreate da momentan auch eine gute Lösung ist. Könntest du mir bitte erklären, wie du dir das mit dem QR-Code vorstellst?

Momentan denke ich es mir quasi so, dass es Geräte mit QR-Codes gibt, die mit einem QR-Code-Scanner (Smartphone oder Gerät, was wenigstens Bluetooth hat) gescannt werden und dann auf eine Website linkt oder den Code zum Erstellen hat?

Ansonsten ist diese Drag&Drop-Funktionalität etwas, wo gerade RWE mit Smarthome recht führend ist. Wir bauen sowas natürlich nicht 'nach' (alleine schon weil RWE das mit Silverlight geschrieben hat *g*), aber wir werden auch Drag&Drop -Funktionalitäten, basierend auf HTML5 und CSS3 nutzen. Da gibt's momentan sehr schöne Entwicklungen in dem Bereich!

Autocreate per QR-Code?

Das klingt nicht unspannend, ist aber vermutlich bei FHEM eher nicht nötig, da Autocreate das ja macht :)
Was aber so gesehen schlau wäre, wäre ein Autocreate Wizzard:

Wenn Autocreate was anlegt, gleich den User Fragen wie das Device denn heißen soll, ob es in einen bestimmten Raum gehört und ob Logfiles angelegt werden sollen, wenn ja, welche Logfiles genau.

Oder aber:
Ein Autocreate für nicht Autocreate fähige Geräte:
Wieder der oben genannte Wizzard:
Welches Gerät willst du anlegen?

=> Liste wird präsentiert von anlegbaren Geräten

User wählt aus, z.B.
=> Samsung TV

Frage:
Welche IP Adresse hat er?

Usereingabe...

Welcher Port? (Hinweistext...)
Usereingabe...

So in etwa könnte ich mir das auch gut vorstellen :)

Ich habe das auch mal mit aufgenommen, die Idee eines Wizards ist recht gut :)


Zusammenfassend:

Ich habe mal all eure Vorschläge in eine nicht-öffentliche Liste eingetragen.
Ich habe nun momentan ca. einen Monat mit Prüfungen zutun und komme daher nicht dazu, groß etwas zu machen.
Sobald ich im August zurück bin, werde ich die Anforderungen einmal genauer betrachten und das Ganze auch einpflegen - ganz zum Schluss kommt es in den neuen Forschungsbericht.

Die gesamte und rege Diskussion freut mich sehr und die betrachte ich auch weiter mit großem Interesse :)

Mit besten Grüßen,
Frank

[forum-merlin]

Hallo FS Frank,

ich bin selbst noch blutiger Anfänger und lerne noch.
Ich bin aber in Sachen IT/Server/Config/etc. recht fit.

Ich stelle mir eine GUI vor, die vll. auf AJAX oder PHP basiert und so aufgebaut ist wie die eines QNAP NAS.
Aktuell schaut die schon wieder anders aus, aber eben der Aufbau wie es unter Firmware 3.7 noch ausgeschaut hat.

So zumindest schonmal vom Design und der Aufteilung.
oder auch gerne so wie es bei der Fritzbox aussieht. Mit einer User Ansicht, und einer Experten Ansicht. Mit einer Programmer Ansicht.
Einfaches umbenennen von Aktoren, Benennen von Räumen, Anlegen eines Floorplans in der GUI


Die GUI sollte für mich etwas userfreundlicher werden.
Sprich, Ich kann auswählen was ich für ein ServerDevice habe, z.B. CUNO, CUL433, CUL868, RFXTRX433, ... und dann bekomme ich schonmal eine Übersicht über die möglichen Hersteller und deren Devices die von dem jeweiligen z.B. CUL so unterstützt werden.

Hilfeseiten innerhalb der GUI zu den einzelnen Funktionen (was bedeutet...)

kleines User Management.
Admin User > darf alles
Eltern > reines User Interface ohne Option auf Programmer Funktionen
Kinder > dürfen teilweise nicht alle Geräte einschalten, oder Zugang zu Papas Arbeitszimmer
Gäste/Urlaubsvertretung > dürfen Wetterinfos lesen, das Rollo rauf und runter, haben Zugang zu..., dürfen aber nicht in Raum xy, und wenn doch, dann WebCam Aufzeichnung,


Was möchte ich alles damit machen?
- Funksteckdosen aus dem Baumarkt steuern
- Unterputzaktoren fürs Licht steuern
- Rollandensteuerung (Verschiedene Szenarien>Urlaubh, oder Temp. abhängig, oder Heimkinomodus)
- Innenraumüberwachung (WebCam, Bewegungsmelder, WLAN Clients, Blutooth, RFID)
- Zugangsberechtigungen steuern (PinCode, RFID, Fingerabdruck)
- Heimkinosteuerung (verschiedene Lichtszenarien, Filmstart löst etwas aus)
- Sprachsteuerung und Informationsmeldungen per Kommando abrufen. "Wie wird das Wetter heute?"
- Heizungssteuerung (Wenn Tür auf, dann Thermostat auf xxx grad, Urlaubskalender etc., Wasser...)
- Gartentechnik steuern (Bachlauf/Licht/Bewässerung/etc.)
- Sensoren auslesen (Temperatur/Luftfeuchte/Luftqualität/etc.)
- Fotovoltaik
- Solaranlage
- Garagentor
- Stromverbrauch messen

Gruß

der Merlin

[FS_Frank]

Guten Abend allesamt,

Ich habe mich nun eine ganze Weile nicht gemeldet. Erst waren Prüfungen, dann war ich noch im Urlaub, danach streckte mich meine Krankheit nieder. Trotz allem bin ich nun im neuen Semester und geht die Arbeit in unserer Gruppe eifrig weiter.

Sämtliche angesprochenen Themen wurden aufgeschrieben und intern mit mir und meinem Kommilitonen diskutiert und evaluiert. Wir werden die daraus folgenden Änderungen und Ideen auch am Ende in unserem Forschungsbericht für das Wintersemester 2013/14 einbringen.

Momentan haben wir sämtliche Aufgaben verteilt und schreiben/programmieren. Wenn wir etwas vorzeigbares haben, melde ich mich natürlich. Alles in allem läuft es aber bisher - in meinen Augen - sehr gut.

Sollte es noch Kritik, Anregungen und Ideen geben, könnt ihr sie gerne herein schreiben.

Mit besten Grüßen,
Frank