Neues Modul InfluxDBLogger

Begonnen von timmib, 07 Oktober 2020, 23:31:09

Vorheriges Thema - Nächstes Thema

m-d-ley

Hallo, ich habe ein Problem Tags zu erstellen.

Und zwar möchte ich aus dem zu loggendem Device mehrere ReadingsVal in mehrere Tas unterbringen.
Sämtliche Versuche daran schlugen bis jetzt fehl.
Derzeit sieht das Attribute so aus:
name=$DEVICE,{"unit=".ReadingsVal("$device", "unit", 0),"serial=".ReadingsVal("$device", "serial", 0) }

Allerdings werden nur die Tags für name und serial geschrieben. Das Tag unit wird ignoriert. Drehe ich das Attribute allerdings, sodass erst serial und dann unit geplottet werden soll :

name=$DEVICE,{"serial=".ReadingsVal("$device", "serial", 0), "unit=".ReadingsVal("$device", "unit", 0) }

wird nur unit als Tag angelegt. Wo liegt hier der Fehler?

Danke schonmal.

rob

Hallo.

Vielleicht meldet sich noch wer, der sich mit den tags besser auskennt als ich. Möchte Dich aber auch nicht hängen lassen :)

Nach meinem Verständnis sollte das so klappen:

attr yourInfluxDBlogger tags name=$DEVICE,serial={ReadingsVal($device, "serial", 0)},unit={ReadingsVal($device, "unit", "")}

Legt hoffentlich die drei tags an: name, serial und unit. Setzt natürlich voraus, dass serial und unit jeweils in den anliefernden Devices als Reading vorhanden sind. Wenn nicht, wird bei serial "0" gesetzt und bei unit nichts (->"").
Magst Du das kurzerhand testen?

m-d-ley

Hi,
leider kommt dor ein Bad reqest  bei raus.
Eigentlich sollte die doch eine normale Anforderung an das Modul sein oder?

rob

Zumindest ist es in der Doku zum Modul als solche aufgeführt  :-\
Wie genau schaut denn Deine Definition des Influxloggers aus? Und könntest Du bitte auch die Fehlermeldung/ LOG-Meldung posten? Aktuell kann ich mir kein konkretes Bild machen. Vielleicht lässt sich mehr erkennen.

rob

mmmh, ich war jetzt mal neugierig und habe in docker fhem, influx und grafana testweise hochgefahren. Die tags so wie oben definiert: klappt wunderbar. Mit Einschränkungen.

das klappt:
attr myTestInflux tags mytag1=$DEVICE,mytag2=prima,mytag3=supa

das klappt bedingt:
attr myTestInflux tags mytag1=$DEVICE,mytag2=$READINGNAME,mytag3=supa weil $READINGNAME nicht aufgelöst wird, es wird "$READINGNAME" als tag in Grafana sichtbar
Ich habe die Hinweise aus der cref so verstanden, dass die Variable aufgelöst werden sollte.

das klappt:
attr myTestInflux tags mytag1=$DEVICE,mytag2={ReadingsVal($device,"quarks",0)},mytag3=supa

das klappt nicht:
attr myTestInflux tags mytag1=$DEVICE,mytag2={ReadingsVal($device,"quarks",0)},mytag3={ReadingsVal($device,"neutrons",0)}
Es kommt eine Fehlermeldung:
2022.01.20 10:25:50.542 1: InfluxDBLogger: [myTestInflux] Error = unable to parse 'quarks,mytag1=mydummy,mytag2= value=7': missing tag value

Habe mehrere Kombinationen versucht. Es scheint, als würde das Parsing immer dann funktionieren, solange nur ein Perl-Ausdruck enthalten ist. Sind es mehr, wird geschimpft.
Habe ich da einen Denkfehler?




meine Test-Devices:
dummy

define mydummy dummy
attr mydummy readingList value quarks neutrons electrons
attr mydummy setList value quarks neutrons electrons

setstate mydummy value 1
setstate mydummy 2022-01-20 10:29:45 electrons 5
setstate mydummy 2022-01-20 10:12:03 neutrons 3
setstate mydummy 2022-01-20 10:29:48 quarks 7
setstate mydummy 2022-01-20 09:42:13 value 2


influx

define myTestInflux InfluxDBLogger http://myinfluxdb:8086 fhem_db mydummy
attr myTestInflux api v1
attr myTestInflux tags mytag1=$DEVICE,mytag2={ReadingsVal($device,"quarks",0)},mytag3={ReadingsVal($device,"neutrons",0)},mytag3={ReadingsVal($device,"electrons",0)}

