[Analyse] Anforderungen an eine moderne GUI

[Johannes]

Also eine komplette Neuentwicklung?
Welche Frameworks und Sprachen sollen zum Einsatz kommen?
Grüße!

[CaptBlaubaer]

Hallo FS_Frank liebe FHEM.Freunde,

ich finde es wichtig, dass es Anforderungsdefinitionen gibt und dass die Diskussion gestartet wurde.

Was ich an der Anforderungsdefinition für das FHEM-GUI (welches) wichtig finde ist die Definition der Benutzer, die durch die GUI angesprochen werden sollen.
Dies zeigen mir die ersten Reaktionen auf Deine Anfrage.

Was kann ich von den Benutzern erwarten, was nicht. Bzgl. Wissen, Fähigkeiten, Durchhaltevermögen, ...

Wenn der Definition festgelegt ist (klar ist sie dann wohl immer noch nicht) würde ich mich an eine Definition des Funktionsumfanges machen.

Eigentlich stehen diese Dinge in einem Lastenheft (Was wird entwickelt und wofür?) und kommt vom "Marketing".
Die Entwicklung liefert dann das Lastenheft (Wie wird entwickelt und womit?)

Gibt es denn mittlerweile dieses Lastenheft und kann man da mal reinschau'n oder besteht das Interesse eines zu erstellen?
Ich würde mir wünschen mit den FHEM Benutzerklassen anzufangen, damit sich zukünftige Diskussionen darauf beziehen können wenn von GUI die Rede ist.

z.B.:
Target: Define User Classes and their tasks in the great FHEM system to find a common base for future discussion, e.g. about requirements and functionality.

Eigentlich geht's mir darum mehr User für FHEM zu begeistern. (CBR)

FHEM-User Classes:
- Programmer:         Is developing new modules, responsible for debugging and documenting the modules and the GUIs
- Administrator:       Commisioning and maintaining FHEM systems, installing new modules
- Configurator:        Adding new devices into the FHEM system, Configuring contol systems, like heating control
- Advanced User:    uses devices to group them and/or assign them to rooms
- User:   Switches   switches lights on or off, opens blinds, checks and sets temperature values ,..

Vielleicht gibt's das ja schon alles.

Viele Grüße,
CaptBlaubaer (CBR)



Vielleicht

[volschin]

Hallo zusammen,
Bestandteil der Anforderungen an ein UI ist für mich der Installationsprozess. Das wird durch die Einschränkung GUI bzw. Frontend dann häufig vergessen.

Der Installationsprozess ist die erste Hürde, die ein neuer Benutzer nehmen muss. Was FHEM für mich interessant gemacht hat, war, dass ich es unkompliziert mit einer Image-Datei auf meiner bestehenden Fritzbox 7390 installieren konnte. Ich musste bis dahin noch nicht ein einziges Mal per telnet auf die Befehlszeile wechseln. Habe ich auch immer noch nicht gemacht

Die FHEM Befehlszeile nutze ich dagegen häufiger. Wenn Dateien zu bearbeiten sind, dann werden die per FTP ausgetauscht.

Das ist auch der Grund, weshalb ich einer PHP-basierten Entwicklung skeptisch gegenüberstehe. Wenn man sich die Nutzerdaten der FHEM-Statistik ansieht, ist völlig klar, was die Nutzer wollen. Ausführung auf kleinen stromsparenden Geräten. 35% nutzen ihre bestehende Fritzbox (nichts anderes ist das mips-linux unter Perl 5.2.12), weitere 36% eine ARM-Architektur (in den häufigsten Fällen ein Raspberry Pi).

Mit einer Entscheidung PHP ohne entsprechenden Unterbau würde bereits ein Drittel der Nutzer abgehängt. Das ist auch eine Anforderung, die man in Analyse und Entscheidungen einkalkulieren sollte, wenn man eine Note 1 haben will.   

Gruß,
Veit

[CaptBlaubaer]

Hallo Veit,

Du schreibst

weshalb ich einer PHP-basierten Entwicklung skeptisch gegenüberstehe

Ich habe leider keine Ahnung, was eine PHP-basierte Entwicklung ist und was das für FHEM User bedeuten würde.

Wäre es möglich, dass Du die Beschreibung von Anforderungen bitte einmal umdrehst und nicht die Umsetzung voranstellst, so dass sich aus der Anforderung ergibt, dass eine Umsetzung mit PHP nicht erfolgen kann?

Das wäre dann auch eine Beschreibung, die in ein Lastenheft mit aufgenommen werden kann.

Viele Grüße
CaptBlaubaer (CBR)

[volschin]

