Attribut-Liste instanzabhängig zur Laufzeit ändern

Begonnen von Damian, 17 März 2018, 22:21:49

Vorheriges Thema - Nächstes Thema

Damian

Lässt sich die Attributliste zum Definitionszeitpunkt eines Moduls unterschiedlich vorbelegen?

Hintergrund: Das DOIF-Modul bekommt einen neuen Perl-Modus, der aufgrund der Definition erkannt wird. Für diesen sind nur bestimmte Attribute sinnvoll.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

rudolfkoenig

Nein, Attribute sind zZt. modulspezifisch, und nicht instanzspezifisch.

Ich vermute, dass es ohne grossen Aufwand optional instanzspezifisch gemacht werden kann, aber es wird dann alles wieder etwas komplizierter. Deswegen: erst nachdem noch ein Entwickler sich dafuer ausspricht, baue ich es ein.

Damian

Zitat von: rudolfkoenig am 18 März 2018, 10:04:58
Nein, Attribute sind zZt. modulspezifisch, und nicht instanzspezifisch.

Ich vermute, dass es ohne grossen Aufwand optional instanzspezifisch gemacht werden kann, aber es wird dann alles wieder etwas komplizierter. Deswegen: erst nachdem noch ein Entwickler sich dafuer ausspricht, baue ich es ein.

OK. Danke für die Info - das habe ich schon vermutet.

Dann muss ich wohl in der Doku aufnehmen, welche Attribute im neuen Perl-Modus sinnvoll anwendbar sind.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

klaus.schauer

Es wäre schon sinnvoll, wenn die Attributliste eines Devices typenabhängig - subtype und /oder model - individuell und zur Laufzeit angelegt und geändert werden könnte. Für EnOcean gibt es zwischenzeitlich insgesamt mehr als 100 Attribute. Welches für das jeweilige Device tatsächlich genutzt wird, versuche ich in der commandref zu beschreiben. Sicherlich nicht der beste Weg.

Zudem sind zunehmend herstellerspezifische Besonderheiten zu berücksichtigen, deren Parameter dann aus XML-Beschreibungen nachgeladen werden sollen.

justme1968

instanz spezifische attribute wären gut und nützlich.

aktuell kann man sich mit addToDevAttrList behelfen. eine richtige lösung wäre aber besser.

aber bitte nicht in einer hauruck aktion die nur halb gar ist und selbst mit mehrmaligem nachbessern nicht wirklich gut wird.

wenn an dem attributen etwas geändert wird dann bitte unter anderem auch die anderen punkte aus dem thread zu attribut gruppen mit berücksichtigen.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

rudolfkoenig

Zitataber bitte nicht in einer hauruck aktion die nur halb gar ist und selbst mit mehrmaligem nachbessern nicht wirklich gut wird.
Ich wollte getAllAttr aendern, und hier erst nach $defs{$d}{AttrList} fragen, und falls nicht gesetzt, dann (wie bisher) nach $modules{...}{AttrList}

Zitatwenn an dem attributen etwas geändert wird dann bitte unter anderem auch die anderen punkte aus dem thread zu attribut gruppen mit berücksichtigen.
Das ist auch noch auf meiner TODO-Liste, da es aber was groesseres ist, schiebe ich es gerne nach hinten.

rudolfkoenig

Ich habe getAllAttr leicht angepasst, so dass (falls existiert) $defs{$d}{".AttrList"} statt $modules{...}{AttrList} genomen wird.
Ich habe die hidden Variante gewaehlt, weil ich die Anzeige nicht unnoetig aendern wollte.

Damian

Zitat von: rudolfkoenig am 18 März 2018, 22:54:41
Ich habe getAllAttr leicht angepasst, so dass (falls existiert) $defs{$d}{".AttrList"} statt $modules{...}{AttrList} genomen wird.
Ich habe die hidden Variante gewaehlt, weil ich die Anzeige nicht unnoetig aendern wollte.

Ich habe es eingebaut, scheint zu funktionieren. Getestet: Auswahl der Attribute im WEB-Browser (auch beim Wechseln des Zustands des Moduls zur Laufzeit).

Wäre es nicht besser solche Features über Funktionsaufrufe zu kapseln. Bisher habe ich das Patchen von $defs gemieden.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

rudolfkoenig

ZitatWäre es nicht besser solche Features über Funktionsaufrufe zu kapseln. Bisher habe ich das Patchen von $defs gemieden.
Dein Wunsch...
fhem> attr d ?
d: unknown attribute ?, choose one of alias comment:textField-long eventMap:textField-long group room suppressReading userReadings:textField-long verbose:0,1,2,3,4,5 readingList setList useSetExtensions disable disabledForIntervals event-on-change-reading event-on-update-reading event-aggregator event-min-interval stateFormat:textField-long timestamp-on-change-reading oldreadings cmdIcon devStateIcon devStateStyle icon sortby webCmd webCmdLabel:textField-long widgetOverride userattr
fhem> { setDevAttrList("d", "a b c") }
a b c
fhem> attr d ?
d: unknown attribute ?, choose one of alias comment:textField-long eventMap:textField-long group room suppressReading userReadings:textField-long verbose:0,1,2,3,4,5 a b c cmdIcon devStateIcon devStateStyle icon sortby webCmd webCmdLabel:textField-long widgetOverride userattr
fhem> { setDevAttrList("d") }
a b c
fhem> attr d ?
d: unknown attribute ?, choose one of alias comment:textField-long eventMap:textField-long group room suppressReading userReadings:textField-long verbose:0,1,2,3,4,5 readingList setList useSetExtensions disable disabledForIntervals event-on-change-reading event-on-update-reading event-aggregator event-min-interval stateFormat:textField-long timestamp-on-change-reading oldreadings cmdIcon devStateIcon devStateStyle icon sortby webCmd webCmdLabel:textField-long widgetOverride userattr
fhem>

