CUL_HM - Philosophy, Funktionen, Verhalten - allgemein

[martinp876]

Wir sind hier in einer Grundsatzdiskussion.. welche ich gerne führe und gerne streite
1) @Pfriemler, Otto, betateilchen: Ich kenne eure vielen und wertvollen Beiträge. Wenn ich meine Meinung vehement vertrete geht das gegen niemanden persönlich und es soll niemanden diskreditieren. Die Entschuldigung also schon einmal vorneweg

2) Ich halte mich nicht für besser oder cleverer als andere Entwickler hier - im Gegenteil! Dennoch besteht FHEM aus einem Zoo an Entwicklern, welche schwer unter eine Haube zu bekommen sind. An einigen Stellen (und bei weitem nicht überall) ist FHEM doch ein Neerd-System. Die SW-affinen Entwickler kennen ihr modul und wissen, dass man "nur" dies oder das einstellen muss, schon gehts. Zugelassen werden soll ALLES, auch Blödsinn.
Grundsätzlich macht das ein "user-system" nicht.

3) FHEM ist von der Struktur extrem flach gehalten. Es gibt nur 4 Ebenene an Daten: Internals, Readings, Attribute und Helper. Das ist m.E. zu Kurz gesprungen, auch wenn es einige Vorteile hat.
Mir fehlen Konfigurationsdaten:
Konfiguration des Device (also u.a. model) welche der User nicht zu verändern hat. Das Device ist ein solches - Punkt. Diese unterscheiden sich von User-Attribute wie "room"
Konfigurationsdaten des Device/Channel (also Register/peerings) welche aus dem Device mehr oder weniger mühevoll gelesen werden müssen. Diese unterschieden sich von operationellen Readings wie "state:on"
Weiter ist nichts für die Sichtbarkeitssteuerung gemacht. Wenn ich alle Readings anzeige kennt sich keiner mehr aus. Und auch ich sehe nichts mehr.

4) FHEM kennt keine Struktur der Entites. Es gibt mehrere Optionen, eine HW-Famile zu implementieren. Siehe HMCCU im Front-end. Hier kann man 2 Optionen wählen, Kanal-entites (beim Entwickler unbeliebt) oder Device-entites mit allen Kanälen (bei mir unbeliebt, auch von EQ3 nicht so vorgesehen!). HMCCU allerdings implementiert alles intern komplett anders, und überhaupt nicht granular oder self-contained.
Für alle Entites welche singular sind klappt einigen wunderbar. Für Entites mit HW-zusammenhang (also Device mit mehreren Channels) kommt man sofort in Probleme. Den HW zusammenhang zu ignorieren halte ich für kritisch - bei CUL_HM schon einmal aus Protokoll-gründen unmöglich. Hilfreich ist es auch nicht.

5) model: Das kann ich (leider)nicht ändern, auch wenn ihr es besser zu wissen scheint. Es gibt einige Modul auf höherere Ebene welche auf "model" (ungefragt) zugreifen. Sorry, ihr liegt hier komplett falsch.
ModelForce: gibt es ausschliesslich für den Anwender welche ein EQ3 Modul erhalten hat, welches sich mit der falschen ID meldete. Ich sehe keinen (KEINEN) grund, warum das jemand einsetzen sollte. Ich ignoriere nicht, dass einige "model" ändern wollen, ich lehene es schlicht ab.

6) FHEM-objektorientierung
ist leider nicht vorhanden. In FHEM greift jeder nahezu beliebing auf die Daten anderer Module zu. Bei Objektorientierung würde man es mit Methoden machen - und man könnte die  Daten sinnvoll aufbereinten.

