FHEM Forum

Hallo Rudi,

könnte der ignore hash in structure_Attr um die Attribute:
* alexaName
* alexaRoom
* siriName

erweitert werden?

Danke,

Grüße,

Oli

hilft structexclude nicht?

gruss
  andre

Zitat von: justme1968 am 19 April 2017, 00:08:52
hilft structexclude nicht?

Das muss man halt bei jedem Device erst einrichten, auch wenn später noch neue hinzukommen.

Ich würde mir wünschen, dass man das ganze mit einem Attribut, am besten sogar global und lokal ausstellen kann

Zitat von: justme1968 am 19 April 2017, 00:08:52
hilft structexclude nicht?

gruss
  andre

Theoretisch schon, in der Praxis denke ich aber sind die Attribute quasi ein alias und könnten ebenso behandelt werden.

Zitat von: igami am 19 April 2017, 05:59:37
Ich würde mir wünschen, dass man das ganze mit einem Attribut, am besten sogar global und lokal ausstellen kann

So vielleicht:

Index: FHEM/98_structure.pm
===================================================================
--- FHEM/98_structure.pm (Revision 13980)
+++ FHEM/98_structure.pm (Arbeitskopie)
@@ -2,8 +2,8 @@
##############################################################################
#
#     98_structure.pm
-#     Copyright by
-#     e-mail:
+#     Copyright by
+#     e-mail:
#
#     This file is part of fhem.
#
@@ -52,6 +52,8 @@
   my %dhash = ( Fn=>"CommandDelStruct",
                 Hlp=>"<structure> <devspec>,delete <devspec> from <structure>");
   $cmds{delstruct} = \%dhash;
+
+  addToAttrList("structexcludeAttr");
}

sub structAdd($$);
@@ -124,7 +126,7 @@
#############################

