[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

rudolfkoenig

Sollte sowas dann nicht eher im konkreten Modul als Event generiert werden?

frank

Zitat von: rudolfkoenig am 27 Oktober 2021, 13:19:01
Sollte sowas dann nicht eher im konkreten Modul als Event generiert werden?
fangfrage? mit einer antwort sitzt man eventuell schnell in den nesseln.  ;)


unbedarfte usersicht:

- grundsätzlich erwarte ich von einem reading erst einmal events, um mindestens über longpoll änderungen im frontend verfolgen zu können.

- mein vorschlag mit nur event bei änderung ziehe ich hiermit zurück, da ich immer dafür eintrete, dass alle readings von haus aus events bei update generieren sollten. nur mit einheitlichem eventverhalten, finde ich, ist die "trickreiche" event minimierung über attribute für anfänger einigermassen verständlich zu machen.
wenn hier zu viele events bei cul_hm auftauchen, ist es auch ein deutlicher hinweis für den maintainer, dass bei der implementierung von AssignIoPort nachgearbeitet werden sollte. so wird wenigstens nichts unter den teppich gekehrt.

- wenn ein modul das reading IODev über AssignIoPort zur verfügung stellt, ist es natürlich sinnvoll, wenn dieses auch direkt entsprechend genutzt werden kann. genau dieses reading repräsentiert doch dann die auswahl des io (sollte).
ein weiteres modul-reading erhöht nur das risiko, dass beide readings nicht deckungsgleich sind, wie beim spiel "stille post".

- nach internal, reading und attribut IODev nun noch ein 2. reading IODev2 ist nicht nach meinem geschmack.
ausserdem wird es dann in jedem modul wieder unterschiedlich implementiert.
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

Zitat von: frank am 27 Oktober 2021, 16:13:00
da ich immer dafür eintrete, dass alle readings von haus aus events bei update generieren sollten

Das würde in vielen Fällen von readings, bei denen heute kein event erzeugt wird, keinen Sinn machen.
Umgekehrt gibt es heute schon sehr viele (hunderte?) von readings, bei denen die erzeugten events überhaupt keinen Sinn machen.

Als Entwickler mache ich mir sehr wohl Gedanken darüber, bei welchen readings ich ein event erzeuge oder nicht.

Außerdem gibt es wohl immer noch Module, die readings nicht über die dafür vorgesehenen Funktionen befüllen, sondern direkt den hash beschreiben.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

frank

ZitatAls Entwickler mache ich mir sehr wohl Gedanken darüber, bei welchen readings ich ein event erzeuge oder nicht.
ich wollte nicht sagen, dass die entwickler sich keine gedanken über sinnvolle events machen. ganz im gegenteil wäre eine sinnvolle "voreinstellung" grundsätzlich wünschenswert.

weiterhin behaupte ich aber, dass ein entwickler nicht überschauen kann, welche wilden ideen sich user einfallen lassen können. da sind sicherlich alle schattierungen von genial bis wahnsinnig dabei.
aktuell behindert eine im code vorgenommene voreinstellung der events die kreativität des users, da er sie nicht wieder erweitern kann.

für jedes zusätzliche event eine diskussion zu starten ist mitunter sehr ermüdend.

ideal wäre eine sinnvolle voreinstellung durch den entwickler, die der user in beide richtungen verändern kann.
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

Da ich explizit aufgefordert wurde, meine Meinung kundzutun, hier mein Senf:

Bitte keine zusätzlichen Events - jedenfalls nicht vor 6.1 release. Wir wissen derzeit nicht, wie viele Events das (v.a. bei schlecht gecodeten Modulen, falls es solche geben sollte) generieren würde, und manche User sind "eventmäßig auf Kante genäht".

franks Anliegen verstehe ich aus gegebenem Anlass allerdings auch nur zu gut, und von daher: Wenn, dann bitte für den Moment nur, wenn die anfordernde Instanz das ausdrücklich so haben will - optimalerweise über den Instanzhash einstellbar, damit man nicht immer wieder den ganzen Code anfassen muss, wo überall ggf. Assign... aufgerufen wird...
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

rudolfkoenig

Zitatideal wäre eine sinnvolle voreinstellung durch den entwickler, die der user in beide richtungen verändern kann.
Am besten bequem (mit Regexp) und natuerlich ohne Performance Einbussen. Der Haken ist: ich weiss nicht, wie ich das machen soll.