Meine Anforderung steht klar im ersten Teil. Mein Kommentar zur von FS_Frank geplanten Umsetzung und der Impact auf die Anforderung im zweiten Teil.

Gruß
Veit

[FS_Frank]

Guten Tag allerseits!

Ich möchte mich erst einmal entschuldigen, dass gerade keine Rückmeldung kam. Ich hatte eigentlich eingestellt, dass ich zu jedem Post hier eine Mail bekomme, aber das wurde glaube ich mit der Forumsumstellung deaktiviert? Hatte nicht mitbekommen, dass es da noch Meldungen gab! Ich schaue daher jetzt mal öfter rein und schaue mal, ob ich das Beobachten des Threads wieder hinbekomme!

Also eine komplette Neuentwicklung?
Welche Frameworks und Sprachen sollen zum Einsatz kommen?
Grüße!

Hallo Johannes,

Wir arbeiten momentan primär mit JQery als Framework. Sprachen sind PHP (Serverseitig) und JavaScript (Clientseitig). Ich gebe mal eine kleine Liste an Dingen, die wir momentan so machen (bzw. was schon zu 90% geht):

-   Funktionierendes Loginsystem mit Hash(+Salt)-Generierung + SQLite-Datenbank
-   Funktionierende Kommandozeile mit Autosuggest
-   XML komplett auslesen
-   PHP-Objekte (Serverseite) und JavaScript-Objekte (Clientseite) generieren zum Performancegewinn.
-   Algorithmus für korrekte Darstellung in IE; Firefox, Chrome und richtiges Generieren der Anzeige bei Verschieben von Objekten und Ändern der Fenstergröße auf PC, Tablet und Smartphone
-   Drag&Drop für intuitives Verschieben von Aktoren und Sensoren in Räumen
-   Rückkoplung der Interaktionen des Clients (JS) mit FHEM-Befehlen an den Server
-   Anlegen neuer Räume, Namensvergabe und Möglichkeit, Aktoren und Sensoren dort hineinzuziehen
-   Implementierung der Erkennung des Geräts der Forschungsgruppe

Hallo FS_Frank liebe FHEM.Freunde,

ich finde es wichtig, dass es Anforderungsdefinitionen gibt und dass die Diskussion gestartet wurde.

Was ich an der Anforderungsdefinition für das FHEM-GUI (welches) wichtig finde ist die Definition der Benutzer, die durch die GUI angesprochen werden sollen.
Dies zeigen mir die ersten Reaktionen auf Deine Anfrage.

Was kann ich von den Benutzern erwarten, was nicht. Bzgl. Wissen, Fähigkeiten, Durchhaltevermögen, ...

Wenn der Definition festgelegt ist (klar ist sie dann wohl immer noch nicht) würde ich mich an eine Definition des Funktionsumfanges machen.

Eigentlich stehen diese Dinge in einem Lastenheft (Was wird entwickelt und wofür?) und kommt vom "Marketing".
Die Entwicklung liefert dann das Lastenheft (Wie wird entwickelt und womit?)

Gibt es denn mittlerweile dieses Lastenheft und kann man da mal reinschau'n oder besteht das Interesse eines zu erstellen?
Ich würde mir wünschen mit den FHEM Benutzerklassen anzufangen, damit sich zukünftige Diskussionen darauf beziehen können wenn von GUI die Rede ist.

z.B.:
Target: Define User Classes and their tasks in the great FHEM system to find a common base for future discussion, e.g. about requirements and functionality.


FHEM-User Classes:
- Programmer:         Is developing new modules, responsible for debugging and documenting the modules and the GUIs
- Administrator:       Commisioning and maintaining FHEM systems, installing new modules
- Configurator:        Adding new devices into the FHEM system, Configuring contol systems, like heating control
- Advanced User:    uses devices to group them and/or assign them to rooms
- User:   Switches   switches lights on or off, opens blinds, checks and sets temperature values ,..

Vielleicht gibt's das ja schon alles.

Viele Grüße,
CaptBlaubaer (CBR)



Vielleicht

Hallo CaptBlaubaer!

Momentan haben wir eine kleine SQLITE-Datenbank laufen (das ist ein eingebettetes Datenbanksystem - also im Grunde genommen eine vor dem Internetzugriff geschützte Datei. Keine Sorge, es ist also keine Datenbankinstallation notwendig für den normalen Nutzer) mit der wir eine Userverwaltung, die zwischen 'Admin' und einem normalen 'User' unterscheidet, haben.

Hallo zusammen,
Bestandteil der Anforderungen an ein UI ist für mich der Installationsprozess. Das wird durch die Einschränkung GUI bzw. Frontend dann häufig vergessen.

