FHEMWEB: dynamische Setup Wizards

Begonnen von DeeSPe, 24 April 2017, 11:39:10

Vorheriges Thema - Nächstes Thema

DeeSPe

Wäre es, gerade für Einsteiger, nicht toll FHEM etwas mehr Wizard-gesteuert einzurichten?

Ich denke darüber nach wie man Einsteigern den Einstieg in FHEM etwas erleichtern kann.
Meine Ideen gehen hier von z.B. einem Firstrun-Wizard bis hin zu einem typischen Add-Wizard zum Anlegen neuer Devices.
Der Firstrun-Wizard in FHEMWEB, fragt z.B. grundlegende Attribute der FHEMWEB Instanzen ab, erklärt und setzt sie (basicAuth,....,.....).
Der Add-Wizard (mit typischer + Schaltfläche in FHEMWEB) würde jeden Schritt einer Device Einrichtung abfragen, angefangen von Namen, über Modul (Dropdown vorhandener Module?) und Abfrage der zusätzlich nötigen/optionalen Parameter.

Das sind bisher nichts weiter als Ideen, die ich hiermit zur Diskussion stellen möchte.
Wäre das überhaupt machbar?
Könnte das evtl. sogar über schon bestehende Einträge in den Moduldateien ("Usage: define <NAME> <MODUL> <MANDATORY1> <MANDATORY2> [OPTIONAL]") realisiert werden, oder müssten evtl. neue "=item" dafür her?

Freue mich auf eine spannende Diskussion!

Gruß
Dan
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Als kleine Unterstützung für meine Programmierungen könnt ihr mir gerne einen Kaffee spendieren: https://buymeacoff.ee/DeeSPe

marvin78

Du bist nicht der erste, der diese Diskussion startet, alle waren fruchtlos (aus guten und nachvollziehbaren Gründen). Ich bin aktuell der Meinung, dass man diese Dinge in FHEM nicht braucht und es auch nicht realistisch ist, sowas umzusetzen, da es niemals vollständig sein kann (Es gibt nichts schlimmeres als Unvollständigkeit) und weil diejenigen, die sowas umsetzen müssten, es eigentlich selbst nicht bräuchten. Ich bin trotzdem gespannt, wie dieses Diskussion diesmal verläuft. Die Community ist ja gewachsen.

Thorsten Pferdekaemper

Hi,

ich glaube, dass das ein gigantischer Aufwand wäre, dem relativ wenig Nutzen gegenüber steht. Natürlich könnte man sozusagen als Default etwas generisches machen, aber das würde praktisch nichts bringen. (Mal davon abgesehen, dass Module in FHEM nur dann geladen werden, wenn mindestens ein Device dafür definiert ist.)
Möglicherweise gibt es ein paar Spezialfälle (wie z.B. das erstmalige Einrichten von FHEMWEB), bei denen so etwas sinnvoll sein könnte. Allerdings fällt mir da jetzt auch nichts ein außer Benutzername und Passwort.

Von wegen Einrichtung neuer Devices: Z.B. bei "meinen" HMW-Teilen muss man zum Einrichten gar nichts machen, außer am Ende "Save config" zu drücken. Meiner Meinung nach sollte das der Normalfall sein.

Wenn ich mir überlege, was an "guten" Wizards eigentlich gut ist, dann ist das meistens die zum Kontext passende Dokumentation. Da wäre es aber meiner Meinung nach wichtiger, so etwas erst einmal auf der Oberfläche selbst zu erlauben. Ich denke, dass man relativ einfach generisch etwas bauen könnte, mit dem man an jedes Element ein bisschen Beschreibung hängen kann.
Außerdem könnte man sich überlegen, die Fehlermeldungen etwas nützlicher zu gestalten, also so, dass sie nicht einfach wieder vom Bildschirm verschwinden und vielleicht auch einen Langtext mit Links etc. haben können.

Gruß,
   Thorsten
 
FUIP

KernSani

Hi,

ich stimme Thorsten im Großen und Ganzen zu, ein Wizard um FHEMWEB oder andere Module einzurichten hat nur stark eingeschränkten Nutzen. Ich denke Szenario-basierte Wizards würden viele Einstiegshürden verringern, also ein Wizard zur Einrichtung Basic Authentication, ein Wizard für Rollladen auf/zu bei Sonnenauf-/untergang, einer für die Waschmaschine fertig Meldung, einer für Fenster offen Warnung... Damit könnte sich der Anfänger eine Grund-Automatisierung aufbauen ohne sich mit Deines, Attributen, Readings, Events, dummies, notifies und ats herumzuschlagen... Manche Module (Ich denke da z.B. an den RESIDENTS-Wecker) machen sowas in der Art ja schon. Die Frage ist, was dem Anwender mehr bringt (und den Entwickler entlastet), sich per Wizard was zu erstellen, was er dann nicht versteht und dann zu verzweifeln oder von Grund auf selbst bauen (auf Basis von WIki, Forum etc...) und es dabei richtig zu lernen...

