FHEM Forum

FHEM - Hausautomations-Systeme => Unterstützende Dienste => Thema gestartet von: d.schoen am 05 Mai 2017, 11:52:12

Titel: Neues Modul: 93_InfluxDBLog
Beitrag von: d.schoen am 05 Mai 2017, 11:52:12
Hallo zusammen, wie der Titel des Threads schon sagt: Ich habe ein neues kleines Modul entwickelt.

Durch den Umzug vom Pi2 auf einen "richtigen" Server hat sich auch meine Infrastruktur für das Charting geändert. Ich setze da mittlerweile auf die Timeseries-DB InfluxDB (https://www.influxdata.com/ (https://www.influxdata.com/)) und das Charting Frontend Grafana (https://grafana.com/ (https://grafana.com/)).

Bisher hatte ich mir meine Messwerte via DBLog in eine MySQL Datenbank gespeichert. Von dort dann über ein Script in die InfluxDB. Ich dachte mir aber, das muss doch auch direkt gehen.

Daher nun das Modul dafür.

Es kann über
update add https://raw.githubusercontent.com/dsgrafiniert/fhem-InfluxDBLog/master/controls_influx.txt in die normale Updateroutine von FHEM eingebunden werden.

Definiert wird das ganze dann folgendermaßen:
define <name> InfluxDBLog <host> <port> <DB> <username> <passwort> <regex>
Beispiel:
define influxlog InfluxDBLog localhost 8086 fhem user pw .*
Würde mich über Feedback aus der Community sehr freuen.

Viele Grüße
d.schoen
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: Thyraz am 05 Mai 2017, 12:13:28
Hallo d.schoen

Bin im Moment auch etwas unzufrieden mit meinen Charts in FHEM, vor allem wenn man mal schnell kurz was auswerten will, das man bisher noch nicht als Chart angelegt hatte.

InfluxDB und Grafana sieht sehr schön aus.
Gerade auch die Wahl des Zeitbereichs etc. was sogar über Mobilgeräte anständig bedienbar ist. :)
Werde ich mir später daheim mal ansehen.

Falls das gefällt, muss ich nur noch sehen wie ich die Altdaten in die InfluxDB bekomme...
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: Thyraz am 05 Mai 2017, 23:55:34
Wollte nur mal die Rückmeldung geben, dass das Modul soweit super funktioniert.
Hab die regex von meiner DBLog Instanz übernommen und jetzt nach ein paar Stunden mitloggen in Grafana die ersten Temperaturcharts meiner Thermometer erstellt. :)

Sehr cool und danke auch dafür, mich überhaupt auf Grafana gebracht zu haben.
Das war genau was ich gesucht habe um eine etwas flexiblere und modernere Charting Lösung zu bekommen.
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: Benni am 06 Mai 2017, 07:42:12
Hätte man die InfluxDB-Unterstützung nicht sinnvollerweise in das DBLog-Modul integrieren können?
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: d.schoen am 06 Mai 2017, 08:19:42
Wäre sicher irgendwie gegangen, allerdings ist der Zugriff auf eine InfluxDB grundlegend anders als der Zugriff auf eine relationale, klassische (bspw. MySQL) DB.

Es darf mein Code und/oder die Funktionalität natürlich gern in das DBLog-Modul integriert werden, für meine Zwecke ging es über ein eigenes Modul einfacher und schneller.
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: DS_Starter am 06 Mai 2017, 17:33:47
Hi Benny und d.schoen,

eine Integration in das DbLog-Modul als weitere unterstützte DB wäre sicherlich sinvoll weil integrativ.
Ich würde mich nach meinem Urlaub auch damit mal beschäftigen und dich d.schoen bitten mich dabei zu unterstützen. (Benny natürlich auch  ;) )
Vorher habe ich aber noch ein paar laufendende ToDos in dem DbLog-Thread  hier -> https://forum.fhem.de/index.php/topic,65860.0.html . (Kein schlechter Thread um auch dieses Thema weiter zu verfolgen)
Von allen unterstützen DBs habe ich mir Testinstanzen aufgebaut und bräuchte die dann natürlich auch für die Influx.

@d.schoen, kannst du ein paar Links/Tipps zusammenstellen die die Installation dieser DB und Grafana auf Debian beschreiben ?
Ich hatte damit bisher nichts zu tun und kenne mich damit nicht aus. Es würde sehr helfen und Zeit sparen.

Also das ist lediglich ein Angebot wenn eine solche Integration gewünscht ist .... und sie muß natürlich auch sinnvoll umsetzbar sein mit diesem DB-Typ.

viele Grüße
Heiko
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: Benni am 06 Mai 2017, 18:52:13
Hallo Heiko,

stelle mich natürlich gerne als Tester zur Verfügung.
Habe zwar bisher auch null Erfahrung mir InfluxDB oder Grafana, aber dann ist das Wahrscheinlich mal wieder so eine Gelegenheit, was Neues zu lernen.  ;D

Gruß Benni.
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: DS_Starter am 06 Mai 2017, 19:11:59
Zitat
Habe zwar bisher auch null Erfahrung mir InfluxDB oder Grafana, aber dann ist das Wahrscheinlich mal wieder so eine Gelegenheit, was Neues zu lernen.

Na dann sind wir schon zwei  :D

Ich schau mal wann ich dazu komme, will erstmal noch ein paar offene Dinge in dem Thread abarbeiten und erfahrungsgemäß dauert es länger als ursprünglich gedacht.
Also bis dann mal wieder ...

Heiko
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: Thyraz am 06 Mai 2017, 21:44:21
Das wäre natürlich sehr cool. 😊

Dann könnte man sein normales DBLog und Grafana unter einen einen Hut bekommen.
Das Ganze sieht auf alle Fälle schonmal recht performant aus. Auf meinem Pi2 läuft jetzt zusätzlich Influx und Grafana und die Charts sind sehr schnell geladen gegenüber Fhem Plots oder FTUI Charts.

Bin mir jetzt nicht sicher woran das liegt.
Ob InfluxDB mit seiner zeitorientierten Datenbank hier seine Stärken ausspielt,
Oder Grafana hier besser optimiert ist.

Grafana passt sich auch gut an Displays von Handys an und die Chartd können auch in andere Seiten embedded werden.

Debian Influx Repo findet man hier:
https://docs.influxdata.com/influxdb/v1.2/introduction/installation/

Grafana hat auch eines:
https://grafana.com/grafana/download

Grafana für Pi:
https://github.com/fg2it/grafana-on-raspberry

InfluxDB kann man dann über das Webinterface anlegen.
(Achtung Standardport nach der Installation ist 8083 wie auch bei Fhem.)

Dort kann man im "Query Template" Menu eine neue Datenbank anlegen.
Die Datenbankanbindubg selbst lauscht nachher auf Port 8086.

Grafana ist hingegen unter Port 3000 erreichbar.
Dort muss InfluxDB als neue Datasource angelegt werden.
Bei mir gab es einen kleinen Stolperstein:
Der Add Datasource Eintrag im Menü war nach der Login Erstellung im Webinterface noch nicht sichtbar.

Erst als ich mir zusätzlich übers Menü eine "Organisation" angelegt habe, ist das Datasource Menü aufgetaucht.

Hier mal noch ein Screenshot wie man die Graphen konfiguriert.
Bei weiteren Fragen zu Installation/Konfiguration einfach melden.
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: d.schoen am 07 Mai 2017, 18:43:05
Zunächst mal danke für die rege Diskussion und das offenkundige Interesse an der Idee.

@Heiko: Natürlich unterstütze ich gern, auch wenn ich mich beim besten Willen nicht als "Profi" für InfluxDB bezeichnen würde.

Die Zusammenfassung von Thyraz ist auf jeden Fall schon mal sehr gut, danke dir!
Ich habe mich für InfluxDB und Grafana grundsätzlich an folgende Anleitung gehalten (habe hier eine Docker-Infrastruktur): https://blog.laputa.io/try-influxdb-and-grafana-by-docker-6b4d50c6a446 (https://blog.laputa.io/try-influxdb-and-grafana-by-docker-6b4d50c6a446)

Allerdings weiß ich tatsächlich nicht, inwieweit die Integration in das DBLog Modul sinnvoll ist. InfluxDB ist eine NoSQL Datenbank und verwendet als Interface für Queries und Dateneinspeisungen eine HTTP-Schnittstelle: https://docs.influxdata.com/influxdb/v1.2/guides/writing_data/ (https://docs.influxdata.com/influxdb/v1.2/guides/writing_data/)
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: DS_Starter am 07 Mai 2017, 19:14:50
Hallo Thyraz und d.schoen,

erstmal vielen Dank für die Informationen.
Es wird auf jeden Fall noch etwas Zeit vergehen ehe ich mich damit auseinandersetzen kann und die Sinnfälligkeit dieses Vorhabens kann ich momentan auch noch nicht einschätzen. Schauen wir einfach mal ...

Was mir aber schon bezüglich der Modularchitektur durch den Kopf ging ....
Wird den euerer Meinung nach der FHEM-User die InfluxDB als vollkommenen Ersatz zu einer SQL-DB verwenden oder eher als Add-on, welches quasi neben einer SQL-DB mitlaufen wird.  Sollte letzteres der Fall sein könnte man über ein Attr die DB zuschaltbar machen und die Regex würden dan automatisch mit greigen. Im anderen Fall müßte man alle nicht zutreffenden Set/get-Kommandos und/oder auch Attribute ausblenden sobald man Influx nutzt und umgedreht.
Das hat dann natürlich ziemliche Auswirkungen auf den zu betreibenden Aufwand .

Ich hoffe mein Gedankengang ist deutlich geworden und mich iteressiert eure Meinung dazu.

Grüße
Heiko
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: d.schoen am 07 Mai 2017, 19:38:11
Puuh.... Ich denke das lässt sich kaum pauschal beantworten, da beide Settings denkbar sind.

Ich kann nur aus meiner Perspektive sprechen: Ich setze die InfluxDB alternativ zur bisherigen MySQL DB ein. Bisher diente die mir auch nur um numerische Werte abzuspeichern und damit die Plots zu erstellen. Da ist InfluxDB und Grafana eben DEUTLICH schneller und schöner.

Sicher ist aber auch der Use-Case, die InfluxDB parallel zu betreiben. Hierfür würde ich aber z.B. folgendes Script empfehlen: https://github.com/GreatLakesEnergy/Mysql-to-influxdb (https://github.com/GreatLakesEnergy/Mysql-to-influxdb)
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: wuast94 am 08 Mai 2017, 16:59:16
ihr behandelt gerade genau das was ich herausfinden wollte :D manchmal hat man auch glück.

Ich würde als "Laie" schon fast sagen das der größte Teil das dblog in Verbund mit MySQL nur für Plots nutzt.. dementsprechend könnte man sagen man kann MySQL weg lassen und einfach InfluxDB nehmen.

Allerdings gibt es sicherlich auch viele die mit Plots arbeiten (floorplan, Telegramm etc) und dementsprechend auf das vorhandene System nicht verzichten können. es sei denn alle anderen Module werden erweitert um die Funktion was denke ich ne menge arbeit heißt. Bin zwar kein Dev aber man hat ja bekannte und sammelt da seine Erfahrungen von außerhalb, ihr habt übrigens Größten Respekt von mir :)

Naja kurzgefasst denke ich das ein paralleles System mit beiden Datenbanken am sinnvollsten wäre. (und ich denke Leistungs Technisch wird da auch kein PI anfangen zu Brennen wenn da zwei DB´s laufen)
schön wäre natürlich wen dieses parallele loggen in 2 DB´s (und das kopieren der vorhandenen) möglichst automatisch passieren kann.

Ich hoffe das ich damit einen Sinnvollen Beitrag/Hilfe leisten konnte :)
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: Thyraz am 09 Mai 2017, 08:47:39
Aber die anderen Module (Telegram etc.) greifen ja wahrscheinlich über DBLog auf die Daten zu, und nicht direkt auf die Datenbankschnittstelle, oder?
Würde InfluxDB also wirklich in DBLog integriert, könnte man sie schon als einzige Datebank für alle Zwecke verwenden denke ich...
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: wuast94 am 09 Mai 2017, 15:45:08
Aber die anderen Module (Telegram etc.) greifen ja wahrscheinlich über DBLog auf die Daten zu, und nicht direkt auf die Datenbankschnittstelle, oder?
Würde InfluxDB also wirklich in DBLog integriert, könnte man sie schon als einzige Datebank für alle Zwecke verwenden denke ich...

Ich glaube nicht da die Grafen (auch je nach Theme/Style) als bild exportiert werden so wie sie in Fhem zu sehen sind .. also als wenn da n screen von gemacht wird :D und grafana ist ja dann nicht in fhem intigriert sondern eine extra homepage wenn mich nicht alles irrt :) und ich gehe nicht davon aus das Grafana in Fhem intigriert wird. Wobei ein komplett überarbeitetes Fhem plus Grafana .. naja Träumen muss man ja nicht :D
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: d.schoen am 09 Mai 2017, 15:50:34
Öhm...  Man kann aus Grafana heraus Embeds und/oder Share-Links generieren. Ebenso kann ein PNG-Render exportiert werden (siehe anbei). Träum also ruhig weiter ;-)

Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: wuast94 am 09 Mai 2017, 16:49:48
Öhm...  Man kann aus Grafana heraus Embeds und/oder Share-Links generieren. Ebenso kann ein PNG-Render exportiert werden (siehe anbei). Träum also ruhig weiter ;-)
ok dann habe ich was das angeht nie was gesagt  ;D ich bleibe aber dennoch dabei das das parallele fahren von beiden Sinnvolelr wäre :) am besten so das die dblog db gespiegelt wird in die andere datenbank .. so kann man mit dblog alles configurieren welche daten man will etc und mit dem gespiegelten influxdb grafana füttern. oder sieht das jemand anderes ?
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: Benni am 09 Mai 2017, 18:10:27
ok dann habe ich was das angeht nie was gesagt  ;D ich bleibe aber dennoch dabei das das parallele fahren von beiden Sinnvolelr wäre :) am besten so das die dblog db gespiegelt wird in die andere datenbank .. so kann man mit dblog alles configurieren welche daten man will etc und mit dem gespiegelten influxdb grafana füttern. oder sieht das jemand anderes ?

