Nochmal Gruppieren von Attributen

[Phill]

Vorheriger Thread hier


Bitte mal testen. Man kann jederzeit wieder zurück zur originalen FHEM Version.
fhem.pl und FHEM/01_FHEMWEB.pm in fhem Verziechnis kopieren und neu starten.


Hallo,

Eigentlich wollte ich ja nur mein FHEM auf 5.9 updaten, aber die Attributgruppen wollte ich dann doch behalten.
Deswegen habe ich den Patch an die Neue Version angepasst und wollte ihn hier nochmal zur Diskussion stellen.

Ich fasse das ganze mal etwas zusammen.

Hintergrund war die Überlegung die FHEM Attribute zu Kategorisieren um eine bessere Übersicht zu erlangen. Auf Grundlage des Patches von justme1968 hatte ich die Attribute in Gruppen eingeteilt, die dann von FHEMWEB gegliedert angezeigt werden.
Das Attribut "userattr" im Device und im Device "global" sind dahingegehend befreit, dass es ausschließlich dem Anwender vorbehalten ist. Sprich "FHEMWEB" definiert seine globalen Attribute nicht mehr in userattr von "global" und structure nicht mehr in userattr des Devices.
Außerdem sind ein paar kleinere Bugfixes gemacht.
Der Arbeitsaufwand für Modulentwickler ist gleich Null, da die vorhanden Funktionen nur um optionale Parameter erweitert wurden. Es kann also alles weiter wie gewohnt genutzt werden.

Der Patch hat ganz klar für die Profis unter euch weniger Mehrwert und ist eher für den Normalanwender und Anfänger gedacht, der Ordnung in die Flut von Attribute gebracht bekommt.

Die Gruppen die aus meiner Sicht sinnvoll sind: (das wording und die Sinnhaftigkeit genauso wie die Reihenfolge mit der sie angezeigt werden ist wohl noch zu diskutieren)

• Custom / Eigene: Wird in userattr des devices definiert und steht nur diesem Device zur Verfügung. Für eigenes Coding des Anwenders.
• Gobal custom / Eigene Global: In userattr des Device "global". Steht FHEM-weit zur Verfügung. Auch für eigenes Coding.
• Module / Modul: Modulspezifische Attribute definiert in $modulhash->{AttrList}. Während Laufzeit überschreibbar mit setDevAttrList. Hier können vom Modulauthor eigene Unterkategorien erzeugt werden
• Events / Ereignisse: Eigentlich Modulattribute alle $readingFnAttributes
• FHEM: Standard Attribute von FHEM gespeichert in $AttrList
• Local / Lokal: Deviceattribute über addToDevAttrList/delFromDevAttrList erzeugt, vormals in userattr jetzt im Hash %AttrGroup gespeichert. z.B. structure
• Frei wählbar ansonsten Global: FHEM-weite Modulattribute über addToAttrList/delFromAttrList z.B. FHEMWEB. Der Name der Gruppe kann als Parameter der Funktion addToAttrList übergeben werden, ansonsten ist der Gruppenname Global.

Das ganze ist vollständig Abwärtskompatibiliät.

Erläuterungen zu dem Patch

Neuer globaler HASH: %AttrGroup
Enthält die Deklaration der Attributkategorien. Wenn die Kategorien geändert werden sollen dann wird dieser Hash geändert.

Code Auswählen Erweitern


