DbLog - Frage zu "state" und Readings

[SusisStrolch]

Beispiel:

Ein Device (ESPEasy) zeigt mir in "state" den Wert "hum: 46.80 pre: 1011.67 tem: 21.88".
In der Datenbank sehe ich dann die folgenden Werte:
EVENT     "hum: 46.80 pre: 1011.67 tem: 21.88"
READING "hum"
VALUE     "46.80 pre: 1011.67 tem: 21.88"

Ich hätte eigentlich erwartet, hier ein Reading namens "state" zu finden.
Ist dies ein Problem von DbLog oder eher eines der Device-Implementierung?

[JoeALLb]

Hallo,

das liegt daran, weil das Modul die Splitfunktion für dbLog nicht nutzt, und dbLog daher raten muss,
wie es den Text aufspalten soll.

Du könntest den Modul-Maintainer diesbezüglich anschreiben.
Als Workaround kannst Du die Aufspaltung selbst über dbLog-valueFn vornehmen und "korrigieren".

[SusisStrolch]

Danke. Da werde ich doch mal an der richtigen Stelle nachfragen.

[dev0]

das liegt daran, weil das Modul die Splitfunktion für dbLog nicht nutzt

Da machst Du es Dir mMn etwas zu einfach. Die Erkennung, ob es sich bei dem Event um das Reading state handelt, müßte schon vorher in DBLog vorgenommen werden und nicht erst in einer Modul DbLog_splitFn. In DbLog_splitFn ist es mWn nicht mehr feststellbar, ob es sich bei den übergebenen Werten um das Reading state handelt.
FileLog, Notify, DOIF und andere Module, die Events anderer Module verarbeiten, lösen das über das addStateEvent Attribut.

[DS_Starter]

Guten Morgen miteinander,

es gibt im DbLog schon von jeher eine Erkennung ob es sich um ein state-Event handelt. Es handelt sich dabei aber um eine relativ einfache Splitfunktion des Events über den Separator ":" den es ja üblicherweise in einem state-Event nicht gibt.
In dem Beispiel des Events "hum: 46.80 pre: 1011.67 tem: 21.88" wird nach "hum" gesplittet und demzufolge "hum" als Reading identifiziert usw.

JoAllb hat insofern recht dass wir dahingehend einwirken wollen, dass diese Modul-spezifische Splitfunktion nach und nach aus dem DbLog verschwindet und in den jeweiligen Modulen ausgeführt wird. Dazu wird im DbLog in der Sub "DbLog_ParseEvent" als allererstes ein Aufruf der  "DbLog_splitFn" durchgeführt sofern das Device/Modul eine solche Funktion enthält. Sie ist im Wiki hier https://wiki.fhem.de/wiki/DevelopmentModuleIntro#X_DbLog_split beschrieben.

Nur wenn es diese Funktion nicht gibt, setzt DbLog ein paar Standardsplittings ein. Vorrangig ist aber gewünscht dass die Modulautoren ihre Splittings selbst pflegen weil es einfach genauer und präziser erfolgen kann.

Wie Joe schon geschrieben hat, kann der Nutzer darüber hinaus mit dem Attribut valueFn eigene Anpassungen vornehmen.

LG
Heiko

[dev0]

Mir wird immer noch nicht klar, warum dbLog nicht selbst als erstes die Funktion deviceEvents() aufruft, um das Reading state zum Event hinzuzufügen. Es macht doch keinen Sinn es bei state nicht zu tun, denn sonst tritt dieser Effekt doch bei allen Modulen auf, die die DbLog_splitFn nicht verwenden.
Das eigentliche Problem ist doch, dass bei state Events das Reading state nicht mit im Event enthalten ist.

Oder was übersehe ich?

[DS_Starter]

Mir wird immer noch nicht klar, warum dbLog nicht selbst als erstes die Funktion deviceEvents() aufruft...

Doch, wird gemacht, allerdings noch mit dem Flag "0". Bei dem Einbau des asynchronen Mode Ende letztes Jahr sollte nicht gleich das ganze Modul umgekrempelt werden. Aber das ist dann im Zuge der Weiterentwicklung mehr oder weniger doch passiert.

Ich schaue mal was eventuell noch im Modul anzupassen ist wenn ich den Flag auf "1" ändere.
Die Version zum Test stelle ich dann wieder im Thread https://forum.fhem.de/index.php/topic,65860.0.html bereit, mal schauen ....

LG
Heiko

[DS_Starter]

Guten Morgen,

hier https://forum.fhem.de/index.php/topic,65860.msg659971.html#msg659971 gibt es die Testversion V2.20.0 zu diesem Thema.

VG
Heiko

[ws]

Hallo,

mit der Änderung

Code Auswählen Erweitern

