Logging von gesprächigem Device reduzieren

Joker · 14 Januar 2019, 12:30:59

Hi,

ich stelle die Frage mal hier im Anfängerbereich da ich nicht so genau weiß wohin damit...

Und zwar habe ich ein Gerät welches in recht kurzen Intervallen seine Readings aktualisiert (< 30s). Ich möchte die Readings loggen (mit DbLog), allerdings in wesentlich längeren Intervallen (z.B. alle 5min).

Ich habe "addLog" gefunden, wäre das das richtige oder gibt es noch was einfacheres (ähnlich wie z.B. event-min-interval)?

Grüße
Bernd

bartman121 · 14 Januar 2019, 12:43:13

https://wiki.fhem.de/wiki/Event-on-change-reading

Dort findest du hilfreiche Ansätze.

Joker · 14 Januar 2019, 13:01:38

Ich glaube das habe ich schon gelesen, aber das hört sich nicht so an wie das was ich brauche:

Code Auswählen

Update + Min-Interval
    ein Event wird erzeugt, wenn der selbe Wert, der bereits im Reading steht, nochmal reingeschrieben wird und mindestens min-interval Sekunden seit dem letzten Event vergangen sind

Wenn jetzt nach einem Event alle paar Sekunden ein neuer Wert kommt (der immer anders ist als der, der das Event erzeugt hat), dann will ich ja auch nach min-interval Sekunden ein neues Event. Aber nicht bei jedem Wert innerhalb des Zeitraums.
Das würde dann aber laut dieser Beschreibung nicht gehen?

KernSani · 14 Januar 2019, 13:05:09

Du kannst bei event-on-change-reading auch angeben, wie groß der "change" sein muß, um ein event zu erzeugen. Wenn die Werte also nicht völlig zufällig kommen sondern (z.B. bei einem Thermometer) langsam ansteigen oder sinken sollte das helfen.

r00t2 · 14 Januar 2019, 13:19:39

Um welches Gerät handelt es sich überhaupt?

Ein RAW Listing hilft hier ggf. schon weiter, um besser zu verstehen, um was es genau geht.

Joker · 14 Januar 2019, 13:24:42

Zitat von: KernSani am 14 Januar 2019, 13:05:09
Du kannst bei event-on-change-reading auch angeben, wie groß der "change" sein muß, um ein event zu erzeugen. Wenn die Werte also nicht völlig zufällig kommen sondern (z.B. bei einem Thermometer) langsam ansteigen oder sinken sollte das helfen.

Das kannte ich noch nicht. Ich glaube das hilft, ich probiere das mal.

Zitat von: r00t2 am 14 Januar 2019, 13:19:39
Um welches Gerät handelt es sich überhaupt?

Ein RAW Listing hilft hier ggf. schon weiter, um besser zu verstehen, um was es genau geht.

Kann ich heute abend machen, aber ich glaube nicht dass es in dem Fall hilft- das "Gerät" ist in dem Fall ein MQTT_DEVICE, d.h es reagiert auf MQTT-Messages, und das Device welches diese Messages schickt kann man darin natürlich nicht sehen. Es ist eine Wetterstation, d.h. es werden Temperatur, Luftfeuchte etc. übertragen aber auch Regenmenge, Windrichtung, Windstärke etc.

Joker · 15 Januar 2019, 09:53:51

OK, also mit der Angabe des threshold beim event-on-change-reading klappt es soweit, danke für den Tip!
Jetzt kommen die Events in einem zeitlichen Abstand so dass es mir nicht die Datenbank sprengt

Allerdings habe ich noch ein Problem, ich habe jetzt folgendes definiert:

Code Auswählen


attr mqtt_weatherstation DbLogExclude .*
attr mqtt_weatherstation DbLogInclude temperature,humidity_rel,pressure,lux
attr mqtt_weatherstation event-on-change-reading humidity.*:0.5,pressure:0.5,temperature.*:0,5,lux
attr mqtt_weatherstation event-on-update-reading .*

Mein Gedanke dabei: Logge nichts in die Datenbank, außer temperature, humidity_rel, pressure und lux (die Station hat noch jede Menge andere Werte, die ich nicht in der DB haben will).
Durch das event-on-change-reading sollen die angegeben Readings bei Änderung in angegebenen Maß immer ein Event erzeugen (und damit in der DB landen), alle anderen bei jedem Update.

Ist der Gedanke soweit richtig?
Das Problem ist jetzt aktuell, dass temperature und humidity_rel in der Datenbank landen, pressure und lux aber nicht. Die Events dazu sehe ich aber im Event-Monitor. Wo ist da mein Fehler?

