FHEM > Sonstiges

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

<< < (11/11)

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.
--- Ende Zitat ---
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.


--- Zitat ---Ob das das Kriterium erfüllt "absichtlich was Falsches" gesetzt zu haben, mag ich nicht beurteilen
--- Ende Zitat ---
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:

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

--- Ende Zitat ---
;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

--- Code: ---list IOAssignmentErrCnt~.+ IOAssignmentErrCnt
--- Ende Code ---
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:

--- Zitat ---es ist aber unmöglich ein problem zu erkennen, wenn ein entsprechendes problem erst nach dem starten der anwendung, also im laufenden betrieb erfolgt.
--- Ende Zitat ---
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.
--- Ende Zitat ---
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

Navigation

[0] Themen-Index

[*] Vorherige Sete

Zur normalen Ansicht wechseln