my $events = deviceEvents($dev_hash,1);

werden bei mir Readings, die vom Modul dewpoint erzeugt werden, nicht mehr geloggt

Kann das jemand bestätigen?

[DS_Starter]

Hallo ws,

da ich dewpoint nicht habe, kann ich die Frage nicht direkt beantworten.
Aber setze dir bitte im DbLog verbose 4 oder 5.
Dann siehst du Ausgaben der Art:

Code Auswählen Erweitern


2017.07.25 09:00:31.521 4: DbLog LogDB -> ################################################################
2017.07.25 09:00:31.523 4: DbLog LogDB -> ###              start of new Logcycle                       ###
2017.07.25 09:00:31.525 4: DbLog LogDB -> ################################################################
2017.07.25 09:00:31.527 4: DbLog LogDB -> amount of events received: 10 for device: SMA_Energymeter
2017.07.25 09:00:31.530 4: DbLog LogDB -> check Device: SMA_Energymeter , Event: Bezug_WirkP_Zaehler_Diff: 0
2017.07.25 09:00:31.533 4: DbLog LogDB -> added event - Timestamp: 2017-07-25 09:00:31, Device: SMA_Energymeter, Type: SMAEM, Event: Bezug_WirkP_Zaehler_Diff: 0, Reading: Bezug_WirkP_Zaehler_Diff, Value: 0, Unit:
2017.07.25 09:00:31.535 4: DbLog LogDB -> check Device: SMA_Energymeter , Event: Bezug_WirkP_Kosten_Diff: 0.0000
2017.07.25 09:00:31.537 4: DbLog LogDB -> added event - Timestamp: 2017-07-25 09:00:31, Device: SMA_Energymeter, Type: SMAEM, Event: Bezug_WirkP_Kosten_Diff: 0.0000, Reading: Bezug_WirkP_Kosten_Diff, Value: 0.0000, Unit:
2017.07.25 09:00:31.538 4: DbLog LogDB -> check Device: SMA_Energymeter , Event: Einspeisung_WirkP_Zaehler_Diff: 0.0049
2017.07.25 09:00:31.540 4: DbLog LogDB -> added event - Timestamp: 2017-07-25 09:00:31, Device: SMA_Energymeter, Type: SMAEM, Event: Einspeisung_WirkP_Zaehler_Diff: 0.0049, Reading: Einspeisung_WirkP_Zaehler_Diff, Value: 0.0049, Unit:
2017.07.25 09:00:31.543 4: DbLog LogDB -> check Device: SMA_Energymeter , Event: Einspeisung_WirkP_Verguet_Diff: 0.0006
2017.07.25 09:00:31.546 4: DbLog LogDB -> added event - Timestamp: 2017-07-25 09:00:31, Device: SMA_Energymeter, Type: SMAEM, Event: Einspeisung_WirkP_Verguet_Diff: 0.0006, Reading: Einspeisung_WirkP_Verguet_Diff, Value: 0.0006, Unit:
2017.07.25 09:00:31.548 4: DbLog LogDB -> check Device: SMA_Energymeter , Event: state: 318.3
2017.07.25 09:00:31.550 4: DbLog LogDB -> added event - Timestamp: 2017-07-25 09:00:31, Device: SMA_Energymeter, Type: SMAEM, Event: state: 318.3, Reading: state, Value: 318.3, Unit:
2017.07.25 09:00:31.552 4: DbLog LogDB -> check Device: SMA_Energymeter , Event: Saldo_Wirkleistung: 318.3
2017.07.25 09:00:31.554 4: DbLog LogDB -> added event - Timestamp: 2017-07-25 09:00:31, Device: SMA_Energymeter, Type: SMAEM, Event: Saldo_Wirkleistung: 318.3, Reading: Saldo_Wirkleistung, Value: 318.3, Unit: W
2017.07.25 09:00:31.556 4: DbLog LogDB -> check Device: SMA_Energymeter , Event: Bezug_Wirkleistung: 0.0
2017.07.25 09:00:31.558 4: DbLog LogDB -> added event - Timestamp: 2017-07-25 09:00:31, Device: SMA_Energymeter, Type: SMAEM, Event: Bezug_Wirkleistung: 0.0, Reading: Bezug_Wirkleistung, Value: 0.0, Unit: W
2017.07.25 09:00:31.559 4: DbLog LogDB -> check Device: SMA_Energymeter , Event: Bezug_Wirkleistung_Zaehler: 2703.1122
2017.07.25 09:00:31.562 4: DbLog LogDB -> added event - Timestamp: 2017-07-25 09:00:31, Device: SMA_Energymeter, Type: SMAEM, Event: Bezug_Wirkleistung_Zaehler: 2703.1122, Reading: Bezug_Wirkleistung_Zaehler, Value: 2703.1122, Unit: kWh
2017.07.25 09:00:31.564 4: DbLog LogDB -> check Device: SMA_Energymeter , Event: Einspeisung_Wirkleistung: 318.3
2017.07.25 09:00:31.566 4: DbLog LogDB -> added event - Timestamp: 2017-07-25 09:00:31, Device: SMA_Energymeter, Type: SMAEM, Event: Einspeisung_Wirkleistung: 318.3, Reading: Einspeisung_Wirkleistung, Value: 318.3, Unit: W
2017.07.25 09:00:31.567 4: DbLog LogDB -> check Device: SMA_Energymeter , Event: Einspeisung_Wirkleistung_Zaehler: 4276.1754
2017.07.25 09:00:31.569 4: DbLog LogDB -> added event - Timestamp: 2017-07-25 09:00:31, Device: SMA_Energymeter, Type: SMAEM, Event: Einspeisung_Wirkleistung_Zaehler: 4276.1754,