7) raw define
a) hatte ich Szenarions welche hier abgedeckt werden sollen könnte ich es unterstützen. Leider hat noch keiner von euch diese vorgelegt.
b) wären wir objektorientiert könnte ich ein "raw-define" SINNVOLL unterstützen. Als Funktionaufruf, enkapsuliert. Beispiel: Legt jemand ein Device an werden die Kanäle auch angelegt. Über die Sinnhaltigkeit braucht man m.E. nicht reden (ausser in Nerd Systemen). Nur um den Sonderfall "device-transfere" abzudecken werde ich das nicht ändern. Nun ergeben ich bei der Definition der Kanäle eine Fälle:
- Der kanal wir mit dem gleichen namen noch einmal definiert. Könnte ich ignorieren, ist aber nicht FHEM-typisch
- der kanal wird mit einem anderen namen definiert -> ich mache also kein Define sondern ein Rename. Dazu muss ich, um Systemkonform zu bleiben, das große Rad drehen, da Rename eine System-weite Anwendung ist.
-> Sinnvoll ist es, dass der User die Kanäle nach dem Define löscht und sie dann neu anlegt.
=> Gäbe es eine "Funktion" "port-device" könnte ich das alles nahtlos unterstützen. Leider will man ein CUL_HM wie ein HMCCU, wie ein Notify wie ein AT und wie eine FB behandeln. Nebenbei, da gibt es 2 Optionen. Entweder hat das system so gut wie keine smarte Funktionalität oder es klappt nicht.

raw Define  Readings
wie schon angemerkt halte ich das kopieren von Readings für Quatsch. Komplett? Natürlich nicht. Man muss wieder einmal differenzieren. Config-readings kann man gerne kopieren. Insbesondere intelligent für Devices welchem an nur durch "config" Methode auslesen kann.
Kopieren eines Status wie Alive, Level,... sind operational. Ein Kopieren ist m.E. sträflich.

==> ich würden gerne eine Methode unterstützen, welche das "moven" eines Device unterstützt. Und zwar für User, nicht Nerd-level. Intelligentes move würden
- nur auf devices anwendbar - Channels würden implizit mitkommen
- Namen würden beibelanten
- User müssen sich um system-attribute keine Gedanken machen
- Operationale Readings werden nicht kopiert, Config-Readings schon.
- autoReadReg schedulen wenn es der Anwender nicht unterdrückt hat.

9) aktuelle Implementierung - support "raw Define"
wie schon erwähnt habe ich das setzen von "model" zugelassen, wenn es a) leer ist oder b) den identischen Wert überschreibt. Damit sollte es erst einmal AN DIESER STELLE klappen. Bitte die workarounds nicht weiter verfolgen...

10) noch einmal "raw define"
Das aktuelle Fenster ist eigentlich "macro-execute" - (ich bin nicht der meinung, dass Namen egal sind)
Ich persönlich finde es interessent, werde es aber wohl nicht nutzen, da mein Scripting-terminal hier besser funktioniert.
Zur Anforderng "raw-define" fehlt mir allerdings immernoch die use-cases. Wird es nun gebraucht, um die Definition eines devices in MEINER Instellation von einem System auf ein anderes zu übertragen? Oder will ich meine Instellation einem anderen User zu Verfügung stellen? Oder will ich eine Art Template? Ich habe also einen "schönen" Dimmer und will  - einfach - einen 2. im gleichen Stil anlegen?
Hier brauche ich echt eure hilfe ... mir fehlt die Vorstellung

[frank]

ModelForce: gibt es ausschliesslich für den Anwender welche ein EQ3 Modul erhalten hat, welches sich mit der falschen ID meldete. Ich sehe keinen (KEINEN) grund, warum das jemand einsetzen sollte. Ich ignoriere nicht, dass einige "model" ändern wollen, ich lehene es schlicht ab.

es gibt scheinbar noch einen 2. sinnvollen einsatz, das originale model zu ändern:
das originale model funktioniert nicht richtig in cul_hm.

ich habe es nicht wirklich verfolgt, aber hier scheint es handlungsbedarf zu geben, damit modelForce unnötig wird.

https://forum.fhem.de/index.php/topic,87924.msg1070181.html#msg1070181

[Beta-User]

Vorab mal:
1. Danke, dass du das aufgreifst, was Otto123 (er war der originale TE des anderen Threads, der dann von jemandem anderen leider "gekapert" wurde) da initiiert hat.

2. Um Mißverständnisse zu vermeiden: Ich habe bei weitem nicht das Hintergrundwissen des von dir hier genannten Developers und sehe die Dinge tendenziell erst mal aus Anwendersicht und "lege mich nur dann unter das Auto", wenn es mir notwendig erscheint.