Es hindert einen übrigens niemand daran, mehrere dblog-devices zu haben. ;)
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: Thyraz am 09 Mai 2017, 21:14:08
@wuast, ich verstehe nur immer noch nicht, warum 2 Datenbanken optimal sind.
Wenn InfluxDB als Datenbank für DBLog genutzt werden könnte, kann ich damit doch sowohl FHEM-Module welche auf DBLog zugreifen fütern, als auch Grafana.

Die doppelte Datenhaltung wäre dann ja nicht mehr nötig.

Ich glaube wir reden da aneinander vorbei, da du auf meinen letzten Post dann was von Grafana geschrieben hast.
Was ich meinte: Wenn InfluxDB eine der möglichen DBs wäre, die man mit DBLog nutzen kann,
dann kann ich auch FHEM interne Plots daraus erstellen lassen. Nicht nur Grafana Charts.

Wenn man aber auf doppelte Datenhaltung steht, wird aber natürlich auch dann dieser Vorliebe nichts im Weg stehen. :P
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: wuast94 am 10 Mai 2017, 14:50:26
@wuast, ich verstehe nur immer noch nicht, warum 2 Datenbanken optimal sind.
Wenn InfluxDB als Datenbank für DBLog genutzt werden könnte, kann ich damit doch sowohl FHEM-Module welche auf DBLog zugreifen fütern, als auch Grafana.

So gesehen ja hast du recht. Mir ging es eher darum das es externe Anwendungen gibt die nicht mit allen Datenbanken um können .. ich weiß zb von einigen charting progs/services die nur mit bestimmten Datenbanken arbeiten. und ich weiß nicht wie viele mit sowas arbeiten .. von daher wäre eine Möglichkeit beides parallel laufen zu lassen für einige evt interessant.
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: d.schoen am 10 Mai 2017, 14:53:12
Was ich meinte: Wenn InfluxDB eine der möglichen DBs wäre, die man mit DBLog nutzen kann,
dann kann ich auch FHEM interne Plots daraus erstellen lassen. Nicht nur Grafana Charts.

Richtig! Was man aber beachten sollte: InfluxDB kann - im Gegensatz zu bspw. MySQL - nur numerische Werte speichern. Textuelle Statusinformationen gehen damit nicht.
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: wuast94 am 10 Mai 2017, 16:27:01
Richtig! Was man aber beachten sollte: InfluxDB kann - im Gegensatz zu bspw. MySQL - nur numerische Werte speichern. Textuelle Statusinformationen gehen damit nicht.

Noch ein grund mehr es Parallel zu fahren (ist ja auch nur optional für die die es brauchen und ich schätze nur wenig mehr aufwand zum coden) soll ja nicht standard mäßig aktiviert sein :D
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: d.schoen am 10 Mai 2017, 16:28:08
Ich vermute ja tatsächlich, dass hier massiv aneinander vorbei diskutiert wird.

Was spricht dagegen bspw. zwei DBLog Devices zu definieren? Eines für die InfluxDB und eines für die MySQL?!
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: Benni am 10 Mai 2017, 18:01:33
Was spricht dagegen bspw. zwei DBLog Devices zu definieren? Eines für die InfluxDB und eines für die MySQL?!

Was ich damit andeuten wollte:

Es hindert einen übrigens niemand daran, mehrere dblog-devices zu haben. ;)
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: Thyraz am 11 Mai 2017, 07:34:10
Noch ein grund mehr es Parallel zu fahren (ist ja auch nur optional für die die es brauchen und ich schätze nur wenig mehr aufwand zum coden) soll ja nicht standard mäßig aktiviert sein :D

Ok, das ist tatsächlich ein sehr guter Grund. :)

Da sollte ich mir dann auch mal meine RegEx für das Loggen in die InfluxDB anschauen, oder werden die anderen Werte einfach ignoriert?
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: d.schoen am 11 Mai 2017, 07:59:57
Die anderen Werte werden einfach ignoriert ;-)
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: gerhardg am 21 Mai 2017, 14:17:32
Für Grafana Dashboards wären aber auch entsprechende Statusinfos von Fensterkontakten usw nicht uninteressant. Werden eigene userReadings ggf übernommen, dann müsste man ja nur open/closed einfach in 0/1 umwandeln?
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: fischit am 21 Mai 2017, 14:59:37
Hallo Zusammen,

erst einmal danke für das Modul.
Ich habe mich deswegen mit Influx und natürlich mit Grafana auseinander gesetzt und bin glücklich über die doch ansprechenderen Dashboards als Standard FHEM Plots :)

Ich bin zwar absolut kein Spezi, aber man kann in InfluxDB auch Strings speichern. Das Modul läuft aber in ein Error (DB, User und PW durch *** ersetzt)
2017.05.21 14:31:44 4: influxlog: Writing contact,site_name=fenster_wohnzimmer_r value=closed (to VCCU)
2017.05.21 14:31:44 4: influxlog: URI: http://192.168.2.12:8086/write?db=***&u=***&p=***
2017.05.21 14:31:44 4: influxlog: Error 400 Bad Request

Wenn man Strings in die DB schieben will muss der Code contact,site_name=fenster_wohnzimmer_r value="closed (to VCCU)" lauten.

Diesen Wert kann man sich in Grafana dann mittels Single Stat anzeigen lassen.

Viele Grüße
Nils
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: matzewob am 26 Mai 2017, 17:42:34
Sehr schönes Modul.
Läuft auf anhieb mit der Grafana/Influxinstanz.

Wäre nur noch cool wenn man bereits vorhandene Daten einlesen könnte.

Gruß aus Wolfsburg

Matthias
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: DWegmann am 27 Mai 2017, 09:26:24
Vielen Dank für das Modul. War genau was ich gesucht habe.
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: reinni123 am 30 Mai 2017, 13:04:23
Besteht nicht die Möglichkeit Grafana direkt mit mysql zu nutzen ohne die InfluxDB? -> http://docs.grafana.org/features/datasources/mysql/
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: pole23 am 25 Juni 2017, 17:35:18
Ja, in der aktuellen Version von grafana kann man direkt auf eine MySQL Datenbank gehen. Ist wohl aber noch im Status Alpha.
Ich habe es heute mal getestet und es funktioniert generell. Siehe Bild
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: reinni123 am 25 Juni 2017, 17:39:10
Was hast du eingestellt, das es bei dir funktioniert? Bei mir wollte es mit MariaDB nicht funktionieren.
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: pole23 am 25 Juni 2017, 17:50:18
Es ist ein normaler Graph, wo ich bei "Metrics" folgenden SQL Befehl ausführen lasse:
SELECT UNIX_TIMESTAMP(TIMESTAMP) as time_sec, VALUE as value, device as metric FROM fhem.history where READING="temp_knx"Das Reading ist ein Userreading für die Temperaturen von KNX.
Das Format des Graphen ist "Time Series".
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: reinni123 am 26 Juni 2017, 11:23:15
Tatsächlich funktioniert. Allerdings musste ich weiter filtern da bei mir unter dem reading "temperature" zu viele Sensoren erscheinen:

SELECT UNIX_TIMESTAMP(TIMESTAMP) as time_sec, VALUE as value, device as metric FROM fhem.history where READING="temperature" AND DEVICE="UG.Heizraum.Speicher.1.Tempsensor.1"
Man merkst allerdings das es deutlich länger zum laden braucht.
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: plin am 26 Juni 2017, 18:22:22
Hi,

das Modul lief mit
define influxlog InfluxDBLog myserver 8086 fhem fhem fhem .*auf Anhieb.

Ich wollte jetzt testweise den Status der Tür/Fensterkontakte mittels Grafana-Plugin Discrete darstellen (das kann Werte in andere übersetzen, also "open (to vccua)"->"1"). Das Reading "contact" gibt's aber nicht in der InfluxDB. Werden nur numerische Werte übertragen?

VG plin
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: deveth0 am 17 Juli 2017, 09:13:39
...
Man merkst allerdings das es deutlich länger zum laden braucht.

Hier ist das Problem, dass du alle Werte lädst und kein GROUP BY machst. Damit sollte es weitaus schneller gehen:
SELECT UNIX_TIMESTAMP(TIMESTAMP) as time_sec, VALUE as value, device as metric
FROM fhem.history
WHERE READING="temperature" AND DEVICE="UG.Heizraum.Speicher.1.Tempsensor.1" AND $__timeFilter(TIMESTAMP)
GROUP BY value, UNIX_TIMESTAMP(TIMESTAMP) DIV 300
ORDER BY time_sec asc;

Du solltest auch im Netzwerk-Monitor vom Browser sehen, dass ansonsten extrem viele Daten übertragen werden (ein einzelner meiner LaCrosse Sensor hat zB ~5MB pro Tag)
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: hermann1514 am 31 Juli 2017, 16:01:02
Hi.

Habe das Modul auch mal installiert und läuft schon einige Wochen.
SIeht gut aus. Jedoch habe ich zumindest ein Gerät / oder Typ bei dem die Daten nich in die INFLUXDB geschrieben werden:
Die EDIPLUG Steckdosen. Z.B. das Reading "current" wird nich tübernommen. Jedoch von meinen EC3000 Powermeter wird das Reading in die INFLUX DB geschrieben.
Die EDIPLUG Dinger haben auch noch power_day, power_month usw. aber diese werden auch nicht geschrieben.
Ich habe die DEF mit .* abgeschlossen - hatte vorher nur bestimmte Einträge drinne - aber es wird von diesen Geräte nichts geschrieben.

Kann ich im LOG (welches??) irgendetwas sehen?

Danke.
Gruß
Hermann
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: hermann1514 am 01 August 2017, 09:30:29
Hi,

habe das Problem nun gefunden. Im Reading stand noch die Einheit "W". Ich habe nun ein Userreading nur mit dem Wert erstellt und dieses wurde sofort in die DB geschrieben.

Gruß
Hermann
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: PichlAlex am 06 Oktober 2017, 10:59:16
Hallo!

ich bin gerade ganz begeistert über diesen Thread.
Wie ist denn der aktuelle Implementierungsstatus? gibt es bereits (oder in näherer Zukunft) eine Integration ins DBLOG oder wie wollt ihr weiter mit dem Thema umgehen?
Ich werde ebenfalls die InfluxDB zu meiner FHEM Installation implementieren - möchte aber eine doppelte Implementierung vermeiden.

schöne Grüße
Alex
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: d.schoen am 06 Oktober 2017, 11:08:23
Hi Alex,

eine Integration in DBLog ist aktuell nicht vorgesehen. Das Modul von mir läuft aber seit Mai zu 100% stabil und darf gern verwendet werden.

Viele Grüße
Dominik
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: Thyraz am 06 Oktober 2017, 13:28:18
Ich habe gestern erst meine Sqlite3 DBLog Datenbank in eine MySQL Datenbank umgezogen und nutze diese nun direkt in Grafana.
Die MySQL-Datasource von Grafana scheint mittlerweile echt gut zu funktionieren.

Damit bleibt die einem die doppelte Datenhaltung erspart.
Auch sind String-Werte wie open/closed kein Problem und man erspart sich zusätzliche numerische Userreadings um das in InfluxDB loggen zu können.

Die Werte kann man dann direkt im SELECT Statement wieder zu Werten mappen um sie in Grafana in den Graphen zu bekommen.
Durch die vielfältigen Funktionen die bei einem SELECT möglich sind, brauchen viele Sachen auch gar nicht in Grafana integriert werden, da man das schon auf MySQL Seite erledigen kann.

z.B. Temperaturdaten ausdünnen und durch Mittelwerte ersetzen, damit der Graph schneller lädt / weniger Traffic erzeugt usw.
Oder Offsets auf Werte aufrechnen um mehrere Kurven übereinander in einem Graphen darzustellen.

Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: artcrime am 14 November 2017, 19:11:09
Hallo,

bin ein totaler Fan von Influxdb / Grafana und freue mich das fhem direkt die Messwerte dort ablegen kann. Echt tolle Arbeit! Ist es auch möglich den Alias eines Messwerte als weiteren Tag in die Influxdb zu schreiben?
Ich möchte für die Grafana Dashboards Template Variablen nutzen was zwar funktioniert aber die Namen meiner Temperatursensoren entsprechen nicht den Raumnamen. Weitere Tags an den Messwerten würden die Templateerstellung deutlich vereinfachen. Am besten fände ich es wenn der Alias des Gerätes als Tag mit geschrieben wird (oder wenn es optional wäre).

Gruß Sascha
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: plin am 14 November 2017, 20:56:27
Und wie schaut es mit Tür-/Fensterkontakten aus? Die haben den Status open / closed der als 0 / 1 in die InfluxDB übertragen werden könnte.
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: artcrime am 15 November 2017, 16:15:29
Da influxdb ein gute Web Schnittstelle zum Einfügen der Daten hat habe ich schon mal darüber nachgedacht bei jedem Schreibevent (wegen mir in den Txt / mysql Log) einen Benutzerdefinierten Curl Aufruf zu starten welcher die Daten in gewünschter Form in die Influxdb schreibt. Damit könnte man auch mehrere Values oder auch Strings in die Datenbank schreiben.

Die http Schnittstellen ist sehr gut dokumentiert. Schreiben in die Datenbank könnte z.B. so aussehen (Auszug aus der influxdb Doku):

curl -i -XPOST 'http://localhost:8086/write?db=mydb' --data-binary 'cpu_load_short,host=server01,region=us-west value=0.64 1434055562000000000'

Wäre meiner Meinung nach der flexibelste Weg!

Ich weiß nicht ob ich sowas mit fhem überhaupt machen könnte (nutze fhem erst seit ein paar Tagen und lese mich wenn ich Zeit habe in ein paar Themen ein).

Gruß
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: antst am 28 November 2017, 18:31:27
Thanks for excellent work!

I configured logging to InfluxDB, converted my text logs to it, and embedded back to FHEM plots from Grafana (dynamically with all goodness of Grafana) and it works like a charm now!
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: volschin am 10 Dezember 2017, 14:31:27
Ich bin gerade auf den Thread gestoßen, da ich auf eine Time Series Datenbank umstellen wollte. Ich las im Netz, dass InfluxDB die bis zu 75-fache Performance einer MariaDB bringt.
Ich finde es immer wieder cool, dass schon einer das Thema vorgedacht hat. Ich war noch unschlüssig, ob InfluxDB oder Prometheus, aber mit dem vorhandenen Modul fällt erstmal die Entscheidung bei mir, InfluxDB auszuprobieren.  :)

Vielen Dank an d.schoen für das Modul.
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: pano am 12 Dezember 2017, 10:06:01
Hallo allerseits,