Im aktuellen Fall wird die Sache dadurch verkompliziert, dass AssignIoPort nicht die "offiziellen" readings*Update Funktionen verwendet, sondern (um Performant zu sein) eine Abkuerzung waehlt. Und selbst bei dieser Abkuerzung gibt es eine Sonderbehandlung (vulgo Hack), was die Anwendung eines generischen Schalters nicht gerade einfacher macht. Und das im Moment fuer einen ganz speziellen Anwendungsfall, was eigentlich anders geloest werden sollte.

Ich will nicht sagen, dass ich irgendwann nicht nachgebe, aber Kosten/Nutzen sollte im Rahmen bleiben.

frank

ZitatAm besten bequem (mit Regexp) und natuerlich ohne Performance Einbussen. Der Haken ist: ich weiss nicht, wie ich das machen soll.
sicherlich nicht gut überlegt, trotzdem mal erwähnt:

ein attribut (eventsDefault:on|off), das das codierte eventverhalten aller readings eines devices umschalten kann.
eventsDefault=on: das vom entwickler codierte/minimierte verhalten ist wirksam, so wie bisher.
eventsDefault=off: alle codierten restriktionen sind unwirksam, also theoretisch können nun alle readings events on update generieren.
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

Zitatein attribut (eventsDefault:on|off), das das codierte eventverhalten aller readings eines devices umschalten kann.
Das ist deutlich bescheidener als das, was ich befuerchtet habe, und ich kann es auch einbauen, ich wuerde es dann aber forceReadingEvents nennen. Leider wird es in diesem Fall (AssignIoPort) nicht helfen: immer noch interessiert? Wenn ja: gibt es einen konkreten Anwendungsfall?

frank

ZitatDas ist deutlich bescheidener als das, was ich befuerchtet habe, und ich kann es auch einbauen, ich wuerde es dann aber forceReadingEvents nennen.
cool, dann könnte martin in cul_hm im code ordentlich events minimieren und viele timingprobleme wären gelöst.

ZitatLeider wird es in diesem Fall (AssignIoPort) nicht helfen: immer noch interessiert? Wenn ja: gibt es einen konkreten Anwendungsfall?
das hatte ich schon verstanden und interessiert bin ich natürlich auch noch.  :)
hierbei reicht mir aber events-on-change.

anwendungen wären alle für cul_hm. also eventuell wie vorgeschlagen eine freischaltung pro device:
-zentrales notify, das durch alle io-wechsel getriggert wird, um
--die geänderten einstellungen der io zu checken (was hoffentlich bald nicht mehr nötig sein sollte)
--einen counter zur signalisierung vermehrter wechseltätigkeit einzurichten
    (normalerweise sollten bei mir keine wechsel nötig sein)
-filelog zum speichern und plotten aller wechsel
-wahrscheinlich eine signalisierung für HMinfoTools, die über ein eingefärbtes icon die korrekte nutzung des eingestellten prefferd io charakterisiert (grün, gelb, rot)
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

Zitatanwendungen wären alle für cul_hm. also eventuell wie vorgeschlagen eine freischaltung pro device:
Das Du das moechtest, ist mir klar, aber wenn ich forceReadingEvents einbaue, wuerdest Du das nicht koennen.
Mich interessieren die Faelle, die moeglich sind, vulgo die readings*Update(...,0) Aufrufe, die ausgewertet werden wollen.

frank

ok, verstanden.

aktuell eher der "umgekehrte" fall, dass ich nun modulautoren bitten kann, events zu reduzieren, da ich mir ja mit dem neuen attribut kein "eigentor" mehr schiessen kann.  ;)

ansonsten hatte ich vor längerer zeit eine für mich sehr unbefriedigende diskussion mit dem autor von 77_Nina.pm (nicht svn). dort wurden damals events extrem minimiert, so dass ich mir die events selber eingebaut habe.
dort brauchte ich einen trigger on-update, es wurde aber nur on-change angeboten.

ideen hatte ich sicher noch ein paar wenige, aber wahrscheinlich keine energie, um diskussionen zu starten. bei einigen
autoren ist vermutlich schon die frage nach weiteren events eher energieverschwendung.
mit einer einführung von forceReadingEvents werden wahrscheinlich wieder ideen kommen, die bisher "verkümmert" sind.
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