Grüße,

Oli
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

CoolTux

Es gibt ja Ansätze für eine einfachere Installation einiger Komponenten.
Angefangen von den bereits existierenden Autocreate bis hin zu Andres aktueller Überlegung und Teilumsetzung von autoscan eines Netzwerkes und somit automatischer Definierung von gefundener und unterstützter Netzwerkhardware.
Leider habe ich von Jörg ne Weile nichts mehr gehört, er ist auch reglich bemüht eine saubere BT Implementierung samt automatischer Erkennung und Definierung von Devices zu entwickeln. Dauert aber alles etwas wenn es gut werden soll.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

DeeSPe

Danke für Eure Antworten.

Mein Ansatz wäre Device-basierte Wizards so unkompliziert wie möglich anzugehen, evtl. sogar mit schon bereits in den Modulen enthaltenen Daten so dass im besten Fall kein Entwickler etwas zusätzlich einpflegen müssten.
Szenario-basierte Wizards halte ich allerdings für noch schwieriger als Device-basierte Wizards, denn Devices kann es nur die geben die auch ein Modul haben, Szenarien kann ich mir X-beliebig viele ausdenken. Um gewisse "Standard-Szenarien" eines jeden Haushalts abzudecken habe ich z.B. das HOMEMODE Modul entworfen.

Wahrscheinlich ist die Diskussion aber hinfällig, denn FHEM ist schließlich nicht für die "breite Masse" gedacht, die mal eben nebenbei alles einrichtet, sondern es bedarf eben einer gewissen (steilen) Einarbeitungskurve.

Gruß
Dan
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Als kleine Unterstützung für meine Programmierungen könnt ihr mir gerne einen Kaffee spendieren: https://buymeacoff.ee/DeeSPe

Thorsten Pferdekaemper

Zitat von: DeeSPe am 27 April 2017, 12:14:24
Mein Ansatz wäre Device-basierte Wizards so unkompliziert wie möglich anzugehen, evtl. sogar mit schon bereits in den Modulen enthaltenen Daten so dass im besten Fall kein Entwickler etwas zusätzlich einpflegen müssten.
Kannst Du mal ein Beispiel geben? Ich denke mal, dass Dein FHEMWEB-Beispiel vom Anfang so schonmal nicht funktionieren dürfte...
Gruß,
   Thorsten
FUIP

DeeSPe

Zitat von: Thorsten Pferdekaemper am 27 April 2017, 19:31:29
Kannst Du mal ein Beispiel geben? Ich denke mal, dass Dein FHEMWEB-Beispiel vom Anfang so schonmal nicht funktionieren dürfte...
Gruß,
   Thorsten

Ich gebe Dir Recht, FHEMWEB wäre schon wieder ein Spezialfall wegen Ersteinrichtung.
Die meisten (alle?) Module geben doch aber eine Rückmeldung wenn Sie nicht vollständig mit allen Parametern konfiguriert werden.
z.B.:
return "Usage: define <name> <MODUL> <IP> <PORT> [<INTERVAL>]" if (@args < 4);

Statt es in FHEMWEB nur anzuzeigen, könnten doch die fehlenden Parameter abgefragt werden!?

Gruß
Dan
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Als kleine Unterstützung für meine Programmierungen könnt ihr mir gerne einen Kaffee spendieren: https://buymeacoff.ee/DeeSPe

Thorsten Pferdekaemper

Hi,
mit Beispiel meinte ich ein konkretes Modul. Ich wüsste jetzt nämlich keins, bei dem das was bringen würde.
Gruß,
   Thorsten
FUIP

DeeSPe

Na im Prinzip alle Module die "(@args > 2)" haben.

Gruß
Dan
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Als kleine Unterstützung für meine Programmierungen könnt ihr mir gerne einen Kaffee spendieren: https://buymeacoff.ee/DeeSPe

Thorsten Pferdekaemper

Hi,
ok, dann nehmen wir mal z.B. HM485_LAN her. Da käme die Meldung...

wrong syntax: define <name> HM485 {none | hostname:port}