ich habe das Modul nun schon seit einigen Monaten in Betrieb und versuche grade das Logging etwas einzuschränken.
Allerdings wird bei mir garnichts mehr geloggt, sobald ich im regex der def irgend etwas anderes als .* stehen habe.

Bsp:
localhost 8086 meidedb meinuser meinpwd (.*:temperature)

Übersehe ich was, oder kann jemand das auch nachvollziehen?

Danke, Pano
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: fischit am 12 Dezember 2017, 17:46:02
Meine Definition läuft mit
<host> <port> <DB> <username> <passwort> .*:(temperature|humidity|lueftung|absFeuchte).*
Titel: Antw:Neues Modul: 93_InfluxDBLog - FileLog Import -> influxdb
Beitrag von: fervor am 17 Dezember 2017, 20:45:11
Hi,

ich bin gerade dabei meine alten FileLogs in die influxdb zu übertragen. Dazu benutze ich ein kleines shell script.
Vielleicht hat ja noch jemand Bedarf.

Es werden alle im gleichen Verzeichnis gefundenen Logs berücksichtigt. Nach dem Import werden die fertigen Logs nach ./ok verschoben. Vielleicht vor dem finalen Start nochmal mit echo vor der curl Anweisung testen.

#!/bin/bash

host=localhost:8086
influxdb_name=fhem_db


################################################################################


mkdir -p ./ok

for file in $(find . -name "*.log" | sort)
do

  while read line
  do

        year=$(echo $line | cut -d - -f 1)
        month=$(echo $line | cut -d - -f 2)
        day=$(echo $line | cut -d - -f 3 | cut -d _ -f 1)
        hour=$(echo $line | cut -d _ -f 2 | cut -d : -f 1)
        minute=$(echo $line | cut -d : -f 2)
        second=$(echo $line | cut -d : -f 3 | cut -d ' ' -f 1)
        sensor=$(echo $line | cut -d ' ' -f 2)
        reading=$(echo $line | cut -d ' ' -f 3 | cut -d : -f 1)
        value=$(echo $line | cut -d ' ' -f 4)

        time=$(echo $(date -d $year'-'$month'-'$day' '$hour':'$minute':'$second +%s)000000000)

        #Test auf nummerische Werte
        if [ "$(echo $value | grep -o '[0-9.]*')" != "" ]; then
#               echo $year-$month-$day'_'$hour:$minute:$second - $time - $sensor $reading $value
                curl -i -XPOST 'http://'$host'/write?db='$influxdb_name'' --data-binary $reading',site_name='$sensor' value='$value' '$time''
        fi


  done < $file

    mv $file ./ok/$file

done
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: pano am 18 Dezember 2017, 00:00:41
@d.schoen: erst mal vielen Dank für das Modul. Habe mittlerweile so ziemlich alles an Logvisualisierung in Grafana verlegt, was ohne dein InfluxDB Modul nicht geklappt hätte. Danke dafür.
Davon mal abgesehen, entwickelst Du das Modul noch weiter?

Zum einen denke ich, dass man mit den Tags in der Influx noch eine Menge machen könnte (im Sinne von eigene Tags vergeben).

Zum anderen bietet Grafana seit einiger zeit auch sog. Annotations, die man hervorragend nutzen könnte um "binäre" Ereignisse (zB Fenster auf/zu) in den Graphen/Dashboards darzustellen. Die dazugehörige Logik könnte ja auch perspektivisch ins InfluxDB Modul wandern.

Und zu guter Letzt bietet das Modul bisher ja die Möglichkeit per Regex die zu protokollierenden Events einzuschränken. Bei hinreichend vielen verschiedenen zu loggenden Devices und Events wird die DEF aber zunehmend unübersichtlich. Vieleicht wäre ein umgekehrter Ansatz hinfreich iSv an einem Device selbst hinterlegen, ob und welche Events es in InfluxDB loggen soll.

Was denkst Du darüber?
Grüße, Pano
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: doridian am 18 Dezember 2017, 16:26:45
Ich habe mal ein bisschen an dem Modul rumgebaut
Es speichert jetzt auch den device type/module mit als tag.
Ausserdem kann es metrics remappen (und in meiner Version loggt es nur Attribute, wofuer es mappings hat). Weil viele Module loggen z.B. temperatur als "measured-temp" oder "temperature", manche sogar als "other"
Ebenfalls eingebaut habe ich ein globales attribute influxIgnore, womit man devices ignorieren kann, selbst wenn der regex matcht (Diese ganzen HomeMatic subdevices wuerden sonst doppelte Log-Werte eintragen, die nicht wirklich nuetzlich sind)

https://github.com/Doridian/fhem-InfluxDBLog/blob/master/FHEM/93_InfluxDBLog.pm

Vielleicht koennte man auch noch device-specifische remaps einbauen, um die Attribute einzuschraenken.
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: rafael.l am 28 Dezember 2017, 21:17:09
Hallo Leute!

Vielen Dank für die sinnvolle Erweiterung für FHEM. Allerdings habe ich Schwierigkeiten Werte von FHEM an die influxDB zu schicken. Bei der Einrichtung habe ich mich an diese beiden howtos gehalten (https://www.frombeyond.de/2017/influxdb-grafana-setup/ (https://www.frombeyond.de/2017/influxdb-grafana-setup/), https://www.frombeyond.de/2017/fhem-6-grafana-und-influxdb/ (https://www.frombeyond.de/2017/fhem-6-grafana-und-influxdb/)).

Mittlerweile habe ich herausgefunden, dass es an der Formatierung der Log-Datei liegt. Wie muss die Log-Datei aussehen, damit das Modul tut, was es soll?

Diese Formatierung führt zu einem http-400-error:

2017-12-28_21:11:37 WZ_spannung 3023
Vielen Dank für Eure Hilfe!
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: pano am 28 Dezember 2017, 22:49:50
Was genau probierst Du denn? Und was hat die Log Datei damit zu tun? Das Modul schreibt - je nachdem was du in der def stehen hast - alle numerischen Readings die ein Event erzeugen in die InfluxDB.
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: toolking am 30 Dezember 2017, 00:16:34
@d.schoen, danke fürs Modul, wir benutzen influx/grafana in der Firma und ich hab mich gleich wohl gefühlt.
@doridian, danke für die Erweiterung.

Ich habe aber einen kleinen Bug gefunden. Wo kann ich den PR hinschicken? ;)

Negative Werte werden bei mir nicht richtig geschrieben.
in der Funktion: InfluxDBLog_Write
...
my $value = $arr[1];
return if($value =~ m/[^.\d]/);
...
wird hier ein negativer $value rausgeschmissen. Habs bei den negativen Außentemperaturen momentan, zum ersten mal festgestellt.

Mein Fix war, einfach den regex zu erweitern:
m/[^.\d-]/
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: shaddi am 12 Januar 2018, 16:17:47
Damit bleibt die einem die doppelte Datenhaltung erspart.
Auch sind String-Werte wie open/closed kein Problem und man erspart sich zusätzliche numerische Userreadings um das in InfluxDB loggen zu können.

Die Werte kann man dann direkt im SELECT Statement wieder zu Werten mappen um sie in Grafana in den Graphen zu bekommen.
Durch die vielfältigen Funktionen die bei einem SELECT möglich sind, brauchen viele Sachen auch gar nicht in Grafana integriert werden, da man das schon auf MySQL Seite erledigen kann.

z.B. Temperaturdaten ausdünnen und durch Mittelwerte ersetzen, damit der Graph schneller lädt / weniger Traffic erzeugt usw.
Oder Offsets auf Werte aufrechnen um mehrere Kurven übereinander in einem Graphen darzustellen.

Kannst du vielleicht ein-zwei Beispiele rein werfen, bitte? Ich stellte mich gerade echt zu blöd an, sinnvolle SQL-Statements zu definieren, die dann im Grafana irgendwas anzeigen..
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: fischit am 12 Januar 2018, 16:26:16
Kannst du vielleicht ein-zwei Beispiele rein werfen, bitte? Ich stellte mich gerade echt zu blöd an, sinnvolle SQL-Statements zu definieren, die dann im Grafana irgendwas anzeigen..
Beispiele findest du hier einiges: https://forum.fhem.de/index.php/topic,77724.0.html
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: g0t0 am 17 März 2018, 16:20:49
Ich bin leider zu doof für die RegEx...

Ich würde gerne alle Readings in die influxDB schieben, deshalb ist ja erstmal .* die RegEx dafür. Damit kommen nur die rein nummerischen Wert in die DB.
Weitere Versuche von mir:
.*:(\d+\.?\d*)
.*:.*:(\d+\.?\d*)

Im RegEx-Tester filtert es aber genau das was ich will: nur floats und ints. Passt z.B. bei "dim 40", "10 %" und "20.5  C".

Wo ist mein Denkfehler?
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: artcrime am 19 März 2018, 14:14:08
Hi,

ich glaube das influxdb Modul für fhem schreibt nur Integer und Float Werte in die Datenbank. Alles was Strings enthält wird verworfen. Eigentlich Schade ich nutze daher beides mysql und influxdb. Beispielsweise um die Datenübertragungsrate meiner FritzBox in Grafana als Graph darzustellen (Daten aus Influx) und die Externe IP im selben Graph als Annotation anzuzeigen (Daten aus mysql).

Eine Kurve aus influx und eine andere mysql im selben Graph funktioniert aber meines Wissen nach nicht.
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: Thyraz am 19 März 2018, 15:23:16
Was aber nicht am Modul liegt.
InfluxDB kann nur Zahlenwerte.
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: fischit am 19 März 2018, 16:21:53
Das stimmt nicht ganz. Ich bin der Meinung, dass es am Modul liegt:
https://forum.fhem.de/index.php/topic,71551.msg638195.html#msg638195 (https://forum.fhem.de/index.php/topic,71551.msg638195.html#msg638195)
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: artcrime am 19 März 2018, 17:40:58
Richtig, influxdb kann sehr wohl Strings. Siehe https://docs.influxdata.com/influxdb/v1.5/write_protocols/line_protocol_reference/  unter Data Types.
Evtl. konnten ältere Versionen von influxdb das jedoch nicht.
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: g0t0 am 23 März 2018, 19:04:47
Das meinte ich gar nicht. Unanhänig davon ob influxDB oder das Modul Strings unterstützt oder nicht müsste ich doch z.B. "30 lum" oder "10 C" über eine Regex zu einem Integer machen können. Oder muss ich es dazu in Perl noch zum Integer casten?

Geht das überhaupt in einem Statement wie .*:.*[:Regex]
Anscheinend castet Perl automatisch von String auf Integer, wenn man 0 addiert:
my $var1 = "123abc";
print $var1 + 0;
--> ergibt 123

Ist das eine nicht eine einfache Anpassung um mehr Werte von fhem in influxDB zu bekommen?

Unabhängig davon:
Wie sieht es bei euch mit Performance aus? Bei kamen vermehrt Perfmon-freezes im log, seit ich influxDB (und DBlog in PostgreSQL) aktiviert hatte.
fhem läuft bei mir auf einem RPi3, influxDB und PostgreSQL und Grafana auf einem anderen RPi3 in Docker.
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: artcrime am 24 März 2018, 09:28:40
Interessant ich wusste nicht das fhem das kann. Davon abgesehen ist die Syntax um Strings in die influxdb einzufügen leicht anders als bei Integer oder Float:

https://docs.influxdata.com/influxdb/v1.5/write_protocols/line_protocol_reference/

Evtl. muss dazu eine Änderung am Modul vorgenommen werden. Davon abgesehen macht es wenig den Wert mit der Einheit zu mischen da bei der Ausgabe wieder alles auseinander genommen werden muss. sinniger wäre es bei influxdb dafür eine tag zu vergeben z.B. unit=Celsius denn der Tag ist gleich ein Index ähnlich wie in mysql und das macht die Suche in den Daten sehr schnell.

Zur Performance kann ich nur sagen das ich keinerlei Probleme mit meinem Pi3 habe. Habe dort divers influxdb Datenbanken drauf. Z.B. Temperatur Logging mit knapp 4 Millionen Measurements über mehrere Jahre. Wenn ich mir dort mit Grafana alle Werte der Aussentemperatur der letzten 5 Jahre raussuche (knapp 550000 Werte) werden die Daten auf 7 Tage gruppiert und das Ganze dauert 30 Sekunden.

Gleichzeitig läuft auf dem selben pi3 eine mysql Datenbank, fhem und in die Influxdb wird ständig sehr viel geschrieben. Probleme bekomme ich nur wenn ich zuviel rumdaddele....
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: pano am 24 März 2018, 10:23:25
Hat schon jemand Erfahrungen mit annotations in Grafana? Wenn ich das richtig sehe, kann man per CLI "Ereignisse" übergeben, die Mann dann in Grafana im Grafen anzeigen kann.

Man könnte zB das öffnen von Fenstern als Annotations im Grafen hinterlegen (senkrechte Linie im Grafen mit Detailinfos beim "Mouseover")

Ggf. kann man das im Modul ja auch unterbringen... (wenn man deutlich mehr Ahnung hat von Perl als ich ;-)
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: artcrime am 24 März 2018, 12:54:17
Genau das mache ich bereits. Man kann die Annotations für ein Dashboard auch aus einer anderen Datenquelle laden. In meinem Fall kommen die Daten für die Kurven aus der influxdb und die Annotations aus mysql.
Man kann auch mehrere Annotations aus verschiedenen Datenquellen oder mit verschiedenen Farben laden. Ist nicht wirklich kompliziert.

Alternativ kann man auch selbst Annotations anlegen wenn man mit CTRL-linksklick im Graph bestimmte Stellen markiert.
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: sparkiie am 24 August 2018, 20:32:26
Besteht eigentlich anders herum die Möglichkeit Daten aus einer bestehenden influxdb als Readings im FHEM zu nutzen?
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: kadettilac89 am 25 August 2018, 18:32:34
ich habe mir den Thread mal durchgelesen. Habe ein paar Fragen dazu. Läuft vermutlich bei einigen schon ein paar Monate

define influxlog InfluxDBLog localhost 8086 fhem user pw .*
--> das ".*" legt fest für welche Events in die Datenbank geschrieben wird. Gibt es eine Möglichkeit hier explizit Devices ein- oder auszuschließen?

Hat jemand einen Vergleich um wieviel größer oder kleiner der Speicherplatz von InfluxDb in Vergleich zu MySQL ist?

