Neues Modul InfluxDBLogger

[gvzdus]

Moin,
ich wollte meinen Senf zum "defaultMinInterval" geben:
Warum soll das in das InfluxDB-Modul rein? Besser ist doch, das Problem an der Quelle zu lösen.
Zur Datenreduktion bietet sich an:

• event-on-change-reading, siehe https://wiki.fhem.de/wiki/Event-on-change-reading
• event-aggregator

Gerade bei Werten wie "power" kommt es doch auf gescheite Mittelwert-Bildung an!

Es ist m.E. nicht hilfreich, wenn es in FHEM eine weitere Möglichkeit gibt, ein Problem spezifisch zu lösen, wenn es schon eine existierende, universelle Möglichkeit gibt.

[meier81]

Hallo,

kann dein Argument verstehen, hatte es ja nur als Vorschlag gebracht da es dies auch im DBLog Modul gibt. Verstehe aber deine Argumentation, event-on-change habe ich sitzen bei mir, bringt hier leider nicht viel da sich der Wert halt alle paar Sekunden ein wenig ändert.

Den event-aggregator muss ich zu meiner Schande gestehen kannte ich noch nicht, werde das aber auf jeden Fall probieren heute Abend. Denke aber das Problem ist damit zu lösen und von daher keine Erweiterung hier nötig.

Was ich allerdings super fände wenn man wie ich oben schon geschrieben habe mit einem Set-Befehl die Möglichkeit hat Readings in influx zu schreiben. Dann funktioniert das wie bisher event getriggert oder ich kann es zusätzlich per Set triggern.

Gruß Markus

[kadettilac89]

Hallo,

kann dein Argument verstehen, hatte es ja nur als Vorschlag gebracht da es dies auch im DBLog Modul gibt. Verstehe aber deine Argumentation, event-on-change habe ich sitzen bei mir, bringt hier leider nicht viel da sich der Wert halt alle paar Sekunden ein wenig ändert.

Den event-aggregator muss ich zu meiner Schande gestehen kannte ich noch nicht, werde das aber auf jeden Fall probieren heute Abend. Denke aber das Problem ist damit zu lösen und von daher keine Erweiterung hier nötig.

Was ich allerdings super fände wenn man wie ich oben schon geschrieben habe mit einem Set-Befehl die Möglichkeit hat Readings in influx zu schreiben. Dann funktioniert das wie bisher event getriggert oder ich kann es zusätzlich per Set triggern.

Gruß Markus

event-on-change reading hat einen Threshold, nur wenn der neue Wert weiter abweicht als Threshold wird ein Event erzeugt.

Das glätten der Werte kannst ggf. auch per User Reading machen. Je nach anforderung und dann nur das loggen was im Userreadings ist

set Befehl zum schreiben? Hast du mal den fhem Befehl "trigger" getestet? Damit erzeugst du ein Event. Addlog Routine macht das selbe (s. Wiki).

[timmib]

Was ich allerdings super fände wenn man wie ich oben schon geschrieben habe mit einem Set-Befehl die Möglichkeit hat Readings in influx zu schreiben. Dann funktioniert das wie bisher event getriggert oder ich kann es zusätzlich per Set triggern.

Hi Markus,

wie oben geschrieben, habe ich noch nicht so recht verstanden wie das funktionieren soll. Dafür müsste ja der Logger anhand der DevSpec alle Geräte durchgehen und alle Readings auswerten. Ist es nicht einfacher zeitgesteuert ein

Code Auswählen Erweitern

get auf die Betroffenen Geräte/Readings zu machen um so die Events auszulösen?

Viele Grüße

Tim

[gromeck]

Hallo,

erstmal danke für dieses Modul -- das geht ja schon mal in die richtige Richtung 

Ich habe festgestellt, dass UserReadings offenbar nicht an die InfluxDB übertragen werden.

Use Case: mein PV-Inverter ist vom Modul-Typ KOSTALPICO und liefert in den Readings u.a. Current und Voltage. Ich berechne daraus die Energie in einem Trigger und lege die dann als UserReading ab. Und genau diese werden nicht an die InfluxDB geschickt.

Ich habe auch readingsInclude ausprobiert. Diese sorgen aber auch nicht dafür, dass UserReadings erfasst werden, ist aber auch klar, denn ist ist ja eher eine WhiteList

[timmib]

Siehst Du für die Userreadings Events?

[Omega]

Auch von mir erst einmal ein dickes Dankeschön für dein Modul - SUPER.

Zum Them "set...".
Aus 99_myUtils heraus verwende ich u.a. folgende Anweisung: fhem "setreading E3DC_Control fc1_Prognose $fc1_Prognose";
Diese so geschriebenen Readings werden dann in der InfluxDB gespeichert. Das ist doch eigentlich das gewünschte Verhalten.

LG
Holger

Nachtrag:
userreadings werden auch geschrieben (zumindest bei folgender Definition):

Code Auswählen Erweitern

attr E3DC_Control userReadings lastUpdate {ReadingsVal("Wetter_Wennigsen","obsTime",0)}


Dabei fällt mir folgendes gerade auf: obsTime hat den Wert 11:00, in der InfluxDB kommt aber nur 11 an (da ja nur Zahlen akzeptiert werden). Hat einer eine Idee, wie ich den Minutenanteil (ohne über 99_myUtils gehen zu müssen) in eine Dezimalzahl umgewandelt bekomme?

[kadettilac89]

Dabei fällt mir folgendes gerade auf: obsTime hat den Wert 11:00, in der InfluxDB kommt aber nur 11 an (da ja nur Zahlen akzeptiert werden). Hat einer eine Idee, wie ich den Minutenanteil (ohne über 99_myUtils gehen zu müssen) in eine Dezimalzahl umgewandelt bekomme?

