Neue Events in MQTT2_DEVICE nach FHEM-Neustart (trotz event-on-change-reading)

[FunkOdyssey]

Ich verstehe es nicht. Ich habe ein MQTT2-DEVICE, in dem ich event-on-change-reading .* gesetzt habe und dennoch direkt nach einem FHEM-Neustart die Readings neu erscheinen und auch im FileLog geschrieben werden. Es gibt aber keine Werte/Leerwerte, die zwischendurch enthalten waren.

Code Auswählen Erweitern

Attributes:
   IODev      m2s
   event-on-change-reading .*
   readingList THERME:BSB/6800:.* History01_DateTime
THERME:BSB/6805:.* History01_Code


Dies tritt nur bei diesem einem Device auf. Andere MQTT2_DEVICES haben dies nicht.

Hat jemand einen Tipp, wie ich die Ursache finden kann?

[FunkOdyssey]

Mir ist nicht bekannt, ob die folgende Vorgehensweise überhaupt bei Events (event-on-change-reading) eine Rolle spielen kann, aber ich habe die Readings testweise per oldreadings-Attribut festgehalten und über die userreadings sichtbar gemacht.
Es sind absolut identische Inhalte. Keine Leerzeichen. Nichts.

Ich frage mich, warum die neu getriggert werden, wenn es doch keine Unterschiede gibt.

[rudolfkoenig]

Wie schauen die Readings aus?
Wann genau "direkt nach FHEM-Neustart" erscheinen sie neu?
Evtl. hilft es, wenn in fhem.pl Zeile 6213 die Log Anweisung einkommentiert, und FHEM mit "attr global verbose 5" neu startet.

[FunkOdyssey]

Ich verstehe das nicht.
In der Zeile https://svn.fhem.de/trac/browser/trunk/fhem/fhem.pl#L6213 steht doch nur die 1.

[rudolfkoenig]

Sorry, habe auf die falsche Zahl geschaut. Ich meinte 4897

[FunkOdyssey]

Ich habe deinen Tipp befolgt.
Zuerst dachte ich, dass dewpoint irgendetwas damit zu tun hat. Denn das Log war voll mit dewpoint-notifies. Das Device habe ich aber sowieso gelöscht, weil ich es nicht benötige.

Ich habe das Beispiel hier im Thread mal auf ein Reading (History01_DateTime) begrenzt.

Die Log-Ausgabe beinhaltete zwar viel wie z.B. die normalen setstate-Zeilen. Aber zu diesem Zeitpunkt wurde das Log mit den Events neu geschrieben.

Code Auswählen Erweitern

2020.11.10 17:33:19.737 4:   m2s_192.168.0.201_52172 BSB-LAN PUBLISH BSB/6800: 05.03.2020 06:20:00
2020.11.10 17:33:19.738 5: m2s: dispatch autocreate=simple\000BSB_LAN\000BSB/6800\000 05.03.2020 06:20:00
2020.11.10 17:33:19.739 4: MQTT2_DEVICE_Parse: THERME BSB/6800 => History01_DateTime
2020.11.10 17:33:19.739 1: EOCR:1 EOUR: CHANGED:1
2020.11.10 17:33:19.739 1: EOCR:1 EOUR: CHANGED:
2020.11.10 17:33:19.740 1: EOCR:1 EOUR: CHANGED:
2020.11.10 17:33:19.743 5: Starting notify loop for THERME, 1 event(s), first is History01_DateTime:  05.03.2020 06:20:00
2020.11.10 17:33:19.744 1: EOCR:1 EOUR: CHANGED:1
2020.11.10 17:33:19.745 1: EOCR:1 EOUR: CHANGED:


Auch mit autocreate = 0 passiert das gleiche.

[rudolfkoenig]

Die Meldung kommt als " 05.03.2020 06:20:01" rein, man achte auf das Leerzeichen vorne.

Beim Wiedereinlesen der gespeicherten Werte beim FHEM Neustart gehen Leerzeichen vor dem Wert verloren, der Vergleich beim eocr funktioniert beim ersten mal nach dem Neustart deswegen nicht.

[FunkOdyssey]

Danke, Rudi, fürs Prüfen.
Ich habe versucht auf so etwas zu achten.
Aber direkt in FHEM bzw. in den Readings konnte ich es nicht erkennen.
Man muss die Debug-Ausgabe auch erst einmal verstehen, um es zu erkennen.
Schön, dass du bei so etwas mithilfst.
Ich habe es an den Entwickler weitergegeben.