[Analyse] Anforderungen an eine moderne GUI

FS_Frank · 20 Mai 2013, 12:03:13

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 · 26 Mai 2013, 11:52:36

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 · 26 Mai 2013, 12:27:34

> 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 · 26 Mai 2013, 12:58:06

Guten Tag allerseits :)

Zitat von: Rince schrieb am So, 26 Mai 2013 11:52Entschuldige, 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.

Zitat von: rudolfkoenig schrieb am So, 26 Mai 2013 12:27> 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 · 17 Juni 2013, 20:34:49

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 · 18 Juni 2013, 19:56:05

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 · 18 Juni 2013, 21:53:24

Zitat von: Johannes schrieb am Di, 18 Juni 2013 19:56Hallo,

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 · 25 Juni 2013, 14:12:10

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 · 26 Juni 2013, 17:34:09

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 · 27 Juni 2013, 17:02:42

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 · 01 Juli 2013, 22:02:08

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 · 02 Juli 2013, 09:07:56

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 · 04 Juli 2013, 10:36:08

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 ;)

Zitat von: oliv06 schrieb am Di, 25 Juni 2013 14:12Could 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?

Zitat von: strauch schrieb am Mi, 26 Juni 2013 17:34Ich 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.

Zitat von: Puschel74 schrieb am Do, 27 Juni 2013 17:02Hallo,

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.

Zitat von: oniT schrieb am Mo, 01 Juli 2013 22:02Hallo,

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!

Zitat von: Rince schrieb am Di, 02 Juli 2013 09:07Autocreate 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 · 06 Juli 2013, 22:19:21

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 · 17 Oktober 2013, 18:40:02

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

Johannes · 18 Oktober 2013, 16:34:56

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

CaptBlaubaer · 25 Oktober 2013, 04:00:35

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.

ZitatEigentlich 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 · 25 Oktober 2013, 08:03:14

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 · 25 Oktober 2013, 11:17:25

Hallo Veit,

Du schreibst

Zitatweshalb 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 · 25 Oktober 2013, 12:47:05

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 · 02 Dezember 2013, 14:35:09

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!

Zitat von: Johannes am 18 Oktober 2013, 16:34:56
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

Zitat von: CaptBlaubaer am 25 Oktober 2013, 04:00:35
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.

Zitat von: volschin am 25 Oktober 2013, 08:03:14
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

Zitat von: CaptBlaubaer am 25 Oktober 2013, 11:17:25
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 · 02 Dezember 2013, 14:46:00

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 · 07 Dezember 2013, 16:23:05

Zitat von: FS_Frank am 02 Dezember 2013, 14:35:09
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 · 07 Dezember 2013, 19:26:08

Zitat von: Strippenzieher am 07 Dezember 2013, 16:23:05
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 · 08 Dezember 2013, 09:38:26

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 · 08 Dezember 2013, 10:55:27

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 · 08 Dezember 2013, 11:09:12

Hallo allerseits!

Zitat von: Franz Tenbrock am 08 Dezember 2013, 09:38:26
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!

Zitat von: UliM am 08 Dezember 2013, 10:55:27
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 · 08 Dezember 2013, 11:35:36

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 · 08 Dezember 2013, 12:10:21

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 · 08 Dezember 2013, 12:34:26

@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

FS_Frank · 08 Dezember 2013, 15:07:16

Zitat von: moonsorrox am 08 Dezember 2013, 12:34:26
@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

Hallo Moonsorrox!

Schaue mal in den Post von mir, während du im FHEM-Forum angemeldet bist (der Post mit der Dropbox) - du müsstest da am Post unten 3 Anhänge sehen, wo die Bilder aus der Dropbox nochmal extra angehangen wurden, die kann man großklicken.

LG Frank

moonsorrox · 08 Dezember 2013, 16:24:23

Zitat von: FS_Frank am 08 Dezember 2013, 15:07:16
wo die Bilder aus der Dropbox nochmal extra angehangen wurden, die kann man großklicken.

die habe ich gesehen, dachte nur es sind noch mehr in der Dropbox

Strippenzieher · 08 Dezember 2013, 19:08:25

Schönen Sonntag Allerseits.

Ist jetzt zwar etwas OffTopic, aber da ich diesen Teilbereich der Diskussion wohl ins rollen gebracht habe,
werde ich mich dazu auch noch kurz oder etwas länger äußern.