Gibt es ein Script das von MySQL nach InfluxDb migriert? Zumindest die Readings mit numerischen Werten.
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: gerhardg am 26 August 2018, 08:54:50
Speicherplatz hängt halt davon ab wie viele Geräte du hast und wie oft du Werte wegschreibst. Ich nutze dieses Modul seit 21.05.2017 und die DB für fhem ist aktuell 148mb groß.
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: kadettilac89 am 26 August 2018, 09:49:56
Speicherplatz hängt halt davon ab wie viele Geräte du hast und wie oft du Werte wegschreibst. Ich nutze dieses Modul seit 21.05.2017 und die DB für fhem ist aktuell 148mb groß.

Muss ich mal versuchen die Daten aus MySQL in Influx zu pushen. Ist halt nicht direkt vergleichbar (Kombination measurments + points). Wie du sagst, Größe ist abhängig von Geräten, Retention time und Häufigkeit.
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: DanielStern am 07 September 2018, 10:00:43
Hallo zusammen,
danke erst einmal für diese tolle Erweiterung. Hat schon jemand Erfahrungen damit, wenn die InfluxDB nicht erreichbar ist. Ich hatte gestern das Phänomen, dass meine externe InfluxDB offline war (wegen Wartungsarbeiten). Das hat dazu geführt, dass sich die gesamte Kommunikation in FHEM die auf einem anderen Server läuft verabschiedet hat. FHEM verlor die Verbindung zur Homatic-Bridge und anderen LAN-Komponenten. Reboots des FHEM-Servers und der Tausch von Hardware hatten nicht geholfen. Erst als ich meine zwei Zeilen InfluxDBLog-Konfiguration in der fhem.cgf auskommentierte hat FHEM wieder richtig funktioniert.

Hat jemand schon einmal ähnliches beobachtet, wenn sein lokaler oder externer InfluxDB-Service nicht erreichbar ist? Gibt es in der Erweiterung einen Fallback, wenn eben genau dies passiert?
Beste Grüße
Danny
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: plin am 17 September 2018, 15:24:57
Hat jemand schon einmal ähnliches beobachtet, wenn sein lokaler oder externer InfluxDB-Service nicht erreichbar ist?
Kommt mir bekannt vor ...
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: volschin am 19 September 2018, 08:56:48
Ist leider wie bei einer ganzen Anzahl anderer Komponenten. FHEM ist da nicht besonders fehlertolerant und das gesamte System wird blockiert.  :(
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: kadettilac89 am 19 September 2018, 09:22:44
Hat jemand schon einmal ähnliches beobachtet, wenn sein lokaler oder externer InfluxDB-Service nicht erreichbar ist? Gibt es in der Erweiterung einen Fallback, wenn eben genau dies passiert?

Im DBLog ist das von DS_Starter gut gelöst, da wird asynchron geschrieben - per Attribut aktivierbar. Wenn die DB kurzzeitig nicht erreichbar ist läuft FHEM seelenruhig weiter.
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: kadettilac89 am 22 September 2018, 08:40:12
Muss ich mal versuchen die Daten aus MySQL in Influx zu pushen. Ist halt nicht direkt vergleichbar (Kombination measurments + points). Wie du sagst, Größe ist abhängig von Geräten, Retention time und Häufigkeit.
mal eine Zahl hierzu, vielleich interessiert es jemanden. Habe mal zum Test meine MySQL Db in Influx eingelesen.

Zeilen ca. 500.000
Nahezu alle Readings sind numerisch

- MySQL Format MyISAM 47MB
- InfluxDB 51MB
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: wuast94 am 22 September 2018, 19:28:44
gibt es eine möglichkeit werte in die datenbank zu schreiben die nicht nur zahlen sind? meine strom messung zb hat das reading "1.37 kWh" oder "   
24.5 W" allerding nimmt er die ja nicht weil es nicht nur zahlen sind.
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: kadettilac89 am 23 September 2018, 10:03:54
gibt es eine möglichkeit werte in die datenbank zu schreiben die nicht nur zahlen sind? meine strom messung zb hat das reading "1.37 kWh" oder "   
24.5 W" allerding nimmt er die ja nicht weil es nicht nur zahlen sind.
Möglich, ich habe mir userReadings angelegt und diese dann geloggt. Dann sind es reine zahlen und gut ist ...

beispiel
attr sysmon userReadings wlan0_diff_RX:wlan0_diff.* { my @a = split ' ',ReadingsVal($name,'wlan0_diff',0);;$a[1] },\
wlan0_diff_TX:wlan0_diff.* { my @a = split ' ',ReadingsVal($name,'wlan0_diff',0);;$a[4] }
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: kadettilac89 am 23 September 2018, 18:02:26
Vielleicht kanns jemand gebrauchen

habe mir ein Perl-Script geschrieben um Daten von DbLog nach Influxdb zu migrieren

- MySQL Konfiguration wird aus FHEM genommen
- InfluxDB host, port, user, pw müssen im Script eingetragen (geändert) werden
- InfluxDB, user und pw muss bereits existieren ... wenn das Modul bereits installiert ist - DB, user + pw von der Definition übernehmen
- Log der nicht geschriebenen Sätze wird im Fhem-Logverzeichnis erstellt

Läuft bei mir mit 500.000 Sätzen ca. 1 Stunde. Kann mehrfach ausgeführt werden. Sätze die schon existieren werden von InfluxDB ignoriert

Wenn man die anzahl der verarbeiteten Sätze sehen will Zeile 84 wieder einkommentieren, "      #print "$cnt\n";"   dann sieht man  bei welchem Satz (Nummer) gerade gearbeitet wird.

Läuft mit einem DB-Cursor somit läuft Memory nicht über. Dafür läufts länger.

Wenn man den Select einschränkt kann man auch paketweise arbeiten. Ich lade mir aktuell alle 5 Minuten die Sätze in InfluxDB. Beispielselect ist im Script als Kommentar enthalten.

Nicht-numerische Sätze landen im Fehlerlog, werden nicht migriert

Ansonsten ... läuft, jedoch etwas DB-Wissen vorausgesetzt. Und sichern ... ich bin nicht für Datenverluste verantwortlich :)

Aufruf auf der Console

perl mysql2influx__db_fhem.pm
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: wuast94 am 25 September 2018, 00:09:24
wäre geil wenn das script oder das modul selbst von alleine nicht nummerische werte in nummerische werte umwandeln würde .. dann hat man den stress mit userreadings etc nicht
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: kadettilac89 am 25 September 2018, 07:14:57
wäre geil wenn das script oder das modul selbst von alleine nicht nummerische werte in nummerische werte umwandeln würde .. dann hat man den stress mit userreadings etc nicht

die Readings müssen in Fhem behandelt werden, entweder im erzeugenden Modul oder im InfluxDB-Modul. Aber hier auch die Frage ... wie soll das Modul wissen wie du das Reading haben möchtest.

Das Script ist für eine initiale Befüllung gedacht. Mapping ist leicht einzubauen ...

my ($timestamp, $unixts, $device, $reading, $value) = @row;  
#print $timestamp,$device,$reading,$value,"\n";

----> your code here

my $data = "$reading,site_name=$device value=$value $unixts";
#print "data: $data\n";

Wenn du ein Mapping oder Konvertierung willst kannst das an der markierten Stelle machen. in $value ist der Readingwert, kannst du dir an der Stelle entsprechend erweitern.
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: wuast94 am 25 September 2018, 11:45:28
naja in dem moment wo ich ein gerät habe das als reading zb "254 W" hat muss ich dann ja n user reading anlegen das dann n reading mit "254" anlegt und dann ist es quasi doppelt. Also wäre es da sinnvoll wenn das influxdb modul einfach aus "254 W" "254" in die db schreibt. So wie es momentan ist wird es einfach gar nicht geloggt.
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: kadettilac89 am 25 September 2018, 13:13:43
naja in dem moment wo ich ein gerät habe das als reading zb "254 W" hat muss ich dann ja n user reading anlegen das dann n reading mit "254" anlegt und dann ist es quasi doppelt. Also wäre es da sinnvoll wenn das influxdb modul einfach aus "254 W" "254" in die db schreibt. So wie es momentan ist wird es einfach gar nicht geloggt.

Steht im Reading oder in state das "254 W"? Hast du DBLog im Einsatz, steht da im Feld "Value" wirklich 254 W? DBLog sollte
Value    254
unit       W
loggen. Wenn nicht ist das ein Thema für das ursprüngliche Modul, nicht für InfluxDB-Modul.
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: wuast94 am 25 September 2018, 17:43:09
im dblog modul ist das getrennt meine ich ja. aber das script würde ich zum einmaligen übertragen nutzen und den rest dann mit influxdb loggen. anstatt beides pöaralell laufen zu lassen und mit dem script immer alles neue übertragen.

deswegen meine ich wäre es sinnvoll wenn das influxdb modul das von sich aus machen würde .. dann könnte ich einfach komplett umsteigen. so muss beides laufen was iwie öde ist
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: kadettilac89 am 25 September 2018, 18:21:36
im dblog modul ist das getrennt meine ich ja. aber das script würde ich zum einmaligen übertragen nutzen und den rest dann mit influxdb loggen. anstatt beides pöaralell laufen zu lassen und mit dem script immer alles neue übertragen.

deswegen meine ich wäre es sinnvoll wenn das influxdb modul das von sich aus machen würde .. dann könnte ich einfach komplett umsteigen. so muss beides laufen was iwie öde ist
ich verstehe das problem nicht. wenn es in dblog sauber geloggt wird ist das reading ja numerisch, wieso soll das dann hier nicht funktionieren? hast du es getestet und die werte fehlen?
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: wuast94 am 03 Oktober 2018, 22:39:24
kann es sein das das modul ohne dblogging nicht funktioniert ? hatte alles eingerichtet und funktionerte auch alles und seid dem ich dblog gelöscht habe wird nichts mehr in die influx db geschrieben.

state ist activ.
verbose auf 5 und im log geguckt aber da steht nur:
2018.10.03 22:38:17 4 : Influxdblog: Log
2018.10.03 22:38:17 4 : Influxdblog: 73
2018.10.03 22:38:17 4 : Influxdblog: Log End
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: Patrick85 am 18 Oktober 2018, 17:32:31
Hallo wuast94,
bei mir funktioniert das Modul auch ohne dblog. Ich habe alle dblog Einstellungen nach der Umstellung auf influxdb komplett aus der Konfiguration entfernt.
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: Dave90 am 02 November 2018, 18:37:50
Hallo,
zunächst vielen Dank für das Modul. :)
Habe Grafana und die Influxdb aufgesetzt und fhem schreibt auch direkt fleißig Werte, welche ich mit Grafana auslesen kann.
Leider habe ich aber trotzdem ein Problem:
Fhem schreibt jedes reading als ein measurement. Das bedeutet bspw. bei mehreren Temperatursensoren habe ich nur einmal das measurement "temperature" auf das alle Sensoren schreiben. Wie habt ihr das gelöst? ;)

Edit: Ok kann über das site_name im query gelöst werden. Hat sich erledigt ;)

Danke und viele Grüße
David
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: highball am 09 Januar 2019, 16:33:40
Hallo zusammen,

erstmal vielen Dank für das influxdb Modul  :), ich habe jetzt soweit alles zusammen mit Grafana am laufen... Aber jetzt zu meiner Frage: Ich würde nun gerne meine FritzBox einbinden, dabei aber nur wenige definierte readings in die influxdb schreiben: box_powerRate, box_rateDown, box_rateUp box_wlanCount

Beim "normalen" DbLog würde ich nun: "attr FritzBox DbLogInclude  box_powerRate,box_rateDown,box_rateUp,box_wlanCount"

Funktioniert das dann auch mit "InfluxDbLog", also "attr FritzBox InfluxDbLogInclude  box_powerRate,box_rateDown,box_rateUp,box_wlanCount" oder muss ich hier dann DbLogInclude nutzen? Irgendwie bekomme ich das nicht so hin wie ich gerne würde  ;)

Vielen Dank und viele Grüße
Jens
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: plin am 21 Januar 2019, 18:18:08
Hi,

ich habe das Modul seit einigen Monaten im Einsatz. Ich habe beobachtet, dass sich die FHEM-GUI aufhängt wenn die Influx-DB nicht zu erreichen ist. Hat jemand anders auch schon die Erfahrung gemacht?

VG plin
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: kadettilac89 am 21 Januar 2019, 19:13:17
Hi,

ich habe das Modul seit einigen Monaten im Einsatz. Ich habe beobachtet, dass sich die FHEM-GUI aufhängt wenn die Influx-DB nicht zu erreichen ist. Hat jemand anders auch schon die Erfahrung gemacht?

VG plin

https://forum.fhem.de/index.php/topic,71551.msg837607.html#msg837607



Im DBLog ist das von DS_Starter gut gelöst, da wird asynchron geschrieben - per Attribut aktivierbar. Wenn die DB kurzzeitig nicht erreichbar ist läuft FHEM seelenruhig weiter.

bekannt aber ist halt nicht asynchron.
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: ChrisW am 24 Januar 2019, 20:33:40
Musste das asynchron bei dblog zu mysql auch aktivieren sonst ging bei fhem nichts mehr .. Ist das bei dem Modul hier auch ?

Würde das Modul gerne nutzen aber nicht wieder alle Geräte per dbloginclude/dblogexclude durchgehen was ich loggen will.

Wie richte ich das ganze am besten ein ? Will Grafana nutzen mit dieser Datenbank. Speicherplatz habe ich genug auf dem NAS also wollte ich erstmal beides parallel laufen lasen.
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: kadettilac89 am 24 Januar 2019, 22:16:01
Musste das asynchron bei dblog zu mysql auch aktivieren sonst ging bei fhem nichts mehr .. Ist das bei dem Modul hier auch ?

Würde das Modul gerne nutzen aber nicht wieder alle Geräte per dbloginclude/dblogexclude durchgehen was ich loggen will.

Wie richte ich das ganze am besten ein ? Will Grafana nutzen mit dieser Datenbank. Speicherplatz habe ich genug auf dem NAS also wollte ich erstmal beides parallel laufen lasen.

asynchron gibts (noch) nicht. deine infrastruktur muss stabil und verfügbar sein sonst hängt fhem

alle Geräte per dlboninclude / exclude bringt sowieso nichts da du die definition direkt im influxdb device machen musst.

Anlegen:
influx installieren .... gidf, gibt genügend anleitungen, in docker z. b. https://forum.fhem.de/index.php/topic,71551.msg631786.html#msg631786

