Ist es möglich aus einem Modul heraus etwas zu definieren, dass man ansonsten nur mit widgetOverride erreicht? Ich würde ungern multiple-strict für das Attribut eines Moduls verwenden, möchte aber ungern aus dem Modul heraus 2 Attribute setzen müssen. 1x das Attribut selbst und 1x das Attribut widgetOverride.
Es wäre superpraktisch, denn man als Modulauthor sowas ebenfalls definieren könnte und der Anwender das dann trotzdem mit widgetOverride überlagern könnte. Man könnte als Modulauthor das Interface massiv aufwerten, ohne dem Anwender die Möglichkeit zu nehmen, das dann am Ende doch anders zu machen.
das setzen von widgetOverride und anderen attributen sind für den endanwender.
als modulautor gibt man die vorgesehenen widgets in der antwort auf set ? bzw. attr ? mit zurück.
d.h. das was du möchtest geht ,schon immer'.
Ich habe kein Modul und auch keine Beschreibung gefunden wie genau das funktionieren soll. Durch probieren bin ich auch nicht drauf gekommen. Im Modul habe ich unter anderem sowas definiert gehabt:
$hash->{AttrList} = "xyz:multiple-strict ".$readingFnAttributes;
Ich kann hier leider nicht sofort Werte hinterlegen, da ich diese erst zur Laufzeit ermitteln muss. Deshalb wollte ich dann später im Modul folgendes machen:
$attr{$name}{"xyz"} = ",a,b,c"
Ich habe verschiedenste Varianten ausprobiert, bin aber nicht darauf gekommen, wie das Problem zu lösen ist. In den meisten Fällen habe ich ein Attribut erzeugt und dahinter ist eine Combobox mit multiple-strict darin aufgetaucht. Die Werte a,b,c waren meist verschwunden.
Bei meinem msgDialog Modul nutze ich folgende sub:
sub msgDialog_updateAllowed {
my $allowed = join(",", sort(devspec2array($msgDialog_devspec)));
$modules{msgDialog}{AttrList} =~
s/allowed:multiple-strict,\S*/allowed:multiple-strict,everyone,$allowed/;
}
Das gilt aber für JEDE Definition des Moduls.
Im Initialize des Moduls wird das Attribut Initialisiert
$hash->{AttrList} =
"allowed:multiple-strict,everyone ".
$readingFnAttributes
;
Im define rufe ich dann die "msgDialog_updateAllowed" sub auf.
um nachträglich attribute hinzuzufügen gibt es addToDevAttrList. siehe hier: https://wiki.fhem.de/wiki/DevelopmentModuleAPI#Attribute_in_anderen_Definitionen_bereitstellen (https://wiki.fhem.de/wiki/DevelopmentModuleAPI#Attribute_in_anderen_Definitionen_bereitstellen)
Zitat von: justme1968 am 12 Oktober 2017, 18:39:10
um nachträglich attribute hinzuzufügen gibt es addToDevAttrList. siehe hier: https://wiki.fhem.de/wiki/DevelopmentModuleAPI#Attribute_in_anderen_Definitionen_bereitstellen (https://wiki.fhem.de/wiki/DevelopmentModuleAPI#Attribute_in_anderen_Definitionen_bereitstellen)
Das bringt mir leider nichts. Ich will ja kein Userattribut erzeugen, sondern ein ganz normales Attribut. Ich schreibe ja das Modul. Ich denke der Ansatz von igami geht in die Richtung die ich suche. Ich muss gucken ob ich das richtig verstehe und dann mal ausprobieren.
Aktuell habe ich es über set hinbekommen, auch wenn ich es als normales Attribut schöner gefunden hätte. Vielleicht geht das ja mit dem Ansatz von igami, das sieht jedenfalls danach aus.
So sieht der aktuelle Stand aus für ,,calendarFilter":
https://github.com/mumpitzstuff/fhem-GCALVIEW/blob/master/FHEM/57_GCALVIEW.pm (https://github.com/mumpitzstuff/fhem-GCALVIEW/blob/master/FHEM/57_GCALVIEW.pm)
Danke auf jeden Fall für die Antworten! Ich probiere es aus.
addToDevAttrList ist für modul autoren und macht genau das was du willst.
Hatte ich gestern spaßeshalber eigentlich ausprobiert. Das hatte mir immer nur ein Userattribut mit Inhalt erzeugt. Darin hätte ich mir dann natürlich das eigentlich gewollte Attribut erzeugen können, aber das wäre von hinten durch die Brust ins Auge. Aber ich schau auch da noch mal rein und vergewissere mich, dass ich nichts falsch gemacht habe. Danke.
Hab es jetzt ausprobiert. Beide Varianten gehen tatsächlich.
Variante 1 (direkt in die AttrList eintragen):
Der entscheidende Nachteil ist hier, dass das dann global für alle devices dieses Typs gilt, wenn ich das richtig interpretiert habe. Da ich aber jeweils andere Listen an der Stelle für jedes Device generieren möchte, fällt das im Prinzip aus.
Variante 2 (addToDevAttrList):
Erzeugt leider ein zusätzliches Attribut namens userattr. Ansonsten erzeugt es dann das gewünschte Verhalten.
Variante 3 (über ein set xyz gehen):
Hat den Nachteil das man hier keine Vorauswahl mitgeben kann bzw. der Anwender nicht sieht was bereits gesetzt wurde. Die Checkboxen sind immer disabled. Ansonsten klappt die Variante aber auch.
Ich werde wahrscheinlich auf Variante 2 wechseln, da mir diese alles in allem als die sauberste Lösung erscheint.
Vielen Dank!