Wenn man nun tatsächlich anfängt, mich als Entwickler mit solchen Mechanismen zu entmündigen, indem man meine Überlegungen zu readings und events einfach ignoriert und -noch schlimmer - übersteuerbar macht, werde ich mir überlegen müssen, wie ich das als Entwickler verhindern kann.

Und wenn es nicht anders geht, werde ich halt wieder anfangen, den readings-hash direkt zu beschreiben.

Wenn ich mir überlege, dass die ganze Diskussion letztendlich nur wegen eines einzigen Moduls (CUL_HM) angestossen wurde, sollte man sich m.E. eher darum kümmern, dieses eine Modul in geordnete Bahnen zu lenken, anstatt die komplette Community von Entwicklern plötzlich zu gängeln und zu bevormunden.
-----------------------
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: betateilchen am 28 Oktober 2021, 20:45:09
Wenn man nun tatsächlich anfängt, mich als Entwickler mit solchen Mechanismen zu entmündigen, indem man meine Überlegungen zu readings und events einfach ignoriert und -noch schlimmer - übersteuerbar macht, werde ich mir überlegen müssen, wie ich das als Entwickler verhindern kann.

Und wenn es nicht anders geht, werde ich halt wieder anfangen, den readings-hash direkt zu beschreiben.

Wenn ich mir überlege, dass die ganze Diskussion letztendlich nur wegen eines einzigen Moduls (CUL_HM) angestossen wurde, sollte man sich m.E. eher darum kümmern, dieses eine Modul in geordnete Bahnen zu lenken, anstatt die komplette Community von Entwicklern plötzlich zu gängeln und zu bevormunden.
jetzt weiss ich endlich, wozu man popcorn braucht.  8)

danke für deine wirklich perfekte untermalung meiner gewagten these:
Zitat von: frank am 28 Oktober 2021, 16:26:31
bei einigen autoren ist vermutlich schon die frage nach weiteren events eher energieverschwendung.


trotzdem noch mal ernsthaft:

wenn deine angebotenen events wirklich so perfekt gesetzt sind, braucht doch kein mensch für deine module dieses attribut. wo wirst du entmündigt, gegängelt oder bevormundet? du sollst, musst und brauchst nichts ändern, soweit ich das überblicke.
was haut dich so aus den socken?
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

Meine 2ct:
Wir sollten nicht Rechenleistung einplanen für Prüfungen, die man nur in ganz seltenen Ausnahmefällen vielleicht braucht (und dann auf andere Weise einbauen kann, und zwar optimalerweise jeweils im "Problemmodul" selbst). Bin also weiter gegen Events, egal ob zwangsweise oder optional herstellbar und auch gegen zusätzliche interne Prüfungen/Abfragen.
Noch ein event-on.*-Attribut ist vermutlich auch aus Usersicht nicht hilfreich; da hat jetzt schon - vorsichtig ausgedrückt - eine nicht unerhebliche Zahl der User Probleme, die bestehenden Optionen sinnvoll zu setzen.

Und bitte - bei allem Herzblut, das da teils drinsteckt - bleibt doch bei der Sache.

Wei gesagt: Nur meine 2ct.
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

betateilchen

Zitat von: Beta-User am 29 Oktober 2021, 09:48:40
Bin also weiter gegen Events, egal ob zwangsweise oder optional herstellbar und auch gegen zusätzliche interne Prüfungen/Abfragen.

Danke! Zumindest bin ich mit meiner Meinung und Denkweise nicht alleine.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

Vielleicht ist die gerade eingecheckte Loesung mit "fhemdebug forceEvents {1|0}" eine Loesung, die beide Parteien befriedigen kann.

Wenn man dieses Befehl nicht aufruft, aendert sich nichts.

Mit dem Aufruf von "fhemdebug forceEvents 1" kriegen die beiden Funktionen einen Wrapper.
setReadingsVal generiert mit IODev ein Event, und readings*Update immer.
Vorausgesetzt, das betroffene Geraet hat "attr forceEvents 1" gesetzt.
Dieses Attribut muss per userAttr aktiviert sein.

"fhemdebug forceEvents 0" entfernt die Wrapper.

frank

#31
danke fürs einbauen.  :)