db anlegen, z. b. influxfhem   https://docs.influxdata.com/influxdb/v1.7/query_language/database_management/#create-database

user mit passwort anlegen
https://docs.influxdata.com/influxdb/v1.7/administration/authentication_and_authorization/#user-management-commands

device in fhem anlegen
https://forum.fhem.de/index.php/topic,71551.msg630749.html#msg630749
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: ChrisW am 25 Januar 2019, 07:50:30
Danke aber dann muss ich wohl einen anderen weg finden :/
Ich habe bei dblog + ganz wenig werte die geloggt werden schon ein lahmes FHEM .. Läuft auf einem PI3 ... ohne was anderes. DB auf einem mysql Docker in der Synology .. 1 switch dazwischen NAS sogar mit 2 Lan angeschlossen usw. also am Netzwerk kann es nicht liegen da läuft alles ganz gut.
Ich werde es aber mal Versuchen in der hoffnung das es zu keinen "hänger" kommt.

Bei dblog wird auch quasi nichts gecached aber fhem bleibt sehr schnell.

Gibt es da vielleicht was anderes um die Daten auf dem sql docker in ein influxdb zu bekommen ? Ohne Fhem ? Da ich dort alle Geäte ja schon durch bin in include/exclude.

Edit: das hier wäre vielleicht etwas wenn fhem langsam werden sollte.
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: kadettilac89 am 25 Januar 2019, 08:41:11
Ich habe bei dblog + ganz wenig werte die geloggt werden schon ein lahmes FHEM .. Läuft auf einem PI3 ... ohne was anderes. DB auf einem mysql Docker in der Synology .. 1 switch dazwischen NAS sogar mit 2 Lan angeschlossen usw. also am Netzwerk kann es nicht liegen da läuft alles ganz gut.

dann passt irgend was am setup nicht. ich habe auf meinem  raspberry mysql, influx, telegraf, fhem, kodi, und noch mehr und es hängt nichts. habe bewusst nichts auf die synology gepackt. Wenn synology in sleep mode geht hast du, egal wie gut das netzwerk ist, erstmal ein paar sekunden bis die festplatten wieder ansprechbar sind. Docker nutze ich - aktuell - auf dem rpi nicht da ich keine docker-compose umgebung für v2/v3 gefunden habe bzw. zum laufen bekommen habe.


Gibt es da vielleicht was anderes um die Daten auf dem sql docker in ein influxdb zu bekommen ? Ohne Fhem ? Da ich dort alle Geäte ja schon durch bin in include/exclude.

Damit lade ich mir alle 10 min das letzte 15 min delta von Mysql in eine influxdb. influx ignoriert dubletten ... darum überlappend
https://forum.fhem.de/index.php/topic,71551.msg838940.html#msg838940
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: ChrisW am 25 Januar 2019, 10:10:16
Vielleicht kanns jemand gebrauchen

habe mir ein Perl-Script geschrieben um Daten von DbLog nach Influxdb zu migrieren

- MySQL Konfiguration wird aus FHEM genommen
- InfluxDB host, port, user, pw müssen im Script eingetragen (geändert) werden
- InfluxDB, user und pw muss bereits existieren ... wenn das Modul bereits installiert ist - DB, user + pw von der Definition übernehmen
- Log der nicht geschriebenen Sätze wird im Fhem-Logverzeichnis erstellt

Läuft bei mir mit 500.000 Sätzen ca. 1 Stunde. Kann mehrfach ausgeführt werden. Sätze die schon existieren werden von InfluxDB ignoriert

Wenn man die anzahl der verarbeiteten Sätze sehen will Zeile 84 wieder einkommentieren, "      #print "$cnt\n";"   dann sieht man  bei welchem Satz (Nummer) gerade gearbeitet wird.

Läuft mit einem DB-Cursor somit läuft Memory nicht über. Dafür läufts länger.

Wenn man den Select einschränkt kann man auch paketweise arbeiten. Ich lade mir aktuell alle 5 Minuten die Sätze in InfluxDB. Beispielselect ist im Script als Kommentar enthalten.

Nicht-numerische Sätze landen im Fehlerlog, werden nicht migriert

Ansonsten ... läuft, jedoch etwas DB-Wissen vorausgesetzt. Und sichern ... ich bin nicht für Datenverluste verantwortlich :)

Aufruf auf der Console

perl mysql2influx__db_fhem.pm

Sorry aber wie benutze ich da sam besten auf meinem PI ? Kann man das per FHEM ? Habe es in /opt/fhem liegen und in /opt/fhem/FHEM Wäre doch schön es aus fhem erraus zu starten ?
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: kadettilac89 am 25 Januar 2019, 10:18:14
Sorry aber wie benutze ich da sam besten auf meinem PI ? Kann man das per FHEM ? Habe es in /opt/fhem liegen und in /opt/fhem/FHEM Wäre doch schön es aus fhem erraus zu starten ?

ich habe einen eintrag in der crontab. ansonsten ein "at" in fhem. such im forum wie du aus fhem ein system-command absetzen kannst. müsste selber suchen, gibt genügend anfragen im anfänger-bereich.
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: ChrisW am 25 Januar 2019, 11:23:07
okay also das script läuft ich sehe auch die Werte und auch die Geräte zeigt er mir an .. aber ich bekomme keine Ausgabe in Grafana nicht und auch in chronograpf was vorher sofort klappte. Er sagt dort syntax stimmt aber keine Inhalte.

Vorher hat das Modul ja kein Device geloggt sondenr nur die Readings nun habe ich auch überall die Geräte das macht wohl irgendwie Probleme
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: kadettilac89 am 25 Januar 2019, 13:02:36
keine ausgabe ist komisch, selbst wenn das script blödsinn macht werden keine bestehende daten gelöscht. es liest nur daten aus mysql und fügt in influx ein.

läuft das script noch? bei mir lief die initiale befüllung ohne filter eine stunde. ... starte mal raspberry und synology durch.
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: ChrisW am 25 Januar 2019, 14:19:10
also hab mal eingeschaltet das er Zeigt wieviel er schon hat bin bei 23000  aber bisher wohl nirgends value enthalten .. warten wir mal ab bis er fertig ist... aber schon komisch

Es geht es musste wirklich komplett durchlaufen :D Erst jetzt kann ich mir alle Werte anschauen
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: plin am 25 Januar 2019, 17:49:29
asynchron gibts (noch) nicht. deine infrastruktur muss stabil und verfügbar sein sonst hängt fhem

Ich habe gerade mal folgende Variante eingerichtet und getestet:

FHEM1 -> FHEM3 in Docker mit FHEM2FHEM und InfluxDBLog -> InfluxDB in Docker
FHEM2 -> FHEM3 in Docker mit FHEM2FHEM und InfluxDBLog -> InfluxDB in Docker

Die relevanten Passagen aus der FHEM1 fhem.cfg:
define 1to3 FHEM2FHEM 172.17.0.4:7072 LOG:.*
attr 1to3 eventOnly 1

define 2to3 FHEM2FHEM 172.17.0.3:7072 LOG:.*
attr 2to3 room Master

define influxlog InfluxDBLog 192.168.1.111 8086 fhem fhem fhem .*
attr influxlog addStateEvent 1

Alle Reading-Änderungen aus den Instanzen FHEM1, FHEM2 und FHEM3 werden in die InfluxDB geschrieben. Die Anzeige erfolgt in Grafana (ebenfalls in einem Docker Container).
Wenn ich den Docker-Container stoppe laufen FHEM1 und FHEM2 problemlos weiter (mir fehlen dann nur die Metriken in der InfluxDB).

Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: kadettilac89 am 25 Januar 2019, 22:04:57
also hab mal eingeschaltet das er Zeigt wieviel er schon hat bin bei 23000  aber bisher wohl nirgends value enthalten .. warten wir mal ab bis er fertig ist... aber schon komisch

Es geht es musste wirklich komplett durchlaufen :D Erst jetzt kann ich mir alle Werte anschauen

Möglich dass beim ersten Lauf noch Strukturdaten fehlen. Beim Update später alle x-Minuten sollte das nicht mehr passieren.
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: pitre am 26 Januar 2019, 11:15:07
Ich kenn mich jetzt noch nicht so gut aus, v.a. bei "tiefergehenden" FHEM-Anwendungen.
Es ist so: ich habe eine influx-db, die Daten aus anderen Systemen aufzeichnet - und auf diese Daten möchte ich in FHEM zugreifen und diese für Abfragen nutzen (im Speziellen: der aktuelle Temperaturwert aus einem Measurement).
Meine Frage: kann man die Daten aus der influx-db auch auslesen, und wenn ja, wie?

Danke euch!
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: kadettilac89 am 26 Januar 2019, 11:18:13
https://forum.fhem.de/index.php/topic,77724.0.html

Grafana
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: ChrisW am 26 Januar 2019, 15:35:55
noch eine kurze frage wie startest du das script "mysql2influx__db_fhem.pm" per cronjob ?
Und was passiert wenn das script noch nciht fertig war ? Hatte es gestern abend das letzte mal laufen und nun braucht es schon wieder schon 1 Stunde. Wenn nu der Cronjob vorher das nochmal startet ?

Kann das script auch nur per sudo starten egal ob Home oder wo auch immer es liegt.
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: kadettilac89 am 26 Januar 2019, 15:54:11
noch eine kurze frage wie startest du das script "mysql2influx__db_fhem.pm" per cronjob ?
Und was passiert wenn das script noch nciht fertig war ? Hatte es gestern abend das letzte mal laufen und nun braucht es schon wieder schon 1 Stunde. Wenn nu der Cronjob vorher das nochmal startet ?

Kann das script auch nur per sudo starten egal ob Home oder wo auch immer es liegt.

wenn es eine stunde läuft hast du keine einschränkung auf 15 minuten oder so. änderung auf die ich irgendwo mal hingewiesen hab. wenn alle 5 minuten der job läuft dann lese ich alles was die letzten 15 minuten geändert wurde. dubletten werden sowieso ignoriert. läuft bei mir ein paar sekunden. für den fall, dass dein server down ist muss du halt manuell nochmal einen full-load machen damit wieder alles drin ist, oder größeren range im timestamp verwenden.

änderung im script ... where-clause timestamp
my $SQL_QUERY=<<__CURSOR_1__;
select timestamp, UNIX_TIMESTAMP(timestamp), device, reading, value  from history where timestamp > TIMESTAMP(DATE_SUB(NOW(), INTERVAL 15 minute))
__CURSOR_1__


globale crontab ....

nano /etc/crontab
# mysql2influx
*/5 * * * * root perl /usr/local/bin/mysql2influxdb_15min.pm >>/dev/null 2>&1
service cron restart       ist nötig damit die geänderte crontab verwendet wrid, alternativ server restart.

alternativ zu der globalen crontab ... crontab -e ... verwenden, s. https://wiki.ubuntuusers.de/Cron/ .... ist für dich als anfänger in dem bereich vorzuziehen.
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: ChrisW am 26 Januar 2019, 19:19:39
Edit:
Okay da er immer 65000 hochzählt hab ich das mal mit den letzten15 minuten versucht bin gespannt. Hoffe nur das das nie mal ausfällt
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: kadettilac89 am 27 Januar 2019, 12:12:05
Edit:
Okay da er immer 65000 hochzählt hab ich das mal mit den letzten15 minuten versucht bin gespannt. Hoffe nur das das nie mal ausfällt

wenn du das Skript in Crontab hast mache den Zähler raus, der flutet dir sonst das daemon-log.
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: plin am 27 Januar 2019, 15:39:00
Ich hätte da einen Wunsch fürs Modul selbst:

Bei nicht numerischen Werten gibt es Fehlermeldungen im Log. Die würde ich überspringen.

Praktisch wäre außerdem ein Mapping für den Status
Sieht bei mir dann so aus:

diff 93_InfluxDBLog.pm 93_InfluxDBLog.pm.orig
114,121c114
<   my $value = $arr[1];
<   return if ! ( $value =~ /^[0-9,.E]+$/ );
<   $value = 1   if ( lc $value eq "on");       # state on
<   $value = 0   if ( lc $value eq "off");      # state off
<   $value = 1   if ( lc $value eq "open");     # contact open
<   $value = 0   if ( lc $value eq "closed");   # contact closed
<
<   my $data = "$arr[0],site_name=$NAME value=$value";
---
>   my $data = "$arr[0],site_name=$NAME value=$arr[1]";

VG plin
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: kadettilac89 am 27 Januar 2019, 17:49:33
Ich hätte da einen Wunsch fürs Modul selbst:

Bei nicht numerischen Werten gibt es Fehlermeldungen im Log. Die würde ich überspringen.

Praktisch wäre außerdem ein Mapping für den Status
  • on => 1
  • off => 0
  • open => 1
  • closed => 0


muss der modulauthor entscheiden.  ... nice to have aber es gibt wichtigere requests. mapping im fhem device selber ...

https://forum.fhem.de/index.php/topic,71551.msg839403.html#msg839403
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: plin am 27 Januar 2019, 18:59:17
mapping im fhem device selber ...

Na ja, wie wär's denn mit der Variante: Im InfloxDBLog-Modul wird das Regelwerk in einem oder mehreren Attributen als Tabelle hinterlegt
s/on/1/
s/off/0/
s/open/1/
s/closed/0/

Die Attribute könnten den Namen des Readings beinhalten auf das die regex angewandt werden sollen
Wenn die Variable $value im Modul gefüllt ist, kann das Regelwerk angewandt werden.

Beispiel:
#!/usr/bin/perl

my $value = "closed";
@trial_array = ("s/on/1/", "s/off/0/", "s/open/1/", "s/closed/0/");
foreach $regex (@trial_array)
{
    my $formula = "\$value =~ ".$regex.";";
    eval($formula);
}
print $value."\n";

Der Vorteil dieser Lösung: man muss die Regeln nur einmal zentral definieren und nicht in jedem Device einzeln.
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: kadettilac89 am 27 Januar 2019, 19:50:07


Der Vorteil dieser Lösung: man muss die Regeln nur einmal zentral definieren und nicht in jedem Device einzeln.

Wie gesagt. Muss der Autor entscheiden. Das Modul wurde schon eine Weile nicht mehr angepasst.

Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: plin am 27 Januar 2019, 19:55:48
Das Modul wurde schon eine Weile nicht mehr angepasst.
Seine persönliche Forumseite sagt

Letzter Besuch:
    02 Mai 2018, 13:16:22

Wenn der nicht mehr aktiv ist (sein Problem ist gelöst) muss man vielleicht einen Fork starten ...

