Generate AttrList

Begonnen von martinp876, 08 Januar 2023, 08:48:30

Vorheriges Thema - Nächstes Thema

martinp876

schön, dass die Attribute nun besser geprüft werden - hat bei mir gleich zu problemen geführt - sicher weil ich verpasst habe, dass die Funktion umgestellt wurde. Hier muss ich noch einmal versuchen, die Dokumentation zu finden.

Unpassend finde ich den Ansatz der Zusammenstellung.
in getAllAttr werden
- Framework attribute fix zugewiesen - sehr gut.
- readingFnAttributes wird nicht automatisch addiert - warum? solte immer vorhanden sein!
- .AttrList auf Device Ebene - fall existent - passt!
- AttrList der Modul-ebene - aber nur wenn keine Device-ebene existiert. => sehr schade.
Beim letzten Punkt wünsche ich mir klar, dass wir ein sauberes hierarchisches Design verfolgen, so wie es auch bei global und framework gefahren wird. Dann wären wir einmal durchgäng

FHEM hat eine schwach implementierte Hierarchie
1) "global" - was ich gerne als kernel bezeichne. die Eigenschaften dieses Levels finden umfassend Anwendung (und so muss es m.E. sein). Module können sich hier einhängen und auch "global" werden. Hm... dann ist global nicht kernel... aber immer noch allgemein gültig.
1a) "framework" - diese Ebene ist mir unklar - was ist der Unterschied zu global? Ok, wenn "global" ein Modul-Erweiterbares Konstrukt (also etwas mehr Dynamik hat) dann ist Framework wohl "kernel.
2) Modul-ebene. Diese sehe ich als "für jedes Device eines Module gültig" an. => ich muss diese NICHT in JEDES device kopieren (kopieren ist blöd!)
3) Devicel-ebene. hier können device-spezifische Attribute addiert werden. Subtrahieren ist dann nicht mehr möglich


Diese Hierarchie sehe ich übrigens nicht nu bei Attributen sondern umfassend. Also auch set und get kommandos könnten realiiert werden - auf global und framework ebene. Ein "Rename" wäre im Device als drop-down verfügbar.

==1> gibt es eine Architektur, wie FHEM sich strukturell sieht? Wirklich flach ist es nicht, aber auch nicht strikt hierarchisch. also so etwas dazwischen. Falls es dokumentiert ist, habe ich es nicht gefunden
==2> kann man den Modul-Level für AttrList anders implementieren?
==3> wie sieht es aus mit duplikates? Wer muss diese abfangen? Kernel oder Modul?
==4> Wie werden Optionen der Attribute behandelt? Ein Modul könne bei Attr1 die Optionen Opt1/opt2 haben und bei einem Device die List auf Opt3/opt4 verlängern - oder ersetzen?
==5> attr "?" wird nun gleich im Kernel abgefangen. Ich nutzte es, um zu prüfen, ob sich die Liste der Mögliche Attribute geändert hat. Das kann passieren, wenn ein Device durch ein Attribut erweiterte Funktionalität bekommt. Wie ist das angedacht? Attribute sind nach Init ja nicht statisch.

Das mit fhemWeb werde ich mir noch ansehen, wenn ich Lust habe...

Wir etwas überdacht an dieser Stelle? Wird der Kernel auch Optionen der Attribute prüfen, wenn diese definiert sind?

betateilchen

Zitat von: martinp876 am 08 Januar 2023, 08:48:30
- readingFnAttributes wird nicht automatisch addiert - warum? solte immer vorhanden sein!

Solange es noch Module gibt, die beispielsweise den readings-Hash direkt beschreiben, anstatt die ReadingsUpdate Mechanismen zu verwenden, macht eine generelle Einbindung der readingFnAttr wenig Sinn.

Zitat von: martinp876 am 08 Januar 2023, 08:48:30
FHEM hat eine schwach implementierte Hierarchie
1) "global" - was ich gerne als kernel bezeichne. die Eigenschaften dieses Levels

Vermutlich ist mit "global" in der Attributliste gar keine hierariche Ebene gemeint, sondern lediglich die im Pseudo-device "global" definierten Attribute.