Die Einträge "Check Device..." sind zunächst interessant. Dort sollte dein dewpoint Devive auftauchen sobald es Events erzeugt.

Ändert sich das Verhalten denn wenn du dieses Flag wieder auf "0" setzt ? Ich kann mir momentan schwer vorstellen dass das Flag die Ursache sein soll.

VG

[ws]

Hallo,

Das Modul dewpoint schreibt bei vordefinierten Devices ein Reading (...und erzeugt dabei kein Event?)
Mit verbose 4 taucht das/die Device(s) zwar im Log auf, aber nicht mit dem Reading, das vom dewpoint aktualisiert wurde.

Wenn ich das Flag auf "0" setze, bekomme ich sofort wieder Werte von dem o.g. Reading in die DB.
Ich möchte damit nicht behaupten, dass der Fehler bei dblog liegt, aber das Verhalten hängt irgendwie zusammen.

[DS_Starter]

Wenn ich das Flag auf "0" setze, bekomme ich sofort wieder Werte von dem o.g. Reading in die DB.
Ich möchte damit nicht behaupten, dass der Fehler bei dblog liegt, aber das Verhalten hängt irgendwie zusammen.

DbLog bedient sich hier der Standard-API "deviceEvents", die du oben ja schon richtig geschrieben hast. Im DbLog-Modul selbst kann ich diesbezüglich nicht viel tun als ggf. dieses Flag über ein Attribut zu/abschaltbar zu gestalten.
Aber ich würde empfehlen auch noch beim Maintainer des dewpoint-Moduls nachfragen wie er das sieht. Denn m.M. nach sollte sich dewpoint diesbezüglich genauso verhalten wie andere Module.
Und vllt. postest du noch ein Beispiel aus deinem Log.

[dev0]

98_dewpoint.pm benutzt nicht die readings*Update() Funktionen um Readings/Events zu erzeugen, sondern schreibt direkt in den device hash.
Im Wiki ist bereits beschrieben, wie Werte auch ohne das dewpoint Modul berechnet werden können: https://wiki.fhem.de/wiki/Dewpoint

Ist der Maintainer joachim09876 im Forum überhaupt noch aktiv?

[DS_Starter]

Hallo dev0,

ja danke für die Info.
Dann wird es tatsächlich eine gute Idee sein das Flag über ein Attribut schaltbar zu machen.
Da ich allerdings davon ausgehe dass der Modus "Flag=0" nur in Ausnahmefällen benötigt wird, würde ich die Standardfunktionalität mit dem Flag "1" belassen.
Der Nutzer kann dann im Notfall auf den herkömmlichen Modus umschalten.

[dev0]

Klingt gut. Ich denke, dass es auch noch weitere ältere Module gibt, die sich so verhalten.

@ws: Nichtsdestotrotz könntest Du den Maintainer bitten das anzupassen, Jochim scheint alle paar Wochen mal ins Forum zu gucken.

[DS_Starter]

Hallo @ws, @all,

hier https://forum.fhem.de/index.php/topic,65860.msg664337.html#msg664337 habe ich die Testversion mit dem Attribut "addStateEvent" bereitgestellt.

VG
Heiko

[ws]

Hi,

das ging ja mega schnell... 

DS_Starter: die Testversion läuft bei mir seit 20 Minuten.
Mit dem default Wert addStateEvent=1 landen keine Werte, die vom dewpoint erzeugt wurden, in der DB.
Mit der Umstellung auf addStateEvent=0, sehe ich sofort wieder Werte.
Es scheint also zu funktionieren...

dev0: PM an Joachim ist raus...

Danke.

[DS_Starter]

Ok, dann checke ich die V mal ein.

VG,
Heiko