Selbst wenn man das jetzt in eine allgemeine Form bringen würde. Und dann? Im Prinzip könnte man ein Eingabefeld bringen, in das man hostname und port eingibt. Oder zwei Felder für die beiden. Ich denke aber, dass das nicht viel hilft, insbesondere da man meistens noch weitere Attribute richtig setzen muss, damit es wirklich tut.
Vielleicht bringt es ein bisschen was, aber da steht Aufwand und Nutzen in einem sehr schlechten Verhältnis.
Schon hier bräuchte man eine Art Szenario-Wizard, der abfragt, welche Hardware jemand hat etc.

Vielleicht hast Du ja doch noch ein besseres Beispiel.

Was meiner Meinung nach sehr viel bringen könnte wäre eine andere Herangehensweise für Fehlermeldungen, wie schon gesagt. Momentan bekommt man ein lapidares "wrong Syntax...". Besser wäre, wenn so eine Fehlermeldung eine Beschreibung hätte mit Links zur richtigen Gerätedoku. Das wäre vielleicht gar nicht so schwierig zu machen und hätte meiner Meinung nach bessere Chancen, eine große Wirkung zu erzielen.

Gruß,
   Thorsten


 

FUIP

DeeSPe

Es sollte nur ein möglicher Verbesserungsvorschlag zur Diskussion gestellt werden.
Wenn daran kein Interesse besteht, auch gut.
Evtl. ist das nicht so leicht umzusetzen wie ich mir dachte und evtl. macht es auch nur begrenzt Sinn. Genau deswegen diskutieren wir das ja hier. ;)

Die Idee die commandref des jeweiligen Moduls im "wrong Syntax" Fall zu verlinken wäre m.E. ein weiteres Nachdenken wert, denn das sollte wirklich relativ leicht umzusetzen sein und könnte einen kleinen Mehrwert bieten.

Gruß
Dan
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Als kleine Unterstützung für meine Programmierungen könnt ihr mir gerne einen Kaffee spendieren: https://buymeacoff.ee/DeeSPe

Thorsten Pferdekaemper

Zitat von: DeeSPe am 28 April 2017, 09:18:24Es sollte nur ein möglicher Verbesserungsvorschlag zur Diskussion gestellt werden.
Das finde ich auch gut. Es kann halt passieren, dass bei solchen Ideen jemand (in dem Fall ich) auf den Zug aufspringt und versucht, ihn in eine etwas andere Richtung zu lenken.

Zitat
Die Idee die commandref des jeweiligen Moduls im "wrong Syntax" Fall zu verlinken wäre m.E. ein weiteres Nachdenken wert, denn das sollte wirklich relativ leicht umzusetzen sein und könnte einen kleinen Mehrwert bieten.
Das wäre meiner Meinung nach etwas zu kurz gesprungen. Was mir vorschwebt ist eine Art integrierte Hilfe-Funktion, die etwas über das Anzeigen der Commandref (siehe help-Kommando) hinausgeht. Natürlich kann man die Commandref immer als Fallback hernehmen, aber was mir vorschwebt ist etwas mehr.

Meiner Meinung nach wäre es schön, wenn man an so ziemlich jedes FHEM-Element einen Hilfetext (und vielleicht auch noch Notizen vom Benutzer) hängen könnte, und zwar unter Umständen sogar unabhängig vom jeweiligen Modulautor. (Ich habe dazu auch schon mal einen Prototypen angefangen, aber der kennt momentan halt auch nur die Commandref...)
Für Fehlermeldungen sind das bisher meine Ideen:
Es gibt glaube ich (wenn man mal von einem Totalabsturz absieht) drei Arten von Meldungen in FHEM:

  • Die Meldungen, die beim Ausführen eines Kommandos in FHEMWEB auftauchen. Diese werden auf einer neuen Seite angezeigt und bestehen meist aus einem kurzen Text. Das sind auch die Meldungen bei einem fehlerhaften define.
  • Meldungen, die als "Toast"-Messages für ein paar Sekunden erscheinen und dann wieder verschwinden. Das ist z.B. die "Connection lost"-Meldung. Es gibt aber auch andere.
  • Meldungen im log. Die können natürlich dieselben sein wie die ersten, aber es gibt noch etwas mehr davon.

Wir könnten jetzt "irgendwie" ermöglichen, dass man zu jeder dieser Meldungen noch einen beschreibenden Text verfasst. Das kann z.B. einfach eine Datei sein, deren Namen einem bestimmten Schema entspricht. Dazu müsste man natürlich den Meldungen noch einen "Schlüssel" (z.B. eine Nummer) mitgeben. Teil des Schlüssels sollte das auslösende Modul sein. Wenn es keine solche Datei gibt, dann kann man den entsprechenden Eintrag aus der Commandref holen. Das gilt auch für Fälle, bei denen es (noch) keinen Schlüssel gibt. Dann halt einfach allgemein die Modul-Doku.