ein problem existiert noch beim spezial reading IODev, denn dort fehlt im event der doppelpunkt nach dem readingnamen:
2021-10-30 16:18:19.492 CUL_HM SwitchPBU05 IODev cul868

bei den "normalen", bisher abgeschalteten readings, funktioniert es perfekt.

edit: kann ich irgendwo erkennen, ob die "wrapper" gesetzt/wirksam sind?
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

Zitatein problem existiert noch beim spezial reading IODev, denn dort fehlt im event der doppelpunkt nach dem readingnamen:
Hoffentlich ist dieses Problem auf der Benutzerseite loesbar.

Zitatedit: kann ich irgendwo erkennen, ob die "wrapper" gesetzt/wirksam sind?
Wuesste nicht, wie.

betateilchen

Das Popcorn-Potenzial dieses Threads wird immer höher...
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

frank

#34
moin,
heute nacht gab es einen ungewollten fhem restart.
bin unsicher, ob fhemdebug beobachter, auslöser oder beides ist

2021.10.31 01:34:55.486 4: CUL_Parse: cul868 A 14 A0 A270 6869B6 1ACE1F 00BD442ACB000000060A8C30 -50
2021.10.31 01:34:55.487 5: cul868: dispatch A14A0A2706869B61ACE1F00BD442ACB000000060A8C::-50:cul868
2021.10.31 01:34:55.503 3: n_iodev return value: HASH(0x73c95a0)
2021.10.31 01:34:55.514 5: cul868 sending As0AA080021ACE1F6869B600
2021.10.31 01:34:55.515 5: CUL 6869B6 dly:71ms
2021.10.31 01:34:55.588 5: DevIo_SimpleWrite cul868: As0AA080021ACE1F6869B600
Modification of a read-only value attempted at ./FHEM/98_fhemdebug.pm line 57.
2021.10.31 01:36:34.140 1: Including fhem.cfg


- der gezeigte sendevorgang findet alle 3min statt und war bis hierhin seit stunden kein problem, wie auch alles andere. 
- "n_iodev return value: HASH(0x73c95a0)" kommt vom test notify, das noch nichts macht.
defmod n_iodev notify .*IODev.* {}
- hier gab es auch kein io wechsel, da meine logmeldung fehlt.


normaler weise werden nach DevIo_SimpleWrite noch die messages der 2 weiteren io (beobachter) ausgewertet. dazwischen muss also der restart passiert sein. hier das log von 3min vorher:
2021.10.31 01:31:45.818 4: CUL_Parse: cul868 A 14 9F A270 6869B6 1ACE1F 00BE452ACB000000060A8C30 -50
2021.10.31 01:31:45.821 5: cul868: dispatch A149FA2706869B61ACE1F00BE452ACB000000060A8C::-50:cul868
2021.10.31 01:31:45.842 3: n_iodev return value: HASH(0x7949208)
2021.10.31 01:31:45.854 5: cul868 sending As0A9F80021ACE1F6869B600
2021.10.31 01:31:45.856 5: CUL 6869B6 dly:64ms
2021.10.31 01:31:45.921 5: DevIo_SimpleWrite cul868: As0A9F80021ACE1F6869B600
2021.10.31 01:31:45.964 0: HMUARTLGW hmuart1 recv: 01 05 00 00 2E msg: 9F A2 70 6869B6 1ACE1F 00BE452ACB000000060A8C
2021.10.31 01:31:45.968 0: HMUARTLGW hmuart1 recv: 01 05 00 00 0F msg: 9F 80 02 1ACE1F 6869B6 00
2021.10.31 01:31:45.973 0: HMLAN_Parse: hmlan1 R:E6869B6   stat:0000 t:252377F8 d:FF r:FFCE     m:9F A270 6869B6 1ACE1F 00BE452ACB000000060A8C
2021.10.31 01:31:45.976 0: HMLAN_Parse: hmlan1 R:E1ACE1F   stat:0000 t:2523787D d:FF r:FFD7     m:9F 8002 1ACE1F 6869B6 00



edit:
fhemdebug muss ja jeweils nach restart neu gestartet werden.
wo und wie baue ich das am besten ein, so dass es zum frühest möglichen zeitpunkt passiert?
systemd?