Ich bin "Strippenzieher", Volksmund für Elektriker und daher ist mir "Hausautomation" schon seit längerem ein Begriff, um genau zu sein seit ich meine Lehre vor 20 Jahren abgeschlossen habe!!

Ohne irgendwelche analytischen Umfragen tätigen zu müssen kann ich mit meinem Urteilsvermögen bestätigen, dass vielen meiner Kunden ein zusätzliches Gerät,
welches womöglich noch eine extra Bedienungsanleitung braucht, eine sehr widerwillig angenommene Lösung ist die letzten Endes in Kauf genommen wird,
weil es keine Alternative dazu gibt. Es Herrscht auch Großteils die Auffassung, dass es in der hochtechnisierten Welt in der wir jetzt leben, nicht mehr nötig sei
5 Fernbedienungen/Displays auf dem Couchtisch rumliegen zuhaben.

FHEM ist als ein Projekt für Bastler gedacht, nicht für den Massenmarkt, so habe ich das bisher hier auch so verstanden.
Da dieses System Open Source ist spricht nichts dagegen es bis zu einem gewissen Grad auch gewerblich zu nutzen,
das steht aber nicht im Vordergrund und man würde sich auch nur mit fremden Federn schmücken bzw.
evtl. Urheberrechte verletzen, wenn man es als eigenes Produkt verkaufen würde!!!

Wie oben schon angedeutet ist Hausautomation kein Neues MustHave, HA läuft schon seit geraumer Zeit im industriellen und gewerblichen Bereich,
heute unter KNX bekannt, früher hieß es EIB/Instabus zumindest werden die Ansätze dieses Standards seit über 20 Jahren
jedem angehenden Elektroinstallateur mit auf den Weg gegeben.
Rollläden/Jalousien von Gebäuden, Klimaanlagen, Heizsysteme, öffentliche Wege innerhalb und außerhalb von Gebäuden und vieles mehr wird schon sehr lange über HA realisiert.

Die Nachfrage war im Eigenheim nie gering nur der Kostenaufwand für Privatkunden stand viele Jahre nicht im Verhältnis zu den Einsparungen
die dadurch ermöglicht wurden, das hat sich spätestens seit der Energiewende in Deutschland sehr Verändert!!

Meine erste (Licht)Automatisierung habe ich mit 12 Jahren über ein Mikrofon gesteuertes Relais(Bauanleitung) realisiert,
kennt bestimmt noch jemand von euch - Klatschen An, Klatschen Aus.
Ist mir zwar irgendwann durchgebrannt weil ich das Mikro an die Stereoanlage gekoppelt hatte, aber das ist wieder eine andere Geschichte ...

Intertechno Funksteckdosen werden schon eine gefühlte Ewigkeit in Eigenheimen verwendet, also besteht auch in der Form schon eine Ewigkeit
Interesse an einer alternativen Licht-Steuerung/-Automation zum gewöhnlichen Lichtschalter neben der Zimmertür.

Der andere Punkt ist vor solchen Systemen wie Homematic und Powernet war eine HA immer nur durch eine Neu/Nachinstallation
der Elektroanlage zu realisieren, was viele autonormal Verbraucher auch abgeschreckte:

"Ja der Zierstuck ist ja ganz schön den sie sich vor 4 Jahren da an die Decken gemacht haben, aber das müssen wir jetzt abreißen, weil wir laut Installationsvorschrift unsere Leitungen da lang verlegen müssen"

Der aktuelle Hype auf HA ist schlussendlich daraus entstanden, dass die deutschen sehr teuer für die Energiewende bezahlen sollen
und ein paar Energieunternehmen eine sehr gelungene Werbekampagne gestartet haben, denn die Systeme dafür - jetzt mal Homematic und KNX - existiert schon ziemlich lange !!
Bei jedem Kunden, bei dem ich in den letzten 10 Jahren war, der nen Hummer oder Bentley in seiner Garage zu stehen hatte, war auch eine KNX-HA in der Villa verbaut.
Nicht unbedingt um Kosten zu sparen, eher um ihrem Luxus zu frönen, ich will damit nur verdeutlichen, dass HA nichts neues ist.
Es ist nur nicht dem "niederem" Volk, sprich für einen schmalen Taler zur Verfügung gestellt worden ... die Fritzbox jedoch schon ^^

Die Fritzbox, wie ein Franz schon meinte:

Zitatsteht heute schon in sehr vielen Haushalten