3. Das eigentliche Hauptproblem, das Anlaß für Ottos Thread war, dürfte gelöst sein:

wie schon erwähnt habe ich das setzen von "model" zugelassen, wenn es a) leer ist oder b) den identischen Wert überschreibt.

Das deckt meinem Bauchgefühl nach alle "typischen" Anwendungsfälle rund um "RAW" ab.


Das strukturelle Thema, dass es bestimmte Konfigurationsdaten gibt, die eigentlich dem Userzugriff entzogen sein sollten, sehe ich ähnlich und fände es an der einen oder anderen Stelle auch hilfreich, wenn die Querbeziehungen zwischen mehreren FHEM-Devices, die alle auf ein- und dieselbe Hardware zurückzuführen sind, auch bei anderen Modulen ähnlich "hart" gehandhabt würde, wie das bei CUL_HM der Fall ist (deine diesbezüglichen Diskussionen mit zap zu HMCCU.* hatte ich aus den Augenwinkeln verfolgt, aber das ist jenseits meines Perl...-Horizonts). Vermutlich paßt diese Art der Grundsatzdiskussion aber nicht in den Homematic-Bereich und wäre ggf. nochmal an anderer Stelle ganz gesondert aufzugreifen.

Was die Frage angeht "Was ist RAW-Def und für was braucht man das?!?" Vermutlich gibt es nicht "die" Antwort. Daher mal einfach eine Liste, was ich so sehe:

Im Kern ist es schlicht ein mehrzeiliges Kommandofeld, das eben anders als "das grüne Plus" vorausgefüllt den aktuellen Zustand eines Geräts (bzw. auch mehrerer "zusammengehöriger" Geräte) in "kopierfähigem Zustand" enthält. Darin kann man ändern, nicht benötigte Zeilen löschen, ganz anderen Content reinkippen usw. usf.. Großer Vorteil gg. dem direkten Editieren der cfg: man hat direkt auch Rückmeldung, wenn Fehler drin sind, Perl-Module fehlen usw.

Nimmt man diese Kopie und überträgt sie z.B. in ein Testsystem, hat man danach ein Gerät, das dem entspricht, was im Original unmittelbar nach einem Neustart auch zu sehen wäre. Im Testsystem habe ich dann zwar keine Möglichkeit der Interaktion mit der Hardware, aber ich kann bestimmte Dinge simulieren, was meistens ausreicht. Das ist bei mir der Hauptanwendungsfall, v.a. im Kontext der Entwicklung von attrTemplate für MQTT2_DEVICE; da fordere ich bei anderen Usern ein RAW an und arbeite dann erst mal mit diesen Daten.

Gelegentlich nutze ich RAW, um eine bearbeitete Kopie eines "erfolgreichen" Gerätes zu erstellen - dann interessiert mich der hintere Teil (=statefile-Content) nicht, ich kopiere nur die eigentliche Konfiguration, bearbeite die (in der Regel in einem externen Editor, da ist search&replace einfacher) und haue das ganze dann wieder in einem Rutsch in mein jeweiliges System - fertig. Ginge auch mit copy, aber das hat hin und wieder seltsame Nebeneffekte.

Viele dürften den RAW-Import (ohne statefile-content) nutzen, um z.B. wesentliche Teile ihrer Konfiguration in eine neue zu übertragen, z.B. bei Ablösung eines Altsystems oder, was immer mehr in Mode kommt, aus einem Testsystem in das Hauptsystem.

Hoffe, der "typische" Usecase ist jetzt etwas klarer?

Gruß, Beta-User

(Du brauchst dich übrigens nicht vorab für irgendwas zu entschuldigen! Alles gut...)

[Pfriemler]

wie schon erwähnt habe ich das setzen von "model" zugelassen, wenn es a) leer ist oder b) den identischen Wert überschreibt.

So. Jetzt noch das Setzten von subType mit einem dezenten Hinweis ignorieren und schon haben wir was Otto am Anfang der Diskussion (wieder)haben wollte.

Gelegentlich nutze ich RAW, um eine bearbeitete Kopie eines "erfolgreichen" Gerätes zu erstellen ... Ginge auch mit copy ...

