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

[frank]

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. 
reicht das?

[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]

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.

[rudolfkoenig]

Ob 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.

[frank]

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.

Ob 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.

[Beta-User]

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.

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

Code Auswählen Erweitern

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.

[rudolfkoenig]

es 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]

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.

[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