Das kann ich bestätigen. Ich selbst empfehle die Fritte den autonormal Kunden immer wieder ^^
Sie

Zitatist ausgereift, sparsam wird super weiterentwickelt etc.

Was man an der neuen 7490 sehr gut erkennen kann:
Dualcore Prozessor für den Router Part und jeweils einen Prozessor für DECT/USB und für 2,4GHz/5GHz WLAN.

Auf der Fritzbox läuft ein abgespecktes Linux, allem Anschein nach eine Art Debian, aber da hört mein Fachwissen darüber aber auch schon auf da ich von OS's nicht viel verstehe.
Man "kann" sie mittels eines Open Source Projekts "freetzen", es geht aber wohl sie auch anders zu "fritzmodden", was beides aber nicht so einfach ist und auch jegliche Garantieanspruche der Hardware in den Wind belässt.

Die Fritzbox wurde im Zusammenhang einiger Updates mit Titel: "Laborversion" schon mal mit Fhem "verheiratet", ob das aktuell noch so ist, kann ich nicht bestätigen,
da AVM inzwischen ja auch ein eigenes "SmartHome" auf der Fritzbox anbietet.
Die Fritzbox ist und bleibt in erster Linie ein Router, ein wirklich sehr guter Router für den Preis(auch wenn Betateilchen das anders sieht), alles weiter ist halt ein Experiment.
Ich für meinen Teil würde es begrüßen wenn die Fhem-Entwickler die Fritzbox in ihre Programmierungen immer berücksichtigen würden, aber das müssen sie für sich selber entscheiden.

Mal abgesehen von der Fritzbox sollte man aber immer im Hinterkopf behalten, dass die Entwickler-Umgebung nicht gleich die User-Umgebung ist.

In deinem Projekt muss man folglich davon ausgehen, dass jeder einen Webserver zuhause hat was, wenn du das genau so ließt wie ich, fern der Realität ist.
Sowas haben für gewöhnlich nur Leute zuhause, die sich mit Webdesign und ähnlichem beruflich oder privat auch beschäftigen.

EDIT:
Ich zumindest habe (noch) keinen Webserver und keine SQL-Datenbank 24/7 zuhause am laufen und außer in Zukunft evtl. für Fhem wüsste ich auch nicht wofür, dafür gibt es Internet Service Provider ...

Ist etwas länger als "länger" geworden, ich hoffe aber dass damit der Teilbereich "Fritzbox" in diesem Thread zu einem friedlich Ende führt und wir uns wieder der
Analyse zu Anforderungen an eine "moderne" GUI widmen können ...

MFG Chris

mangei.markus · 09 Dezember 2013, 12:43:17

@Strippenzieher:

Mit ziemlich hoher Sicherheit werden auch bei dir einige Datenbankserver laufen, sehr viele Desktopanwendungen verwenden diese, um interne Datenstrukturen zu verwalten. Beispielsweise nutzen Firefox, Android und Safari intern eine SQLite Datenbank. Ab einer gewissen Datenmenge und Komplexität der Datenstrukturen können Datenbanken einfach ihre Stärken ausspielen und da steigt irgendwann eben auch die Fritzbox aus.

Gruß Markus

Strippenzieher · 09 Dezember 2013, 14:31:35

Zitat von: mangei.markus am 09 Dezember 2013, 12:43:17
@Strippenzieher:

Mit ziemlich hoher Sicherheit werden auch bei dir einige Datenbankserver laufen, sehr viele Desktopanwendungen verwenden diese, um interne Datenstrukturen zu verwalten. Beispielsweise nutzen Firefox, Android und Safari intern eine SQLite Datenbank. Ab einer gewissen Datenmenge und Komplexität der Datenstrukturen können Datenbanken einfach ihre Stärken ausspielen und da steigt irgendwann eben auch die Fritzbox aus.

Gruß Markus

Dem kann ich nicht widersprechen da ich, wie schon andeutete, Softwareseitig nicht wirklich eine Ahnung habe was da in meinen Rechnern in Hintergrund passiert.
Was deine expliziten Beispiele angeht nutze ich Firefox nur wenn IE gar nicht mit der Webseite klar kommt(5/500x). Android .. naja sagen wir es mal so, ich würde mir lieber den alten Bananaknochen von Nokia ans Ohr legen als mit einem Android rum zu laufen, habe ein WP8 was sicherheitstechnisch in meinen Augen auch bedenklich ist ... Und ein Mac oder IPhone habe ich auch nicht. Das wäre mal meine Ausgangsituation z.B.

