FHEM - Entwicklung > FHEM Development

IODev Handling durch device

(1/14) > >>

noansi:
Hallo Rudolf,

ich hoffe, Du schaust hier mal rein.

Das Attribut IODev erfährt in fhem.pl in CommandAttr($$) (ab derzeit Zeile 3099) eine Sondernachbehandlung, um die Initialisierungsphase mit ungünsiger Definitionsreihenfolge "zu überstehen", so meine Codeinterpretation.

Wenn man das aber sebst handlen möchte/muss, dann stört diese Sonderbehandlung.
Ausweg ist derzeit nur, in der Attribut Funktion eine falsche Fehlermeldung zurück zu liefern, so dass Zeile 3096 mit next dafür sorgt, dass die Sonderbehandlung nicht durchgeführt wird.

--- Code: ---    $ret = CallFn($sdev, "AttrFn", "set", $sdev, $attrName, $attrVal);
    delete($defs{$sdev}->{CL});
    if($ret) {
      push @rets, $ret;
      next;
    }

--- Ende Code ---
Leider wird dabei die falsche Fehlermeldung auch an den Aufrufer zurück geliefert, was unerwünscht ist. Sowohl beim FHEM Start, als auch beim händischen Setzen den Attributs.

Kannst Du damit leben, einen bestimmten Rückgabestring in der Zeile davor nicht auf das @rets array zu pushen und damit zu unterdrücken? Z.B. "IODev handled" oder "attr handled". Also so z.B.:

--- Code: ---    $ret = CallFn($sdev, "AttrFn", "set", $sdev, $attrName, $attrVal);
    delete($defs{$sdev}->{CL});
    if($ret) {
      push @rets, $ret if ($ret ne "attr handled");
      next;
    }

--- Ende Code ---
Damit wird die falsche Fehlermeldung wird unterdrückt und das Handlen des attr Kommandos muss durch das jeweilige Modul erfolgen.

Natürlich gerne auch eine andere Alternative.

Grund ist ein Änderungsvorschlag für 10_CUL_HM.pm mit Bezug auf IODev und den Konflikten mit automatischer Zuweisung des IODev:

--- Code: ---  elsif($attrName eq "IODev") {
    if ($cmd eq "set"){
      if ($attrVal) {
        if ($init_done) {
          return 'CUL_HM '.$name.': unknown IODev '.$attrVal.' specified'
              if (!defined($defs{$attrVal})); # noansi: resonable for a defined IO device only, real error to be reported
          $hash->{helper}{io}{restoredIO} = $attrVal; # noansi: first choice on next CUL_HM_assignIO
          CUL_HM_assignIO($hash);                     # noansi: try an assign
          delete($hash->{IODev}{'.clientArray'}) if (defined($hash->{IODev})); # Force a recompute
        }
        else {
          if (!$hash->{helper}{io}{restoredIO}) {                # noansi: do not overwrite restored data from IO, e.g. TSCUL
            $hash->{helper}{io}{restoredIO} = $attrVal;          # noansi: first choice on next CUL_HM_assignIO with vccu set till $init_done==1
            if (defined($defs{$attrVal})) {                        # noansi: resonable for a defined IO device only
              $attr{$name}{IODev}                     = $attrVal;  # noansi: first choice on next CUL_HM_assignIO with vccu not set
              @{$hash->{helper}{mRssi}{io}{$attrVal}} = (100,100); # noansi: set IO high rssi for first autoassign
              CUL_HM_assignIO($hash);                              # noansi: try an assign
              delete($hash->{IODev}{'.clientArray'}) if (defined($hash->{IODev})); # Force a recompute
            }
          }
        }
        if (defined($hash->{IODev}) && $hash->{IODev}{NAME} ne $attrVal) {
          DoTrigger('global', 'ATTR '.$name.' IODev '.$hash->{IODev}{NAME}, 1) if ($init_done);
          return 'attr handled'; # noansi: we return something to avoid fhem.pl to set $hash->{IODev} by it's own
                                 #         fhem.pl needs an adaption, not log/report it as "error"
                                 #         discussion started here https://forum.fhem.de/index.php/topic,120603.msg1151486.html#msg1151486
        }
      }
      else {
        return 'CUL_HM '.$name.': no IODev specified' if ($init_done); # noansi: real error to be reported
      }
    }
  }

