Neues Modul InfluxDBLogger

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

Vorheriges Thema - Nächstes Thema

Weisswurstverkäufer

Eigentlich egal - der temperature-Wert des Regensensors ist eh Quatsch. Nur blöd dass es dann im Log immer auftaucht. Kann ich das leicht excluden?

Mein aktuelles readingInclude ist:

(temperature:.*|humidity:.*|co2:.*|noise:.*|water:.*|.*open|.*closed|.*motion|.*nomotion|lux:.*|lightlevel:.*|dark:.*|daylight:.*)

timmib

Ja, nimm das Attribut readingExclude.


rob

Bezüglich der Devspec habe ich leider Verständnisprobleme. Ich möchte meine Definition in FHEM gerne generalisieren, damit weitere Devices mit passendem Reading automatisch ins Influx-Logging reinrutschen.
Den Ansatz von kadettilac89 aus Post #161 finde ich elegant und schlüssig:
Zitat von: kadettilac89 am 03 November 2021, 19:03:53
...
Hier mal meine Def. mit etlichen Readings. Ich logge per Readingnamen. z. B. XHR, actuator. Egal wie das Device heißt.

   DEF        influxdb 8086 fhem <<<password>>>  .*:(XHR|actuator|desired-temp|measured-temp|download|upload|ping|presence|pressure|brightness|temperature|humidity|wind_speed|wind_direction|batVoltage|DbFileSize|location_real|light|twilight|twilight_weather|countHistory|door|Super_E5|Diesel|active_zone|box_rateDown_kbit|box_rateUp_kbit|todayR|todayS).*
   FH

...

Adaptiere ich das von meinem expliziten Filter:
defmod myTestInflux InfluxDBLogger http://ip:8086 fhemdb DS18B20.*,WH1080
auf den impliziten Device-Filter analog dem Post:
defmod myTestInflux InfluxDBLogger http://ip:8086 fhemdb .*:(temperature|humidity|absHumidity).*
wird leider nichts mehr geloggt  :-\

In der cref wird auf devspec der cref verwiesen - von dort genannten Varianten habe ich einige auf meiner Testumgebung mit zwei Dummies + InfluxDBLogger versucht auszutüfteln, komme aber leider auf keinen grünen Zweig.
Habt Ihr eine Idee, wo mein Fehler liegen könnte?

Vielen Dank und beste Grüße
rob




meine dummies:

define crashtest1 dummy
attr crashtest1 readingList temperature humidity absHumidity
attr crashtest1 setList temperature humidity absHumidity

define crashtest2 dummy
attr crashtest2 readingList temperature humidity absHumidity
attr crashtest2 setList temperature humidity absHumidity

setstate crashtest1 2022-02-10 08:23:53 absHumidity 3.9
setstate crashtest1 2022-02-10 08:24:31 humidity 41
setstate crashtest1 2022-02-10 08:24:09 temperature -1.1

setstate crashtest2 2022-02-10 08:23:07 absHumidity 7.6
setstate crashtest2 2022-02-10 08:23:17 humidity 38
setstate crashtest2 2022-02-10 08:22:47 temperature 5.1


InfluxDBLogger - der klappt:
defmod myTestInflux InfluxDBLogger http://myinfluxdb:8086 fhem_db crashtest.*


klappt nicht:

defmod myTestInflux InfluxDBLogger http://myinfluxdb:8086 fhem_db .*:(temperature|humidity|absHumidity).*
defmod myTestInflux InfluxDBLogger http://myinfluxdb:8086 fhem_db .*:temperature.*
defmod myTestInflux InfluxDBLogger http://myinfluxdb:8086 fhem_db .*temperature.*


klappt teilweise:

http://myinfluxdb:8086 fhem_db r:temperature=..*,r:humidity=..*

die Readings werden erfasst, aber auch welche, die dort NICHT stehen (absHumidity)

nicht nachmachen
Beim Rumstochern bin ich vom rechten Weg abgekommen und dem bösen Wolf begegnet  :o :
Habe mich am "list" orientiert, weil dort ebenfalls devspec greift. Ein "list .* temperature" bringt z.B. beide Dummies. Im InfluxDBlogger ist das Leerzeichen ja nicht vorgesehen, also versuchte ich dies:
http://myinfluxdb:8086 fhem_db (.* temperature)
FHEM verabschiedet sich dann sofort mit einem Gruß im LOG und startet neu