Geht eben nicht mit copy, wenn die DEF als bereits vorhanden bemängelt wird. Was in diesem Fall auch gut so ist.
(Ein HM-eigener Clone-Befehl wäre nett, aber die Grenzen zwischen FHEM-Konfig und Register-Konfig sind vll. nicht allen klar. Wobei Martin da schon sehr viel umgesetzt hat: Den "Gerätetausch", den die CCU anbietet, kann man mit hminfo über x-deviceReplace ja schon sehr umfassend machen.)

Viele dürften den RAW-Import (ohne statefile-content) nutzen, um z.B. wesentliche Teile ihrer Konfiguration in eine neue zu übertragen, z.B. bei Ablösung eines Altsystems oder, was immer mehr in Mode kommt, aus einem Testsystem in das Hauptsystem.

Ich habe da noch einen (seltenen) Usecase: ein aus dem System entferntes Altgerät, welches ich temporär wieder einbinden möchte. Meist habe ich es nicht zurückgesetzt in die Schublade gelegt. Um die Def wiederzuholen, kopiere ich den Definitionsblock aus einer alten fhem.cfg in den RAW-Editor und mache multi-execute (Ja, das trifft es wirklich besser). Das wäre ohne jede Stolperfalle eben nett.

[Beta-User]

Geht eben nicht mit copy, wenn die DEF als bereits vorhanden bemängelt wird. Was in diesem Fall auch gut so ist.
(Ein HM-eigener Clone-Befehl wäre nett, aber die Grenzen zwischen FHEM-Konfig und Register-Konfig sind vll. nicht allen klar. Wobei Martin da schon sehr viel umgesetzt hat: Den "Gerätetausch", den die CCU anbietet, kann man mit hminfo über x-deviceReplace ja schon sehr umfassend machen.)

Ups, da war ich eher wieder auf der allgemeinen Schiene...
Vor dem Hintergrund vielleicht noch eine Anmerkung:

Das "RAW" (multiline-execute finde ich auch nicht übel, aber in der Regel will ich vom User ein "list -r" haben bzw. eben die Kopie dessen, was eben in der RAW-Definition steht), also jedenfalls genau dieses Eingabefeld ist für mich (und eine zunehmende Anzahl weiterer User) DAS Mittel der Interaktion mit FHEM und genau dieses Vorgehen empfehle ich auch weiter:
- Es stärkt den mAn sehr wichtigen Grundsatz: Kein cfg-editieren! Nirgends! (große Fehlerquelle bei Anfängern!), auch nicht über FHEMWEB
- Der Output ist (wie beschrieben) "portabel"
- Wenn man (fast) nur so arbeitet, hat man auch keinen (großen) Hackel mit escapes von ;; usw.. Jedenfalls ist es immer dasselbe Format im Sinne eines einheitlichen Standards.

Von daher kann ich die Anforderung von Otto und Pfriemler nur unterstützen, vollständige RAW-Imports möglich zu machen bzw. jedenfalls da stressfrei möglich zu halten, wo es nichts kaputt machen kann...



Vielleicht noch eine ergänzende Anmerkung:
Dass CUL_HM spezielle Funktionalitäten für rename, "replace", vccu usw. vorhält, ist mir damals bei der Lektüre der Grundlagen entgangen, und an der Situation bzgl. Doku hat sich afaik nichts wesentliches verbessert (es steht vermutlich in der cref, aber wenn man sehr gute externe Dokumente hat, kommt es vermutlich nicht nur in meinem Fall zu solchen Effekten...). Jetzt gibt es mit frank's Tool wohl noch ein sehr gutes add-on.
Vielleicht sollte man sich nochmal die Mühe machen, das irgendwie etwas systematischer aufzuarbeiten, auch wenn CUL_HM (mit einem gewissen "leider") wohl irgendwann nicht mehr mit käuflicher Hardware versorgt werden wird.