P.S. Habe ihm gerade eine PN geschickt.
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: kadettilac89 am 27 Januar 2019, 20:07:53
Könnte man, ja. Ds_starter, maintainer vom dblog wollte sich das Thema mal ansehen. Aktuell ist die Nachfrage aber gering. Es funktioniert und es gibt wenige Nutzer.
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: DS_Starter am 27 Januar 2019, 20:22:14
Zitat
Könnte man, ja. Ds_starter, maintainer vom dblog wollte sich das Thema mal ansehen. Aktuell ist die Nachfrage aber gering.
Hallo ihr zwei. Ich lese tatsächlich immer mal mit.
Es ist tatsächlich so, dass ich einfach zu wenig Zeit habe und momentan mit meinen Modulen und deren Weiterentwicklung gut beschäftigt bin.  ;)
Und da ich influxDbLog selbst nicht einsetze, ist die Motivation nicht so dramatisch hoch. Bin eher im MySQL/MariaDB Umfeld tätig.
Eigentlich hatte ich vor einen DbLog-Nachfolger nur für MySQL über das Winterhalbjahr zu bauen, was sich wirklich nur um das Logging kümmert. Alles andere liegt im DbRep. Ich weiß nicht ob ich es noch schaffen werde.

Dann könnte man evtl. influxDb als noSQL mit integrieren. Es war nämlich mein Problem, dass die vielen Zusatzfunktionen die es seit langem im DbLog gibt, nicht mit einer noSQL harmonieren und schlecht programmtechnisch zusammengeführt werden können.
Bei einem neuen Modul könnte man es im Design berücksichtigen.

Mal schauen ... Aber vielleicht macht der Influx-Autor auch nur eine schöpferische Pause. :)

Grüße
Heiko
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: ChrisW am 27 Januar 2019, 21:11:56
also ich als nichts mysql Profi finde dieses Influx echt super.
Die Auswertungen mit Grafana sind echt Kinderleich. Glaub wenn es da eine Schnitstelle direkt im dblog gibt werden das viel mehr benutzen.

DBlog und mysql funktioniert ja sehr gut. Influxdb hier legt leider mein FHEM lahm :(
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: d.schoen am 27 Januar 2019, 21:31:26
Hallo, ich war in der Tat länger nicht mehr da und das Modul auch nur so ein Testfeld.

Es freut mich natürlich, dass mein Modul Anklang findet. „Leider“ bin ich kittlerweile aber auf OpenHAB umgestiegen.

Macht daher gern einen Fork und entwickelt das Modul nach euren Wünschen weiter.
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: DS_Starter am 27 Januar 2019, 21:36:28
Jede DB hat ihre Stärken und nicht für jeden Zweck ist jede DB gleich gut geeignet. Es gibt natürlich nicht nur Influx als noSQL, sondern  z.B. auch MongoDB und mehr.
Damit die Influx dein FHEM nicht ausbremst, wäre wahrscheinlich eine ähnliche Technik wie ich sie bei DbLog mit dem asynchronen Mode eingebaut habe, ausreichend. Allerdings kenne ich mich mit der InfluxDB nicht aus, müßte mich erst intensiv damit befassen.
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: kadettilac89 am 27 Januar 2019, 21:42:47
Influxdb hier legt leider mein FHEM lahm :(

du kannst ja mal testen was plin gemacht hat. die idee hatte ich auch mal aber plin war schneller :)

mach dir eine 2. fhem instanz die nur dazu da ist, in influxdb zu schreiben. hauptinstanz mach normale arbeit, zweite instanz hat das influxdb device und schreibt. verbunden über fhem2fhem. ist ein asynchron-workaround.
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: MarkusN am 31 Januar 2019, 14:23:02
Ich hätte da einen Wunsch fürs Modul selbst:

Bei nicht numerischen Werten gibt es Fehlermeldungen im Log. Die würde ich überspringen.

Praktisch wäre außerdem ein Mapping für den Status
  • on => 1
  • off => 0
  • open => 1
  • closed => 0
Sieht bei mir dann so aus:

diff 93_InfluxDBLog.pm 93_InfluxDBLog.pm.orig
114,121c114
<   my $value = $arr[1];
<   return if ! ( $value =~ /^[0-9,.E]+$/ );
<   $value = 1   if ( lc $value eq "on");       # state on
<   $value = 0   if ( lc $value eq "off");      # state off
<   $value = 1   if ( lc $value eq "open");     # contact open
<   $value = 0   if ( lc $value eq "closed");   # contact closed
<
<   my $data = "$arr[0],site_name=$NAME value=$value";
---
>   my $data = "$arr[0],site_name=$NAME value=$arr[1]";

VG plin

Habe das mal eingebaut, aber zumindest der state scheint dabei nicht geloggt zu werden. Funktioniert das so bei dir?
Mir ist auch aufgefallen dass offenbar keine negativen werte mit diesem Plugin geloggt werden. Kann das jemand bestätigen?
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: kadettilac89 am 31 Januar 2019, 16:05:33
Habe das mal eingebaut, aber zumindest der state scheint dabei nicht geloggt zu werden. Funktioniert das so bei dir?
Mir ist auch aufgefallen dass offenbar keine negativen werte mit diesem Plugin geloggt werden. Kann das jemand bestätigen?

ich logge kein state da es m. e. keinen sinn macht. negative werte an sich habe ich aber in der db und diese werden auch in grafana angezeigt. s. angehängtem screenshot
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: plin am 01 Februar 2019, 17:13:33
Funktioniert das so bei dir?
Hat es mal. Jetzt aber nicht mehr. Schaue ich mir am Wochenende an.

Update: Tja, knapp daneben ist auch daneben.

diff 93_InfluxDBLog.pm 93_InfluxDBLog.pm.orig
114,121c114
<   my $value = $arr[1];
<   $value = 1   if ( lc $value eq "on");               # state on
<   $value = 0   if ( lc $value eq "off");      # state off
<   $value = 1   if ( lc $value eq "open");     # contact open
<   $value = 0   if ( lc $value eq "closed");   # contact closed
<   return if ! ( $value =~ /^[0-9,.E]+$/ );
<
<   my $data = "$arr[0],site_name=$NAME value=$value";
---
>   my $data = "$arr[0],site_name=$NAME value=$arr[1]";
Die Numerisch-Prüfung sollte nicht vor der Substitution durchgeführt werden.

In Grafana sollte dann
    FROM default state WHERE site_name = <devicename>
mit
    SELECT field(value) distinct()
ausgewählt werden. Dann gibt's auch was zu sehen.

VG plin
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: ChrisW am 08 Februar 2019, 08:16:13
also das mit dem Modul SQL in Influxdb will einfach nicht so recht. Es funktioniert zwar aber irgendwie viel zu langsam ..
Habe nun schon einestellt check letzte 15 Minuten und lasse es alle 10 Minuten von Fhem ausführen.
Gerade geguckt seit gestern abend habe ich aktuell 6 offene Prozesse mit dem script :(

Ich kann mir nur vorstellen das das Filtern der nicht "zahlen" werte so lange dauert da ich in die sql relativ viel anderes noch speicher ??!!
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: kadettilac89 am 08 Februar 2019, 17:07:32
also das mit dem Modul SQL in Influxdb will einfach nicht so recht. Es funktioniert zwar aber irgendwie viel zu langsam ..
Habe nun schon einestellt check letzte 15 Minuten und lasse es alle 10 Minuten von Fhem ausführen.
Gerade geguckt seit gestern abend habe ich aktuell 6 offene Prozesse mit dem script :(

Ich kann mir nur vorstellen das das Filtern der nicht "zahlen" werte so lange dauert da ich in die sql relativ viel anderes noch speicher ??!!
Kann ich nicht sagen. Ich habe reine zahlenwerte und es hängt nichts. Dann musst du wohl oder übel dein Setup auf influx optimieren.
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: ChrisW am 08 Februar 2019, 19:42:10
ja ich will das mit dem 2. Fhem vermeiden.

Schade das man im Device nicht sowas wie incinflux excinflux setzen kann
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: kadettilac89 am 08 Februar 2019, 19:47:24
Global kannst du das setzen was du loggen willst.
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: ChrisW am 15 Februar 2019, 13:13:22
ja aber da muss ich das alles Manuell exakt angeben :( Würde es gerne per Device steuern. Quasi wie beim dblog

Und wie kann ich da bei influx etwas Optimieren ? Das script zum sql zu influx ist einfach zu langsam :( sehe das im Prozess das es teilweise 6-7 mal immer gleichzeitig offen ist. In Grafana hab ich dadurch oft auch ausfälle das einiges nicht mit kommt. Aktuell musste ich fhem ganz neu starten weil zu viel offen war. Grafana hing schon 3 Stunden zurück.
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: kadettilac89 am 15 Februar 2019, 16:19:53


Und wie kann ich da bei influx etwas Optimieren ? Das script zum sql zu influx ist einfach zu langsam

Das mag für dein setup so sein. Über welche Datenmenge reden wir hier?wie viele Sätze willst du übertragen? Laufzeit war bei mir für 10 Minuten Delta im unteren einstelligen sekundenbereich.

Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: Andreasgs am 18 August 2019, 00:19:58
Hallo Zusammen,

Habe grade mit erschrecken festgestellt, dass es by design nicht möglich ist, dass das InfluxDBLog Modul stings in die Datenbank schreibt. Den fehler hab ich jetzt seit 2 Monaten gesucht.

So wie ich den Thread verstehe, wirds wohl dahingehend keine Besserung geben, und wenn ich in Grafana Strings anzeigen lassen will, (z.B. "Regen?" - "Ja"/"Nein") komme ich an einer zweiten Datenbank wie SQL nicht rum. Ist der Status mittlerweile anders?

 >:( Die hatte ich schon in Nutzung, und habs dann zugunsten der InfluxDB totgelegt.

Grüße,
Andreas
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: plin am 18 August 2019, 08:31:48
Hallo Andreas,

sieh Dir meinen Post weiter oben vom 31 Januar 2019, 14:23:02an.

Ich habe durch Anpassung des Modules aus den üblichen Strings wie on/off, open/closed jeweils Zahlen gemacht. Die Zahlen lassen sich in Grafana dann wieder als Text ausgeben.

VG plin
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: volschin am 18 August 2019, 08:51:39
Habe grade mit erschrecken festgestellt, dass es by design nicht möglich ist, dass das InfluxDBLog Modul stings in die Datenbank schreibt.
Das ist weniger Problem des Moduls, als Design der InfluxDB als Timeseries Datenbank für Messwerte.
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: plin am 22 August 2019, 17:50:30
Hi,

ich war so frei und habe das Modul 93_InfluxDBLog.pm um zwei weitere Attribute ergänzt:

regexp_0: regular expression für strings die auf '0' zu setzen sind, z.B. '(off|closed|battery low)'
regexp_1: regular expression für strings die auf '1' zu setzen sind, z.B. '(on|open|battery ok)'

Alle nicht-numerischen Werte werden übersprungen, erzeugen also keinen Datenbankfehler beim Schreiben.

VG plin
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: W_Esch am 05 Dezember 2019, 16:03:37
Das Schreiben von negativen Werten funktioniert, wenn man in der Zeile vor dem log "Writing data" -->  return if ! ( $value =~ /^[0-9,.E]+$/ ); nach dem E noch ein Minuszeichen setzt. Habe ich heute getestet, nachdem die ersten Minustemperaturen nicht in die InfluxDB geschrieben wurden.
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: kadettilac89 am 08 Dezember 2019, 13:51:37
Das Schreiben von negativen Werten funktioniert, wenn man in der Zeile vor dem log "Writing data" -->  return if ! ( $value =~ /^[0-9,.E]+$/ ); nach dem E noch ein Minuszeichen setzt. Habe ich heute getestet, nachdem die ersten Minustemperaturen nicht in die InfluxDB geschrieben wurden.

Negative Werte werden beim mir seit Beginn korrekt geschrieben. Das Problem hatte hier schon mal jemand nachdem er das Modul um Status 0/1 oder ähnlich erweitert hatte.
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: pitre am 21 Dezember 2019, 15:11:11
Es wurde ja schon ein paar Mal gefragt, aber Antwort konnte ich keine finden.
Ist es möglich Daten aus Influxdb nach FHEM zu laden? Hintergrund: ich habe Daten, die nur in influxdb liegen und die ich über andere Wege auch nicht erhalten kann (kleiner Arduino schickt direkt an influx (und macht einiges anderes) und der Sourcecode ist weg). In FHEM bräuchte ich jetzt genau diese Daten für eine Steuerung.
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: kadettilac89 am 21 Dezember 2019, 16:38:47
Es wurde ja schon ein paar Mal gefragt, aber Antwort konnte ich keine finden.
Ist es möglich Daten aus Influxdb nach FHEM zu laden? Hintergrund: ich habe Daten, die nur in influxdb liegen und die ich über andere Wege auch nicht erhalten kann (kleiner Arduino schickt direkt an influx (und macht einiges anderes) und der Sourcecode ist weg). In FHEM bräuchte ich jetzt genau diese Daten für eine Steuerung.

Mehr Informationen wenn du mehr Input lieferst. Was bedeutet "nach FHEM laden?". Willst du in MySQL laden und in Fhem DBLog nutzen? Wenn ja ... was Fertiges wirst du hier nicht finden da die DB-Strukturen zu unterschiedlich sind.

Möglicher Weg wenn du ein bischen IT-Background hast
1) lade dir einen INfluxdb Editor / Client runter. z. B. InfluxDB Studio und exportiere die Werte in CSV
2) Bearbeite die Daten in Excel o. ä.
3) Lade die CSV in PhpMyadmin oder Console in MySQL

Vorgehen abhängig von Datenstruktur und Menge vielleicht nicht anwendbar bzw. in Paketen.

Ich habe hier mal die umgekehrte Richtung befüllt .... wenn du Perl kannst könntest du dir auch sowas basteln.
https://forum.fhem.de/index.php/topic,71551.msg838940.html#msg838940
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: KernSani am 21 Dezember 2019, 17:24:56
Ich habe auch einen Anwendungsfall bei dem ich Daten aus einer InfluxDB verwenden möchte... allerdings nicht über CSV oder Excel o.ä. sondern per Direktzugriff... Ich mache mir dazu mal ein paar Gedanken...
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: KernSani am 21 Dezember 2019, 21:35:36
@pitre: Wie sieht dein Anwendungsfall konkret aus? Ich habe mir einen kleinen Prototypen in 99_myUtils gebaut, mit dem ich die InfluxDB abfragen kann. Das würde ich nun in ein Modul gießen. Für meinen aktuellen Anwendungsfall ist es völlig ausreichend den aktuellen (letzten) Wert eines Feldes in ein Reading zu schreiben. Wenn dein Anwendungsfall komplexer ist, kann ich das ja vielleicht gleich irgendwie berücksichtigen...

Grüße,

Oli
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: pitre am 22 Dezember 2019, 08:53:53
Danke für eure schnellen Antworten!
Im konkreten schaut mein Fall so aus: ich habe ein Aquarium. Ein ESP32 misst mit onewire die Temperatur und schickt sie rein zur Darstellung in eine InfluxDB. Ich würde nun die Aq-Heizung gerne mit fhem steuern (eine weitere Variable: Leistung der PV-Anlage), brauche dafür aber primär die Temperatur im Aquarium. Für den ESP32 ging der Sourcecode verloren - wäre nicht so schlimm, wenn er nicht mit noch einer anderen wichtigen Aufgabe (Werte via 433MHz an eine proprietäre Funkuhr senden) beschäftigt wäre (und das mag ich mir nicht nochmals neu ausdenken müssen).
Also zusammenfassend: mir reicht der aktuelle Wert der Temperatur im Aquarium (aus der InfluxDB), der dann in regelmäßigen Abfragen in FHEM integriert werden könnte.
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: KernSani am 22 Dezember 2019, 16:10:57
und hier wäre dann das InfluxDBQuery Modul (zumindest eine erste rudimentäre Version): https://forum.fhem.de/index.php/topic,106580.msg1004405.html#msg1004405
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: wopl am 12 Juli 2020, 14:04:27
Hallo allerseits,
(mal sehen, ob den Thread noch jemand liest...)

Ich nutze das Modul nun seit zwei Jahren ohne Probleme, muß aber meine InfluxDB umziehen.
Ist es möglich, die Verbindung zur InfluxDB mit HTTPS (Port 443) aufzubauen?

Über die defmod Parameter kann ich diese Option nicht erkennen. Wäre HTTPS mit einem kleinen Patch im Modul zu realisieren?
Dank und Gruß,
Wolfram
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: kadettilac89 am 12 Juli 2020, 17:11:30
das modul ist nie offiziell eingecheckt worden. Der Ersteller hat das Fhem-Umfeld verlassen. Wenn du eine Änderung benötigst musst du dir die Stellen im Modul suchen und anpassen. Wahrscheinlich nur HTTPS davorstellen ...  Sobald du Änderungen eingebaut hast und Probleme hast kannst dich mit konkreten Fehlermeldungen oder Logeinträgen nochmal melden. Gibt sicher Entwickler hier die dir dann weiterhelfen.

  $uri->scheme('http');    <---- vielliecht reich hier schon https ---- <<<<<<<<<<<<<<<<
  $uri->host($log->{INFLUXSRV});
  $uri->port($log->{INFLUXPORT});
  $uri->path('write');
  $uri->query_form(db => $log->{INFLUXDB}, u => $log->{INFLUXUSER}, p=> $log->{INFLUXPW}) if (defined $log->{INFLUXDB});
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: wopl am 13 Juli 2020, 06:08:28
Dank Dir !
Ja, jetzt funktioniert die Abfrage auch mit HTTPS.  :)
War ja wirklich einfach !

Gruß Wolfram
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: spcqike am 15 Juli 2020, 13:46:45
Hallo zusammen,

leider wird das Modul ja nicht weiter entwickelt (und damit auch hoffentlich bei einem Update nicht zurück geändert?)

Mir persönlich hat nicht gefallen, dass die Readings der Devices in der InfluxDB als measurement mit dem listing "value" angelegt wurden. Ebenso der Tag "site_name" war irgendwie komisch :)

Daher hab ich ein Attribut "measurement" hinzugefügt und den $data String um dieses erweitert.

Falls jemand etwas änliches implementieren will, hier im konkreten:
1) das Attribut hinzufügen
  my @attrList = qw(
      addStateEvent:1,0
          disable:1,0
          disabledForIntervals
          measurement
      );

