diskussionsgrundlage: gruppieren von attributen

Begonnen von justme1968, 23 Januar 2018, 17:54:07

Vorheriges Thema - Nächstes Thema

Benni

Zitat von: zap am 27 Januar 2018, 09:06:26
Wie wäre es denn, wenn man im ersten Schritt oder auch als Default einstellung feste Gruppen vorsieht, z.B.

Im ersten Schritt sollte eine Gruppierung nach Modul(en) und global genügen. Eine weitere, womöglich statische Gruppierung nach Funktion sorgt am Ende wahrscheinlich eher wieder für mehr Verwirrung als für Übersicht.



Phill

#16
Wofür ist denn eigentlich die Attributgruppierung da? Nur zur Übersicht in FHEMWEB oder hat es noch einen anderen Grund.
Ok es können mehrfach vorkommende Attributnamen existieren die sich in der Gruppe unterscheiden? Aber das soll ja eher die Ausnahme sein, macht dass dann sinn? Oder sollte man nicht einfach FHEMWEB automatisch gliedern?

Ich sag jetzt einfach mal in:
Moduleigene
Globale
FHEM Intern
Allerdings kenne ich die anderen Diskussionen nicht, und deswegen würde mich erst mal meine erste Frage interessieren!
Homebrew 1-Wire / HomeMatic Mix - Cubietruck mit FHEM als Server - Raspberry PI 3 als Informationsanzeige im MagicMirror Stil - Raspberry Pi 1 als Klingelanlage - VDR

Mein Modul: Talk2Fhem - Mein Tipp: https://forum.fhem.de/index.php/topic,82442.0.html

justme1968

primär ist das erst mal nur zur übersicht. das man den gleichen attribut namen in mehr als einer gruppe haben kann ist ein nebeneffekt set manchmal sinnvoll ist, aber nicht übertrieben genutzt werden sollte.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Phill

#18
Für mich wäre es mal Hilfreich aufzulisten, welche Arten von Attribute existieren und wie sie definiert werden können.
Ich fang mal eine Liste an und werde sie dann aktualisieren.


  • Global definierte: im userattr von global
    $attr{global}{userattr}
  • Lokal definierte: im userattr vom Device
    $attr{[device]}{userattr}
  • Auf Modulebene definiert: in Initialize des Device
    $modules{[module]}{AttrList}
  • Auf Modulebene FHEM relevante: $readingFnAttributes disable, disable-for-interval, dummy, ignore, loglevel, verbose
  • Und FHEM Standard in fhem.pl definiert. $AttrList

Noch was?
Homebrew 1-Wire / HomeMatic Mix - Cubietruck mit FHEM als Server - Raspberry PI 3 als Informationsanzeige im MagicMirror Stil - Raspberry Pi 1 als Klingelanlage - VDR

Mein Modul: Talk2Fhem - Mein Tipp: https://forum.fhem.de/index.php/topic,82442.0.html

Markus Bloch

Zitat von: Phill am 31 Januar 2018, 20:54:10

  • $readingFnAttributes sind ja eigentlich FHEM Standard und auf Modulebene definiert

Die Attribute aus $readingFnAttributes enthalten alle Attribute, die ein Modul unterstützt, wenn es die readings*Update()-Funktionen verwendet (event-on-change-reading, event-on-update-reading, etc.). Dies trifft (glücklicherweise) auf die Mehrheit der Module zu. Es stammt aus der Anfangszeit wo Readings noch direkt in $hash->{READINGS} geschrieben wurden und jedes Modul selbstständig für die Generierung eines Events via $hash->{CHANGED} und DoTrigger() verantwortlich war. Es sind also Attrribute, die ein Modul unterstützt, wenn es eine bestimmte Funktion/Funktionalität von FHEM benutzt (hier die readings*Update()-Funktionen).

Gleicher Fall ist das Attribute "do_not_notify". Wenn man die readings*Update()-Funktionen nutzt, oder ein Event im Modul via DoTrigger() feuert, wird dieses Attribut ausgewertet. Der Modulautor muss es aber aktuell immer selbstständig in die eigene AttrList aufnehmen, obwohl das Modul selber dieses Attribut garnicht auswertet. Auch hier wird das Attribut do_not_notify durch die Nutzung der Funktion DoTrigger() unterstützt. Da die readings*Update()-Funktionen DoTrigger() verwenden, wird auch dadurch implizit do_not_notify unterstützt. Dennoch muss der Autor dies immer in der AttrList angeben.

Ein weiterer Fall ist das Attribut "disable", sowie "disabledForIntervals". Wenn ein Modul die Funktion IsDisabled() nutzt, werden diese beiden Attribute ausgewertet. Der Autor muss sie aber explizit aufnehmen.

Das ganze kann man für "dummy" und "ignore" weiterspinnen.