OdfFhem · 15 Januar 2019, 11:03:01

Laut https://wiki.fhem.de/wiki/Event-on-update-reading gilt:

Zitat
Ist für ein Reading sowohl event-on-change-reading als auch event-on-update-reading spezifiziert, wird bei jeder Aktualisierung des Readings ein Event erzeugt, das event-on-change wird für dieses Reading also außer Kraft gesetzt bzw. "überstimmt".

Daher ist attr mqtt_weatherstation event-on-update-reading .* wahrscheinlich keine gute Idee ...

Joker · 15 Januar 2019, 11:22:36

Zitat von: OdfFhem am 15 Januar 2019, 11:03:01
Laut https://wiki.fhem.de/wiki/Event-on-update-reading gilt:
Daher ist attr mqtt_weatherstation event-on-update-reading .* wahrscheinlich keine gute Idee ...

Hm, da hast du im Prinzip recht. Allerdings kann ich das überhaupt nicht bestätigen, es kommt mit dieser Konfiguration definitiv nicht bei jeder Aktualisierung ein Event. Ich hatte zunächst nur das event-on-update-reading mit den thresholds angegeben, aber dann kamen für alle anderen Readings gar keine Events mehr. Ist hier auch beschrieben:

ZitatSind bei einem Device weder event-on-update-reading noch event-on-change-reading spezifiziert, werden für alle Readings sowohl bei Aktualisierung (mit dem gleichen Wert) als auch bei der Änderung Events erzeugt. Sobald jedoch eines der beiden Attribute gesetzt ist, müssen alle Readings, die protokolliert werden sollen bei (mindestens) einem der Attribute berücksichtigt sein.

Ich war im Prinzip nur zu faul, jedes Reading einzeln beim event-on-change-reading anzugeben. Kann ich aber machen, falls es notwendig ist.

Aber mein Hauptproblem ist, dass pressure und lux nicht in der Datenbank landen, obwohl ich die Events dafür sehe....

Sany · 15 Januar 2019, 22:25:19

ZitatIch war im Prinzip nur zu faul, jedes Reading einzeln beim event-on-change-reading anzugeben. Kann ich aber machen, falls es notwendig ist.

genau hier liegt das Problem: sobald Du irgend ein event-on-xx Attribut gesetzt hast werden alle Events von readings unterdrückt, die nicht ausdrücklich angegeben sind.
Ich habe meine Sensoren üblicherweise so "gezähmt":(die Werte sind beispielhaft)

Code Auswählen

event-on-change-reading temperature:0.2,humidity,lux:5
event-min-interval temperature:900,humidity:900,lux:900

Das Beispiel bedeutet: Temperaturänderungen > 0.2 Grad, jede humidity-änderung sowie lux-Änderungen > 5 erzeugen einen event.
Bleiben die Werte unverändert oder innerhalb der angegebenen Toleranz so erzeugt jeweils nach Ablauf von 15min der nächste ankommende Wert einen Event.
Die Toleranzen musst Du halt so wählen, dass ausreichend aber eben auch nicht zu viele Events erzeugt werden.
event-on-update-reading braucht es meiner Meinung nach bei solchen Sensoren nicht, eher bei Schaltern o.Ä., obwohl die genauso gefiltert werden können.
event-min-interval steht in der commandref (leider) etwas weiter unten.

Probier mal damit rum, ein offenes Event-Monitor-Fenster mit der passenden Regex

Code Auswählen

SensorName.*(temperature|humidity|lux).* hilft, um die Funktion der Attribute zu checken und zu verstehen.

P.S. Ich nutze kein DbLog, deshalb kann ich zu den von Dir angegebenen Attributen nichts sagen. Wenn ich es aber richtig verstanden habe behandeln die event-on- Attribute die Events, die dann irgendetwas auslösen, z.B. loggen in die Datenbank, so dass die DbLog Attribute quasi "danach" erst greifen...

Viel Erfolg!

Sany

Joker · 17 Januar 2019, 10:19:14

Danke für die Antworten.

Wie gesagt hatte ich die Events ja so gesehen wie ich sie wollte, trotz gesetztem event-on-update-reading .*. Aber in der Datenbank landeten sie nicht. Das konnte ich mittlerweile herausfinden, das lag daran dass ich bei der DbLog Definition auch schon ein Regex angegeben habe für die Werte die gelogged werden sollen und da war das gewünschte nicht drin.

Ich habe jetzt sicherheitshalber alle gewünschten Readings explizit in event-on-update-reading und event-on-change-reading und event-min-interval angegeben. Das tut jetzt soweit!