%AttrGroup = (
  "userlocal"=> { NAME=>{EN=>"Custom", DE=>"Eigene"},
    ORDER=>10,
    FN=>sub {
      return unless $_[0]{NAME};
      $attr{$_[0]{NAME}}{userattr};
    } 
    },
[...]



Definition AttrObj: Ein Hash mit den Attributeigenschaften. Grundsätzlich als Array vorhanden.
Bisher die scalare Attributdefinition

Code Auswählen Erweitern


beispielattr:1,2,3,4,5 anderes:textfield-long

Neu AttrObj:

Code Auswählen Erweitern


[{ATTRNAME=>"beispielattr", SETTING="1,2,3,4,5", GROUP="userlocal"},
{ATTRNAME=>"anderes", SETTING="textfield-long", GROUP="userlocal"}]


Modulauthoren können Ihre Attribute selbst gruppieren
Veranschaulicht beim Device global wofür diese Funktion Sinnvoll wäre siehe Anhang global_device.jpg
Mein umgesetzter Vorschlag.
Statts wie gewohnt die $hash->{AttrList} zu füllen wird ein Array in $hash->{AttrGroup} folgendermaßen angelegt:

Code Auswählen Erweitern

  @{$hash->{AttrGroup}} = (
{NAME=>"Attributgruppenname ohne sprachliche unterschiede",
AttrList=>"attr1:1,2,3 attr2 attr3"},
{NAME=>{EN=>"Group 2",DE=>"Gruppe 2"},
AttrList=>"attrb1:ja,nein attrb2 attrb3"},
{NAME=>{EN=>"THREE",DE=>"DREI"},,
AttrList=>"attrc1 attrc2 attrc3"},
);
oder
  push($hash->{AttrGroup}, {NAME=>"Attributgruppenname", AttrList=>"q w e"});
 
Will man während der Laufzeit die Attribute des Moduls eines Devices ändern, geht das weiterhin wie bisher mit "setDevAttrList" nur kann jetzt auch der Array wie oben übergeben werden.

Neue Funktionen:

sub getAttrObjByGroup($;$);
Liefert alle Attribute der angegebenen Gruppe des optionalen Device

sub getAttrObjByString($);
konvertiert die scalare AttrList in AttrObj

sub isAttr($$;$);
Überprüft ob das Attribut für das Device definiert ist.

Geänderte Funktionen:

sub addToAttrList($;$);
Der Funktion kann jetzt ein Name übergeben werden der den Gruppennamen darstellt, sinnhafterweise der Modulname. z.B. FHEMWEB. Wenn nicht gesetzt werden die Attribute der Gruppe Global hinzugefügt.
Kann jetzt neben einem einzelnen Attribut, auch AttrList und AttrObj verarbeiten

sub delFromAttrList($;$);
Bugfix: Löscht jetzt auch vorhandenen Attribute aus den Devices.

sub addToDevAttrList($$)
Fügt die AttrList nicht mehr dem Attribut userattr hinzu, sondern speichert die Liste im AttrGroup-Hash.
$AttrGroup{local}{DEVS}{$devname}
Ist damit auch nicht mehr über Attribute gespeichert und wird bei jedem Neustart neu generiert. Verträgt jetzt auch den Device-Hash.

sub delFromDevAttrList($$)
Nur Kompatibilitätsanpassung.

sub getAllAttr($;$);
Im scalaren Kontext wird die Liste wie gewohnt ausgegeben, im Listen Kontext (Array) wird AttrObj zurückgegeben. Verträgt jetzt auch den Device-Hash.

sub CommandAttr($$)
konnte jetzt vereinfacht werden.
Bugfix: Attributnamen können nicht mehr mit RegExp Zeichen frei gewählt werden. (Etwas schwer zu erklären siehe hier

setDevAttrList($;$)
Kann neben der AttrList auch den Array AttrGroup vertragen.

Folgendes ist noch zu tun:

• addToAttrList sollte konsequenterweise auch AttrObj verarbeiten können
• Commandref anpassen
• DevGuide Wiki anpassen

Und noch ein paar Brainstormingnotizen.

• Beim definieren von Attributen über userattr testen ob Attribut schon existiert
• Gruppierte darstellung in FHEM Befehlen. list und attr dev ?
• Gruppieren von Readings / INTERNALS ermöglichen

Bitte mal ausprobieren und Feedback geben, Danke.

Gruß

Anhang: Patch und gepatchte fhem.pl und 01_FHEMWEB.pl

[Loredo]

Find ich super!

[JoWiemann]

Schließe mich an.


Gesendet von iPad mit Tapatalk

[CoolTux]

Schließe mich einem dafür an. Gefällt mir sehr.

[Benni]

Sieht gut aus!

+1

[Phill]

Das klingt doch schon mal gut.

Wie bekommen wir jetzt aber die über addToDevAttrList und addToAttrList bereits im Attribut "userattr" gespeicherten Attributdefinitionen raus.

Meine erste Idee ist, dass bei jedem Aufruf von addToAttrList die userattr-Liste vom Device global mit der übergebenen Attributliste verglichen und gefiltert wird.

Genauso bei addToDevAttrList, hier dann nur mit dem angegebenem Device.

Die Attribute werden ja bei jedem Neustart erneut gesetzt, wenn ich das richtig sehe? Wie macht das z.b. structure.

Oder jemand eine bessere Idee? Eventuell während des Update-prozesses! Ansonsten würde ich das mal so umsetzen.

Gruß

[Phill]

Ich habe das entfernen der "userattr" jetzt mal so umgesetzt wie ich es beschrieben habe. Es gibt jetzt bis auf die userattr keine Attributdefinitionen mehr die über einen FHEM Neustart hinweg gespeichert sind. Ist mMn richtig und konsequent.

Bitte mal testen. Und Feedback geben. Man kann jederzeit wieder zurück zur originalen Version.
Einfach die files.tar.gz aus dem ersten Beitrag im FHEM Verzeichnis entpacken oder den Patch ausführen und neu starten.

Geändert sind fhem.pl und FHEM/01_FHEMWEB.pm. Diese eventuell vorher sichern.

Mit den Gruppennamen bin ich wie gesagt noch nicht 100%ig zufrieden, daher bitte Vorschläge machen.

Gruß

[Benni]

Hallo zusammen,

was ist eigentlich aus der Idee geworden?
Soweit ich sehe, leider nix!

Ich bin aktuell mal wieder am Modul basteln und habe mich wieder mal daran gestört, alle modulspezifischen Attribute mit einem Präfix versehen zu müssen, um Sie a) für den Nutzer eindeutig als modulspezifisch zu kennzeichnen und sie b) in der Attributliste "gruppiert" zu haben.

Bei der Fülle der Module, v.a. wenn man viele davon nutzt, wäre m.E. "irgendeine" Gruppierung inzwischen besser, als gar keine.

gb#

[Phill]

Hallo, also ich bin noch dabei wenn sich hier noch was tut. Dabei habe ich gleich mal den Patch auf die aktuelle Revision (17566) angepasst. (AttrGroup_9.patch)
Läuft nach wie vor ohne Probleme.

Bitte von dem etwas umständlichen Code in der 01_FHEMWEB.pm nicht verunsichern lassen. War damals einfach nur QuicknDirty und sollte sich noch um einiges vereinfachen lassen.

Was ich nochmal besonders erwähnen wollte, ist, dass die Modulauthoren nicht tätig werden müssen, da die Attribute automatisch in die Modulkategorie wandern.
Grüße

[Benni]

Sehr schön!

Ich habe den neuen Patch direkt mal auf meinem Entwicklungssystem eingespielt.
Funktioniert, wie erwartet und gefällt mir sehr gut! 

Ich hoffe, Rudi lässt sich diesmal darauf ein

gb#