Autor Thema: IODev Handling durch device  (Gelesen 7462 mal)

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 24494
Antw:IODev Handling durch device
« Antwort #75 am: 10 Juli 2021, 12:30:32 »
Zitat
Noch bei Setzen des Reading IODev vor Setzen des Internals zusätzlich zu prüfen, ob das Modul das Attribut unterstützt wäre nicht sehr aufwändig, analog zu CommandAttr($$).
Ich finde zwar die Begruendung sehr speziell, ich will aber weder unsere Zeit mit weiteren Diskussionen vergeuden, noch Euer Wunsch ignorieren, habe also den Vorschlag implementiert. Bin unsicher, ob es alle Sonderfaelle so abfaengt, wie Du dir das vorgestellt hast, bitte also um Feedback.

Offline noansi

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1310
Antw:IODev Handling durch device
« Antwort #76 am: 10 Juli 2021, 16:44:45 »
Hallo Rudolf,

danke für's drüber schauen und den Umsetzungsversuch.

In CommandSetstate wird mit
    if($b1 eq "IODev") {
      my $ret = fhem_setIoDev($hash, $b[2]);
      push @rets, $ret if($ret);
      next;
    }
über fhem_setIoDev
  $hash->{IODev} = $defs{$val};
  setReadingsVal($hash, 'IODev', $val, TimeNow()); # 120603
weiterhin das Internal IODev als Sonderbehandlung gesetzt.
Nur das Setzen des Readings wird nun unterbunden (so weit ich den Code verstehe), wenn das Attribut vom Modul nicht unterstützt wird.

Was ich meinte
Zitat
Das Reading IODev jedoch nicht und es wird mit CommandSetstate gesetzt, erfährt damit auch die Sonderbehandlung des Setzens des Internals IODev.
Hat der Modulprogrammierer aber anderes im Sinn, z.B. Setzen des Internals bereits beim define, dann wird es überschrieben.
sehe ich im Code daher noch nicht umgesetzt.
Das Setzen des Readings hat mich nicht gestört, sondern das Setzen des Internals.

D.h. ich vermute aus Deinem Zitat noch ein Missverständnis und ich hoffe, das klärt es nun.

Weiterhin interpretiere ich Deine Änderung derzeit dahingehend, dass Du das Reading IODev in jedem Fall gerne für fhem.pl reservieren möchtest.

Müsste nicht sein, ich meine primär nur Sonderbehandlungen, wenn das Attribut IODev vom Modul in der Attributsliste geführt wird. Andererseits würde eine klare Exklusiviität auch für das Reading natürlich auch künftige IODev Stolperfallen für Modulprogrammierer und unglückliche Userfehlinterpretation verhindern helfen.
Sprich, ein Modul, das die IO Zurodnungsverwaltung selbst übernehmen möchte, lasst die Finger sowohl vom Attribut, als auch vom Reading IODev.
Zitat
Readings gehoeren eigentlich nicht dem Benutzer, genauso wie Attribute nicht dem Modul.
Nicht dem Benutzer ist klar, aber noch nicht so recht, unter welchen Bedingungen des Reading IODev dem Modul oder dem Kernel "gehört".

Gruß, Ansgar.

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 24494
Antw:IODev Handling durch device
« Antwort #77 am: 11 Juli 2021, 13:11:38 »
Naechste Runde, bitte um Feedback.

Offline noansi

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1310
Antw:IODev Handling durch device
« Antwort #78 am: 11 Juli 2021, 14:33:42 »
Hallo Rudolf,

danke! :-)

Damit steht nun fest:
- das Reading IODev steht grundsätzlich unter der exklusiven Kontrolle von fhem.pl
- das Reading IODev wird nur gesetzt, wenn das Attribut IODev vom Modul unterstützt wird
- das Internal IODev wird nicht nach Reading IODev gesetzt, wenn das das Attribut IODev vom Modul nicht unterstützt wird
- sollte ein Modul dynamisch die Attribut IODev Unterstützung ab-/zuschalten wollen, dann gibt es dafür keine Kernel Unterstützung. Ein entsprechender Feature Request mit Diskussion der Funktionalität wäre dann erforderlich.

Der letzte Punkt entspringt den variablen HM-Device Eigenschaften.

Gruß, Ansgar.

 

decade-submarginal