2)das Attribut auslesen, wenn keins gesetzt ist soll "FHEM_Log" verwendet werden.
  my $metric = AttrVal($ln, "measurement", "FHEM_Log");

###original
#  my $data = "$arr[0],site_name=$NAME value=$arr[1]";
  my $data = "$metric,Device=$NAME $arr[0]=$arr[1]";

Damit kann man mehrere influxdblog module anlegen und jedes in ein anderes measurement protokollieren lassen. Ebenso kann man dann in bspw. Grafana wieder sinnvoll Tabellen erstellen (zumindest hab ich keine Tabelle hinbekommen, solange jedes Reading ein measurement war...)


Grüße :)
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: volschin am 19 Juli 2020, 10:59:19
Kommt ja sowieso bald influxdb 2.0. Da kann man sich das mal bzgl. sinnvoller Änderungen näher ansehen. Flexibilisierung wäre sicher nicht verkehrt.
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: timmib am 06 Oktober 2020, 08:01:12
Guten Morgen,

sagt mal. Ist es nicht sehr problematisch, dass hier alle HTTP Aufrufe synchron gemacht werden und nicht Non-Blocking?

Zitat
Das bedeutet, dass FHEM bei einem Aufruf einer dieser Funktionen solange wartet und dabei absolut nichts macht, bis die Antwort vom HTTP-Server eintrifft und die Funktion damit beendet ist. Das kann bei Verbindungsproblemen evtl. dazu führen, dass FHEM für die gesamte Wartezeit (Timeout) steht und nichts verarbeitet. Problematisch ist das gerade bei Anwendungen oder Hardware, die eine zeitnahe Reaktion von FHEM erwarten (z.B. HomeMatic-Geräte). In der Zeit, in der auf eine HTTP Antwort gewartet wird, steht FHEM dabei komplett.

Es wird daher empfohlen, die Funktionen so sparsam wie möglich zu verwenden und die Timeouts so niedrig wie möglich zu halten, um ein längeres Einfrieren von FHEM möglichst zu vermeiden.

Um eine Blockierung zu vermeiden wird generell die Verwendung von

HttpUtils_NonblockingGet
empfohlen. Diese führt den HTTP-Request asynchron durch, wodurch ein Blockieren von FHEM verhindert wird. Wie das genau funktioniert, wird in dem entsprechenden Kapitel beschrieben.

Viele Grüße

Tim
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: kadettilac89 am 06 Oktober 2020, 11:24:39
Guten Morgen,

sagt mal. Ist es nicht sehr problematisch, dass hier alle HTTP Aufrufe synchron gemacht werden und nicht Non-Blocking?

Viele Grüße

Tim

Aktuell gibt es keinen Maintainer für das Modul.

Kann problematisch sein wie du schon gefunden hast, jeder der das Modul übernehmen will und umbaut ist herzlich willkommen.
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: timmib am 07 Oktober 2020, 23:34:19
Zitat
jeder der das Modul übernehmen will und umbaut ist herzlich willkommen.

Ich war mal so frei einfach ein komplett neues Modul zu schreiben - siehe hier  8) 8) 8)
https://forum.fhem.de/index.php/topic,114860.0.html (https://forum.fhem.de/index.php/topic,114860.0.html).

Dabei habe ich die Anmerkungen aus dem Thread hier natürlich einfliessen lassen. Bitte schaut mal rein und schreibt was ihr davon haltet.

Viele Grüße

Tim
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: kadettilac89 am 08 Oktober 2020, 08:30:22
es gibt nicht viele die das Modul bis jetzt nutzen. Ich bin einer der wenigen.

Werde es mir mal ansehen und einbinden ... gebe bescheid wie es sich verhält
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: kadettilac89 am 08 Oktober 2020, 19:19:49
Authentication funktionierte nicht --> Falscher Parameter in Zeile 66
Parameteranzahl bei Funktionsaufrufen angepasst ... nur kosmetisch

Habe die angepasste Version angehängt dann muss ich den Text kopieren.

Mit der Definition von devspec und Regex-Parameter komme ich nicht zurecht. Vielleicht auch weil ich DBLog schon kenne. Dir überlassen ... aber macht es vielleicht Sinn, das genau so zu übernehmen wie in DBLog? Die meisten werden entweder von DBLog kommen, oder es sogar parallel einsetzen.

Gib vielleicht mal ein Beispiel welches Format du bei mehreren Devices erwartest bei der Definition und dem Regex-Parameter.

Ansonsten, DB wird geschrieben. Da ich zum Test nichts ausgenommen habe, kommt der Fehler s. u. ...habe nicht weiter nachgesehen wo das herkommt. Ggf. abfangen. Denke es wird kein nummerischer Wert gefunden.

failed_writes_last_error
unable to parse 'ram,site_name=sysmon_host value=Total': invalid boolean
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: timmib am 08 Oktober 2020, 22:42:27
Vielen Dank für den Hinweis. ich habe deinen Fix in die neueste Version eingepflegt. Diese findet man in dem Ankündigungsthread. https://forum.fhem.de/index.php?topic=114860.msg1090782#msg1090782

Dort habe ich jetzt auch englische und deutsche Doku hinzugefügt und das Verhalten beim init und bei Endlos schleifen verbessert.
In der Doku ist auch Hinweis auf die devspec. https://fhem.de/commandref_DE.html#devspec (https://fhem.de/commandref_DE.html#devspec)

Laut Developer Dokumentation ist es besser für die Performance beim Regisitieren auf Events NOTIFYDEV/notifyRegexpChanged zu nutzen. Ich persönlich find es auch einfacher erst auf Geräte und im zweiten Schritt auf Readings zu filten.
Ich schaue mir aber mal die anderen Logger als Inspiration an.

Eine Ausschlussfilterung auf Readings ist auf der TODO Liste.

Mein primäres Ziel war es mein lahmendes FHEM wieder zu beschleunigen. Das ist mir auch tatsächlich gegenüber dem alten Influx-Modul gelungen, dank NonBlocking HttpUtils und NOTIFYDEV.

Die Prüfung auf FHEM-Seite ob der Wert wirklich numerisch ist steht auf der TODO Liste.




Ich würde vorschlagen in dem neuen Thread weiter zu schreiben.
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: kadettilac89 am 09 Oktober 2020, 13:48:30
Ich würde vorschlagen in dem neuen Thread weiter zu schreiben.
Da habe ich keine Schreibrechte, kann also nicht antworten


Mit der Definition von devspec und Regex-Parameter komme ich nicht zurecht. Vielleicht auch weil ich DBLog schon kenne. Dir überlassen ... aber macht es vielleicht Sinn, das genau so zu übernehmen wie in DBLog? Die meisten werden entweder von DBLog kommen, oder es sogar parallel einsetzen.

Laut Developer Dokumentation ist es besser für die Performance beim Regisitieren auf Events NOTIFYDEV/notifyRegexpChanged zu nutzen. Ich persönlich find es auch einfacher erst auf Geräte und im zweiten Schritt auf Readings zu filten.
Ich schaue mir aber mal die anderen Logger als Inspiration an.
OK, andere Baustelle ... wie gesagt, dein Modul. Anders muss nicht schlecht sein.

Ich habe nun mal eine devspec angehängt ... es wird alles geloggt, devspec wird ignoriert
http://influxdb:8086 fhemtest InfluxDbLog=1

Ich sehe im Code aber auch keinen Aufruf von "devspec2array". Wo arbeitest du die devspec ab?

Edit:

ich habe mir mal quick'n'dirty devspec eingebaut ... mal schaun obs dann läuft
my $devName = $dev_hash->{NAME}; # Device that created the events
my $events = deviceEvents($dev_hash, 1);

my @list = devspec2array($own_hash->{REGEX});   #<<<<<<<<<<<<----------------------
return "" if not grep { $_ eq $devName } @list;     #<<<<<<<<<<<<<<<<<<-------------------

    return "" if($devName eq "global" && grep(m/^INITIALIZED|REREADCFG$/, @{$events}));
    return "" if($own_hash->{TYPE} eq $dev_hash->{TYPE}); # avoid endless loops from logger to logger
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: timmib am 10 Oktober 2020, 19:49:19
Ich habe mir das DbLog_Modul angesehen. Meine Meinung zu Thema befindet sich im Thread vom neuen Modul.
https://forum.fhem.de/index.php/topic,114860.0.html (https://forum.fhem.de/index.php/topic,114860.0.html)
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: kadettilac89 am 11 Oktober 2020, 11:03:29
Ich habe mir das DbLog_Modul angesehen. Meine Meinung zu Thema befindet sich im Thread vom neuen Modul.
https://forum.fhem.de/index.php/topic,114860.0.html (https://forum.fhem.de/index.php/topic,114860.0.html)
Bitte schiebe den Post in ein forum in dem auch nicht-developer schreibrechte haben
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: timmib am 12 Oktober 2020, 19:30:31
Zitat
Bitte schiebe den Post in ein forum in dem auch nicht-developer schreibrechte haben

Hm, ich dachte man soll das so machen. Ich schieb ihn mal hierhin, bis ein Moderator sich anderweitig äussert.
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: timmib am 12 Oktober 2020, 19:34:08
Zitat
Ich sehe im Code aber auch keinen Aufruf von "devspec2array". Wo arbeitest du die devspec ab?

InternalTimer(0, sub(){  notifyRegexpChanged($hash, $hash->{REGEX}); }, $hash);
Passiert dann automatisch.
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: kadettilac89 am 12 Oktober 2020, 20:53:37
InternalTimer(0, sub(){  notifyRegexpChanged($hash, $hash->{REGEX}); }, $hash);
Passiert dann automatisch.
Die Funktion löst keine devspec auf die du in der Doku verweist. Damit kannst du nur Regex auf devicenamen absetzen. Devspec ist viel mehr und würde, wenn eingebaut, auch Mehrwert bieten.

notifyRegexpChanged
Diese Funktion kann nur verwendet werden, wenn $event_regexp auf <Definitionsnamen> bzw. <Definitionsnamen>:<Event> matcht (Event Regexp-Syntax aus notify).

devspec löst du mit devspec2array auf.
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: timmib am 12 Oktober 2020, 21:17:50
Also bei mir funktioniert das wunderbar - dachte ich bis grade,

Wenn ich z.B. Harry als devspec am Ende vom define angebe habe ich automatisch ein NOTIFYDEV mit dem Wert Harry und bekommen auch nur noch Ereignisse von Harry gemeldet.