setstate myTestInflux Statistics: t=14 s=10 f=4 e=14
setstate myTestInflux 2022-01-20 10:11:21 dropped_writes 0
setstate myTestInflux 2022-01-20 10:11:21 dropped_writes_last_message <none>
setstate myTestInflux 2022-01-20 10:29:48 failed_writes 4
setstate myTestInflux 2022-01-20 10:29:48 failed_writes_last_error unable to parse 'quarks,mytag1=mydummy,mytag2= value=7': missing tag value
setstate myTestInflux 2022-01-20 10:29:48 state Statistics: t=14 s=10 f=4 e=14
setstate myTestInflux 2022-01-20 10:23:46 succeeded_writes 10
setstate myTestInflux 2022-01-20 10:29:48 total_events 14
setstate myTestInflux 2022-01-20 10:29:48 total_writes 14



m-d-ley

Ich habe den Fehler gefunden:

Sobald man sich im Perlmodus befindet muss man auch dort bleiben.

{"device=$device,serial=" .ReadingsVal("$device", "serial", 0).",unit=" .ReadingsVal("$device", "unit", 0).",scalefactor=" .ReadingsVal("$device", "scalefactor", 0).",value_unscaled=" .ReadingsVal("$device", "value_unscaled", 0).",name=" .ReadingsVal("$device", "name", 0)}

So passt es.

rob

Naja, Du setzt dadurch alles in Perl zu einem String zusammen. OK. Und glücklicherweise wird dies akzeptiert/ aufgelöst. Sehe ich mehr als Workaround an. Lass mich aber gern vom Gegenteil überzeugen  ;)

Die cref lese ich jedenfalls so, dass das nicht nötig sein sollte. Insbesondere wird ja ein Beispiel entspr. gezeigt.
Zitat
tags attr <name> tags <x,y>
Dies ist the Liste der tags die an InfluxDB mitgesendet werden. Das Schlüsselwort $DEVICE wird ersetzt durch den Gerätenamen. Wenn dieses Attribut gesetzt ist wird das Attribut deviceTagName nicht berücksichtigt. Standard ist site_name=$DEVICE. Um keine Tags zu schreiben (insbesondere, weil measurement auf $DEVICE und fields auf $READINGNAME=$READINGVALUE steht) bitte ein "-" eintragen. Es können Perl-Ausdrücke in geschweiften Klammern verwendet werden um z.B. Attribute als tag zu nutzen. $name, $device, $reading, $value stehen dabei als Variable zur Verfügung. attr influx tags device={AttrVal($device, "alias", "fallback")}

msome

#187
Hi, ich bin seit kurzem dabei bestimmte Daten statt in MySQL in die Influx DB zu senden.
Mit ein paar InfluxLogger Devices funktioniert das auch schon ganz schön, aber ich habe ständig dropped_writes .

Nachdem ich mich gerade ein bisserl im Code umgesehen habe, scheint das Problem darin zu liegen,
dass non-numeric values in InfluxDBLogger_BuildData explizit als "incompatible" verworfen werden. It's not a bug, it's a feature.

Leider habe ich aber halt Readings in Textform die ich auch gerne mit in der Influx DB hätte um nicht 90% Readings in Influx + 10% in MySQL haben zu müssen.
Kann sich jemand erinnern warum diese Beschränkung im Code eingebaut wurde?
FHEM auf ODROID-C4 & FHEM auf Raspberry 3B+
IO: HMUARTLGW (wired), Velux KLF200, DuoFernStick, DeConz, HMUSB-2, JeeLink, ModBus, RS232, WiFi,
Geräte: so ziemlich alles was es an Geräten von HM gibt, PCA301, SDM630M, Hue Lampen & Steckdosen

meier81

Hallo msome,

das ist ganz einfach, soweit ich mich erinnere kann influxdb nur zahlen loggen, keinen String, etc.

Es gibt die Möglichkeit das du mit dem Attribut "conversions" arbeitest, da kannst du "Ersetzungen" machen, hier mal eine von mir:

closed=0,open=1,tilted=2,false|off|no=0,true|on|yes=1

Somit wandle ich z.B. "yes" oder "true" in 1 um, "no" oder "false" in "0" und für meine Fenster mache ich halt "0,1,2".

Anders wäre mir nicht bekannt das hier was geht, das ist halt der "einzige" Nachteil von influxdb. Da aber für mich die Vorteile überwiegen (einfacher konfigurierbar in Grafana, DB-Größe ist um ein vielfacher kleiner, etc.) gehe ich diesen "Verlust" gerne ein.