Von der Darstellung her könnte das dann so laufen (Kategorien wie oben):

  • Hier haben wir eh Platz auf dem Screen. Der ganze Text kann im Prinzip angezeigt werden.
  • Statt der Toast-Message, die verschwindet, sollte es einen Bereich geben, der für Meldungen "reserviert" ist. Das sollte in FHEMWEB immer gleich sein. Dort könnten die Meldungen als Link erscheinen. D.h. die Meldung sieht so aus wie bisher, kann aber angeklickt werden.
  • In der Log-Anzeige dürfte es einfach sein, Links zu setzen...

Ich weiß, dass das alles noch überhaupt nicht ausgegoren ist...

Gruß,
  Thorsten

FUIP

Georg312

Hallo,

ich verstehe nicht wo die Aussagen herkommen, dass Wizards für FHEM keinen Sinn machen. Es gibt sie schließlich bereits. Beispiel Plots: Am Anfang von FHEM war das grafische Darstellen eines Temperaturverlaufs definitiv mit mehreren Stunden Doku/Forum-lesen verbunden. Absolut nicht einsteigertauglich. Seit einiger Zeit gibt es aber unter den Filelogs die Funktion (Wizard) "Create_SVG_Plog". Hiermit schafft es nun jeder innerhalb von Minuten ein Diagramm zu erzeugen, dass für 90% der Fälle auch ausreichend ist. Trotzdem gibt es erweiterte Features, die sich nach wie vor nur durch Handbuch lesen erschließen.

Was für Einsteiger hilfreich wäre ist eine Funktion "Ereignisgesteuerte Geräteschaltung anlegen". In einer Liste wird zuerst das ereigniserzeugende Gerät ausgewählt, dann ein mögliches Ereignis (open, closed, on, off, ...), das zu schaltende Gerät und den Befehl (on, off, ....). Sowas würde für schnelle Erfolgserlebnisse sorgen.


Thorsten Pferdekaemper

Zitat von: Georg312 am 07 Mai 2017, 12:18:27ich verstehe nicht wo die Aussagen herkommen, dass Wizards für FHEM keinen Sinn machen.
Also aus diesem Thread hier so explizit zumindest nicht.

ZitatEs gibt sie schließlich bereits. Beispiel Plots: Am Anfang von FHEM war das grafische Darstellen eines Temperaturverlaufs definitiv mit mehreren Stunden Doku/Forum-lesen verbunden. Absolut nicht einsteigertauglich. Seit einiger Zeit gibt es aber unter den Filelogs die Funktion (Wizard) "Create_SVG_Plog".
Das ist meiner Meinung nach kein Wizard. Ein Wizard ist eine Abfolge von einzelnen Dialogen, bei dem jeweils immer nur ein Aspekt (oder eben sehr wenige Aspekte) abgefragt wird. Das ist hier nicht so. Das ist eher eine halb-grafische Einstellungsseite mit Ausfüllhilfe. Ich will damit nicht sagen, dass es schlecht ist. Es ist halt kein Wizard. (...und das ist gut so.)

ZitatWas für Einsteiger hilfreich wäre ist eine Funktion "Ereignisgesteuerte Geräteschaltung anlegen".
Das gibt's schon. Einfach im Event Monitor auf "Create/Modify Device" klicken. Damit kann man z.B. ein passendes notify anlegen. Im notify-Editor kann man sich dann z.B. ein set-Kommando zusammenklicken.
Das ist aber auch kein Wizard.

Zitat
In einer Liste wird zuerst das ereigniserzeugende Gerät ausgewählt, dann ein mögliches Ereignis (open, closed, on, off, ...),
So wäre das schwierig zu realisieren, da FHEM die möglichen Ereignisse nicht kennt. Deshalb fängt man im Event Monitor an.

Ich bin absolut für solche Vereinfachungen, so lange es auch noch die Möglichkeit gibt, den ganzen Kram über "klassische" FHEM-Kommandos einzugeben. Sonst hätte ich nicht HM485 aufgepimpt. (Siehe Anhang.)
Ich wage aber zu bezweifeln, dass Wizards wirklich das Mittel der Wahl sind. Wie aber von KernSani schon gesagt, kann es schon sein, dass es bestimmte Szenarien gibt, wo ein Wizard sinnvoll wäre.

Gruß,
   Thorsten
FUIP