Ich sehe grad beim meinem a,b,c Beispiel setzt der das NOTIFYDEV nicht. Laut https://wiki.fhem.de/wiki/DevelopmentModuleAPI#notifyRegexpChanged (https://wiki.fhem.de/wiki/DevelopmentModuleAPI#notifyRegexpChanged)
Zitat
Es kann durchaus vorkommen, dass kein Eintrag in NOTIFYDEV gesetzt wird, da nicht zweifelsfrei zwischen Definitionsnamen und Event unterschieden werden kann.
Womöglich ist das bei a,b,c der Fall - Schade.

Und nu? Soll ich jetzt selber filtern oder selber $event_regexp setzen.

BTW. Ich habe das andere Thema verschoben und ein paar neue Sache eingebaut. Inklusive konfigurierbarer Konvertierung.



Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: timmib am 14 Oktober 2020, 22:38:33
Danke für eure schnellen Antworten!
Im konkreten schaut mein Fall so aus: ich habe ein Aquarium. Ein ESP32 misst mit onewire die Temperatur und schickt sie rein zur Darstellung in eine InfluxDB. Ich würde nun die Aq-Heizung gerne mit fhem steuern (eine weitere Variable: Leistung der PV-Anlage), brauche dafür aber primär die Temperatur im Aquarium. Für den ESP32 ging der Sourcecode verloren - wäre nicht so schlimm, wenn er nicht mit noch einer anderen wichtigen Aufgabe (Werte via 433MHz an eine proprietäre Funkuhr senden) beschäftigt wäre (und das mag ich mir nicht nochmals neu ausdenken müssen).
Also zusammenfassend: mir reicht der aktuelle Wert der Temperatur im Aquarium (aus der InfluxDB), der dann in regelmäßigen Abfragen in FHEM integriert werden könnte.

Btw. um die letzten Werte von InfluxDB nach FHEM zu bekommen nutze ich den Kapacitor. https://www.influxdata.com/time-series-platform/kapacitor/ (https://www.influxdata.com/time-series-platform/kapacitor/)
Der gehört mit zum TICK-Stack und ist wirklich super, auch zum aggregieren und filtern usw. inkl. gleitende Fenster usw.
Der Kapacitor unterstützt auch Outputs wie z.B. MQTT. Und genau nutze ich um dann di Werte in ein MQTT-Device in FHEM zu bekommen.

Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: matzewob am 23 Oktober 2020, 07:55:56
Moin,

ich setzte jetzt seit ein paar Tagen das Modul ein, läuft auch scheibar, etwas....

Meine Frage nun da ich mehrere Devices habe dessen Messerwerte nicht übertragen werden, wie z.b. dieses hier:

defmod Waschmaschine FBDECT Fritzbox:19 switch
attr Waschmaschine IODev Fritzbox
attr Waschmaschine devStateIcon on:rc_GREEN:off off:rc_RED:on absent:rc_BLUE:off gpio:rc_YELLOW:off
attr Waschmaschine event-min-interval power:120
attr Waschmaschine room Keller
attr Waschmaschine stateFormat {"T: " . ReadingsNum($name,"temperature",0) . "°C / Verbrauch: "  . ReadingsNum($name,"energy",0)/1000 . "KW/h" }

setstate Waschmaschine T: 25.5°C / Verbrauch: 389.718KW/h
setstate Waschmaschine 2020-10-23 07:52:12 AIN 08761 0363051
setstate Waschmaschine 2020-10-23 07:52:12 FBNAME Waschmaschine
setstate Waschmaschine 2020-10-23 07:52:12 FBPROP microphone,powerMeter,tempSensor,switch
setstate Waschmaschine 2020-10-23 07:52:12 FBTYPE FRITZ!DECT 200
setstate Waschmaschine 2020-10-23 07:52:12 ID 19
setstate Waschmaschine 2020-10-23 07:52:12 devicelock no
setstate Waschmaschine 2020-10-23 07:52:12 energy 389718 Wh
setstate Waschmaschine 2020-10-23 07:52:12 fwversion 04.16
setstate Waschmaschine 2020-10-23 07:52:12 locked no
setstate Waschmaschine 2020-10-23 07:52:12 mode manuell
setstate Waschmaschine 2020-10-23 07:52:12 power 0.64 W
setstate Waschmaschine 2020-10-23 07:52:12 present yes
setstate Waschmaschine 2020-10-23 05:44:03 running off
setstate Waschmaschine 2020-10-23 07:52:12 state on
setstate Waschmaschine 2020-10-23 07:52:12 tempadjust 0.0 C
setstate Waschmaschine 2020-10-23 07:52:12 temperature 25.5 C (measured)
setstate Waschmaschine 2020-10-23 07:52:12 voltage 234.579 V


Mein Influx:

defmod INFLUXLOG InfluxDBLog 127.0.0.1 8086 fhem fhem hochgeheim .*

setstate INFLUXLOG active
setstate INFLUXLOG 2020-10-23 07:52:10 filecount 0


Wie kann ich den überzeugen das er die Readings mit aufnimmt?

Vor allem interessiert mich:

setstate Waschmaschine 2020-10-23 07:52:12 power 0.64 W
setstate Waschmaschine 2020-10-23 07:52:12 temperature 25.5 C (measured)

Danke, und grüße
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: timmib am 23 Oktober 2020, 08:28:49
Das neue Modul wird in einem anderen Thread behandelt und hat einen anderen Namen und Syntax.

https://forum.fhem.de/index.php/topic,114860.0.html (https://forum.fhem.de/index.php/topic,114860.0.html)

Usage: define devname InfluxDBLogger [http|https]://IP_or_Hostname:port dbname devspec
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: arran am 07 Januar 2021, 15:52:39
Ein gutes Neues allerseits.

Hab jetzt das Modul auch am laufen und bin fleißig am testen - danke an die Entwickler des Moduls.

In der Testumgebung versuche ich die Spritpreise von 5 Tankstellen in die Influx Datenbank zu übertragen. Dort habe ich User, Organisation und InitialBucketName erstellt. In der Device Definition ist der Name der "Organisation"=fhemdb angegeben:

Internals:
   DATABASE   fhemdb
   DEF        http://influxdb:8086 fhemdb ALGTH81377,Esso80639,JET80687,JET80639,Shell80639
   FUUID      5ff6ec75-f33f-bc43-2b04-aa5b7976662b93e9
   FVERSION   93_InfluxDBLogger.pm:0.233660/2020-12-16
   NAME       iflxlog
   NOTIFYDEV  ALGTH81377,Esso80639,JET80687,JET80639,Shell80639
   NR         132
   NTFY_ORDER 50-iflxlog
   STATE      Statistics: t=10 s=0 f=10 e=210
   TYPE       InfluxDBLogger
   URL        http://influxdb:8086
   token      saved
   READINGS:
     2021-01-07 15:08:59   dropped_writes  0
     2021-01-07 15:08:59   dropped_writes_last_message <none>
     2021-01-07 15:26:50   failed_writes   10
     2021-01-07 15:26:50   failed_writes_last_error 404 Not Found
     2021-01-07 15:26:50   state           Statistics: t=10 s=0 f=10 e=210
     2021-01-07 15:08:59   succeeded_writes 0
     2021-01-07 15:26:50   total_events    210
     2021-01-07 15:26:50   total_writes    10
Attributes:
   readingExclude address:\s.+
   room       Database
   security   token
   verbose    5

Ich bekomme den Fehler "404 Not Found" - hiermit ein Ausschnitt aus der Log:

2021.01.07 15:11:51.987 4: InfluxDBLogger: [iflxlog] notified from device Esso80639
2021.01.07 15:11:51.987 4: InfluxDBLogger: [iflxlog] notified from device Esso80639 about Diesel: 1.179
2021.01.07 15:11:51.987 4: InfluxDBLogger: [iflxlog] notified from device Esso80639 about SuperE10: 1.259
2021.01.07 15:11:51.987 4: InfluxDBLogger: [iflxlog] notified from device Esso80639 about SuperE5: 1.309
2021.01.07 15:11:51.988 4: InfluxDBLogger: [iflxlog] notified from device Esso80639 about statSuperE10DayMin: 1.259
2021.01.07 15:11:51.988 4: InfluxDBLogger: [iflxlog] notified from device Esso80639 about statSuperE10DayAvg: 1.288
2021.01.07 15:11:51.988 4: InfluxDBLogger: [iflxlog] notified from device Esso80639 about statSuperE10DayMax: 1.369
2021.01.07 15:11:51.988 4: InfluxDBLogger: [iflxlog] notified from device Esso80639 about statSuperE10MonthMin: 1.209
2021.01.07 15:11:51.988 4: InfluxDBLogger: [iflxlog] notified from device Esso80639 about statSuperE10MonthAvg: 1.312
2021.01.07 15:11:51.988 4: InfluxDBLogger: [iflxlog] notified from device Esso80639 about statSuperE10MonthMax: 1.419
2021.01.07 15:11:51.988 4: InfluxDBLogger: [iflxlog] notified from device Esso80639 about statSuperE5DayMin: 1.309
2021.01.07 15:11:51.988 4: InfluxDBLogger: [iflxlog] notified from device Esso80639 about statSuperE5DayAvg: 1.338
2021.01.07 15:11:51.988 4: InfluxDBLogger: [iflxlog] notified from device Esso80639 about statSuperE5DayMax: 1.419
2021.01.07 15:11:51.988 4: InfluxDBLogger: [iflxlog] notified from device Esso80639 about statSuperE5MonthMin: 1.259
2021.01.07 15:11:51.988 4: InfluxDBLogger: [iflxlog] notified from device Esso80639 about statSuperE5MonthAvg: 1.362
2021.01.07 15:11:51.988 4: InfluxDBLogger: [iflxlog] notified from device Esso80639 about statSuperE5MonthMax: 1.469
2021.01.07 15:11:51.988 4: InfluxDBLogger: [iflxlog] notified from device Esso80639 about statDieselDayMin: 1.179
2021.01.07 15:11:51.988 4: InfluxDBLogger: [iflxlog] notified from device Esso80639 about statDieselDayAvg: 1.218
2021.01.07 15:11:51.988 4: InfluxDBLogger: [iflxlog] notified from device Esso80639 about statDieselDayMax: 1.289
2021.01.07 15:11:51.988 4: InfluxDBLogger: [iflxlog] notified from device Esso80639 about statDieselMonthMin: 1.179
2021.01.07 15:11:51.988 4: InfluxDBLogger: [iflxlog] notified from device Esso80639 about statDieselMonthAvg: 1.241
2021.01.07 15:11:51.989 4: InfluxDBLogger: [iflxlog] notified from device Esso80639 about statDieselMonthMax: 1.349
2021.01.07 15:11:51.990 5: InfluxDBLogger: [iflxlog] set ?
2021.01.07 15:11:51.990 5: InfluxDBLogger: [iflxlog] set ?
2021.01.07 15:11:51.990 4: InfluxDBLogger [iflxlog] - Read token from file
2021.01.07 15:11:51.991 4: InfluxDBLogger: [iflxlog] Sending data SuperE10,site_name=Esso80639 value=1.259
statSuperE5DayMax,site_name=Esso80639 value=1.419
Diesel,site_name=Esso80639 value=1.179
statSuperE10MonthMax,site_name=Esso80639 value=1.419
statDieselMonthMin,site_name=Esso80639 value=1.179
statDieselDayMin,site_name=Esso80639 value=1.179
statDieselDayMax,site_name=Esso80639 value=1.289
SuperE5,site_name=Esso80639 value=1.309
statSuperE5DayMin,site_name=Esso80639 value=1.309
statSuperE5DayAvg,site_name=Esso80639 value=1.338
statSuperE10MonthAvg,site_name=Esso80639 value=1.312
statSuperE5MonthMax,site_name=Esso80639 value=1.469
statSuperE10DayMin,site_name=Esso80639 value=1.259
statSuperE10MonthMin,site_name=Esso80639 value=1.209
statSuperE10DayMax,site_name=Esso80639 value=1.369
statDieselMonthMax,site_name=Esso80639 value=1.349
statSuperE5MonthAvg,site_name=Esso80639 value=1.362
statDieselMonthAvg,site_name=Esso80639 value=1.241
statSuperE10DayAvg,site_name=Esso80639 value=1.288
statDieselDayAvg,site_name=Esso80639 value=1.218
statSuperE5MonthMin,site_name=Esso80639 value=1.259
 to http://influxdb:8086/write?db=fhemdb
2021.01.07 15:11:51.993 1: InfluxDBLogger: [iflxlog] Error = 404 Not Found
2021.01.07 15:11:51.994 5: InfluxDBLogger: [iflxlog] set ?

Kann mir jemand einen Hinweis geben woran die Befüllung der Datenbank scheitert?
Irgendwie komme ich als totaler Anfänger nicht dahinter vermute aber, dass es mit der Datenbank Anbindung zusammenhängt.

Vielen Dank
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: fischit am 07 Januar 2021, 16:17:55
Ich kann dir zwar nicht sonderlich viel helfen, aber folgendes kann ich dir sagen.

1. Das ist der falsch Thread -> https://forum.fhem.de/index.php/topic,114860.0.html (https://forum.fhem.de/index.php/topic,114860.0.html)
2. du hast ein Leerzeichen nach deinem ersten Device
3. Wenn du Anfänger bist und du die Influxdb ganz rudimentär aufgesetzt hast, behaupte ich, dass das Attribut "Security" unnötig ist. 

Ansonsten gehe ich davon aus, dass dein System auch wirklich über http://influxdb:8086 erreichbar ist und das deine DB wirklich fhemdb heißt.
Hiermit kannste mal testen was da zurück kommt: curl -G http://influxdb:8086/query --data-urlencode "db=fhemdb" --data-urlencode "q=SHOW SERIES" --data-urlencode "pretty=true"
 (http://curl -G http://influxdb:8086/query --data-urlencode "db=fhemdb" --data-urlencode "q=SHOW SERIES" --data-urlencode "pretty=true")
Titel: Antw:Neues Modul: 93_InfluxDBLog
Beitrag von: arran am 08 Januar 2021, 00:33:19
@fischit:


Sowohl die InfluxDB V2 als auch FEHEM laufen unter DOCKER im gleichen Netzwerk - das passt auch.

Was gefehlt hat waren die Attribute für InfluxDB API und der Name (meiner) der Organisation:

attr iflxlog api v2
attr iflxlog org fhemdb

Jetzt klappt es :-)