Zitat von: martinp876 am 08 Januar 2023, 08:48:30
schön, dass die Attribute nun

Was meinst Du mit "nun"?
Die Umstellung der Attribute und ihre Gruppierung erfolgte im März 2021 - das ist fast zwei Jahre her.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

Zitat- readingFnAttributes wird nicht automatisch addiert - warum?
Weil bei bestimmten Modulen (FHEMWEB, telnet, global) das nicht sinnvoll ist.

Zitat1a) "framework" - diese Ebene ist mir unklar - was ist der Unterschied zu global?
global gibts nur einmal, framework bietet das gleiche Attribut fuer jede Instanz an.

Zitatgibt es eine Architektur, wie FHEM sich strukturell sieht?
Es sollte kein Geheimnis sein, dass FHEM nicht nach einem goettlichen Plan realisiert wurde, sondern sich nach und nach entwickelt hat, und dabei grossen Wert auf Rueckwaertskompatibiitaet gelegt hat. Letzteres ist notwendig, weil viele, nicht aktiv gepflegte Module gibt.

martinp876

ZitatSolange es noch Module gibt, die beispielsweise den readings-Hash direkt beschreiben, anstatt die ReadingsUpdate Mechanismen zu verwenden, macht eine generelle Einbindung der readingFnAttr wenig Sinn.
Verstehe ich nicht. Module welche sich nicht an die Konventionen halten haben eben weniger support. So what. Sie scheitern schliesslich nicht daran. Mit diesem Argument kommt man nie vorwärts. 
Haben die Module dann wirklich Probleme? Denke ich nicht.

ZitatVermutlich ist mit "global" in der Attributliste gar keine hierariche Ebene gemeint, sondern lediglich die im Pseudo-device "global" definierten Attribute.
Ist mir schon klar, das "global" die pseudo Instanz ist. Diese ist aber auch die einzige übergreifende Instanz. Damit ist global eben global - und prädestiniert für solche Aufgaben. Da ist jede Menge Potential. Global könnte zum "FHEM-Kernel" UI ausgebaut werden. Schmerzfrei.

ZitatDie Umstellung der Attribute und ihre Gruppierung erfolgte im März 2021 - das ist fast zwei Jahre her.
nun - ich habe schon (viel) länger datauf gewartet. Eingentlich hatte ich mir noch mehr erhofft. Aber klar - ich verfolge das alles nicht offensiv. Und ich bin mit Sicherheit nicht der einzige - und hoffentlich nicht der Eiffrigste, welcher Verbesserungen vorschlägt.

ZitatWeil bei bestimmten Modulen (FHEMWEB, telnet, global) das nicht sinnvoll ist.
dann wird es mit Standard eng. Irgend einer passt immer nicht. DBlog klinkt sich bei FHEMWEB ein - ist das sinnvoll?

Zitatglobal gibts nur einmal, framework bietet das gleiche Attribut fuer jede Instanz an.
verstehe ich nicht. Attribut oder Attribut-Instanz?
Ok, evtl Missverständnis. global vs global-UserAttr.
Also genauer definiert
Global attr
  Attribute der "global" instanz wie "showInternalValues". Zu behandeln wie Attribute eines einzelnen Device. Alles klar, logisch.
  diese werden (logisch) bei anderen Devices nicht angeboten.
global User Attr
  - hier klinken sich Module ein, welche ALLE anderen Module beglücken - ungefragt und ohne Prüfung der Sinnhaltigkeit. ok für mich - für Euch?
  - von der Semantik ist hier "global" und "global" strikt zu unterscheiden.
framework
  - Attribute welche vom Kernel  unterstützt werden. Können in Devices gesetzt werden, die eingentliche Funktionalität ist im Kernel realisiert. Der Kernel muss dokumentieren, values bei Eingabe prüfen,... das volle Program eben.
  - Includiert sind attribute wie "supressReading" und "eventMap" bedingungslos. Auch bei FHEMweb
  - bedingt zu Verfügung stehen sonstige Reading-behandende-attribut.
  => hm. die Grenze ist wohl willkürlich gezogen. Da könnte man auch gleich alle zulassen. Frist kein Brot. Kein Aufwand bei anderen Modulen. Standartisiert mehr. Ich verstehe die Begrenzung nicht.