--- Ende Code ---
Dabei stört die Nachbehandlung inklusive Setzen des Attributwertes durch CommandAttr($$).
Denn
- im CUL_HM Änderungsvorschlag wird während der FHEM Initialisierung ggf. ein notwendigerweise anderes IO bevorzugt (ein vor einem Neustart für das HM device zuständige), als der übergebene $attrval. Dann soll das IODev im device auch nicht auf den unerwünschten Wert gesetzt werden, was aber am Ende des FHEM Starts in finish_init() passiert, denn es stört im Nachgang bei der CUL_HM Nachinitialisierung.
- die für CUL_HM korrekt funktionale IO Zuweisung funktioniert nur mit CUL_HM_assignIO, weil auch dem IO das HM device als eines seiner bekannten devices mitgeteilt werden muss. Nur Setzen des Attributwertes und IODev setzen reicht nicht (betrifft auch HMLAN, HMUARTLGW). Diese Zuweisung macht CUL_HM entweder bei HM device Definition direkt nach dem FHEM Start.
- bei der vorgeschlagen Unterdrückung mittels Rückgabewert wird ein "Fehler" gelogged, der nur im Log verwirrt.
- im anderen Fall nach dem FHEM Start durch Userwunsch wird im Vorschlag bereits das IO durch CUL_HM_assignIO zugewiesen, damit auch das IO entsprechend initialisiert wird und nicht erst bei der ersten Sendenachricht an das device, wie es bisher der Fall war. Das bisherige Setzen des Attributs war (ist noch) noch nicht voll funktional.
- bei der vorgeschlagenen Unterdrückung mittels Rückgabewert wird derzeit eine störende Meldung angezeigt.


Sollte es weitere Anwendungsfälle geben, dann wäre es eventuell noch nötig, sich Gedanken um die Nachbehandlung am Ende zu machen

--- Code: ---    addStructChange("attr", $sdev, "$sdev $attrName $attrVal")
        if(!$opt{silent} && (!defined($oVal) || $oVal ne $attrVal));
    DoTrigger("global", "ATTR $sdev $attrName $attrVal", 1) if($init_done);

--- Ende Code ---
die mit dem Mini Patch von oben mangels $opt{silent} Information nicht vollständig im Modul umgesetzt werden kann.

Gruß und Danke,

Ansgar.

rudolfkoenig:

--- Zitat --- im CUL_HM Änderungsvorschlag wird während der FHEM Initialisierung ggf. ein notwendigerweise anderes IO bevorzugt, als der übergebene $attrval
--- Ende Zitat ---
Anders formuliert: der Benutzer setzt ein Attribut, dem Modul passt der gesetzte Wert nicht, will was Anderes setzen, und der Benutzer soll diese Manipulation nicht mitkriegen. Wenn ich dabei nichts Wesentliches uebersehen habe(*), dann finde ich das nicht ok, und bin auch nicht bereit, es mit dem Framework zu unterstuetzen.

Ausserhalb des Frameworks kann man das auch jetzt schon machen, indem man nach der Initialisierung den Attributswert ueberbuegelt.

*: Da ich keine Klartext-Begruendung fuer die Notwendigkeit gefunden habe, versuche ich das aus dem 10_CUL_HM.pm Patch abzuleiten, gelingt mir aber nicht. Wenn CUL_HM besser weiss, welches IODev zu einem Geraet gehoert, als der Benutzer, wieso laesst es das Attribut ueberhaupt zu?

noansi:
Hallo Rudolf,