Mal abgesehen davon sind die Beispiele temporärer Natur, wenn ich meine 1000W Rechenmaschine zuhause aus mache sollte die Heizung nicht aus gehen ^^
Es ist aktuell eher aus zuschließen, das jeder Haushalt einen NAS 24/7 am laufen hat und somit auch keine SQL-Dantenbank 24/7 läuft, mal abgesehen jetzt von der Kompetenz einer/m Hausfrau/mann unter das NAS OS einen SQL-Server zu schmuggeln.
Und es ist ja möglich eine SQLite auf der Fritte das gehen bei zubringen, nur eben äußerst schwierig für Anfänger-Nerds und auch mit Risiken verbunden.

Aufgrund der Richtung in die sich die Programmierungen von Fhem entwickeln, insbesondere was GUI's angeht, habe ich diesbezüglich auch einen Thread bei Fritzbox eröffnet in dem nach Erweiterungsmöglichkeiten für die Fritzbox gesucht wird. Apache mit PHP und SQLite ist schon bei einigen auf der Fritte am laufen, ich bin nur momentan von meiner Fritte getrennt(Ich Schweiz,Fritzbox Deutschland), sonst würde ich auch noch andere Erweiterungen selber checken, wie z.B. Fritzdebian (Lenny?).

Aber es geht ja auch nicht um die Fritzbox hier ...
Einerseits wollte ich mal erläutern, dass Hausautomation keine neue Erfindung ist, und anderseits wollte ich mal andeuten,
dass in jener "Analyse" einige Faktoren nur passiv wahr genommen wurden bzw. nicht mit einbezogen wurden.
Also in die Anforderungen an einem modernen GUI auch die Anforderungen des GUI's selbst mit ein zu beziehen und ob jene auch für die moderne Hohlbirne realisierbar sind.

Ansonsten finde ich die Arbeit von FS_Frank(Team) ja super.
Sieht sehr Überschaubar aus und denke mal die GUI selbst wird auch Anwenderfreundlich ungesetzt.

MFG Chris

FS_Frank · 16 Dezember 2013, 16:34:22

Hallo allerseits!

Ich möchte euch nur einmal darüber informieren, dass ich mal wieder alles - was hier diskutiert wurde - gesammelt und zusammengefasst (und aufbereitet) habe. Ich werde die angesprochenen Punkte noch weiter mit meinem Kommilitonen (Rick) diskutieren und es dann an das gesamte Forschungsseminar zur Diskussion weiterbringen.

Bis dahin danke ich weiterhin für die sehr schöne Diskussionskultur und Anregungen und Ideen, die hier kommen.

Uns fällt vor allem auf, dass hier sehr viele Blickwinkel und Welten zusammenfallen. Exemplarisch möchte ich hier einmal unseren Elektriker, Hausarzt und Informatiker nehmen, der miteinander redet. Es ist immer wieder ein sehr (und das ist positiv gemeint^^) großer Spagat, den man hier stemmen muss. Das lohnt sich aber sichtlich!

Ich würde daher noch einmal bezüglich einer SQLite-Datenbank ein wenig Klarheit schaffen:

Das ist kein Datenbankserver, den man 24/7 am Laufen hat. Das ist ein eingebettetes Datenbanksystem oder ganz einfach gesagt: Eine einzige Datei, die man hat. In der sind die z.B. unkenntlich gemachten Passwörter (wen es interessiert, kann sich mit dem Thema Hash und Salt auseinandersetzen) liegen. Es ist also kein SQL-Server per se, der Rechenleistung und dergleichen benötigt.

Es ist vielmehr so, dass PHP das ab einer bestimmten Version integriert hat.

LG Frank

Matthias · 21 Dezember 2013, 11:29:45

Hi,

warum muss denn eigentlich immer eine komplett neue GUI entwickelt werden? Wie bereits angesprochen gibt es schon x Varianten - und jede steht für sich allein. Wie wäre es denn FHEMWEB zu erweitern? Das ist bereits bei einer breiten Nutzerbasis installiert, hat einen festen Entwicklerstamm und läuft auch - ohne Anpassungen, zusätzliche Installationen o.ä. - auf der FritzBox. Mir ist natürlich aus eigener Erfahrung bewusst, dass Uni-Projekte normalerweise für sich stehen. Für ein OpenSource Projekt ist dies allerdings _nicht_ von Vorteil.

