Structure: Wishlist: Zusätzliche Attribute in ignore hash mit aufnehmen

[rudolfkoenig]

Warum ist es denn dann eingebaut?

Weiss nicht genau, ich meine es stammt aus der Zeit, wo devspec mit Attributen noch nicht umgehen konnte und ich fand so viele Attribute auf einmal zu setzen faszinierend, ohne ueber Sinn nachzudenken.

nur möchte ich eben einstellen können welche weitergegeben werden

Das kann man doch mit structexclude, oder irre ich mich?

[igami]

Das kann man doch mit structexclude, oder irre ich mich?

Meiner Meinung nach aber nicht praktikabel. Am Beispiel von alexa: ich habe eine structure für alle Lampen und wollte dieser den alexaName "alle" geben und schwupps hießen alle meine Lampen für alexa so, weil ich nicht vorher structexclude um "alexaName" erweitert habe.  Es ist also nicht möglich einfach Attribute an die structure zu geben ohne, dass diese weitergegeben werden.

Man könnte es auch noch anders lösen und ein Attribut structInclude schaffen, wenn dies vergeben ist werden nur die da aufgeführten Attribute weitergegeben.

[justme1968]

Code Auswählen Erweitern

Meiner Meinung nach aber nicht praktikabel.warum nicht?

du kannst ein mal beim anlegen der structure in der structure selber das structexclude auf .* setzen. da das attribut noch nicht gesetzt ist wird es ein mal an alle beteiligten decices weiter gegeben und damit hast du das weitergeben aller attribute in der zukunft verhindert.

problematischer ist eher das das attribut für set und attribute gleichzeitig wirkt und das eine whitelist vermutlich praktikabler ist als eine blacklist.

structInclude finde ich eigentlich gut, aber dann gehört aber noch eine regelung dazu ob include oder exclude vorang hat. vom konfigurierbar machen fange ich garnicht erst an

[KernSani]

Ich fasse zusammen: Es gibt viele Varianten ob und wie der Vererbung genutzt wird, aber gibt es ein Szenario in dem es Sinn macht alexa.* bzw. siriName zu vererben?

[igami]

Code Auswählen Erweitern

Meiner Meinung nach aber nicht praktikabel.warum nicht?

du kannst ein mal beim anlegen der structure in der structure selber das structexclude auf .* setzen. da das attribut noch nicht gesetzt ist wird es ein mal an alle beteiligten decices weiter gegeben und damit hast du das weitergeben aller attribute in der zukunft verhindert.

eben nicht

Code Auswählen Erweitern


define d1 dummy

define d_s structure d d1
attr d_s userattr structexclude
attr d_s structexclude .*

define d2 dummy

addstruct d_s d2

attr d_s sortby structexclude?

welche Attribute hat nun d2?

[justme1968]

du musst bei structexclude noch den structure namen mit angeben.

und wenn du ein element hinzufügst auch structexclude neu setzen.

dann sollte alles passen:

Code Auswählen Erweitern

define d1 dummy

define d_s structure d d1
attr d_s userattr structexclude
attr d_s structexclude d:.*

define d2 dummy

addstruct d_s d2
attr d_s structexclude d:.*


attr d_s sortby xyz

[igami]

du musst bei structexclude noch den structure namen mit angeben.

und wenn du ein element hinzufügst auch structexclude neu setzen.

deswegen meinte ich ja nicht praktikabel und nicht unmöglich

[Schlimbo]

Hallo zusammen,
Ich bin auch gerade bei meiner structure für "Alle Rollos" auf das Problem gestoßen, dass die structure alle Alexa Attribute der unterlagerten Geräte überschrieben hat.

Das Vererben der Attribute führt aus meiner Sicht zu mehr Verwirrung & Problemen als Nutzen.
Ich bin der Meinung das ein Modul nicht einfach ungefragt Attribute andere Geräte überschrieben sollte und plädiere auf "deaktiviert by default".

Würde mich freuen wenn des Thema noch mal aufgegriffen werden könnte.

Beste Grüße
Schlimbo

[rudolfkoenig]

Stoert mich auch seit laengerem, ich bin nur nicht ganz sicher, wie man das elegant Rueckwaertskompatibel loest.
Mein Favorit z.Zt.: structure Attribut inheritAttributes dessen default erst true, und ab Featurelevel 6 false ist.
Andere Vorschlaege?

Edit. Sehe gerade, dass ich diese Idee schon vor zwei Jahren hatte...

[justme1968]

die frage ist: muss es rückwärts kompatibel sein? wenn sich das verhalten ändert hat es ja keine auswirkung auf eine bestehende konfiguration. die bleibt ja wie sie ist.

ich könnte mir vorstellen das man das alte verhalten komplett deaktiviert und statt dessen im attr (und set/get ?) kommando eine option vorsieht mit der man festlegt ob das setzen auf die strcuture, auf die beteiligten devices oder beides wirken soll. dann kann man von fall zu fall entscheiden und ist nicht an ein inheritAttributes attribut gebunden das zumindest bei einem einfachen true/false auf alle attribute auswirkung hätte.

also etwas wie attr -propagate <name> <value>.

[rudolfkoenig]

muss es rückwärts kompatibel sein?

Vermutlich nicht, ich kann fuer attr nichts sinnvolles vorstellen.
set muss vererben (sonst waere set in structure sinnlos), und ein get gibt es nicht.
Dein Vorschlag ist nur was fuer telnet oder die Befehlseigabe ist, aber vermutlich reicht das fuer die "sinnlosen" Faelle.

[Schlimbo]

Sehe auch keine Notwendigkeit der Rückwärtskompatibilität, es ist ja keine Änderung die das Verhalten im Live-Betrieb beeinflusst, sondern nur bei der Konfiguration.
Fände hier ein Attribut sinnvoll, über das man Leerzeichen getrennt, die zu vererbenten Attribute angeben kann.

[rudolfkoenig]

Fuer "attr -propagate" (oder attr name -propagate) muesste ich fhem.pl anpassen, und z.Bsp. alles was mit - anfaengt per $hash weitergeben, wovon ich noch zurueckschrecke.
Auch ein "attr structName attrName attrVal -propagate" funktioniert nicht ohne eine Aenderung von fhem.pl (abgesehen von der komischen Syntax).

Ich habe deswegen propagateAttr eingebaut:
- Wert ist ein Regexp
- die Voreinstellung fuer featurelevel <= 5.9 ist .* (d.h. so wie bisher), danach ^$

Ganz gluecklich bin ich damit noch nicht, weil es weiterhin eine lange Liste von hartkodierten Ausnahmen gibt:
alias async_delay clientstate_behavior clientstate_priority devStateIcon disable disabledForIntervals group icon room setStateIndirectly stateFormat webCmd userattr

[Schlimbo]

Danke für die Anpassung.
Sind die hartkodierten Ausnahmen mit dem neuen Attribut überhaupt noch nötig?
Jetzt kann sich doch jeder individuell seine vererbungen zusammenstellen.

[rudolfkoenig]

Diese Attribute moechte man (mAn) normalerweise nicht weitergeben, und ich weiss noch nicht, wie man diese elegant per Voreinstellung fuer featurelevel > 5.9 einbindet.