https://wiki.fhem.de/wiki/Zeitangaben,_rechnen_mit

time_str2num("YYYY-MM-DD HH:MM:SS") wandelt einen FHEM-Zeitstempel in Sekunden um [2] ... teste mal format ("HH:MM"), Sunden dann noch durch 3600 ... ansonsten, 99_myutils und einzelne Variablen für HH, MM ... und dann wieder zusammen bauen ...

[Omega]

Und schon kommt meine nächste Frage ... 

Aus 99_myUtils heraus schreibe ich hintereinander weg 9 Readings per setreading.
Die InfluxDB, mit der ich teste, ist folgendermaßen definiert:

Code Auswählen Erweitern

Internals:
   CFGFN     
   DATABASE   E3DC_Control
   DEF        http://192.168.33.181:8086 E3DC_Control E3DC_Control
   FUUID      5fd713fe-f33f-bbf3-de66-d8a750a96501d62a
   NAME       influxDB.E3DC_Control
   NOTIFYDEV  E3DC_Control
   NR         275341
   NTFY_ORDER 50-influxDB.E3DC_Control
   STATE      Statistics: t=66 s=61 f=2
   TYPE       InfluxDBLogger
   URL        http://192.168.33.181:8086
   READINGS:
     2020-12-14 08:45:03   failed_writes   2
     2020-12-14 08:45:03   failed_writes_last_error database not found: "E3DC_Control"
     2020-12-14 15:45:03   state           Statistics: t=66 s=61 f=2
     2020-12-14 15:45:03   succeeded_writes 61
     2020-12-14 15:45:03   total_writes    66
Attributes:
   DbLogExclude .*
   fields     $READINGNAME=$READINGVALUE
   measurement $DEVICE
   room       Server
   tags       -

Schaue ich in die DB (s. Hardcopy), sehe ich, dass jedes Reading einzeln gespeichert wird. Kann ich das irgendwie zusammenfassen zu einer einzigen DB-Zeile? Und falls ja, wie?

[Omega]

@kadettilac89: Danke für den Tip - schaue ich mir an

[gromeck]

Siehst Du für die Userreadings Events?

Nein, und ich habe keine Ahnung warum.
Ich habe alle Readings in dem Device mit event-on-change-reading versehen und beim Setzen des userReadings mit readingsSingleUpdate() ist das Flag für die Events gesetzt.
Im UserReading kommt der gesetzte/berechnete Wert korrekt an, aber es wird eben kein Event ausgelöst :-/

[kadettilac89]

Schaue ich in die DB (s. Hardcopy), sehe ich, dass jedes Reading einzeln gespeichert wird. Kann ich das irgendwie zusammenfassen zu einer einzigen DB-Zeile? Und falls ja, wie?

Möglichkeit ... to be tested ...

https://wiki.fhem.de/wiki/DevelopmentModuleIntro#Readings
Schlagwort .... readingsBulkUpdate ... damit werden die Readings in einem Aufwasch gesetzt. Dadurch sollte der Timestamp auch identisch sein ...

hash müsstest so in etwa bekommen (Referenz auf das entsprechende Device)
https://www.ethersex.de/index.php/Nutzung_in_FHEM_(Deutsch)#DHT22_Temperatur-.2FFeuchtesensoren

Ungetestet, musst ggf. etwas im Forum suchen.

[kadettilac89]

Nein, und ich habe keine Ahnung warum.
Ich habe alle Readings in dem Device mit event-on-change-reading versehen und beim Setzen des userReadings mit readingsSingleUpdate() ist das Flag für die Events gesetzt.
Im UserReading kommt der gesetzte/berechnete Wert korrekt an, aber es wird eben kein Event ausgelöst :-/

Ist der gesetzte Wert unterschiedlich zum vorherigen? Teste mal ohne event-on-change reading oder andere Filter ob dann das Event im Event-Monitor auftaucht

[timmib]

Hallo,

ich habe ein große Bitte/Vorschlag an euch.

Lass uns diesen Thread hier beenden und für die verschiedenen Themen jeweils einen eigenen Thread machen. Ich verliere heir sonst total die Übersicht, wenn alles durcheinander geht.

Das Modul ist ja nun auch in SVN drin und somit ist die "Beta-Phase" quasi feierlich beendet. Jetzt beginnt der normale Support und die Weiterentwicklung.

Viele Grüße

Tim

[gvzdus]

Komm', wir machen eben noch den Omega fertisch :

@Omega:
Bei mir stehen sie sauber als Tupel mit gleicher Zeit in der DB. Und ja, bei mir geht es auch um Solar-Gedöns:

Definition meines at-Jobs, der dann auch via InfluxDB loggt:

Code Auswählen Erweitern


+*00:05:00 {
my $power5min = $defs{"power5min"};
my $whneu=ReadingsVal("MT175","total_consumption","--");
my $whalt=ReadingsVal("power5min","kwh","--");
my $watt=sprintf("%.1f", ($whneu-$whalt)*12);
my $fwhneu=ReadingsVal("MT175","total_feed","--");
my $fwhalt=ReadingsVal("power5min","kwhfeed","--");
my $fwatt=sprintf("%.1f", ($fwhneu-$fwhalt)*12);
readingsBeginUpdate($power5min);
readingsBulkUpdate($power5min, "kwh", $whneu);
readingsBulkUpdate($power5min, "watt", $watt);
readingsBulkUpdate($power5min, "kwhfeed", $fwhneu);
readingsBulkUpdate($power5min, "wattfeed", $fwatt);
readingsEndUpdate($power5min, 1);
}