Bei meinem MAX Modul benötige ich bei einem bestimmten Device Typ Attribute die bei anderen Typen keinen Sinn machen.
Bis jetzt hatte ich dazu in der DefineFn folgende Zeilen :
if ($devtype == 6) {
addToDevAttrList($name ,'delay_open delay_close');
delay_open & delay_close stehen danach im userattr des Device -> alles gut wie es sein soll
jetzt wollte ich die Liste erweitern :
addToDevAttrList($name ,'delay_open delay_close peers sendMode:peers,group,Broadcast');
und bin fast durchgedreht das die neuen Attribute nicht in userattr und in der dropDown Liste erscheinen.
Nachdem ich das Attribut userattr komplett gelöscht und FHEM neu gestartet habe stehen nun brav alle vier im userattr.
Ich hatte den Kommentar dazu in fhem.pl
# Add an attribute to the userattr list, if not yet present
so verstanden das ich einzelne Elemente dazunehmen kann wenn sie noch nicht vorhanden sind, ( add an attribut ) aber es wird die Liste nur angelegt wenn sie noch gar nicht vorhanden ist.
Ist das so gewollt und nur der Kommentar etwas irreführend oder ein Bug ?
Ich sehe weder im Code ein Bug, noch kann ich das Problem nachstellen:
fhem> define d dummy
fhem> l d userattr
fhem> { addToDevAttrList("d" ,'delay_open delay_close') }
delay_close delay_open
fhem> l d userattr
d delay_close delay_open
fhem> { addToDevAttrList("d" ,'delay_open delay_close peers sendMode:peers,group,Broadcast') }
delay_close delay_open peers sendMode:peers,group,Broadcast
fhem> l d userattr
d delay_close delay_open peers sendMode:peers,group,Broadcast
Da ich mit dieser Funktion intensiv arbeite kann ich Rudis Tests bestättigen. Bei mir funktioniert alles so wie es soll. Selbst wenn schon entsprechende UserAttribute über die Funktion vorhanden sind können ohne weiteres neue hinzugefügt werden.
Danke fürs testen und sorry für die zustätzliche Arbeit. Ihr habt ja beide recht, wenn man so im laufenden Betrieb testet klappt das ohne Probleme.
Wenn aber der Aufruf wie bei mir innerhalb der DefineFn erfolgt klappt es eben nicht sobald ein gespeichertes usserattr vorhanden ist.
Allerdings vermute ich inzwischen einen Denkfehler auf meiner Seite, d.h. die Funktion als solches arbeitet fehlerfrei, ruft man sie allerdings innerhalb von Define auf dann macht einem danach das weitere abarbeiten der fhem.cfg einen Strich durch die Rechnung und stellt userattr wieder so her wie es aktuell in der fhem.cfg steht.
Ich bin aber eigentlich auch Udos Meinung der mal geschrieben hat "User Attribute gehören dem User" , d.h. da muss ich als Modulautor nicht unbedingt dran drehen.
Als Alternative käme ja auch setDevAttrList in Betracht, alerdings kann ich nach ersten Tests die $hash->{AttrList} aus Inialize nicht einfach erweitern sondern nur komplett neu setzen.
Oder gibt es noch eine andere Alternative die ich jetzt nicht sehe / kenne ?
Bzw kennt jemand ein Modul das ähnliches bereits umgesetzt hat und ich kann mal wieder ganz elegant einfach abschreiben ?
Die Menge der setzbaren Attribute besteht aus der Summe von:
- die hartkodierten Attribute (room, verbose, etc)
- die instanzspezifische Liste ($defs{X}{".AttrList"}, gesetzt via setDevAttrList), oder falls diese nicht vorhanden ist, die modulspezifiche Liste ($modules{T}{AttrList})
- global userattr
- instanzspezifische userattr
Wenn man im DefineFn die Liste der zusaetlichen Attributnamen bestimmen kann, dann reicht es im DefineFn setDevAttrList() zu verwenden.
Wenn diese Liste erst spaetert, anhand von anderen Attributen/Events/etc. erkannt wird, dann sollte man beim Erkennen die instanzspezifische userattr mit addToDevAttrList() erweitern.