--- Zitat ---Anders formuliert: der Benutzer setzt ein Attribut, dem Modul passt der gesetzte Wert nicht, will was Anderes setzen, und der Benutzer soll diese Manipulation nicht mitkriegen. Wenn ich dabei nichts Wesentliches uebersehen habe(*), dann finde ich das nicht ok, und bin auch nicht bereit, es mit dem Framework zu unterstuetzen.
--- Ende Zitat ---
Nun,
- der andere Wert wird für den Nutzer schon sichtbar im Attributwert. Natürlich wäre es auch kein Problem an der Stelle noch einen Log Hinweis zu ergänzen.
- mit entsprechendem verbose level gibt es auch Log Einträge, wenn IODev genutzt wird, siehe CUL_HM_assignIO Code
- nur, wenn die Möglichkeiten des automatischen IO Wechsels von CUL_HM mit VCCU genutzt werden, kommt es überhaupt zum Tragen. Und dann ist es gut, wenn nach einem FHEM Restart das zuletzt genutze IO auch wieder verwendet wird, statt des IODev Attributs. Sowohl funktional, als auch für tsculfw CULs mit wenig Speicher schonend für deren EEPROM. Wird vor einem FHEM Neustart "Save config" genutzt, dann wird auch das zuletzt zugewiesene IO im IODev Attribut in der config gespeichert.
- sofern andere IO-Typen für HM ein Rücklesen zugewiesener devices unterstützen, könnten sie den funktionalen Vorteil ebenfalls nutzen
- wenn zusätzlich noch das Attribut IOgrp mit Vorzugs-IO genutzt wird, dann ist das IODev Attribut nicht mehr "Master", sondern das gesetzte Vorzugs-IO (sofern nicht auf Fehlerstatus). Das ist schon lange so. Wenn IODev dazu nicht passend gesetzt ist, führt das derzeit eher zu Problemen.
- "unterstützen" tut es das Framework ja schon großenteils, wenn auch nicht beabsichtigt, störend ist aus bisheriger Sicht nur die u.U. verwirrende Meldung und Log Einträge


--- Zitat ---wieso laesst es das Attribut ueberhaupt zu?
--- Ende Zitat ---
Es gibt virtuelle devices, die es benötigen. Die anderen Wege greifen da nicht.
Wird keine VCCU benutzt, dann bestimmt IODev das genutzte IO. Notnagel, wenn auch das nicht verfügbar ist, ist AssignIoPort, siehe CUL_HM_assignIO Code.

Hier der Anlass, das IODev Attribut Thema überhaupt anzupacken -> https://forum.fhem.de/index.php/topic,119853.msg1144425.html#msg1144425


--- Zitat ---Ausserhalb des Frameworks kann man das auch jetzt schon machen, indem man nach der Initialisierung den Attributswert ueberbuegelt.

--- Ende Zitat ---
Dann müsste das Framework das mit Kapselung verhindern, sonst verstehe ich den Einwand oben nicht so ganz in Konsequenz (nicht das ich das damit herauf beschwören wollte  ;) ).

Gruß, Ansgar.

rudolfkoenig:
Soweit ich sehe, wird hier verzweifelt versucht ein Attribut fuer etwas zu missbrauchen, was eigentlich Reading sein sollte.

Attribut ist das, was der Benutzer setzt. Reading ist das, was das Modul setzt, wenn es gepsiechert werden soll. Mir ist bewusst, dass das zunehmend vermischt wird, und das ich auch nicht immer konsequent bin, das ist aber keine Begruendung es weiter zu treiben, eher im Gegenteil.

Ich verstehe schon, dass ein Umbau auf Reading mehr Arbeit bedeutet, ich faende es aber toll, wenn nicht bei jedem Problem sofort eine Ausnahme vom beabsichtigten Architektur gemacht wird.

Wie sehen das die anderen Mitschreiter?

Beta-User:
Hallo zusammen,

bin zwar alles andere als ein SW-Architekt, aber ganz allgemein finde ich die Vermischung von Attribut ("gehört dem User") und "allem anderen" nicht glücklich.

Bei CUL_HM ist das Phänomen ziemlich verbreitet, eventuelle Uservorgaben auch schon mal zu "überstimmen" z.B. auch, was "model" angeht. Das "Problem" scheint mir zu sein, dass es eigentlich eine "Klasse" zwischen Readings (fhem.save) und Attributen bräuchte, die dann auch dem Userzugriff entzogen sein sollte und (klassisch) in der fhem.cfg zu verorten wäre. Das Problem ist, dass die Info vorhanden sein "muss", was schiefgeht, wenn es (noch) keine Readings gibt (ok, da kann man dann defaults setzen, die aber falsch/kontraproduktiv sein könnten) oder die fhem.save kaputt, verloren, whatever...

Jedenfalls gibt es zu dem IO-Thema auch eine Diskussion mit martinp876, in der er auch erläutert hat, was er "dann noch" im Nachgang so macht. Ist evtl. hier auch interessant: https://forum.fhem.de/index.php/topic,112302.msg1067739.html#msg1067739.

Navigation

[0] Themen-Index

[#] Nächste Seite

Zur normalen Ansicht wechseln