2022.02.10 09:00:03.459 3: FHEMWEB WEB CSRF error: csrf_blabla ne csrf_blablabla for client WEB_balblaip / command modify myTestInflux http://myinfluxdb:8086 fhem_db (.* temperature). For details see the csrfToken FHEMWEB attribute.
Unmatched ( in regex; marked by <-- HERE in m/( <-- HERE .*/ at ./FHEM/93_InfluxDBLogger.pm line 42.



timmib

#213
Hallo Rob,

bei der DevSpec handelt es sich um eine Einschränkung auf Devices und nicht auf Readings. Dafür gibt es die Attribute ReadingInclude bzw. ReadingExclude.
Siehe hierzu auch die Doku.https://fhem.de/commandref_DE.html#devspec

Ich kann nur jedem raten, nicht zu sehr zu versuchen zu viel über einen InfluxDBLogger zu loggen. Das hat außer Bequemlichkeit keinerlei Vorteile - im Gegenteil die Konfiguration wird nur komplizierter. Effizienzgewinne oder so gibt es nicht.
Bei mir laufen produktiv acht InfluxDBLogger.

Viele Grüße

Tim

rob

Hi Tim.

Vielen Dank für Deine flinke Rückmeldung. Das deckt sich auch mit meinen Experimenten :) Dann denk ich ist es mir klar, wie das soll bzw. was erlaubt ist.
So richtig viel Krams loggen möchte ich auch nicht. Überwiegend Umweltsensorik á la Temp/ Hum. Via event-on-change-reading schränke ich zusätzlich stark ein.

@kadettilac89: Wie hast Du das hinbekommen? Nutzt Du etwas anderes als den InfluxDBLogger?

VG
rob

msome

Zitat von: timmib am 09 Februar 2022, 11:17:23
Eigentlich sollte er 6.103515625e-05 als numeric erkennen. Ich bin bisher nur von großen 'E' ausgegangen. Füge mal das kleine "e" in Zeile 375 in die RegEx ein, ob Influx damit leben kann.
^[0-9,.eE-]+$

Hi Tim, vielen Dank für den Korrekturvorschlag.
Die veränderte RegEx läuft bei mir seit Dienstag und funktioniert einwandfrei.
Es werden alle Werte eingefügt; kein Drop, keine Fehlermeldungen mehr.  :)
Gruß, Matthias
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

bartpl

Ich habe eine Frage - kann dieser Modul auch non-numerische Werte ins Influx schicken? Influx2 unterstützt solche ohne Probleme... Mir würde konkret um die aus statistics Modul gehen, stat.*Last readings. Diese würde ich dann in Influx2 mittels tasks ins separate values trennen... Will keine extra readings in Fhem bei jeden Device schrauben müssen... aktuell sehe ich, das allein die readings ins influx gepackt werden, die numerisch sind.
Wäre so eine Änderung technisch schwierig?

Weisswurstverkäufer

Zitat von: bartpl am 17 Februar 2022, 09:09:14
Ich habe eine Frage - kann dieser Modul auch non-numerische Werte ins Influx schicken? Influx2 unterstützt solche ohne Probleme... Mir würde konkret um die aus statistics Modul gehen, stat.*Last readings. Diese würde ich dann in Influx2 mittels tasks ins separate values trennen... Will keine extra readings in Fhem bei jeden Device schrauben müssen... aktuell sehe ich, das allein die readings ins influx gepackt werden, die numerisch sind.
Wäre so eine Änderung technisch schwierig?

Siehe

Zitat von: timmib am 04 Februar 2022, 17:26:26
Hi,

schaut euch mal die neue BETA-Version an.

Diese kann nun Strings (Danke an msome) UND originale Zeitstempel

Bitte beides inklusive Doku testen und zurückmelden, damit ich das nach SVN schieben kann.

Viele Grüße

Tim

(Ist mittlerweile keine Beta mehr)

bartpl

Danke! da bin ich zeitlich sehr gut gekommen, das scheint eine extrem frische Sache zu sein :) Vielen Dank!

bzg. des Problem, das values die zuerst als int in influx angelegt werden, später zur string schwehr konwertierbar sind... Es gibt readings, die eigentlich strings sind, können aber ab und zu nur zahlen beinhalten und als int misinterpretiert werden... Wäre es nicht gut für das stringValuesAllowed noch ein extra Wert 2 implementieren, so das auch integer als strings abgeschickt werden? Dann wäre das Problem weg, jeder könnte für sich entscheiten ob er strings oder zahlen haben muss und es würde erzwungen werden...

Ich fange an die tests...
Ps. wo finde ich das Modul in irgend ein Repo?

meier81

Zitat von: bartpl am 17 Februar 2022, 10:03:08
Ps. wo finde ich das Modul in irgend ein Repo?

Die kommt automatisch wenn du ein update von fhem machst, einfach oben in die Leiste update eingeben und bestätigen, anschließend fhem neustarten mit shutdown+restart

Gruß
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

bartpl

ok, super. ich dachte nur das es noch in Beta war und noch nicht in main stream. Danke!