sub
-structure_getChangedDevice($)
+structure_getChangedDevice($)
{
   my ($dev) = @_;
   my $lastDevice = ReadingsVal($dev, "LastDevice", undef);
@@ -177,7 +179,7 @@
   # Struktur ist
   return "" if (! exists $hash->{CONTENT}->{$dev->{NAME}});

-  # lade das Verhalten, Standard ist absolute
+  # lade das Verhalten, Standard ist absolute
   my $behavior = AttrVal($me, "clientstate_behavior", "absolute");
   my %clientstate;

@@ -185,7 +187,7 @@
         if($attr{$me}{clientstate_priority});

   return "" if($hash->{INSET}); # Do not trigger for our own set
-  return "" if(@{$hash->{".asyncQueue"}}); # Do not trigger during async set
+  return "" if(@{$hash->{".asyncQueue"}}); # Do not trigger during async set

   if($hash->{INNTFY}) {
     Log3 $me, 1, "ERROR: endless loop detected in structure_Notify $me";
@@ -194,7 +196,7 @@
   $hash->{INNTFY} = 1;

   my %priority;
-  my (@priority, @foo);
+  my (@priority, @foo);
   for (my $i=0; $i<@structPrio; $i++) {
       @foo = split(/\|/, $structPrio[$i]);
       for (my $j=0; $j<@foo;$j++) {
@@ -202,7 +204,7 @@
         $priority[$i+1]=$foo[0];
       }
   }
- 
+
   my $minprio = 99999;
   my $devstate;

@@ -438,7 +440,7 @@
}

sub
-structure_asyncQueue(@)
+structure_asyncQueue(@)
{
   my ($hash) = @_;

@@ -456,6 +458,13 @@
structure_Attr($@)
{
   my ($type, @list) = @_;
+  my $me = $list[0];
+
+  return undef
+    if(AttrVal(
+         $me, "structexcludeAttr", AttrVal("global", "structexcludeAttr", 0)
+    ));
+
   my %ignore = (
     alias=>1,
     async_delay=>1,
@@ -474,7 +483,6 @@

   return undef if($ignore{$list[1]});

-  my $me = $list[0];
   my $hash = $defs{$me};

   if($hash->{INATTR}) {
@@ -586,7 +594,7 @@
         timercalls is given by the value of async_delay (in seconds) and may be
         0 for fastest possible execution.  This way, excessive delays often
         known from large structures, can be broken down in smaller junks.
-        </li>
+        </li>

     <li><a href="#disable">disable</a></li>
     <li><a href="#disabledForIntervals">disabledForIntervals</a></li>
@@ -674,6 +682,13 @@
         </ul>
         </li>

+    <a name="structexcludeAttr"></a>
+    <li>structexclude<br>
+        if this attribute is defined, all devices excluded from attribute
+        operations. It's possible to set the attribute in the global device as
+        default.
+        </li>
+
     <li><a href="#readingFnAttributes">readingFnAttributes</a></li>

   </ul>
@@ -718,7 +733,7 @@
       <li>define house structure building kitchen living</li>
       <li>set house off</li>
     </ul>
-    <br>
+    <br>
   </ul>

   <br>
@@ -758,7 +773,7 @@
       gegeben, ein Wert von 0 entspricht der schnellstm&ouml;glichen Abfolge.
       So k&ouml;nnen besonders lange Verz&ouml;gerungen, die gerade bei
       gro&szlig;en structures vorkommen k&ouml;nnen, in unproblematischere
-      H&auml;ppchen zerlegt werden.
+      H&auml;ppchen zerlegt werden.

       </li>

@@ -816,7 +831,7 @@
       <code>haus</code> den Status <code>An</code> hat nimmt die Struktur den
       Status <code>Any_On</code> an. Um dagegen den Status <code>All_off</code>
       anzunehmen, m&uuml;ssen alle Devices dieser Struktur auf <code>off</code>
-      stehen.
+      stehen.
       </li>

     <li>&lt;struct_type&gt;_map<br>
@@ -865,6 +880,13 @@
           </code>
         </ul>
     </li>
+
+    <a name="structexcludeAttr"></a>
+    <li>structexclude<br>
+        Bei gesetztem Attribut werden alle attr/deleteattr ignoriert. Das
+        Attribut kann auch im global Device als Vorgabe gesetzt werden.
+        </li>
+
     <li><a href="#readingFnAttributes">readingFnAttributes</a></li>
   </ul>
   <br>


Bei neuen globalen Attributen reagiere ich allergisch :)
Ich tendiere dazu, dass ein structure Attribute nicht mehr weitergibt (bis auf das "eigene").
Meinungen?

Zitat von: rudolfkoenig am 19 April 2017, 08:26:48
Bei neuen globalen Attributen reagiere ich allergisch :)
Ich tendiere dazu, dass ein structure Attribute nicht mehr weitergibt (bis auf das "eigene").
Meinungen?

Das habe ich erwartet :)

Gibt es denn Benutzer die das nutzen, dass structure Attribute weitergibt? Wenn man es einfach ausbaut wäre es eben nicht mehr abwärtskompatibel. Alternativ könnte man es auch einfach per default ausstellen und über ein Attribut wieder aktivieren.

meine Meinung:
ich pflege i.d.R. ein structexclude .*:.* (aber manchmal vergesse ich das und dann schimpfe ich mit Alexa, die mich nicht versteht, weil die Esstischlampe mal wieder "Alle Lichter Erdgeschoss" heißt)

ZitatAlternativ könnte man es auch einfach per default ausstellen und über ein Attribut wieder aktivieren.

Akzeptiert.

Zitatmeine Meinung: ...

War das ein "ja, weg mit der automatischen Attributweitergabe" ?

Zitat von: rudolfkoenig am 19 April 2017, 09:42:17
War das ein "ja, weg mit der automatischen Attributweitergabe" ?

Eher ein "Ich persönlich brauche es nicht"

Ich wäre für ein NEIN, nicht weg mit der Attributsvererbung. Auch wenn ich damit mal ganz schön Probleme hatte. Aber mittlerweile finde ich es hilfreich.

Zitat von: CoolTux am 19 April 2017, 10:07:42
Ich wäre für ein NEIN, nicht weg mit der Attributsvererbung. Auch wenn ich damit mal ganz schön Probleme hatte. Aber mittlerweile finde ich es hilfreich.

Und ein Attribut um das Verhalten zu steuern wäre okay?

das ein setzen von structexclude aktuell automatisch durchgereicht wird finde ich schon nützlich.

das durchreichen generell abzuschaffen führt glaube ich zu problemen.

den default zu ändern und es per attribut konfigurierbar zu machen ist vermutlich besser. aber auch mehr code. ich weiß nicht ob es das wert ist.

Meine letzte Absicht war per Voreinstellung die Weiterreichung aller Attribute an den "Mitgliedern" zu unterbinden, mit einem Attribut (propagateAttr) koennte man das bisherige Verhalten aktivieren.
Scheint aber nicht auf so viel Begeisterung zu stossen wie ich dachte, mache also erstmal nichts.

Ist noch jemand ausser  KernSani fuer die Aufnahme der unteren drei Werte in die ignore Liste?

Die enthaelt z.Zt. "alias async_delay clientstate_behavior clientstate_priority devStateIcon disable disabledForIntervals group icon room stateFormat webCmd userattr". Welche Attribute man ueber structure setzen will, ist mir ein Raetsel.

Zitat von: rudolfkoenig am 19 April 2017, 14:29:00
Meine letzte Absicht war per Voreinstellung die Weiterreichung aller Attribute an den "Mitgliedern" zu unterbinden, mit einem Attribut (propagateAttr) koennte man das bisherige Verhalten aktivieren.
Scheint aber nicht auf so viel Begeisterung zu stossen wie ich dachte, mache also erstmal nichts.

deswegen ja der Vorschlag es abschaltbar zu machen, dann ändert sich ja nichts, nur, dass es möglich ist es abzuschaltet.

Zitat von: rudolfkoenig am 19 April 2017, 14:29:00
Welche Attribute man ueber structure setzen will, ist mir ein Raetsel.

Warum ist es denn dann eingebaut?

Prinzipiell finde ich die möglichkeit Attribute weiter zu geben gut, siehe archetype, nur möchte ich eben einstellen können welche weitergegeben werden, gerade da es sich ja bei structure um eine Zusammenfassung von mehreren Geräten handelt die ja auch steuern kann.

ZitatWarum 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.

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

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

Zitat von: rudolfkoenig am 19 April 2017, 17:19:29
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.

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 :)

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?

Zitat von: justme1968 am 19 April 2017, 18:32:19

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

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?

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: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

Zitat von: justme1968 am 19 April 2017, 20:16:41
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 ;)

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

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...

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>.