(Mich hat eQ-3 mit ihrer teils absonderlichen Preispolitik verärgert, zudem habe ich immer mal wieder wegsterbende Hardware bzw. Fensterkontakte mit Amnesie, von daher werde ich wohl dieses Gehege meines Zoos nicht mehr vergrößern und mich eher damit beschäftigen, wie ich ohne x-replace@CUL_HM auskomme. Aber evtl. findet sich ja jemand, der da zumindest eine Art ersten Pfad für Neulinge anlegen will? Von UliM habe ich auch die Word-Fassung dessen, was den Anhang zum Einsteiger-pdf bildet, falls das jemand in diesem Zusammenhang verwenden will; der Anhang selbst ist übrigens nochmal ein Extra-Danke an Martin wert!!! Hat mir sehr geholfen, mich in den HM betreffenden Teil meines Hausautomatisierungsprojekts einzufuchsen. Sehr technisch für mich als noob, aber es hat einigermaßen geklappt...).

[martinp876]

@frank: es gibt nur einen grund für modelForce: ein bug. Den bug in culhm habe ich gesehen, werde ihn korrigieren. Ist also nur temporär. Bugs in fw sind ausserhalb meiner Kontrolle.

@betauser: der usecase ist das kopieren in ein test system oder umgekehrt (hattest du nicht, aber auch möglich). Evtl. Findet man eine coole Einstellung und will es über übernehmen.
Stellt sich die Frage, was funktionieren soll. Man könnte .... Einiges. Das Feld ist zu weit um einen guten support zu leisten.

Ottos Problem sollte in der Tat Geschichte sein. Partiell.

@pfriemler: subtyp ist doch schon Geschichte. Eigentlich sollte ich subtyp komplett verschwinden lassen. Oder in fhem nicht mehr nutzen. Dann wäre es nur noch ein merker ohne funktion. Allerdings hasse ich diese Leichen, da dich der user ständig fragt, wozu es gut ist.... Nur Unsicherheit.

Das mit altgeräten wird an den channels scheitern.

Später mehr...

[noansi]

Hallo Martin,

nur eine Anmerkung zu

subtyp ist doch schon Geschichte. Eigentlich sollte ich subtyp komplett verschwinden lassen. Oder in fhem nicht mehr nutzen. Dann wäre es nur noch ein merker ohne funktion. Allerdings hasse ich diese Leichen, da dich der user ständig fragt, wozu es gut ist.... Nur Unsicherheit.

Man kann mit subType die Anordnung der Geräte in einem room passend umgruppieren und sich damit schnell eine dem Nutzen nach übersichtlichere Ansicht schaffen, als es über TYPE gruppiert wird. Daher sollte es als Attribut beliebig benennbar verfügbar bleiben, denke ich, aber ohne sonstige Funktion (zumindest, so lange es diese Ordnungsfunktion auf der Weboberfläche in FHEM behält).

Gruß, Ansgar.

[papa]

Der subType wird für die Homebrew-Geräte gebraucht oder wir brauchen hier einen anderen Mechanismus.

[martinp876]

Schon klar, entfernen ist immer ein Problem. Es gibt min einen der es nutzt. Und da ich ihn nicht kenne kann ich nichts absprechen.
Beispiel subtyp: ist in den channels nicht vorhanden. Natürlich könnte man ihn mit get param abfragen. Das ist objektorientiert, man nutzt eine Methode. Könnte man prima unterstüzen. Leider in fhem nur selten modulübergreifend genutzt.
So renne ich wie so oft in die Falle nicht herr über das hässliche attribut zu sein. Denn letztendlich ist es in channels kein attribut sondern ein Parameter. Im device hat es den status attribut schon jahre überlebt und ist ein als attribut getarnter helper. Nur model ist ein attribut, wobei eigentlich .mId die Musik spielt.
So viel zu den unzulänglichkeiten der fhem Architektur, Struktur und nutzung durch viele Entwickler. Genug gejammert.

@ansgar: deinen Ansatz kann ich definitiv nicht unterschreiben. Gründe: attribute zur Gruppierungen sollten keine Erfindung von Modulen sein. Ich erwarte mir diese (notwendigen) differentustoren von der Plattform zu vorgegebenen. So wie room und group. Schliesslich ist switch eine funktion welche nicht nur in culhm zu finden ist.
Am Ende ist es dann nicht mehr der aktuelle subType sondern so etwas wie"function".
Grundsätzlich ist die idee aber korrekt. Allerdings wieder erst mal die ungeliebte Papier Arbeit: welche funktionen soll es geben und was ist die schnittmenge der funktionen?
Was eingeführt ist, kann man nicht mehr abschaffen, siehe oben.

