Hallo zusammen,
ich habe beim Dashboard-Modul die Anforderung, dass die verfügbaren Attribute "dynamisch" gesetzt werden können. Das heisst beim XXX_Initialize habe ich die Information bezüglich der Attribut-Liste noch nicht. Ich habe das nun erstmal so gelöst, dass ich in der XXX_Define über folgenden Aufruf die Attribute "dynamisch" hinzufüge:
$modules{Dashboard}{AttrList} .= ".........";
Ich vermute mal, dass dies aber vom FHEM Framework her so nicht gedacht ist. Gibt es das Konzept, Attribute dynamisch zu erweitern vielleicht schon? Wenn ja, wie macht man das am besten. Wenn nein, wäre das etwas, was man noch mit aufnehmen könnte? Ich würde mir dann auch die Gedanken dazu machen, wie man das in eine schöne Funktion verpackt. Oder spricht das kategorisch etwas dagegen?
Danke!
Gruss
es gibt addToDevAttrList (und addToAttrList).
gruss
andre
Zitat von: justme1968 am 09 Juni 2015, 10:11:48
es gibt addToDevAttrList (und addToAttrList).
gruss
andre
Hatte ich probiert, funktioniert aber in der XXX_Define nicht => hat keine Auswirkungen.
also bei structure und LightScene und anderen hat es auswirkungen und funktioniert. ich glaube du musst genauer werden.
Zitat von: justme1968 am 09 Juni 2015, 10:25:58
also bei structure und LightScene und anderen hat es auswirkungen und funktioniert. ich glaube du musst genauer werden.
Ich werde es noch mal ausprobieren.
Danke!
addToAttrList fuegt ein Attribut jedem Geraet hinzu, indem es "attr global userattr" erweitert.
addToDevAttrList ist das Gleiche fuer nur ein Geraet.
Damit das userattr aus dem Statefile nicht das aus DefineFn ueberschreibt, muss man dieses Attibut in dem NotifyFn("global:INITIALIZED") setzen, bzw in DefineFn, falls $init_done wahr ist. Oder man faengt das Setzen dieser Variable in AttrFn ab. Oder man macht nichts, und akzeptiert, dass das Statefile das letzte Wort hat.
Hallo Rudi,
danke für die Hinweise, ich werde mich noch mal durch die Logik wühlen.
Gruss
Hallo zusammen,
ich habe es nun nochmal (wie von justme1968 suggeriert) mit
addToDevAttrList
in DefineFn probiert und es scheint tatsächlich zu funktionieren.
Danke nochmal!
Gruss
Hallo zusammen,
ich persönlich finde diese Variante nicht so toll, da die userattr ja wie der Name schon sagt "User-eigene Attribute" sind und man als Modulentwickler keine Kontrolle hat, wenn der User das Attribut weglöscht usw. und sich dann wundert, warum das Attribut nicht mehr in seiner Liste auftaucht. Wäre es nicht besser, wenn man sowas an einer speziellen Stelle in $hash ablegen kann und fhem.pl/FHEMWEB dann beim Zusammenbau der Attributsliste auch an diese spezielle schaut, ob dort was ist und dann die zusammengesetzte Liste letztendlich anzeigt?
Gruß
Markus
Der Benutzer hat in FHEM z.Zt. sehr viele Moeglichkeiten, was kaputtzumachen.
Ich sehe z.Zt. noch keinen Grund, ihn daran zu hindern.
bevor addToDevAttrList eingebaut wurde gab es eine solche diskussion schon mal. dabei sind eine ganze reihe schöner dinge aufgetaucht die bezüglich attribute eigentlich auch nett wären.
addToDevAttrList war dann aber die variante bei der das aufwand/nutzen verhältnis klein genug war das sich jemand (rudi) hin gesetzt und es eingebaut hat. die anderen probleme und vorteile sind scheinbar nicht so gross das sich jemand genötigt sah einen patch dafür zu bauen oder sogar alte module anzupassen.
gruss
andre
Einen Patch würde ich bauen, das wär kein Thema. Auch wenn ich weis, das Rudi mein Programmierstil nicht gefällt und er es dann doch auf seine Weiße implementiert ;-)
Deswegen frage ich vorher einfach mal nach. Wenn Rudi gegen so eine Änderung nichts hat, würde ich einen Patch erstellen.
@Rudi: ist nicht böse gemeint, jeder hat eben andere Vorstellungen.
Hallo zusammen,
ich persönlich bin auch dafür, dass die dynamischen Attribute nicht so anfällig für "Benutzerfehler" sind. Finde daher den Vorschlag von Markus zumindest eine Überlegung wert.
Gruss
Das Thema ist zwar schon alt, aber bei mir auch gerade interessant.
Ich habe mir auch gewünscht das Verändern der Attribute ginge so dynamisch wie bei den set und get.
Finde die Lösung mit addToDevAttrList so la la eben wegen der versehentlichen Änderung vom Benutzer.
Auch fehlt mir als Gegenstück zu addToDevAttrList ein removeFromDevAttrList.
Gruß
Dan