fhemWEB
  - beglück alle mit UserAttributen - welche aber in einer eigenen Gruppe dargestellt werden. Sind sicher "modulübergreifend" - d.h. werden in einem Device gesetzt und dann von jeder fhemWEB Instanz identisch behandelt.  Also eigentlich sind es "globalUserAttr" - so werden sie auch verwaltet.
  - eine Sonderbehandlung ist nur in der Darstellung sichtbar (die Darstellung finde ich gut)
==> wenn fhemWeb eine eigene Gruppe von Attributen bekömmt wäre es evtl sinnvoll das komplett zu machen? Jedes Modul welches die Umwelt mit einem Attr beglückt bekommt eine Gruppe.
==> ich sehe somit einen Grund, das ganze einfach zu standartisieren. Eine Attributoption mehr bringt kein Modul ins wanken. Wenn es nicht behandelt wird ist es nicht tragisch - so etwas habe ich allenthalben.

ZitatEs sollte kein Geheimnis sein, dass FHEM nicht nach einem goettlichen Plan realisiert wurde, sondern sich nach und nach entwickelt hat, und dabei grossen Wert auf Rueckwaertskompatibiitaet gelegt hat. Letzteres ist notwendig, weil viele, nicht aktiv gepflegte Module gibt.
nun, ein göttlicher Plan wäre cool. Mir würde schon ein Plan reichen. Wenn er am Anfang nicht stand ist das ok. Der Anfang ist nun schon ein paar Tage her. Ich vermisse (ich wiederhole mich) die Guideline, den Masterplan - wie auch immer ihr es nennen wollt, wo es hingehen soll. Die Umsetzung ist dann erst der 2. Schritt.
Rudi hat so etwas sicher im Kopf. Leider habe ich da keine Leserechte.

Ich sehe keine Grund, das Thema hier sauber zu definieren und Umzusetzen. Die Fragen klären (ich wiederhole mich, sorry)
- welche Attributslisten werden wie genutzt (hierarchie)
   - framework - immer vorhanden
   --- framework optionals (WIRKLICH notwendig)
   - global user - jedes Modul kann Attribute eintragen und alle beglücken
   - Module-level: wenn ein Modul das definiert wird es auf alle Devices des Modul angewendet
   - devivelevel: selbsterklärend
   - duplicates werden erkannt und aussortiert
   - priority hat das Device und dann aufwärts. Entscheidend sind hier die Optionen des Attributs, welche sich unterschieden können.
   - dynamische Attribute: wie kann der Modulentwickler die Attr-Liste updaten, wenn sich Bedingungen ändern? Nur statisch ist eh keine Option für mich
    Stichwort "attr <def> ?". hier konnte ich einst eingreifen. wie soll das jetzt gehen?

Ich habe in meinerVersion noch conditional-options vorgesehen.

Aber an den Reaktionen erkenne ich, dass ich besser meinen Plan verfolge, da alles was ich Vorschlage bei irgendeinem Modul zu Problemen führen könnte.
Und ich habe nicht die Zeit noch die Gedult dafür.
Wie gesagt, göttlich wäre cool, schriftlcih wäre für mich ausreichend - aber bitte mit allen Anforderungen



rudolfkoenig

Zitat==> wenn fhemWeb eine eigene Gruppe von Attributen bekömmt wäre es evtl sinnvoll das komplett zu machen? Jedes Modul welches die Umwelt mit einem Attr beglückt bekommt eine Gruppe.
Das geht auch, wenn das Modul userAttr mit addToAttrList($;$) bzw. addToDevAttrList($$;$) erweitert, und den letzten Parameter (Modul) setzt.

ZitatStichwort "attr <def> ?". hier konnte ich einst eingreifen. wie soll das jetzt gehen?
Verstehe das "einst" nicht.
Man konnte frueher pro Modul die Liste der Attribute setzen mit $modules{XXX}{AttrList}.
Seit einiger Zeit kann man Attribute instanzspezifisch setzen mit $defs{XXX}{".AttrList"}.