edit2:
der block startet ja jeweils mit dem empfang einer message von einem sensor.
im eventlog des sensors ist zum crash zeitpunkt nur das event des readings IODev zu sehen. sensordaten wurden nicht mehr gelogt. demzufolge würde ich sagen, dass es bei der eventgenerierung der "normalen" sensordaten passiert sein müsste.
die rohdaten sehen aber grundsätzlich unverdächtig aus, nichts ungewöhnliches. zum vorhergehenden zyklus haben sich die werte temperature und humidity geändert.
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

ZitatModification of a read-only value attempted at ./FHEM/98_fhemdebug.pm line 57.
Habe zwar keine Ahnung, wie man das generiert, aber ich habe den Wert jetzt in eine lokale Variable kopiert vor dem Modifizieren.


Zitatwo und wie baue ich das am besten ein, so dass es zum frühest möglichen zeitpunkt passiert?
Ich empfehle "define n1 notify global:INITIALIZED fhemdebug forceEvents 1".
Alternative ist eine "fhemdebug forceEvents 1" Zeile vorne im fhem.cfg, das muss man aber nach einem save immer wieder einbauen.

betateilchen

Die Variante mit dem notify funktioniert zumindest auch bei configDB Nutzern.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

frank

ZitatHabe zwar keine Ahnung, wie man das generiert, aber ich habe den Wert jetzt in eine lokale Variable kopiert vor dem Modifizieren.
sehr gute massnahme, seit 12 std keine probleme mehr.
bisher spätestens nach 3 std fhem restart.

das problem wurde übrigens regelmässig nur bei dem gezeigten device produziert.
eine besonderheit ist, dass dieses device (homebrew) seine parse funktion in einer eigenen datei bereitstellt. die relevanten "readings-funktionen" sind aber zentral in cul_hm. ein 2. homebrew device, für das eine 2. externe datei bereitsteht, hat allerdings keine probleme verursacht.

vermutlich gibt es keinen zusammenhang, aber hier mal aufruf und datenübergabe dieser externen funktion in cul_hm:
  elsif (eval "defined(&CUL_HM_Parse$mh{st})"){################################
    no strict "refs";
    my @ret = &{"CUL_HM_Parse$mh{st}"}($mh{mFlg},$mh{mTp},$mh{src},$mh{dst},$mh{p},$target);
    use strict "refs";
    push @evtEt,@ret;
  }
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

hallo rudi,

nochmal zum problem des fehlenden doppelpunktes im event des readings IODev.

Zitat von: rudolfkoenig am 30 Oktober 2021, 17:00:12
Hoffentlich ist dieses Problem auf der Benutzerseite loesbar.
das aktuelle event schafft es nicht über longpoll in das frontent zu gelangen.
dadurch wird das reading nicht aktualisiert und über javascript kann ich auch nicht reagieren.

wenn ich das event aber "richtig" simuliere in zeile 62 fhemdebug, funktioniert es wunderbar:
        DoTrigger($_[0]->{NAME}, "$_[1]: $_[2]")



und noch ein zweiter wunsch:
in AssignIoPort gibt es auch den fall, dass kein io zugewiesen wird:
    Log 3, "No I/O device found for $hn";
tritt dieser fall ein, sind reading und internal aber nicht mehr identisch.
spricht etwas dagegen, dem reading einen entsprechenden wert für diesen fall zuzuweisen, zb "none"?
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

        DoTrigger($_[0]->{NAME}, "$_[1]: $_[2]")

Habs so eingecheckt.

Zitatspricht etwas dagegen, dem reading einen entsprechenden wert für diesen fall zuzuweisen, zb "none"?
None ist mir suspekt, ich wuerde eher dieses Reading entfernen.

frank

Zitat von: rudolfkoenig am 03 November 2021, 19:28:56
Habs so eingecheckt.
danke.

ZitatNone ist mir suspekt, ich wuerde eher dieses Reading entfernen.
hoffentlich meinst du nicht damit, das reading grundsätzlich abzuschaffen.  ;)

falls aber gemeint ist, das reading zu entfernen, wenn "if($hash->{IODev})" nicht wahr ist, dann würde ich als user das löschen des readings befürworten, wenn dieser vorgang ein "lösch-event" generiert.
ich möchte im frontend gerne auf diesen fall reagieren können.
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