Der Installationsprozess ist die erste Hürde, die ein neuer Benutzer nehmen muss. Was FHEM für mich interessant gemacht hat, war, dass ich es unkompliziert mit einer Image-Datei auf meiner bestehenden Fritzbox 7390 installieren konnte. Ich musste bis dahin noch nicht ein einziges Mal per telnet auf die Befehlszeile wechseln. Habe ich auch immer noch nicht gemacht

Die FHEM Befehlszeile nutze ich dagegen häufiger. Wenn Dateien zu bearbeiten sind, dann werden die per FTP ausgetauscht.

Das ist auch der Grund, weshalb ich einer PHP-basierten Entwicklung skeptisch gegenüberstehe. Wenn man sich die Nutzerdaten der FHEM-Statistik ansieht, ist völlig klar, was die Nutzer wollen. Ausführung auf kleinen stromsparenden Geräten. 35% nutzen ihre bestehende Fritzbox (nichts anderes ist das mips-linux unter Perl 5.2.12), weitere 36% eine ARM-Architektur (in den häufigsten Fällen ein Raspberry Pi).

Mit einer Entscheidung PHP ohne entsprechenden Unterbau würde bereits ein Drittel der Nutzer abgehängt. Das ist auch eine Anforderung, die man in Analyse und Entscheidungen einkalkulieren sollte, wenn man eine Note 1 haben will.   

Gruß,
Veit

Hallo Veit,

Du schreibst

Ich habe leider keine Ahnung, was eine PHP-basierte Entwicklung ist und was das für FHEM User bedeuten würde.

Wäre es möglich, dass Du die Beschreibung von Anforderungen bitte einmal umdrehst und nicht die Umsetzung voranstellst, so dass sich aus der Anforderung ergibt, dass eine Umsetzung mit PHP nicht erfolgen kann?

Das wäre dann auch eine Beschreibung, die in ein Lastenheft mit aufgenommen werden kann.

Viele Grüße
CaptBlaubaer (CBR)

Dazu möchte ich kurz sagen:

Sinn ist es, dass unser System auf Tablet, Smartphone und PC läuft - zeitgleich auf Chrome, Firefox und Internet Explorer. Unser Gedankengang ist in einer Zukunft gerichtet, in der vielleicht in einigen Jahren auch Familien bei sich zuhause eine 'kostengünstige' Hausautomatisierung aufziehen und dann schnell mal via Smartphone, Tablet oder PC ihr Haus steuern können.

Diese PHP/JavaScript-Sache ist dabei nur ein Mittel zum Weg, eine nutzerfreundliche Sache zu bauen. Für die alten FHEM-Veteranen haben wir aber auch eine Kommandozeile eingebaut, die sogar via Autosuggest vorhandene Befehle vorschlägt.

Ich gebe später nochmal ein paar Screenshots rein, falls das hier geht.

Mit besten Grüßen,

Frank

[FS_Frank]

Wegen der Nachfrage der momentanen Anforderungsanalyse:
http://www2.htw-dresden.de/~wiki_sn/images/b/ba/Forschungsbericht_Sensornetze_SS_2013_Web_Frontend.pdf

Das ist der Forschungsbericht vom Sommersemester 2013. Was im Entwurf steht wurde aber mittlerweile nochmal komplett überarbeitet und wird im nächsten Bericht auch reingestellt. Momentan sieht es ungefähr so aus:

https://www.dropbox.com/lightbox/home/Public/FHEMScreens

Hier könnt ihr euch mal die Bilder ansehen.

Edit: Bilder (von Aktoren/Sensoren) sind alle selbst gemacht und werden wir dann natürlich zur freien Verfügung stellen (für Sensoren und Aktoren).

Ich füge sie auch nochmal als Anhang dazu:
Edit: Wichtig! So wie ihr es auf den Bildern seht wird es auch am Ende aussehen, aber wir schreiben momentan an vielen Dingen. Diese letzten 10% dieser momentan angegangenen Probleme sind recht komplex, daher laden wir auch noch erst einmal keinen Zwischenstand hoch.

[Strippenzieher]

Wir arbeiten momentan primär mit JQery als Framework. Sprachen sind PHP (Serverseitig) und JavaScript (Clientseitig). Ich gebe mal eine kleine Liste an Dingen, die wir momentan so machen (bzw. was schon zu 90% geht):

