FHEM - Entwicklung > Wunschliste

fhem 4 Nerds or users?

(1/17) > >>

martinp876:
ich werde in diesem Thread thematisieren, wie ich fhem aus Anwendersicht sehe, warum ich meine dass es verbessert werden sollte und auch ein paar Vorschläge machen. Da in der Natur der Sache liegt, dass ich viel meckern werde vorne weg einmalig ein paar Statements von mir:
- es gibt (sehr) viele gute Dinge in fhem - diese sind nicht mein Thema. Also sorry, wenn ich das nicht immer erwähne.
- es gibt sehr viele bessere und kompetentere Personen und Entwickler bei FHEM als mich. Auch hier werde ich bei meinen Aussagen keine Rücksicht nehmen, es geht mir um den Inhalt.
- ich werden in einzelnen Posts Themen ansprechen - wild gewürfelt - um darzulegen, wo ich potential sehe und mir eigentlich Änderungen wünsche
- einige Anpassungen würden einen Paradigmenshift benötigen. Viel in fhem ist gewachsen, nicht designt. Ich halte es dennoch für wert, hier Anpassungen durchzuführen.

? Warum Änderungen, klappt doch alles. Diese Frage ist gerechtfertigt.
Nun, erst einmal stellt sich die Frage, für wen fhem gedacht ist. In der homeautomation gibt es einige Rollen:
+ User - nutzt das System zu hause. Bsp: meine Frau. Sie will noch nicht einmal wissen, dass FHEM in Einsatz ist. Keine Programmierkenntnisse, kein Bedarf. Aufgaben: Schaltet Lichter ein (wenn es nicht automtisch geht) und liest Wettervorhersagen.
+ Admin(istrator) - betreut das system, wechselt rechtzeitig Batterien, erkennt Probleme (Fehler, tote Devices) und kann diese bedingt beheben. Das macht auch meine Frau
+ designer - setzt das System auf. Entscheidet oder realisiert die Technologie. Erstellt Verknüpfungen. Kümmert sich um Ausfallsicherheit und Konzepte. Das ist der eigentliche FHEM-Kunde.
    Zu unterscheiden sind 2 extreme: Nerd versus User. Der User will einfache Konzepte, devices in das System einzubinden (virtuelle oder physische). Das System muss alle notwendigen und typischen Einstellungen automatisch vornehmen. Devices sollten im Default  hochkommen. Einige, möglichst wenige Einstellungen können vorgenommen werden und sind als solche zu erkennen. Eine Flut von Optionen ist nicht zielführend.
    Der Nerd will viele Optionen - und mehr noch - automatismen (oder diese erstellen können) um sein System zu konfigurieren.

Bei den Anwendern vergleich ich einmal mit Appel, Andriod, windows, linux.
Appel Anwender erklären mir uni sono dass das System macht, was man will - ohne dass man viel einstellen muss. geht einfach.
Android geht in eine ähnlich Richtung, lässt mehr zu, hat mehr Probleme
Windows ist hier  noch deutlich hinter Andriod, holt aber auf mit app handling.
Linux nun ist klar auf dem Nerd level. Ich richte gerade einen neuen Raspberry ein. Das macht evtl einem Nerd Spass - wenn man viele Knöpfchen drücken darf und alles umstellen kann. Am Ende macht es auch nichts anderes, war nur anstrengender.
==>wo positioniert sich FHEM?

Ich verstehe meinen Kollegen, welcher sich gegen FHEM entschieden hat - mit der Begründung: da muss man programmieren, es geht nix automatisch.

Das ist so in etwa meine Basis, auf der ich fhem und dessen Module nun beurteilen und reviewen werden. Alles meine persönliche Meinung! Ich werden es auch nicht wirklich diskutieren, ich mache das lange genug. Ich kann die Aussage verteidigen, mehr nicht. Es gibt immer mehr als eine Lösung - wenn ich also etwas vorschlage gibt es mit Sicherheit alternativen!

Was wünsche ich mir:
FHEM könnte die Zeile hier definieren. Designruls und einfacheres "designer-API" ist mein Ziel.

Beispiele folgen

martinp876:
Erstes Beispiel: die Sektion "Internals" im primär Entity-Frontend.