In der AttrList sollten normalerweise nur modulrelevante Attribute aufgeführt sein, die das Modul selber auswertet mMn.
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

Phill

#20
Nachdem hier der Wunsch nach eine Grundkategorisierung der Attribute gefallen ist und ich den Gedanken, um nicht den Modulauthor oder User damit zu belästigen, teile. Habe ich mal folgenden Patch erarbeitet.
Ich habe einen anderen Ansatz gewählt, als an die Attribute etwas dran zu hängen. Es existiert ein HASH (%AttrGroups) indem sind die Attributgruppen beschrieben, die Gruppen sind erst mal so gewählt wie von mir vorne Aufgezählt. Das lässt sich aber leicht anpassen. Das geniale, die Attribute sind nicht direkt benannt sondern die bestehenden Mechanismen sind darin beschrieben und verlinkt, daher wird hier kaum eine Pflege notwendig sein.
Eine neue Funktion getAttrObjByGroup($;$) bekommt eine GruppenID und liefert einen Array mit allen Attributen der Gruppe. Bei Device speziefischen Gruppen muss noch der Devicename oder hash übergeben werden.
Um alle globalen Attribute zu bekommen ist der Aufruf:
my @grps = map { getAttrObjByGroup($_) } keys %AttrGroup;
möglich. Um alle Attribute eines Devices zu bekommen wäre es
my @grps = map { getAttrObjByGroup($_, $dev) } keys %AttrGroup;


Momentan sind alle userattr aus global in einer Gruppe. Ich könnte mir aber vorstellen, addToAttrList umzubauen, dass die Module Ihre globalen Attribute in %AttrGroups registrieren, der Gruppenname wäre dann der Modulname oder vom Author wählbar.  Dann wäre userattr auch wirklich nur für User.

Warum steht eigentlich "userattr" nicht in $AttrList?
Einfach mal anschauen.

Gruß

Homebrew 1-Wire / HomeMatic Mix - Cubietruck mit FHEM als Server - Raspberry PI 3 als Informationsanzeige im MagicMirror Stil - Raspberry Pi 1 als Klingelanlage - VDR

Mein Modul: Talk2Fhem - Mein Tipp: https://forum.fhem.de/index.php/topic,82442.0.html

Phill

Achso die Umsetzung in FHEMWEB ist jetzt nicht das non plus ultra, kann sein das es da Konflikte gibt mit widgets oder wie auch immer da kenne ich mich zu wenig aus. Ist halt erst mal zur Veranschaung gedacht.
Homebrew 1-Wire / HomeMatic Mix - Cubietruck mit FHEM als Server - Raspberry PI 3 als Informationsanzeige im MagicMirror Stil - Raspberry Pi 1 als Klingelanlage - VDR

Mein Modul: Talk2Fhem - Mein Tipp: https://forum.fhem.de/index.php/topic,82442.0.html

justme1968

der patch selber fehlt :).

ja. addToAttrList und addToDevAttrList sollten unabhängig von der gruppierung umgebaut werden damit die attribute nicht mehr in den userattr landen. und wie oben schon vorgeschlagen $readingFnAttributes leeren und über getAllAttrs immer hinzufügen.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Phill

Homebrew 1-Wire / HomeMatic Mix - Cubietruck mit FHEM als Server - Raspberry PI 3 als Informationsanzeige im MagicMirror Stil - Raspberry Pi 1 als Klingelanlage - VDR

Mein Modul: Talk2Fhem - Mein Tipp: https://forum.fhem.de/index.php/topic,82442.0.html

justme1968

hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Phill

#25
Hallo, ich mal wieder...

Ich habe die Tage an einem Vorschlag gearbeitet wie im Zuge meines Umbaus, gleich die Attribute besser zur Verfügung gestellt und gesetzt werden können und auf userattr verzichtet werden kann. Ist eigentlich auch schon fertig, aber zwei Dinge sind mir dabei etwas aufgestoßen.

1.  In der Funktion getAllAttr($;$) gibt es den optionalen Paramter $cl? Der wird in der Funktion selbst nicht verarbeitet und auch ein grep auf das komplette FHEM Verzeichniss ergab das nirgends dieser zweite Parameter verwendet wird. Wurde das vorab reserviert für eine $clienthash Authorizecheck? Die noch nicht implementiert wurde? Und ist das noch geplant?

2. In CommandAttr wird am Anfang auf Vorhandensein des Attributs in der AttrList geprüft. Als nächstes wird nochmal jedes Attribut seperat geprüft. Mit dem Kommentar "is it a regexp".
Meiner Meinung nach ist bei der Prüfung kein Mehrwert, weil wieder nur auf einen Treffer der RegExp getestet wird.
    if(" $list " !~ m/ ${attrName}[ :;]/) {
       my $found = 0;
       foreach my $atr (split("[ \t]", $list)) { # is it a regexp?
         $atr =~ /^([^;:]+)(:.*)?$/;
         my $base = $1;
         if(${attrName} =~ m/^$base$/) {
           $found++;
           last;
         }
      }
      if(!$found) {
        push @rets, "$sdev: unknown attribute $attrName. ".
                        "Type 'attr $sdev ?' for a detailed list.";
        next;
      }
    }