-   Funktionierendes Loginsystem mit Hash(+Salt)-Generierung + SQLite-Datenbank
-   Funktionierende Kommandozeile mit Autosuggest
-   XML komplett auslesen
-   PHP-Objekte (Serverseite) und JavaScript-Objekte (Clientseite) generieren zum Performancegewinn.
-   Algorithmus für korrekte Darstellung in IE; Firefox, Chrome und richtiges Generieren der Anzeige bei Verschieben von Objekten und Ändern der Fenstergröße auf PC, Tablet und Smartphone
-   Drag&Drop für intuitives Verschieben von Aktoren und Sensoren in Räumen
-   Rückkoplung der Interaktionen des Clients (JS) mit FHEM-Befehlen an den Server
-   Anlegen neuer Räume, Namensvergabe und Möglichkeit, Aktoren und Sensoren dort hineinzuziehen
-   Implementierung der Erkennung des Geräts der Forschungsgruppe

Somit kann man davon ausgehen, dass eine saubere Fritzbox flach fällt, auch zukünftig.

Reicht es einen Apache mit PHP und SQLite auf der Fritzbox zum laufen zu bringen oder sind noch andere Erweiterungen erforderlich ?

MFG Chris

[FS_Frank]

Somit kann man davon ausgehen, dass eine saubere Fritzbox flach fällt, auch zukünftig.

Reicht es einen Apache mit PHP und SQLite auf der Fritzbox zum laufen zu bringen oder sind noch andere Erweiterungen erforderlich ?

MFG Chris

Hallo Chris,

Ja, das würde meines Wissens schon reichen (also das ist zumindest so, wies bei mir läuft - auf einem Apache). PHP wird mindestens Version 5.3.7 bei uns momentan benötigt. Ich hoffe, dass das helfen konnte!

LG Frank

[Franz Tenbrock]

wenn man für den Massen markt was machen will
wird man wohl kaum um die Fritzbox rumkommen...
sie steht heute schon in sehr vielen Haushalten
ist ausgereift, sparsam wird super weiterentwickelt etc
in den meisten Haushalten stehen schon mehr als genug technische Geräte
die meisten versuchen krampfhaft mit ihrem Stromverbrauch runter zu kommen und trotzdem geht es weiter bergauf...
so wie ich es hier im orum lese kann man mehr als genug Dinge mit der Fritzbox machen, so dass der Massenmarkt sicher damit ausreichend abgedeckt werden kann.
Ich glaube einfach nicht das sich der normale Endanwender mit noch einem neuen weiteren Gerät auseinandersetzen will....

manchmal ist weniger mehr !

das wichtigste wäre , wie oben bereits erwähnt, den Anfänger von Seiten der Software besser mitzunehmen, das war für mich am Anfang und immer noch das schwierigste.
Wenn man den Massenmarkt erreichen will sind die Probleme der Anfänger das wichtigste..
Ein Wizzard der einen unterstütz wäre für mich als Anfänger das wichtigste. Der müsste dann selbsterklärend sein...

Floorplan war eigentlich ganz simpel und konnte von mir als Anfänger ganz leicht umgesetzt werden

Schwierig wird es bei dummy, notify etc.
falls da ein wirrard was helfen könnte...

Also Entwicklungen für den Massenmarkt immer wieder und wieder auch von Anfängern testen lassen. Programmierer sehen da durch eine etwas andere Brille.

[UliM]

Hi,
vielleicht könntet ihr statt Apache ja sowas nehmen wie
http://www.floodgap.com/httpi/
das sich dann evtl. auch auf ner Fritzbox installieren liesse?  (Habs nicht getestet).
Vll gibt's ja was Ähnliches zu PHP...
LG, Uli

[FS_Frank]

Hallo allerseits!

wenn man für den Massen markt was machen will
wird man wohl kaum um die Fritzbox rumkommen...
sie steht heute schon in sehr vielen Haushalten
ist ausgereift, sparsam wird super weiterentwickelt etc
in den meisten Haushalten stehen schon mehr als genug technische Geräte
die meisten versuchen krampfhaft mit ihrem Stromverbrauch runter zu kommen und trotzdem geht es weiter bergauf...
so wie ich es hier im orum lese kann man mehr als genug Dinge mit der Fritzbox machen, so dass der Massenmarkt sicher damit ausreichend abgedeckt werden kann.
Ich glaube einfach nicht das sich der normale Endanwender mit noch einem neuen weiteren Gerät auseinandersetzen will....

manchmal ist weniger mehr !

das wichtigste wäre , wie oben bereits erwähnt, den Anfänger von Seiten der Software besser mitzunehmen, das war für mich am Anfang und immer noch das schwierigste.
Wenn man den Massenmarkt erreichen will sind die Probleme der Anfänger das wichtigste..
Ein Wizzard der einen unterstütz wäre für mich als Anfänger das wichtigste. Der müsste dann selbsterklärend sein...