Damian

Zitat von: rudolfkoenig am 20 März 2018, 22:15:51
Dein Wunsch...
fhem> attr d ?
d: unknown attribute ?, choose one of alias comment:textField-long eventMap:textField-long group room suppressReading userReadings:textField-long verbose:0,1,2,3,4,5 readingList setList useSetExtensions disable disabledForIntervals event-on-change-reading event-on-update-reading event-aggregator event-min-interval stateFormat:textField-long timestamp-on-change-reading oldreadings cmdIcon devStateIcon devStateStyle icon sortby webCmd webCmdLabel:textField-long widgetOverride userattr
fhem> { setDevAttrList("d", "a b c") }
a b c
fhem> attr d ?
d: unknown attribute ?, choose one of alias comment:textField-long eventMap:textField-long group room suppressReading userReadings:textField-long verbose:0,1,2,3,4,5 a b c cmdIcon devStateIcon devStateStyle icon sortby webCmd webCmdLabel:textField-long widgetOverride userattr
fhem> { setDevAttrList("d") }
a b c
fhem> attr d ?
d: unknown attribute ?, choose one of alias comment:textField-long eventMap:textField-long group room suppressReading userReadings:textField-long verbose:0,1,2,3,4,5 readingList setList useSetExtensions disable disabledForIntervals event-on-change-reading event-on-update-reading event-aggregator event-min-interval stateFormat:textField-long timestamp-on-change-reading oldreadings cmdIcon devStateIcon devStateStyle icon sortby webCmd webCmdLabel:textField-long widgetOverride userattr
fhem>


OK. Ich habe es ins DOIF-Modul eingebaut.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Phill

#10
Das heißt es gibt jetzt:
Zitatsub addToDevAttrList($$);
sub setDevAttrList($;$);

welche unterschiedliche Speicherorte verwenden.
addTo... bearbeitet das Attribut userattr des Devices.
set... setzt das Internal .AttrList
Das ist verwirrend.

Eigentlich füllt addToDevAttr in meinem Patch der Attributgruppen schon nicht mehr userattr, sondern erzeugt ein verstecktes Attribut AttrList.
Sollte man aber trotzdem nicht über einen Kamm scheren, da die Anwendung der Funktionen unterschiedlich ist.   
addTo... (aktuell userattr) wird ja von diversen Modulen (structure) dafür verwendet Attribute devicespezifisch zu setzen.
set... Soll die Attribute des Modul während der Laufzeit ändern. Das ist aber mit dem Attributgruppenpatch auch leicht umsetzbar.

Wie gesagt der Funktionsname geht m.M.n. nicht. Bitte nochmal überdenken. Vorschlag: setModAttrList ?

Sorry das ich erst hinterher damit ankomme... Habe das vorher nicht so ganz überrissen.
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

ZitatWie gesagt der Funktionsname geht m.M.n. nicht. Bitte nochmal überdenken. Vorschlag: setModAttrList ?
Verstehe ich nicht: setModAttrList suggeriert, dass man damit die Liste fuer das Modul setzen kann, in diesem Fall setze ich aber die Geraetespezifische Liste.

Phill

#12
Ja das suggeriert es wirklich. Aber die Funktion bekommt ja als Parameter nicht den Modulhash sonder den Devicehash.

Problem ist ja, dass es jetzt 2 gerätespeziefische Attributlisten gibt. Und mit setDevAttrList überschreibt man im Endeffekt die Modulattribute des Gerätes und nicht die ursprüngliche DevAttrList (userattr) die mit addToDevAttrList bearbeitet wird.

Mir fällt da noch replaceModAttrList ein.

EDIT: Was auch nicht behandelt ist, wenn ein Attribut gesetzt wurde welche dann später vom Modul über "setDevAttrList" gelöscht wird, entsteht ein totes Attribut was nicht mehr gelöscht werden kann, aber weiterhin angezeigt wird. Gibt dann einen Fehler beim Neustart bis einmal gespeichert wird.
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

Damian

Da ich mein Modul mit setDevAttrList einchecke, sollte es nicht mehr geändert werden.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

rudolfkoenig

ZitatMir fällt da noch replaceModAttrList ein.
Du hast Recht damit, dass setDevAttrList u.U. falsche Assoziationen hervorrufen kann, allerdings ist replaceModAttrList auch nicht besser (man koennte Annehmen, dass sie $modules{XXX}{AttrList} setzt), und  Funktionsnamen, die laenger als eine Zeile sind, sind auch keine Loesung. Wer diese Funktion verwenden will (und das ist eher die Ausnahme), der moege bitte nachlesen, wozu sie gut ist. setDevAttrList bleibt bis auf Weiteres.