Es ist mir nicht bekannt, wo definiert ist, was in dieser Sektion dargestellt werden soll. Internals als sichtbare Gruppe von Daten belegt einen der wertvollsten Plätze in der Darstellung. Hier sollten aus meiner Sicht maximal komprimiert und somit auch nur wichtige Informationen stehen.
Wichtig definiert sich als: kann der Anwender hiermit auch etwas anfangen?
und Sortiert: das bedeutet "nicht alphabetisch". Alphabetisch ist aus meiner Sicht auf die Faulheit des Verantwortlichen zurückzuführen - hilft den Anwender entsprechend wenig
Änderbar: Internals bietet die Option, Werte zu ändern durch anclicken. Leider ist das nicht konsequent durchgezogen

von den default (kernal) angewendeten Infos sind (aus meiner Sicht ) wichtig: Type, Name, Definition, State.
Nicht hilfreich sind FUUID, NR, CFGFN.
Fraglich sind die Informationen zu notify.

Meine Forderungen sind:
- die default Daten sind IMMER als erste Zeilen darzustellen, damit ich diese immer sofort sehe und nicht suchen muss
- "NAME" sollte wir auch DEF durch anclicken änderbar sein, also mit rename verknüpft werden
- tiefere informationen, welche nicht sichtbar sind (FUUID,...) kann man über ein get kommando abfragen. OHNE Sichtbarkeit in global "showinternalvalues" umschalten zu müssen (das ist eh ein Scherz :) )
- cfgfn nutze ich schon immer - und immer intensiver. Das ist dann doch eher nerdisch. Also doch unsichtbar!
- ein Satz "get" kommandos über welche man die verborgenen Infos darstellen kann. Ich habe hier "list" als standard in allen meinen frisierten Modulen eingebaut. Man kann ALLE infos sehen, auch die hidden ones. Ist nicht nur wünschenswert sondern ein MUSS!
- eine guideline, was ein Entwickler hier darstellen sollen.
  # keine doppelte Information (bei Presence wird die IP Adresse im Define und explizit dargestellt! Gleiches gilt für Mode
  # Vereinzelte Daten (MODE, ADDRESS,...) müssen einfach automatisiert abfragbar sein. UNABHÄNGIG von der Sichtbarkeit. (die "." Kennung ist technisch einfach für den Programmierer - ansonsten eine Katastrophe)

Internals bietet - im Gegensatz zu readings und attibuten die mögichkeit der Verlinkung. Das ist cool und verleitet(e mich) dazu, assoziierte entites in Internal darzustellen. Probably assiciated ist eine schwache Alternative - werde ich noch kommentieren.
=> also bitte 1) komprimieren 2) sinnvoll sortieren 3) modifikationsoptionen komplettieren 4) guidelines für Entwickler bereitstellen und durchsetzen

martinp876:
Sektion "READINGS"

klare Ansage: nichts ist schlechter als falsche Information - besser ist keine Information.
Ich will mich auf Readings verlassen können, wenn sich angezeigt werden. Zu oft nun habe ich gesehen, wie Readings überfrachtet sind, nicht aufgeräumt werden, veraltet sind, geraten sind,....
Das trifft insbesondere auf entites mit vielen mögliche Readings zu. Fritzbox, Stereoanlagen, Wettervorhersagen aber auch Devices mit teils komplexen Konfigurationsmöglichkeiten.

1) Selbstredend muss der Entwickler nicht mehr aktuelle oder abgewählte Readings "LÖSCHEN".
  a) wenn ich den Anzeigemode umschalten kann müssen die nicht mehr gewünschten Readings ENTFERNT werden. Bei HMCCU kann man darstellen, mit oder ohne führende Kanalnummer. Bitte abgewähltes Löschen!!!
  b) bei der Stereoanlage werden die dem Mode entsprechenden Readings angezeigt (radio oder CD oder streaming oder...)  . Also die nicht gewählten Modi löschen!!!
2) wenn die Readings nicht garantiert werden können, müssen diese kenntlich gemacht werden. Wenn bspw ein Device nicht mehr erreichar ist (batterie leer, webseite  nicht erreichbar,...) darf doch ein State "on/off" angezeigt werden. Vielmehr MUSS hier "unknown" zum ausdruck gebracht werden - oder unreachable - oder "übergeordneter Fehler". Man kann gerne vorher retries einbauen
3) bei entites mit extrem vielen Readings kann es sinn machen, die Sichtbarkeit umzuschalten. Die aktuelle Implementierung über "." prefix ist allerdings mehr als schwach. gefordert ist klar:
- Das Abfragen von ReadingsVal muss unabhängig sein von dessen Sichtbarkeit