Floorplan war eigentlich ganz simpel und konnte von mir als Anfänger ganz leicht umgesetzt werden

Schwierig wird es bei dummy, notify etc.
falls da ein wirrard was helfen könnte...

Also Entwicklungen für den Massenmarkt immer wieder und wieder auch von Anfängern testen lassen. Programmierer sehen da durch eine etwas andere Brille.

Danke für deine Rückmeldung, Franz! Ich möchte erst einmal ein Thema aufgreifen!

Du sagst, es stehen in Haushalten schon 'genug' technische Geräte herum. Hast du dafür Quellen, Beweise, etc.? Laut meinen bisherigen Erfahrungen haben die Menschen in ihren Autos mehr Technik und Automatisierung drin als bei sich zuhause stehen.

Wenn wir die 'normale' Familie nehmen, dann haben sie noch nicht zwingend ein voll-, geschweige denn teilautomatisiertes Haus. Wir reden hier wirklich momentan noch von einer Nische, die sich aber meines Erachtens gerade in den letzten Jahren enorm weiterentwickelt und langsam auch von Firmen wie RWE, etc. massentauglich gemacht wird.

Es gibt ja keine örtliche Beschränkung für den PHP-Server. Mit freetz kann man sich auf seiner Fritzbox auch seinen Apache-Server draufinstallieren:
http://freetz.org/

Hier einmal eine Liste der Packages, die das 'Firmware-Update' bringen kann:
http://freetz.org/wiki/packages

Ich hoffe, das hilft vielleicht ein wenig oder nimmt die Sorge? Wenn ich dich falsch verstanden habe, bitte einmal melden!

Hi,
vielleicht könntet ihr statt Apache ja sowas nehmen wie
http://www.floodgap.com/httpi/
das sich dann evtl. auch auf ner Fritzbox installieren liesse?  (Habs nicht getestet).
Vll gibt's ja was Ähnliches zu PHP...
LG, Uli

Hallo Uli, vielen Dank! Ich schaue es mir mal mit meinem Kommilitonen die Tage an!

LG Frank

[Franz Tenbrock]

Hallo, also ich oute mich mal, ich bin Hausarzt und sehe daher sehr viele Menschen tagtäglich.
Da ich eine technisch hochgerüstete Praxis habe rede ich häufiger auch mal über technische Sachen mit meinen Patienten Ich frage auch immer nach dem Beruf weil das eben häufig Auswirkungen auf die Gesundheit hat. Darüber hinaus bin ich Berater in einem Softwareprojekt (maxidoc)
Du hast Recht wenn di sagt das Hausautomatisierung sehr selten ist.
bisher hab ich nur einen gefunden der das schon macht ( zumindest mit denen ich gesprochen habe) Homematik aber über Standardsteuerung... ( war Ingenieur )

Also das Ganze ist sicher ganz am Anfang.

Die Fritzbox ist aber sehr verbreitet. 1und1 ist sicher kein ganz kleiner Anbieter und viel Nutzer dieser Firma haben sicherlich eine Fritz zu Hause. Der Einstieg über diese Box ist darüber hinaus super einfach.
Cul rein fertig.
Einsteiger PDF lesen und schon sehr viele Erfolgserlebnisse haben.
Also Spass auf mehr.
Dann ist leider aber ein Loch ( an dem ich gerade knabber)
und da sollte man ansetzen.


Freetz habe ich schon mal gehört und etwas gelesen, da traue ich mich aber noch nicht ran.
( so jetzt erst mal ein paar max Thermostate installieren )
Schönen Sonntag

[justme1968]

und genau für dieses loch ist eine kleine black box aus z.b. einem raspberry pi und einer fertigen fhem distribution besser als an einem gerät das  eine bestimmte funktion wie telefon oder internet bereitstellen und funktionieren muss mit spitzen fingern irgendeine firmware zu installieren die nicht offiziell vom hersteller kommt. ich denke da ist die hemmschwelle sehr viel größer. zumal die fritzbox wirklich nicht die ideale hardware ist. 

eine solche distribution hätte auch nicht mit den unterschieden zwischen allen möglichen fritzboxen zu kämpfen.

gruss
  andre

[moonsorrox]

@FS_Frank
der Dropbox Link führt zu einer Anmeldung, leider nicht zu den Bildern

@ justme1968
dem stimme ich uneingeschränkt zu, habe auch zwei Fritzboxen am laufen und wollte da nicht ran gehen die kleinen Pi's sind doch absolut ideal dafür, kosten wenig verbrauchen wenig... Absolut ausreichend