Zitatfalls aber gemeint ist, das reading zu entfernen, wenn "if($hash->{IODev})" nicht wahr ist, dann würde ich als user das löschen des readings befürworten, wenn dieser vorgang ein "lösch-event" generiert.
Das verstehe ich, es gibt aber auch sonst kein delete reading Event, abgesehen davon weiss ich nicht, wie ich ein solches Event nur mit dem fhemdebug Wrapper erzeugen soll.
Hat das Problem eine praktische Relevanz, sprich kommt einer der Module nachweislich auf die Idee, unakzeptable IODevs zu setzen?

frank

ZitatDas verstehe ich, es gibt aber auch sonst kein delete reading Event, abgesehen davon weiss ich nicht, wie ich ein solches Event nur mit dem fhemdebug Wrapper erzeugen soll.
genau, hier besteht eine informations defizit.
neue idee: ein "leeres" reading IODev setzen.
oder zuerst ein leeres reading IODev setzen, wodurch das event erzeugt wird und anschliessend das reading löschen.


wieso schaffe ich es eigentlich nicht, ein leeres reading mit setreading zu erzeugen? verboten?
offensichtlich wird hier das leerzeichen am ende des cmd "wegoptimiert". egal wie ich es probiere, es kommt immer die selbe fehlermeldung:
Usage: setreading <name> [YYYY-MM-DD HH:MM:SS] <reading> <value>
where <name> is a single device name, a list separated by comma (,) or a regexp. See the devspec section in the commandref.html for details.


das modul HTTPMOD schafft es aber regelmässig das reading UNMATCHED_READINGS ohne inhalt zu setzen. die events können auch mit event-on attributen minimiert werden und longpoll aktualisiert auch entsprechend den timestamp im frontend.

versuche mit dem trigger cmd waren ähnlich erfolglos.
hier habe ich mit einem &nsbp am ende des cmd zumindestens geschaft, das event in den eventmonitor zu bekommen. allerdings schafft es auch dieses event nicht auf die entsprechende detailseite des devices.

mit der funktion "DoTrigger" funktioniert es dann problemlos.
{DoTrigger("Wetter.Sued", "IODev: ")}



ZitatHat das Problem eine praktische Relevanz, sprich kommt einer der Module nachweislich auf die Idee, unakzeptable IODevs zu setzen?
nicht das ich wüsste, aber ausschliessen tue ich es auch nicht.
bisher ist mir nur die "informationslücke" aufgefallen, die ich gerne geschlossen hätte.
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

Zitat von: frank am 09 November 2021, 15:32:56
nicht das ich wüsste, aber ausschliessen tue ich es auch nicht.
bisher ist mir nur die "informationslücke" aufgefallen, die ich gerne geschlossen hätte.
In CUL_HM waren afaik bestimmte Situationen denkbar, in denen CUL_HM glaubte, es besser zu wissen wie fhem.pl, welches IO in $hash->{IODev} rein muss. Das ist aber seit der letzten svn-Version raus. (Ich weiß nur noch nicht, ob der jetzt für solche Mismatches eingebaute Zähler funktioniert, und nein: der triggert nicht, man kann nur den ersten Fall im Log finden).

Zitat von: frank am 09 November 2021, 15:32:56
genau, hier besteht eine informations defizit.
neue idee: ein "leeres" reading IODev setzen.
oder zuerst ein leeres reading IODev setzen, wodurch das event erzeugt wird und anschliessend das reading löschen.
So informativ manche Dinge sein mögen, irgendwie irritiert es mich immer noch, dass man dafür Events generiert und nicht den Modulcode direkt nutzt. Bin gedanklich immer noch eher bei dem Modell, dass man Events dann generiert, wenn die allgemein interessant sind und alles andere (modul-) intern klärt. Werde wohl alt oder übersehe mal wieder was wesentliches...

Zitat
das modul HTTPMOD schafft es
"Alle Module" schaffen das, man muss nur eine der "readings.*Update"-Funktionen nutzen.
Sehe auch kein Problem darin, dass das Frontend solche Optionen nicht anbietet.
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

rudolfkoenig

Zitatoffensichtlich wird hier das leerzeichen am ende des cmd "wegoptimiert"
Nicht nur da, auch am Anfang. Beides habe ich nicht wegen mir eingebaut :)

Zitatnicht das ich wüsste, aber ausschliessen tue ich es auch nicht.
Ich mache mir Gedanken ueber diesen Fall, wenn jemand zeigt, dass es vorkommen kann.

