[fhem.pl/AssignIoPort] Fehlende Events beim Reading IODev

Begonnen von frank, 25 Oktober 2021, 10:36:29

Vorheriges Thema - Nächstes Thema

frank

moin,

ich vermisse events beim reading IODev.
mir ist auch unklar wer in der modulkette ggf der verantwortliche für die eventgenerirung ist.

ist es mein unvermögen, ein feature oder ein bug?
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

rudolfkoenig

Zitatich vermisse events beim reading IODev.
Wenn du damit die automatische Zuwesung meinst per AssignIoPort, das ist ein Feature.

frank

ZitatWenn du damit die automatische Zuwesung meinst per AssignIoPort, das ist ein Feature.
danke für den hinweis, schlecht für mein vorhaben.

wie könnte ich denn das feature am einfachsten ändern?
bei der automatischen zuweisung durch cul_hm gibt es eventuell noch ein problem. bisher habe ich es erst einmal zufällig festgestellt, konnte aber nicht nachvollziehen, wann und wodurch es entstanden ist.
daher wollte ich nun von "aussen" über ein notify einen check starten, der bei io wechsel prüft, ob die präparation der io noch passt.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

rudolfkoenig

CUL_HM ist in diesem Zusammenhang besonders, ich weiss nicht ob es ueberall AssignIoPort verwendet, da sie nicht fuer vom Modul dynamisch ausgesuchte IO-Schnittstellen eignet. AssignIoPort respektiert ein vom Benutzer gesetztes Attribut, und der Maintainer hatte mit diesem Konzept seine Probleme.

Beta-User

Zitat von: rudolfkoenig am 25 Oktober 2021, 13:11:23
CUL_HM ist in diesem Zusammenhang besonders, ich weiss nicht ob es ueberall AssignIoPort verwendet, da sie nicht fuer vom Modul dynamisch ausgesuchte IO-Schnittstellen eignet. AssignIoPort respektiert ein vom Benutzer gesetztes Attribut, und der Maintainer hatte mit diesem Konzept seine Probleme.
Da mit den neueren Versionen das IODev-Attribut gelöscht wird, wenn eine VCCU mit IOlist gesetzt ist, dürfte das nicht (mehr) das Problem sein. Soweit ich das im Kopf habe, wird überall weiter AssignIoPort genutzt.

Zitat von: frank am 25 Oktober 2021, 12:50:15
bei der automatischen zuweisung durch cul_hm gibt es eventuell noch ein problem. bisher habe ich es erst einmal zufällig festgestellt, konnte aber nicht nachvollziehen, wann und wodurch es entstanden ist.
...ich glaube die vermutete Lücke zu spüren: Wenn ein IO mit einer "Registrierung" dazukommt und für einzelne Devices dann prefIO wird, muss eigentlich dem bisherigen IO mitgeteilt werden, dass es nicht mehr zuständig ist. Ob das in allen Fällen passiert, kann ich im Moment auch nicht sicher sagen, meine aber, alle Stellen mit prefIO mal durchgegangen zu sein; da wird soweit erkennbar überall dann auch das $oldIoDev informiert. Müßte man eventuell nochmal doppelchecken, der Code ist leider auch an der Stelle ziemlich verschachtelt...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

frank

ZitatMüßte man eventuell nochmal doppelchecken
genau deswegen möchte ich einen trigger bei io wechsel im reading IODev.  :)
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Beta-User

Na ja, wenn es "nur" um's testweise Aufrufen von Prüfcode geht, könnte vorübergehend ein entsprechender Funktionsaufruf auch direkt aus fhem.pl heraus reingeflickt werden, fhem.pl ca. #2235 nach
setReadingsVal($hash, "IODev", $val, TimeNow()); # 120603
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

frank

grundsätzlich wäre ein event über ein io wechsel für den user hoch informativ.
zur zeit ist mir völlig unklar, warum dieses ereignis so geheim gehalten wird. im idealfall sollte es gar keinen wechsel geben, somit auch kein event erzeugt werden.

alle paar sekunden das reading abfragen kann ja nicht die lösung sein, um zeitnah einen wechsel mitzubekommen.


Zitatfhem.pl ca. #2235
in setReadingsVal ist für iodev allerdings noch eine beschränkung. also eher dort.
scheinbar gibt es weitere "mechaniken", die einfluss auf das reading nehmen, was an dieser stelle aber nicht zu interessieren scheint. sehr "verworren".
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

betateilchen

In dem hier diskutierten Zusammenhang stelle ich mir gerade die Frage, ob es überhaupt Sinn macht, das reading IODev in das statefile zu schreiben?
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

ZitatIn dem hier diskutierten Zusammenhang stelle ich mir gerade die Frage, ob es überhaupt Sinn macht, das reading IODev in das statefile zu schreiben?
Das IODev-Reading ist die Einstellung, was FHEM gewaehlt hat, beim Erstellung des logischen Geraetes.
Das sollte sich nicht aendern, nur weil ein weiteres IODev hinzugefuegt wurde.

frank

Zitat von: betateilchen am 26 Oktober 2021, 10:42:52
In dem hier diskutierten Zusammenhang stelle ich mir gerade die Frage, ob es überhaupt Sinn macht, das reading IODev in das statefile zu schreiben?
soweit ich verstanden habe, soll über das reading IODev die möglichkeit gegeben werden, nach einem restart mit dem io im reading direkt fortfahren zu können, falls das attr IODev nicht existiert.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

frank

ich habe nun in setReadingsVal erst mal 2 logmeldungen eingebaut und könnte mich da ggf noch mit einem notify dranhängen.

  #return if($rname eq "IODev" && !fhem_devSupportsAttr($hash->{NAME}, "IODev"));
  if($rname eq "IODev") {
    my $old = ReadingsVal($hash->{NAME}, "IODev", "---");
    Log(1,"----- $hash->{NAME}-iodev_changed ----- => o:$old n:$val") if($hash->{TYPE} eq "CUL_HM" && $old ne $val);
    if(!fhem_devSupportsAttr($hash->{NAME}, "IODev")) {
      Log(1,"----- $hash->{NAME}-iodev_error ----- => o:$old n:$val") if($hash->{TYPE} eq "CUL_HM");
      return;
    }
  }
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

rudolfkoenig

Wuerden so ein Event auch andere interessant finden?
Wenn ja, dann baue ich was ein.

betateilchen

Ich brauche diese events nicht.

Kannst Du das ggf. konfigurierbar machen, z.B. über das vorhandene globale Attribut disableFeatures?
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

frank

Zitat von: rudolfkoenig am 27 Oktober 2021, 11:43:32
Wuerden so ein Event auch andere interessant finden?
Wenn ja, dann baue ich was ein.
zumindestens für cul_hm wäre es sicherlich auch sinnvoll beim einbau/aktivierung von haus aus nur events bei change zu bekommen.
zur zeit wird nach meinem empfinden bei cul_hm AssignIoPort sehr häufig unnötiger weise aufgerufen.

verkaufsargument für interessierte:
vor allem bei multi-io anwendungen (cul_hm/vccu, max?) könnte man mit diesen events eine schlechte io-verteilung/zuweisung erkennen und ggf ändern, um unnötig häufiges wechseln des io zu vermeiden. je nach io wird bei jedem wechsel ggf das EEPROM beschrieben und verkürzt die lebenszeit des io.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html