kennymc.c

#221
Ich bin gerade dabei Daten von einer mySQL Datenbank auf Influxdb mit API v2 zu übertragen. Dazu habe ich das im Wiki verlinkte Skript von kadettilac89 etwas angepasst. Auf meinem Rechner selbst scheint das schreiben von Testdaten auch gut zu funktionieren aber wenn ich es im Fhem Docker Container ausführe, bekomme ich eine Zertifikatswarnung für Influxdb (Code 500), obwohl ich die Überprüfung absichtlich deaktiviert habe. Außerdem bekomme ich für Zeile 31 einen Error. Eventuell hat ja schon jemand selbst ein mit der API v2 kompatibles Skript gebaut. Ich habe meinen Versuch mal angehangen auch wenn ich mich nicht wirklich mit Perl auskenne und mich da eher an anderen Beispielen orientiert habe.

Außerdem tauchen immer wieder failed und dropped writes im Modul auf. Leider bekomme ich auch mit verbose 5 keine wirklich Infos dazu:

2022.02.20 17:03:42.777 4: InfluxDBLogger: [InfluxDB] notified from device SZ_xRouter
2022.02.20 17:03:42.777 4: InfluxDBLogger: [InfluxDB] notified from device SZ_xRouter about linkquality: 47
2022.02.20 17:03:42.779 5: InfluxDBLogger: [InfluxDB] set ?
2022.02.20 17:03:42.779 5: InfluxDBLogger: [InfluxDB] set ?
2022.02.20 17:03:42.779 4: InfluxDBLogger [InfluxDB] - Read token from file
2022.02.20 17:03:42.780 4: InfluxDBLogger: [InfluxDB] Sending data linkquality,site_name=SZ_xRouter value=47
to https://192.168.1.201:8087/api/v2/write?org=%2d&bucket=fhem
2022.02.20 17:03:42.788 1: InfluxDBLogger: [InfluxDB] Error = 
2022.02.20 17:03:42.790 5: InfluxDBLogger: [InfluxDB] set ?
2022.02.20 17:03:42.790 5: InfluxDBLogger: [InfluxDB] set ?
2022.02.20 17:03:42.791 5: InfluxDBLogger: [InfluxDB] set ?
2022.02.20 17:03:42.791 5: InfluxDBLogger: [InfluxDB] set ?
2022.02.20 17:03:42.791 1: InfluxDBLogger: [InfluxDB] Error = Statistics: t=11813 s=11729 f=166 e=12318
2022.02.20 17:03:42.792 5: InfluxDBLogger: [InfluxDB] set ?
2022.02.20 17:03:42.793 5: InfluxDBLogger: [InfluxDB] set ?
2022.02.20 17:03:42.793 5: InfluxDBLogger: [InfluxDB] set ?
2022.02.20 17:03:42.794 5: InfluxDBLogger: [InfluxDB] set ?

kennymc.c

Schade, dass auch knapp 3 Monate später niemand die Error Log Meldungen erklären kann. Ich weiß immer noch nicht, wo der Fehler liegt, da das Modul einfach keine Infos ausgibt bei welchen Device(s) der Fehler auftritt.

topa_LE

Bin mir nicht sicher, ob der Entwickler für die Influx 2.0 das Modul weiterentwickelt oder getestet hat. M.E. nutzt er (wie auch ich) die V1.8 , also die api v1 als Attribut.

Schonmal damit probiert?

Aber auch ich bekomme meine Sonoff Plug Devices auch nicht 100% ans laufen. Zumindest in der InfluxDB ne ordentliche Struktur reinzubekommen.

Ob nun die attr fields, tags oder doch measurement besser sind, bin ich nicht schlüssig. Scheinbar gibt es ja mehrere Ansätze durch die damalige Weiterentwicklung.


Um grundsätzlich auch non numerisch zu loggen, ist das Attr stringValuesAllowed zu nutzen, besten Dank an Tim!


kennymc.c

#224
Zitat von: topa_LE am 16 Mai 2022, 16:51:52
Bin mir nicht sicher, ob der Entwickler für die Influx 2.0 das Modul weiterentwickelt oder getestet hat. M.E. nutzt er (wie auch ich) die V1.8 , also die api v1 als Attribut.

Schonmal damit probiert?

Hab eigentlich erst vor kurzem alles bei mir auf v2 umgestellt und würde nur ungern wieder zurück. Zudem unterstützt das Modul ja offiziell die v2 API. Dann sollte die auch supported werden oder ein Hinweis in der Commandref ergänzt werden. Letztendlich sieht bei mir auch alles ok aus in den Graphen und ich erkenne auf den ersten Blick keine fehlenden Einträge. Aber da kann ich mich auch irren.