frank

Zitat von: rudolfkoenig am 09 November 2021, 20:01:02
Ich mache mir Gedanken ueber diesen Fall, wenn jemand zeigt, dass es vorkommen kann.
wenn ich das forum nach "No I/O device found for" durchsuche (Ergebnisse als Beiträge anzeigen), werden mir 16 seiten a 30 beiträge gezeigt.  8)
reicht das?
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

Natuerlich nicht, es geht darum, dass ein Modul absichtlich was Falsches setzt.
Nicht darum, dass ein Benutzer ein IODev nie definiert oder entfernt hat, oder dass ein IODev Modul nicht geladen werden konnte.

Beta-User

Zitat von: rudolfkoenig am 10 November 2021, 10:45:59
Natuerlich nicht, es geht darum, dass ein Modul absichtlich was Falsches setzt.
Nochmal zur Klarstellung: der "Auslöser" der Diskussion hier (CUL_HM) hatte bis vor kurzem eine Zeile drin, die zur Folge haben konnte, dass etwas anderes gesetzt wurde, als AssignIoPort nach entsprechendem Vorschlag effektiv gesetzt hatte. Das ist jetzt raus.
Ob das das Kriterium erfüllt "absichtlich was Falsches" gesetzt zu haben, mag ich nicht beurteilen, mir erschien die betreffende Zeile jedenfalls unlogisch => Vorschlag das zu ändern => jetziger svn-Stand.
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

rudolfkoenig

ZitatOb das das Kriterium erfüllt "absichtlich was Falsches" gesetzt zu haben, mag ich nicht beurteilen
Ich meine nicht, weil CUL_HM einen "richtigen" IODev setzt, nur womoeglich nicht das, was der Benutzer haben will.
Genau das kann man mit dem Vorschlag hier auswerten.
Mit falsch meinte ich etwas, was gar nicht existiert, und deswegen per AssignIoPort nicht zugewiesen werden kann.

Beta-User

Soweit ich die Zusammenhänge im Kopf habe, war es auch möglich, dass CUL_HM $hash->{IODev} auf undef gesetzt bekam, wenn der User "Mist" angegeben hatte (oder auf irgendwas, das nicht mal irgendein IO sein mußte).
Das geht erst seit rev. 25158 (wieder?) nicht mehr: https://svn.fhem.de/trac/changeset/25158/trunk/fhem/FHEM/10_CUL_HM.pm, siehe dort die alte #10918.
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

Zitat von: rudolfkoenig am 10 November 2021, 10:45:59
Natuerlich nicht, es geht darum, dass ein Modul absichtlich was Falsches setzt.
Nicht darum, dass ein Benutzer ein IODev nie definiert oder entfernt hat, oder dass ein IODev Modul nicht geladen werden konnte.
aber genau darum geht es mir doch!

meine javascript anwendung überwacht die io auswahl, ggf dauerhaft im laufenden betrieb.
der user soll umgehend informiert werden, wenn ein falsches oder "sinnloses" oder gar kein io gewählt werden kann. dabei ist doch völlig egal, ob dieser fall durch einen individuellen konfigurationsfehler eintritt.

beim starten der anwendung ist es ein leichtes alle benötigten daten (zb internal IODev) von fhem zu pollen, um eine aktuelle problematische io auswahl zu erkennen. es ist aber unmöglich ein problem zu erkennen, wenn ein entsprechendes problem erst nach dem starten der anwendung, also im laufenden betrieb erfolgt.
dazu muss die anwendung aber ein event über longpoll erhalten.
ich hoffe nicht, dass ich gleich höre, zb alle 10s alle benötigten daten von fhem zu pollen, um "mein" problem zu lösen.

zudem würde ich sagen, dass ein modul bereits "absichtlich was falsches setzt", wenn dieser fall eintritt. es hätte nie AssignIoPort aufrufen dürfen. andererseits frage ich mich, warum AssignIoPort selbst umfangreiche checks durchführt und sogar ggf versucht selbst ein brauchbares io zu finden.

ZitatOb das das Kriterium erfüllt "absichtlich was Falsches" gesetzt zu haben, mag ich nicht beurteilen
offensichtlich ein typisches "henne oder ei, was war zuerst da" problem.