Zitatmuss 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.

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.

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

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.

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

'elegant' ist meiner meinung nach wenn der anwender es sehen kann. das ginge wenn fhem das attribut ein mal vor ausfüllt. das in jedem device zu machen ist aber blöd. ein globales attribut als default das dann pro device überschrieben werden kann wäre gut.

die frage ist ob der aufwand lohnt.

ja ich weiss attribute gehören dem anwender. das genau ein mal vor ausfüllen hilft dem anwender aber. er sieht was passiert.

ein globales attribut ist aber eigentlich unschön. es gibt schon zu viele. ideal wären modul spezifische attribute. d.h. für alle tnstanzen eines TYPE. die diskussion hatten wir aber schon mal :)

und wir haben ganz prinzipiell das problem das es keine leeren attribute gibt. die diskussion zwischen leer und nicht gesetzt hatten wir auch schon mal :)

Zitat von: rudolfkoenig am 09 Juli 2019, 23:04:25
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

Hallo Rudolf,

Könntest du evtl. noch mal über die "hartkodierten Ausnahmen" nachdenken?
Hatte gerade die Situation, dass ich genau diese Attribute vererben wollt:
attr Alle_Rollos propagateAttr ^(genericDeviceType|homebridgeMapping|devStateIcon|stateFormat|webCmd)$
Hatte mich anfangs gewundert warum es nicht funktioniert, bis ich diesen alten Beitrag wieder gefunden habe.

Falls eine Änderung mit einem zu großen Aufwand verbunden ist, wäre zumindest ein Hinweiß über die Ausnahmen in der Commandref hilfreich.

Beste Grüße
Schlimbo

Ich habe die hartkodierte Ignore-Liste fuer featurelevel > 5.9 entfernt.