So ganz nebenbei ist es natürlich in Perl geschrieben und nicht in PHP. Ich war noch nie ein Fan davon Programmiersprachen an die Entwickler anzupassen. Es sollte eben die Sprache verwendet werden, die am Besten zum Projekt passt. Das ist für FHEM traditionell Perl. Verargumentieren kann man das an der Uni natürlich auch - oder geht ihr davon aus nach dem Studium nur PHP zu brauchen?

Bitte diesen Post nicht negativ auffassen - ich möchte keineswegs (zukünftigen) Entwicklern vor den Kopf stoßen. Ich denke nur, dass bestimmte Entwicklungen für das Gesamtprojekt nicht von Vorteil sind.

So far,
Matthias

fhainz · 21 Dezember 2013, 12:08:36

Also ich hoffe wirklich auf eine neue gui.
HTML 5, CSS3, usw haben immense vorteile. Die vorhandene fhemweb zu erweitern würde nichts bringen. Schau die mal den html code an den fhemweb generiert..

Und wenn die neue gui auf deiner fb nicht läuft musst die sie ja nicht nutzen. Oder du holst dir für 40€ ein raspi und die sache hat sich.

FS_Frank · 21 Dezember 2013, 14:06:39

Huhu alle miteinander!

Zitat von: Matthias am 21 Dezember 2013, 11:29:45
Hi,

warum muss denn eigentlich immer eine komplett neue GUI entwickelt werden? Wie bereits angesprochen gibt es schon x Varianten - und jede steht für sich allein. Wie wäre es denn FHEMWEB zu erweitern? Das ist bereits bei einer breiten Nutzerbasis installiert, hat einen festen Entwicklerstamm und läuft auch - ohne Anpassungen, zusätzliche Installationen o.ä. - auf der FritzBox. Mir ist natürlich aus eigener Erfahrung bewusst, dass Uni-Projekte normalerweise für sich stehen. Für ein OpenSource Projekt ist dies allerdings _nicht_ von Vorteil.

So ganz nebenbei ist es natürlich in Perl geschrieben und nicht in PHP. Ich war noch nie ein Fan davon Programmiersprachen an die Entwickler anzupassen. Es sollte eben die Sprache verwendet werden, die am Besten zum Projekt passt. Das ist für FHEM traditionell Perl. Verargumentieren kann man das an der Uni natürlich auch - oder geht ihr davon aus nach dem Studium nur PHP zu brauchen?

Bitte diesen Post nicht negativ auffassen - ich möchte keineswegs (zukünftigen) Entwicklern vor den Kopf stoßen. Ich denke nur, dass bestimmte Entwicklungen für das Gesamtprojekt nicht von Vorteil sind.

So far,
Matthias

Hallo Matthias. Keine Sorge, ich fasse diese Post nicht negativ auf. Das ist konstruktive Kritik und du hast deine Meinung dazu beigetragen. Sowas ist schön, gibt uns immer neue Betrachtungswinkel und ist gut. Ich mag es nur nicht - das ist hier aber nie vorgekommen - wenn jemand beleidigend wird oder derartig Kritik äußert, dass es keine Kritik, sondern ein 'Trollpost' oder 'Flame' wird. Das ist aber wie gesagt hier nicht der Fall und wir haben denke ich schon alle einen sehr schönen Umgang miteinander.

Aber zu deinem Thema:

Puuh, wie fange ich da an? Zu aller erst einmal möchte ich sagen, dass das Problem mit den jetzt drei (laut meiner Rechnung?) momentan aktiv parallel laufenden GUIs für FHEM das Problem ist, dass jeder für sich entwickelt und jeder zwar sehr schöne Dinge in seiner GUI hat, aber manch andere Dinge vielleicht vergessen könnte.

Aus eben diesem Grund wurde es von uns als sinnvoll erachtet, mal eine Analyse für die gesamte Community aufzuziehen, um zu sehen, was denn Sinn macht und was nicht. Diese Analyse ist das Hauptziel der Forumsdiskussion. Die funktionalen und nichtfunktionalen Anforderungen sind für alle einsehbar und frei verwendbar. Man muss sie nicht nutzen, kann es aber tun. Damit wollten wir die Grundlage dafür legen, dass zukünftige Entwickler schon einmal einen Grundstamm an Informationen haben. Wir wollen aber keinen in seiner Entwicklung einschränken und die Menschen durchaus ermutigen, auch ihre eigenen Projekte anzufangen. Klar gibt es da eine gewisse Fluktuation mit eingestellten Projekten - keine Frage - aber die Vielfalt hat nicht nur Nachteile.

