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

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

danke fürs einbauen. 

ein problem existiert noch beim spezial reading IODev, denn dort fehlt im event der doppelpunkt nach dem readingnamen:

Code Auswählen Erweitern

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?

[rudolfkoenig]

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

edit: kann ich irgendwo erkennen, ob die "wrapper" gesetzt/wirksam sind?

Wuesste nicht, wie.

[betateilchen]

Das Popcorn-Potenzial dieses Threads wird immer höher...

[frank]

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

Code Auswählen Erweitern

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.

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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.

[rudolfkoenig]

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

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

[frank]

Habe 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:

Code Auswählen Erweitern

  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;
  }


[frank]

hallo rudi,

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

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:

Code Auswählen Erweitern

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



und noch ein zweiter wunsch:
in AssignIoPort gibt es auch den fall, dass kein io zugewiesen wird:

Code Auswählen Erweitern

    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"?

[rudolfkoenig]

Code Auswählen Erweitern

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

Habs so eingecheckt.

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

Habs so eingecheckt.

danke.

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

[rudolfkoenig]

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.

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]

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.

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:

Code Auswählen Erweitern

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.

Code Auswählen Erweitern

{DoTrigger("Wetter.Sued", "IODev: ")}

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

[Beta-User]

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

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

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.

[rudolfkoenig]

offensichtlich wird hier das leerzeichen am ende des cmd "wegoptimiert"

Nicht nur da, auch am Anfang. Beides habe ich nicht wegen mir eingebaut

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