AttrList während der Laufzeit verändern

[Markus Bloch]

Hallo zusammen,

ich würde gern fragen, ob es möglich ist die AttrList während der Laufzeit von FHEM zu verändern. Generell wird diese ja nur mit der Initialize-Funktion gesetzt.

Nun hab ich den Fall, dass ich bei PRESENCE den Fall habe, dass je nach Definition das ein oder andere Zusatz-Attribut verwendbar ist.

Ich würde es dabei gerne so halten, dass das Attribut nur dann angezeigt wird, wenn es auch wirklich benutzbar ist.

In $hash ist zur Laufzeit aber AttrList nicht enthalten. Jetzt ist die Frage ob diese Attributliste pro Definition oder nur pro Modul existiert.

Ist so etwas aktuell möglich?

Vielen Dank

Gruß
Markus

[rudolfkoenig]

Die AttributNamen sind nicht Instanz, sondern Modul-spezifisch. Diesen Wert kann man natuerlich jederzeit aendern durch setzen von $modules{$defs{$d}{TYPE}}{AttrList}

[Markus Bloch]

Hallo Rudi,

vielen Dank für die Information. Leider wollte ich es gerade so machen, dass die Instanz je nach Definition einen zusätzlichen parameter freigibt.

Da es aber nur generell für deinen Modul-Typ möglich ist, würde ich damit auch die Attribute von anderen Definitionen des selben Moduls ändern und das wollte ich nicht.

Trotzdem vielen Dank für die Info.

Gruß
Markus

[Tobias]

Hi,
ich stehe ebenfalls vor diesem Problem. Ich möchte aber die Attrlist aller Instanzen eines Moduls anpassen.
Warum ist aber dann $modules{$defs{$d}{TYPE}}{AttrList} Instanzabhängig? -> $d ist die ModulInstanz

Im Speziellen möchte ich eine Werteliste eines ModulAttributes verändern. Hat das schonmal jemand in einem Modul verbaut wo ich spicken kann?

[betateilchen]

Das was Du in einem Bewässerungsmodul alles per attribut machen möchtest, ist nicht wirklich zielführend.
Sowas würde ich immer über ein set machen, nicht über ein attr.

Grundsätzlich kannst Du ein attribut aber auch per devspec mit TYPE=<module> in allen definierten Einheiten Deines gewünschten Typs setzen.

[betateilchen]

Meiner Meinung nach "gehören" die Attribute dem Anwender. Nicht dem Modul und schon gar nicht dem Modulentwickler.
Nach dem define sollten diese nur noch vom Anwender verändert werden.

[Tobias]

Anwendungsfall ist analog dem attr iodev. Ein übergeordnetes Modul wird definiert und die untergeodneten Module können sich per attr daran hängen. Und da möchte ich gerne die attrliste automatisch Name jedem define des übergeordneten Moduls generieren lassen.
Wir reden also mittlerweile nicht mehr von einem bewasserungsmodul sondern  von einer zweier Gruppe.

Gesendet von meinem ALCATEL ONE TOUCH 997D mit Tapatalk

[betateilchen]

Das ändert nichts an meiner Meinung. Als Modulentwickler hat man durchaus andere Möglichkeiten, anstatt Attribute dafür zu verwenden, irgendwelche Parameter zu übergeben/vererben.

[Tobias]

Wasser meint Rudi dazu? Schliesslich hat er das Konstrukt mit iodev eingeführt welches gerade meine Grundlage hierfür darstellt...

Gesendet von meinem ALCATEL ONE TOUCH 997D mit Tapatalk

[betateilchen]

IOdev ist eine Altlast, da ging es vermutlich nicht anders. Bei Dir geht es aber um eine Neuentwicklung.

Ausserdem solltest Du dringend Deine Autovervollständigung am Handy abschalten, da kommt manchmal ganz schöner Mist raus 

[Tobias]

Ich bin immer noch so schlau wie vorher wie soll ich nun beide Module verbinden??

Gesendet von meinem ALCATEL ONE TOUCH 997D mit Tapatalk

[justme1968]

mal ein paar ungeordnete antworten und bedanken... also:

- $modules{$defs{$d}{TYPE}}{AttrList} -> $d ist zwar die instanz aber der TYPE aller deiner instanzen ist der gleiche. somit gibt es $modules{<TYPE>}{AttrList} genau ein mal. deshalb ist es modul weit und nicht instanz weit.

- die liste der set und get ist instanz spezifisch. die kannst du ohne probleme zur laufzeit ändern und hier kannst du genau die möglichen in frage kommenden werte dynamisch machen.

- rudi ist der meinung das attribute dem user gehören. das muss aber nicht in allen fällen richtig sein und manchmal gibt es noch keinen globalen mechanismus der besser ist als attribute.

- in (fast?) allen fällen bei dem zwei oder mehr module mit einander zu tun haben ist es bis jetzt so das das eine i/o aufgaben für die anderen übernimmt. das geht dann über IODev,readFn,writeFn und IOWrite. das könnte man missbrauchen.

- warum machst du es so kompliziert? es sind doch deine beiden module. du kannst auf beiden ebenen funktionen bereit stellen die sich jeweils aus der anderen einfach aufrufen lassen. die passenden module findest du z.b. in einer schleife über alle module in dem du TYPE prüfst. das machen die internen routinen alle auch nicht anders. wenn du dir sorgen um die performance machst kannst du jewels den parent und die liste der children cachen.

- deine frage ist glaube ich noch zu abstrakt um sinnvolle vorschläge zu machen.

gruss
  andre