Auf der Basis dieser Informationen entwickeln wir im Rahmen der Uni eine eigene GUI, das ist korrekt. Wir wollen zum einen damit zeigen, dass unsere momentane Anforderungsanalyse verwendbar ist und was man mit momentanen Entwicklungen machen kann.

Zu Perl:
Das werden die Entwickler dieses Forums vielleicht nicht so gerne hören, aber Perl ist für Webentwicklungen nicht die ultimative Sprache. Das ist natürlich meine persönliche Meinung, aber wir haben eine Abwägung zwischen Perl und PHP+JS gemacht (die könnt ihr auch im Forschungsbericht einsehen, das ist kein Geheimnis). Was man in Perl macht, ist eigentlich nur auf indirektem Wege sein HTML zu basteln. Dass passiert auch noch auf eine - in meinen Augen - äußert komplizierte und rückständige Weise, wo man als Student von heute die Krise kriegt.

Dass Perl für die gesamte Kommunikationsabwicklung mit den Sensoren und Co. sehr gut ist, das streite ich keinesfalls ab. Da würde man denke ich in PHP sterben, wenn man das versuchen wollte. Was wir hier machen ist einfach nur noch FHEM als unser 'Model' in einem MVC-Muster zu betrachten und wir einen eigenen Controller und View (für die Website natürlich betrachtet) machen.

Hinzu kommt: In Universitäten wird bei Informatikern - in unserer Stadt gibt es neben einer Uni auch Hochschule und BAs - PHP und co. prinzipiell mit beigebracht. Eine Perl-Ausbildung? Keine Chance. Das hat in meinen Augen auch gewisse Gründe.

Worauf ich hinaus will: Wenn hier jeder ein Perl-Projekt anfängt und mal die jetzt momentan fertig Studierten sich hierfür engagieren wollen, dann ist diese reine PERL-Entwicklung einfach total abschreckend. Das meine ich wirklich nicht böse, aber in unserem Studiengang redet man von Perl und winkt schon ab. Ist natürlich etwas subjektiv belastet, aber ich hoffe ihr könnt euch vll. auch in die heutigen Studierenden versetzen, die ihr bereits Gelerntes schon anwenden wollen und nicht mal eben eine neue Sprache lernen wollen, nur um über Umwege HTML zu generieren und JS einzubauen, wenn es auch direkt geht.

Schaut euch mal an wie viele entwicklungsunterstützende Tools für JS und PHP gibt und wie viele Unterstützungen es für PERL-Module gibt, die dasselbe machen. Oder informiert euch mal darüber, wie viele Webserver die man heute mieten kann noch PERL und kein reines PHP installiert haben.

Ehrlich gesagt ist es vll. sogar vorteilhaft für das Gesamtprojekt, wenn man etwas mehr in Richtung von 'häufig benutzten' Sprachen geht und so mehr Entwickler für sich gewinnen kann.

Zitat von: fhainz am 21 Dezember 2013, 12:08:36
Also ich hoffe wirklich auf eine neue gui.
HTML 5, CSS3, usw haben immense vorteile. Die vorhandene fhemweb zu erweitern würde nichts bringen. Schau die mal den html code an den fhemweb generiert..

Das würde ich auch so unterschreiben. Wie gesagt, ich betone aber nochmal: Das ist meine subjektive Meinung. Aber mit Perl werden wir nicht entwickeln, das möchten wir denen überlassen, die das mit Herzblut machen. An unserer Hochschule wird man damit aber wenig Freunde haben.

Vor dem neuem Jahr werde ich erst einmal nichts schreiben.

Ich wünsche euch allen frohe Weihnachten und einen guten Rutsch ins neue Jahr!

LG Frank

FS_Frank · 27 Januar 2014, 17:51:00

Sehr geehrte Damen und Herren, liebe FHEM-Gemeinde,

Das Semester neigt sich dem Ende und ich möchte euch nun den aktuellen Stand offenlegen. Ich habe das - damit Neulinge es auch schneller finden - ebenso im Eingangspost editiert.

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.

Mit besten Grüßen,
Frank