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.
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.
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.
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.
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.
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.
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.
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.
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>
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.
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.
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.
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.
Da ich mein Modul mit setDevAttrList einchecke, sollte es nicht mehr geändert werden.
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.
Ok. Vielleicht sehe ich das auch zu drastisch.
Nur soll der Entwickler darauf achten, das die ignorierten Attribute nicht bereits existieren.
Gruß
Hallo,
ich stieß soeben auf die Funktion
setDevAttrList
Ich habe diese mal ausprobiert und in mein Testmodul eingebaut.
Eine Frage hätte ich diesbezüglich.
Wie kann ich zur Laufzeit modifizierte Attribute, welche mit der Funktion erstellt werden und deren Wert in der fhem.cfg speichern wieder abrufen nach einem FHEM restart?
Die Werte bleiben in der cfg gespeichert aber wenn ich die Attribute erst wieder jedes mal neu erstelle, lesen diese ja nicht die Konfiguration aus der cfg aus.
Gibt es da einen Trick oder überrsehe ich dort etwas?
MfG und Danke im Vorraus.
mit AttrVal. wie jedes andere attribut auch.
Wie stellt man sicher, dass die mit setDevAttrList gesetzten/erstellten Attribute nach einem shutdown restart weiterhin vorhanden sind? In meiner aktuellen Implementierung gehen sie nach dem Neustart verloren. Ich mach direkt im Define aktuell immer ein setDevAttrList. Darf ich das vielleicht nur einmal machen?
Ein Aufruf im DefineFn sollte reichen.
In fhem.pl wird die Variable $defs{x}{".AttrList"} nur im setDevAttrList und in getAllAttr angefasst.
Ich weiß nun woran es liegt.
Beim Starten wird bei mir nicht das komplette Define durchlaufen, sondern erst zu einem späteren Zeitpunkt. Das führt dazu, dass nach dem Define das Attribut noch unbekannt ist. Erst nach $init_done=1 werden alle Attribute bekannt. Wäre es möglich, dass wir beim Laden der fhem.cfg/config.db alle Attribute zulassen, ohne Prüfung? Weil dann kann man auch später zur Laufzeit noch ein setDevAttrList machen.
Ungern: fhem.cfg Editierer wuerden kein Feedback beim Vertippen bekommen.
Vermutlich gibt es auch andere Nebeneffekte, die ich jetzt nicht abschaetzen kann.
Ich sehe folgende Alternativen:
- setDevAttrList im DefFn auf "Alles" setzen, und sie spaeter nochmal aufrufen, und beschraenken
- gesetzte "Problemattributnamen" zusaetzlich im Device spezifischen userattr setzen.
- "Problemattributnamen" alphabetisch hinter "Bestimmerattributnamen" setzen, und setDevAttrList aus AttrFn(Bestimmeratribut) aufrufen.
Danke für den Tipp! Das mit dem userattr ist vielleicht eine gute Möglichkeit. Ich kann die userattr kurz anlegen und danach auch wieder löschen wenn setDevAttrList gesetzt ist.