bei cul_hm potenziert sich das problem ausserdem: diverse module von unterschiedlichen autoren benutzen jeweils diverse hardware, die zudem teilweise mit unterschiedlicher fw genutzt werden kann.
jetzt könnte ich sarkastisch werden und behaupten: viele köche verderben den brei. aber nein, ich finde es grossartig, dass es so viele möglichkeiten gibt. allerdings erhöht es das risiko, dass unvorstellbare konstellationen auftauchen und viel code existiert, der auch immer wieder fehler enthalten kann.

wenn sich da jemand traut zu sagen, dass der fall niemals eintreten kann, zieh ich den hut.
ein kleines event, ausgelöst in AssignIoPort könnte alle möglichen und unmöglichen fehler sofort sichtbar machen.

da aktuell in cul_hm durch einen fehler-counter sogar dafür gesorgt wird, offensichliche fehler an dieser stelle zu "vertuschen", indem nur einmalig eine fehlermeldung erscheint, ist es für mich eigentlich auch nicht mehr verwunderlich, wenn potentielle fehler noch weniger beachtung finden.
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

Zitat von: frank am 10 November 2021, 13:44:57
da aktuell in cul_hm durch einen fehler-counter sogar dafür gesorgt wird, offensichliche fehler an dieser stelle zu "vertuschen", indem nur einmalig eine fehlermeldung erscheint, ist es für mich eigentlich auch nicht mehr verwunderlich, wenn potentielle fehler noch weniger beachtung finden.
;D Imo ist die Diskussion über CUL_HM hier falsch, aber wenn es um die Frage geht, wie man das konkrete Problem denn am besten löst: Das mit dem Counter war eine Idee, um den in einem (oder zwei) Fall/Fällen aufgetretenen massiven Log-Einträgen zu begegnen. Nach meinem Verständnis der Abläufe ist es aber bereits durch die o.g. Änderung eher unwahrscheinlich, dass das überhaupt wieder in großer Zahl eintritt, weil sich nicht mehr CUL_HM durchsetzt, sondern AssignIoPort().
Jetzt kann man ggf. (nur durch pollen, ja) ermitteln, ob das überhaupt noch ein zahlenmäßig relevantes Thema ist, oder ein durch einen einmaligen Konfigurationseingriff zu lösendes Problem, das AssignIoPort() automatisch fixt. Nix genaues weiß man nicht, und ich gebe dir recht, frank, dass es interessant wäre, das zu erfahren.

In meiner Installation liefert jedenfalls bis dato
list IOAssignmentErrCnt~.+ IOAssignmentErrCnt
genau nichts.
Vielleicht sollten wir mal die Tester fragen, wer da was dazu vermelden kann...?

Falls da wirklich was wichtiges schlummert, kann man den Code m.E. in CUL_HM auch so (zum testen?) ändern, dass man da mehr/häufiger Infos bekommt.
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

rudolfkoenig

Zitates ist aber unmöglich ein problem zu erkennen, wenn ein entsprechendes problem erst nach dem starten der anwendung, also im laufenden betrieb erfolgt.
Wenn man das weiter denkt, muesste ich dem Benutzer ermoeglichen alle Framework-Funktionen zu ueberwachen, weil die Module beliebige Funktionen falsch verwenden koennen.

Ich bin der Ansicht, das dass der falsche Weg ist, und das Problem anders geloest werden muss.

frank

Zitat von: rudolfkoenig am 10 November 2021, 14:42:00
Wenn man das weiter denkt, muesste ich dem Benutzer ermoeglichen alle Framework-Funktionen zu ueberwachen, weil die Module beliebige Funktionen falsch verwenden koennen.
nicht gleich übertreiben.  :)

ich bin der ansicht, AssignIoPort stellt mit dem reading IODev bereits eine überwachungsmöglichkeit bereit, aber bedient es im "fehlerfall" schlicht falsch. ist es denn nicht logisch, dass wenn der letzte in einer komplexen kette einen fehler feststellt, diesen auch entsprechend mitteilt, zumal der informationskanal doch schon existiert?

ok. da du nicht willst, bleibt es wie es ist.
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

erwin

Also wie ich das verstehe, (und auch im Notfall praktiziere)
gibts noch immer die Möglichkeit - ein Attr IODev zu setzen und erst danach assignIOPort  aufzurufen...
l.g. erwin
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...