Von daher kann ich die Anforderung von Otto und Pfriemler nur unterstützen, vollständige RAW-Imports möglich zu machen bzw. jedenfalls da stressfrei möglich zu halten, wo es nichts kaputt machen kann...

Culhm kennt keinen rawimport. Da ich keinen weg kenne, das zu erkennen gibt es technisch ausschliesslich die üblichen Kommandos. Egal was über dem Eingabe fenster steht. Es ist eine Mogelpackung. Schlicht ein macro execute. Namen spielen eben doch eine Rolle.
Ich bin zuversichtlich ein raw definition export und/oder ein raw define import unterstützen zu können. Beides existiert leider nicht, nur ein copy von best guess werten.

Das Problem ist klar? Du definierst ein device. Dessen 4 Kanäle werden instanziiert. Dann kommt dein define channel. Culhm MUSS es zurückweisen, da die addresse schon vergeben ist.
Ein implizites rename könnte helfen. Aber, beim besten Willen: was für ein Pfusch! Wenn der anwender define sagt bekommt er ein define ... oder ein reject. Punkt.

Noch einmal anders: in jeder sw welche etwas auf sich hält missbraucht ein entwickler keine attribute anderer Module sondern fragt diese über interfaces ab.

das Angebot eines raw define Export steht. Über hminfo auch ein import. Das "macro interface" bietet keinen Absatz zur Unterstützung!

[Beta-User]

[...] gibt es technisch ausschliesslich die üblichen Kommandos. Egal was über dem Eingabe fenster steht. Es ist eine Mogelpackung. Schlicht ein macro execute. Namen spielen eben doch eine Rolle.

Sorry, wenn ich mich da wohl etwas missverständlich ausgedrückt hatte:
Die Erwartung ist, dass das "macro execute" durchläuft, solange der User darin keine (echten) Fehler eingebaut hat. (Der Namensbestandteil "Import" mag in der Tat "unglücklich" sein, im Prinzip gilt das aber 1:1 auch für die normale Eingabezeile "Kommandofeld").
Der Versuch, eine HmID nochmal zu verwenden, ist aber ein Eingabefehler und darf (bzw. soll!) auch dann zum Abbruch der ganzen Aktion führen. Zumindest auf den ersten Blick (das ist "Bauchgefühl") würde ich sogar soweit gehen zu sagen, dass in einem solchen Fall _niemals_ dann ein rename oder irgendwas anderes unerwartetes passieren sollte.

Es ging ausschließlich darum, dass hier an sich (in 99,9% der Fälle) korrekte und im "schlimsten Fall" unnötige bzw. schon bekannte Angaben mit einer für den User nicht einleuchtenden - und auch technisch nicht unbedingt zwingenden - Begründung verweigert worden sind, und meine diesbezügliche Anmerkung erfolgte auch nur, weil @Pfriemler neben dem bei mir im Fokus stehenden model/modelForce noch ein weiteres Attribut ins Spiel gebracht hatte.
(Zu "technisch nicht zwingend": Dass es technisch besser ist, diesen Teil dem Modul zu überlassen, ist klar. Dass es möglich ist, darüber dann (User-) Fehler einzubauen, ist auch klar (in der Regel ist es aber ein Übertrag einer ehemals funktionierenden Konfiguration; wer was anderes macht, muß mit den Folgen leben...). Dass es ggf. wünschenswert wäre, solche Fehlerquellen generell zu vermeiden, ist auch klar, aber mMn. eine andere Diskussion.)

das Angebot eines raw define Export steht. Über hminfo auch ein import. Das "macro interface" bietet keinen Absatz zur Unterstützung!

Meinem Bauchgefühl nach wäre die Zeit vermutlich besser in Überlegungen zu einer "module-only"-Kategorie von Konfigurationsangaben investiert, wie gesagt: ich meine nicht, dass heute bzgl. der "macro execute"-Option noch groß Handlungsbedarf besteht und fürchte andererseits, dass weiter perfektionierte Sonderwege dann zwar am Ende für CUL_HM vorhanden sind, diese aber - mangels Kenntnis hiervon - am Ende kaum jemand nutzt.
Aber wie immer: der Modulautor entscheidet am Ende, was wie geschieht .