Ich sehe hier - insbesondere bei entites mit vielen Readings - entsprechende "get" kommandos in welchen man die Readings lesbar aufbereitet darstellen kann. Ein klarer Grund, warum ich Fritzbox umgebaut habe. Das Readings Handling entsprach nicht meinem Anspruch. Einiges war knapp daneben. Aber Knapp daneben ist eben auch vorbei.

==> A) unterstützung des Kernals sichtbarkeit zu schalten um übersicht ermöglichen zu KÖNNEN - ohne sich die Finger zu brechen (wie in CUL_HM) B) disziplin der Entwickler, nicht einfach Readings rauszuko... und dem Anwender das aufwischen zu überlassen C) hierarchische Fehlermeldungen und Readings-handling durch den Entwickler D) NIE ungültige/unsichere Readings stehen lassen. Wenn ich es nicht weiss, darf ich es nicht sagen!


Wernieman:
Habe es jetzt nur überflogen (Soyrry) aber noch eine Ergänzung zum ersten Post:
Apple: Viele User sind Glücklich damit, das das System einfach läuft (Apple Weg). Wenn Du es aber nicht so willst wie Appel, kämpst Du nicht nur mit Deinem Problem sondern auch mit Apple
Linux: Genau anders Herum ....

Sorry aber Du gibst den Apple Weg zu viel Positives. Es ist einfach nur ein anderer Weg (Der Konzern bestimmt, was für Dich gut ist).

Ich finde gut, das z.B: FHEM es genau so nicht macht (viele Wege führen nach Rom .. ähh zum Hausautomationssystem). Dafür bezahlt man diese Freiheit aber mit Komplexität.

martinp876:

--- Zitat ---Sorry aber Du gibst den Apple Weg zu viel Positives.
--- Ende Zitat ---
sehe ich definitiv nicht so - und das als nicht-apple user. Ich habe noch nicht einmal appel Erfahrungen. Allerdings sollte man sich die Aussagen der AppelJünger auf der Zunge zergehen lassen!
Und - falls es nicht klar geworden ist - ich will Beides. geht das? Ich meine schon. Das System soll in einer sinnvollen und typischen Konfiguration AUTOMATISCH hochkommen. Also nicht das System (das auch) aber eben auch jede Entity für sich. Es ist mir hier wurscht wenn mir einer dann erklärt "das kann man doch einstellen".
Einstellungen will ich für Ausnahmen und "meinen seltsamen Geschmack" machen können.
Für mich ist es schon etwas frustrierend, dass ich bei jedem 2. Modul welches ich implementiere mit Attributen und oder Readings zugesch...adet werde. Bis es das macht, was man sich vorstellt muss man sich durch gefühlt 1000 sonder-parameter wühlen welche Einer aus Hundert möchte - sonst aber kein Schwein interessiert - um dann eine Einstellung zu finden welche macht was man will. De-facto bin ich schon mehrfach zur Selbstversorgung übergegangen. Ich kapere die Module und schreibe sie um. Eigentlich finde ich das traurig.

Wenn FHEM den Linux-Weg geht, (Sytem kommt nackt hoch - da stehen dann alle Möglichkeinten offen es zu konfigurieren) werden min 80% der möglichen User (nutzer einer Haussteuerung) sich gegen das System entscheiden. Und das zurecht, da, wenn sie verstorben sind die Ehefrau das System mangels Maintainbarkeit entsorgen muss - keine Chance!

Aber - wie auch schon erwähnt: Mir ist klar, dass ich hier in einer Nerd-gemeinde poste und somit nur meiner Ansichten und Ideen poste, meine Seele entlaste - aber ohne wirkliche Aussicht auf Erfolg. Who knows, vielleicht dringe ich doch mit dem einen oder anderen durch.
Und Sorry, eigentlich müsste es mir klar sein - unter Lunix-Nerds resultiert das positive Erwähnen von Appel im sofortigen Einstellen des Weiterlesens.

Navigation

[0] Themen-Index

[#] Nächste Seite

Zur normalen Ansicht wechseln