Gruß Markus
QNAP NAS mit Debian VM, darauf FHEM, debmatic, influxdb2 und Grafana || HB-RF-ETH || SIGNALduino 433MHz mit Maple mini || WS980 Wetterstation || Xiaomi Mi Robot mit valetudo-FW || Buderus web KM100 || div. Tasmota-Devices

msome

#189
Hi,

dann war das wohl früher mal so.  Aktuell scheint es zu funktionieren.

influx
use Zzz_test
insert testStrings,site_name=daham value="test test test"


Dann werd ich wohl mal versuchen müssen die Limitierung auszubauen...
FHEM auf ODROID-C4 & FHEM auf Raspberry 3B+
IO: HMUARTLGW (wired), Velux KLF200, DuoFernStick, DeConz, HMUSB-2, JeeLink, ModBus, RS232, WiFi,
Geräte: so ziemlich alles was es an Geräten von HM gibt, PCA301, SDM630M, Hue Lampen & Steckdosen

Weisswurstverkäufer

Hallo,

kann es sein dass das Modul beim erzeugen der Einträge in InfluxDB nicht den Zeitpunkt des Readings in FHEM nutzt sondern einfach den aktuellen Timestamp?

Das scheint teilweise zu Problemen zu führen wenn Readings nicht nur auftauchen wenn sie entstehen sondern auch mal zeitversetzt. Bei mir ist das z. B. der Fall bei Netatmo. Da werden manchmal pro Update mehrere Readings geladen. In FHEM sind die dann mit ihrem korrektem Timestamp. In der InfluxDB landen sie aber alle zu einem Zeitpunkt. Das ist irgendwie ein bisschen blöd - Netatmo ist zwischendurch auch gerne mal nicht erreichbar und es kommen dann Daten für 1-2 Stunden auf einmal in FHEM an und dadurch so blöd in die InfluxDB.

Könnte das vielleicht noch irgendwie verbessert werden?

timmib

Hi,

ja das ist richtig die Uhrzeit wird nicht mitgegeben. Die Schnittstelle gäbe es aber her.

Bei mir nutze ich einen lokalen NTP Server um alle Systemzeiten gleich zu halten auf allen Systemen. Deswegen hätte es bei mir so gut wie keinen Effekt.

Nutzt du lokal NTP für FHEM und Influx?

Weisswurstverkäufer

Zitat von: timmib am 03 Februar 2022, 18:24:02
Hi,

ja das ist richtig die Uhrzeit wird nicht mitgegeben. Die Schnittstelle gäbe es aber her.

Bei mir nutze ich einen lokalen NTP Server um alle Systemzeiten gleich zu halten auf allen Systemen. Deswegen hätte es bei mir so gut wie keinen Effekt.

Nutzt du lokal NTP für FHEM und Influx?

Ich vermute ich habe das falsch ausgedrückt. Die Netatmo Station schickt die Werte ins Internet. Das Modul holt sie alle 15 Minuten oder so ab. Teilweise liegen dann aber mehrere Messwerte bereit. Das Netatmo FHEM Modul scheint die Readings aber mit dem korrekten (= von Netatmo abgerufenen) timestamp zu setzen.

Beispiel: ich hatte letztens einen Tag kein Internet. Die Netatmo Station hat aber alle Werte gespeichert und als Internet wieder da war hochgeladen. FHEM hat die Werte dann abgerufen und die Readings erzeugt. Im dblog ist auch alles richtig, in der influxdb sind aber alle Messwerte von dem Tag zur gleichen Sekunde angekommen.

timmib

Ah, jetzt ja, verstehe.

Ja macht Sinn. Baue ich die Tage gerne ein.

timmib

#194
Ich hab mir das grad mal angeschaut und festgestellt, das es doch ein etwas größere Sache ist.

Das Problem ist, dass das Modul bei einem Notify eine Zusammenfassung aller events in einen POST request zusammenfasst und darin alle readings, die zum gleichen measurement(default ist reading) und tagset(default ist site_name=DEVICE) in eine Zeile packt.
Das measurement kann dabei alles sein, DEVICE, READING, oder sogar das Ergebnis eines PERL Ausdrucks.

Das Problem ist nun, von welchem Reading schreibe ich nun den TimeStamp?
Es bleibt also in dem Falle, wo der Zeitstempel vom Reading genommen werden soll nichts anderes übrig als dann nicht Zeilen zusammenzufassen.

Hinzu kommt, das laut https://wiki.fhem.de/wiki/DevelopmentModuleAPI#readingsBulkUpdate es für ein Modul garnicht so einfach möglich ist den Timestamp eines Readings zu manipulieren.

Kannst Du mir den Modulnamen/Quelle mal schicken? Dann guck ich da mal in den Code rein.