[zap]

Mm, ich werde zwar hier im Thread mal erwähnt, weiß aber gerade nicht, worum es geht. Scheint irgendwie an anderer Stelle eine Diskussion gegeben zu haben, die ich nicht kenne. Also halte ich mich mal lieber raus

[martinp876]

@beta-user: ich gebe dir recht, keinen sonderweg zu beschreiten. Das Feature scheint doch eher selten von normalen usern verwendet. Erfahrene welche mit testsystemen aggieren und Archive alter Installationen jonglieren haben eh mehr drauf.

Im normalen Verhalten des administrativen Frontend werde ich das also nicht weiter betrachten.
Das Frontend wie das ganze system sollte best möglich selbst konfigurierend sein, so ist es vereinbart. Klare Fehler des Users sind zu vermeiden und zu rejecten.
Mir klar, dass culhm hier noch lange nicht Plug and Play ist und es aufgrund der Umstände auch nicht schaffen kann. Anlernem muss nun einmal so stattfinden.

Vision ist:
Anlernen => device und entities werden erstellt, config gelesen
Peersmart => einfaches peeren mit drop-down Selektion sinnvoller optionen
Template => zuweisen der funktion auf user/smart Niveau. Für peerings sowie grund Funktionen.
Configcheck => sind Fehler erkennbar

Attr model und register settings sollten im Normalfall keinen mehr interessieren

Edit: culhm versucht alle nicht notwendigen oder schlimmer, alle nicht möglichen optionen im frontend zu unterdrücken. Leider ist diese bei attributen nicht vorgesehen. Schade.
Weiter sinnvoll erachte ich das unsichtbar schalten von readings. Auch das geht leider in fhem nicht/ kaum sinnvoll. Jede Menge probleme mit notify,... Das problem sehe ich ebenfalls bei einigen anderen modulen, welche schlicht nicht lesbar sind.
Ich denke culhm ist hier auf einem sinnvollen weg der Abstraktion und Nutzbarkeit. Für"gut" wäre Unterstützung des kernals notwendig

[Beta-User]

Edit: culhm versucht alle nicht notwendigen oder schlimmer, alle nicht möglichen optionen im frontend zu unterdrücken. Leider ist diese bei attributen nicht vorgesehen. Schade.
[...]Für"gut" wäre Unterstützung des kernals notwendig

Wie gesagt: Eine solche allgemeine Diskussion über "module-only" Konfig-Einstellungen mag sinnvoll sein (@zap: sorry, wenn ich dich hier im Thread erwähnt habe, bis dato hatte das aber auch keinen inhaltlichen Bezug zu deinen Modulen. Falls du aber was zu diesem speziellen und allgemeinen Aspekt anmerken möchtest: feel free! Es würde Sinn machen, wenn Leute wie du und Martin, die ihr auch den notwendigen theoretischen Background habt, das auf eine sachgerechte Weise beleuchtet, ich habe zu diesen ganzen Themen leider nur ein (meist ganz brauchbares) Bauchgefühl...)

Wenn es allgemeine Punkte gibt, die man in diese Richtung benötigt, müßte es jemand kompetentes so aufbereiten, dass es a) in die allgemeine Infrastruktur eingearbeitet wird, b) den Modulverantwortlichen (mehr oder weniger) verständlich verklickert wird und c) auch von den Usern am Ende einfach genutzt werden kann.

Weiter sinnvoll erachte ich das unsichtbar schalten von readings. Auch das geht leider in fhem nicht/ kaum sinnvoll. Jede Menge probleme mit notify,... Das problem sehe ich ebenfalls bei einigen anderen modulen, welche schlicht nicht lesbar sind.

Den Punkt verstehe ich nicht so ganz; ob eine Readingänderung jetzt per default triggert oder nicht, bleibt doch dir als Modulautor überlassen? Nur, wenn der User glaubt, da rumpfuschen zu müssen, wird es ggf. komisch? Oder übersehe ich mal wieder was wichtiges? (Da mache ich evtl. auch an den von mir derzeit gepflegten Modulen was falsch, von daher bin ich ernsthaft an einer Antwort interessiert!)