Sollte eine Aussage getroffen werden ob es sich um eine RegExp handelt, müsste es eigentlich  so heißen: if(${attrName} =~ m/^$base$/ && ${attrName} ne $base) {Aber selbst dann könnte man sich den ganzen Aufwand sparen und nur auf is equal prüfen?
Hab ich was falsch verstanden? Aber tatsächlich scheint es nicht zu funktionieren, denn ich kann ein RegExp-Attribut anlegen. attr WEB commen. Hallo legt tatsächlich das Attribut commen. an.
Das kann doch nicht gewollt sein oder?
Außerdem, was hat es eigentlich mit der Trennung über ein Semikolon auf sich, hierzu konnte ich keine Dokumentation finden.
Homebrew 1-Wire / HomeMatic Mix - Cubietruck mit FHEM als Server - Raspberry PI 3 als Informationsanzeige im MagicMirror Stil - Raspberry Pi 1 als Klingelanlage - VDR

Mein Modul: Talk2Fhem - Mein Tipp: https://forum.fhem.de/index.php/topic,82442.0.html

rudolfkoenig

Zitat1.  In der Funktion getAllAttr($;$) gibt es den optionalen Paramter $cl?
Ich wollte die Aufrufe analog zu getAllGet/getAllSet machen, eine Verwendung habe ich nicht kurzfristig geplant.

Zitat2. ... Mit dem Kommentar "is it a regexp".
Der Kommentar ist irrefuehrend. Es geht darum, dass die Spezifikation der zulaessigen Attribute ein Regexp ist, da manche Module eine Variable Anzahl von Attributen brauchen, schau mal AttrList in HTTPMOD an.

ZitatAußerdem was hat es sich mit der Trennung über ein Semikolon auf sich
Weiss leider nicht mehr. In FHEM 4.0 / 11_FHT.pm war model mit ; von der Liste der moeglichen Modelle getrennt, die anderen (dummy,showtime,do_not_notify,loglevel) mit : von ihrem jeweiligen Argument. Wuerde mich wundern, wenn es noch sinnvoll funktioniert.

Phill

Ok verstehe, Danke für die Antwort.
Dann ist es aber trotzdem nicht notwendig Attributnamen zuzulassen, die auf keine AttributRegex zutreffen. Das ist aktuell der Fall. Siehe Beispiel "commen."

Dann wäre es ausreichend wenn man das "if" einfach weg lässt.
Denn dort wird der angegebene Attributname als RegExp intepreiert, und das ist eigentlich Falsch, da die AttributListe als Regexp angeommen werden muss. Und das geschieht ja dann anschließend in der Schleife.

Wäre mMn richtig und schneller. Ich werde das bei meinem Vorschlag mal so einbauen. Bei meinen Tests hat es so geklappt.
Gruß
Homebrew 1-Wire / HomeMatic Mix - Cubietruck mit FHEM als Server - Raspberry PI 3 als Informationsanzeige im MagicMirror Stil - Raspberry Pi 1 als Klingelanlage - VDR

Mein Modul: Talk2Fhem - Mein Tipp: https://forum.fhem.de/index.php/topic,82442.0.html

Phill

#28
So der Patch ist fertig. Zumindest soweit ich es getestet habe. Würde mich wundern wenn gleich alles erschlagen wurde.
Bitte mal testen und Rückmeldung geben.

Ich habe diesmal auch Kommentare hinzugefügt. Folgendes ist jetzt gegeben:

  • Automatische Gliederung der Attribute in diese Kategorien

  • Custom: userattr des device
  • Gobal custom: userattr von global
  • Local: Devicespezifische Modulattribute addToDevAttrList vormals userattr
  • Module: Modulspezifische Attribute Modul->AttrList
  • Globalmodul: Modulspezifische globale Attribute z.B. FHEMWEB addToAttrList
  • Events: $readingFnAttributes
  • Activity: disable verbose ...
  • FHEM: $AttrList

  • userattr und global userattr sind frei und werden durch die Module z.b. FHEMWEB oder structure nicht mehr gefüllt
  • Vollständige Abwärtskompatibiliät, gerüstet für zukünftige Erweiterungen
  • FHEMWEB Änderungen vereinfacht und Kommentiert

Kurzer Überblick

Neuer globaler HASH: %AttrGroup
Definiert die Attributeigenschaften.

Neue Funktionen:

sub getAttrObjByGroup($;$);
AttrObj ist ein hash der Attrbuteigenschaften "attrname", "setting", "group" in einem Array. Setting sind die defaultwerte.

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

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

Geänderte Funktionen:

sub addToAttrList($;$);
Zusätzlich kann der Funktion jetzt der Name der Gruppe übergeben werden, normalerweise der Modulname. z.B. FHEMWEB. Wenn nicht gesetzt werden die Attribute der Gruppe Global hinzugefügt.
Kann jetzt neben einem einzelnen Attribut, auch eine ganze AttrList verarbeiten

sub addToDevAttrList($$)
Fügt nicht mehr dem userattr, sondern dem neuen versteckten Attribut AttrList hinzu

sub getAllAttr($;$$);
Neuer Parameter $hidden. Wenn $hidden 0 ist werden nur die Sichtbaren Attribute ausgegeben. undef und 1 werden Sie ausgegeben, für die Abwärtskompatibilität.
Im scalaren Kontext wird die Liste wie gewohnt ausgegeben, im Listen Kontext (Array) wird AttrObj zurückgegeben.

sub CommandAttr($$)
konnte jetzt vereinfacht werden. RegEx Attribute werden nicht mehr akzeptiert. siehe vorherigen Beitrag

Folgendes ist noch zu tun:

  • Löschen der Attributdefinition aus userattr und global userattr beim initializieren
  • Benchmark
  • gibt noch ein paar undef compare warnungen.
  • eine funktion "isAttrInGroup" könnte den Code noch etwas vereinfachen / schneller machen
  • addToAttrList könnte sogar direkt AttrObj oder CODE aufnehmen
  • in FHEMWEB die Spracheinstellung in $AttrGroup{type}{name}"{EN}" einsetzen.
  • Gruppen sinnvoll sortieren. Z.b. zuerst moduleigene

Feedback wäre schön.

Gruß

EDIT: 07.02 14:37 Update Ich habe noch ein bisschen weiter gemacht, da ich es mittlerweile in meinem Produktivsystem drin hab.
EDIT: 21.02 11:41 Update Patch an die aktuelle Revision angepasst
Homebrew 1-Wire / HomeMatic Mix - Cubietruck mit FHEM als Server - Raspberry PI 3 als Informationsanzeige im MagicMirror Stil - Raspberry Pi 1 als Klingelanlage - VDR

Mein Modul: Talk2Fhem - Mein Tipp: https://forum.fhem.de/index.php/topic,82442.0.html

rudolfkoenig

Zitataber weiter gedacht: gibt es überhaupt einen grund warum $readingFnAttributes nicht einfach immer für jedes modul zur verfügung steht?
Ich habe mal gezaehlt: aus den ca 480 Moduldateien der Form ??_*.pm gibt es 110, die kein readings.*Update aufrufen (z.Bsp FBAHAHTTP, FHZ, FHEMWEB), und das auch nicht planen. Fuer diese Module waere das automatische Hinzufuegen von readingFnAttributes kontraproduktiv.

ZitatDann ist es aber trotzdem nicht notwendig Attributnamen zuzulassen, die auf keine AttributRegex zutreffen. Das ist aktuell der Fall. Siehe Beispiel "commen."
Verstehe ich nicht:
fhem> set CUL_0 commen. hallo
Unknown argument commen., choose one of...


Ich habe den Patch von andre angeschaut, Bemerkungen/Probleme:
- AttrVal wird langsamer, falls das Attribut nicht gesetzt ist: auf meinem Rechner kosten 1Mio Aufrufe in der alten Version 2.25s, in der Neuen 7.45. Klingt nicht nach viel, aber ein RPi ist 10-mal langsamer, und ein FHEMWEB-Seitenaufruf (fhem.cfg.demo, Sensors Seite) bedeutet 2000 AttrVal Aufrufe, das wuerde auf einem RPi statt  0.045s in der neuen Version 0.149s bedeuten, "nur" wegen Gruppieren.
- die Aenderung fuer Zeile 2750 verstehe ich nicht.
- das Fuellen des Wertes bei Gruppen-Attributen in FHEMWEB funktioniert nicht
- das Setzen der Gruppen-Attribute in FHEMWEB funktioniert nicht
- das Dropdown ist nicht wie im Screenshot: Attribute sind zwar eingerueckt aber eine Ueberschrift gibt es nicht.

Patch von Phill:
- der Patch ist groesser und schwerer zu verstehen.
- bin noch unsicher, ob man wirklich so viele Gruppen braucht, die Namen sind jedanfalls nicht intuitiv.
+ scheint alles zu funktionieren
+ AttrVal bleibt unveraendert, ist also auch nicht langsamer.

Z.Zt. tendiere ich fuer Phills Patch, allerdings etwas vereinfacht. Falls noch Interesse daran besteht.