FHEM - Hausautomations-Systeme > Unterstützende Dienste

Neues Modul InfluxDBLogger

(1/34) > >>

timmib:
Guten Tag,

da FHEM eine super Sache ist und die InfluxDB auch, gehören die beiden zusammen. Es gab schon ein externes erstes InfluxDBLog Modul von jemandem (siehe https://forum.fhem.de/index.php/topic,71551.msg1073087.html), aber es:

* wurde nicht weiter gepflegt
* blockierte den Main-Loop
* war kaum konfigurierbar
* intransparent was wirklich passierte
* das Passwort wurde im Klartext gespeichert
Deswegen habe ich nun ein neues Modul geschrieben welches:

* nicht den Main-Loop blockiert, da es die HTTPUtils verwendet
* konfigurierbarer ist
* transparent statistik-readings und logs produziert
* das Passwort ordentlich gespeichert
Zum Thema "konfigurierbar":

* Man kann die devspec und eine separate optionale regex für die readings definieren.
* Bei einer devspec die auf alles matched disabled sich das Modul erstmal selber, weil es sonst die DB zumüllt.
* Man kann über ein Attribut die Art der Security wählen (bisher basicAuth und keine, InfluxDB unterstützt aber auch Token
* Das Passwort setzt man über set password, der user über ein Attribut
* Man kann den Namen des Tags wählen wo der Devicename gespeichert wird. Um alte Datenschätze nicht zu stören ist der default wie beim alten Modul 'site_name'
Zum Thema "Statistik":

* Es werden die Gesamtzahl die Erfolge und Mißerfolge gezählt
* Es wird der letzte Fehler als Reading angezeigt
* Es werden DNS, HTTP und Influx Fehler als Fehler erkannt
* Man kann die Statisik über set resetStatistics zurücksetzen
Zum Thema "Sonstiges":

* Es werden true,yes und on und deren Gegenspieler in 1 bzw. 0 übersetzt
Es auch mein erstes Modul aber besonders Mutige sind herzlich eingeladen das mal in einer Testumgebung zu testen. Ich selber habe es auch einer Testumgebung getestet und setze es nun auch produktiv ein.
Das Ziel ist es, das Ganze recht bald auch offiziel in SVN zu commiten.  8)

Es liegt englische und deutsche Dokumentation vor.

*** UPDATE  28.11.2020 ***
Das Schema ist jetzt frei konfigurierbar über die Attribute measurement,tags,fields.
Die HTTP Calls werden nun bei Bulk-Updates vereint.

*** UPDATE  30.11.2020 ***
tagset ist jetzt optional mit '-' (Danke an gvzdus)
Zeilen werden schon FHEM-seitig optimiert. (Danke nochmal an gvzdus)

*** UPDATE  09.12.2020 ***
Unterstützung für Influx2-Token Security und Perl-Ausdrücke in tags. Doku ergänzt.

*** UPDATE 10.12.2020 ***
Das Modul ist nun im FHEM SVN.

*** UPDATE 16.12.2020 ***
Es werden nun https://fhem.de/commandref.html#readingFnAttributes unterstützt. (Danke nochmal an gvzdus)
Damit lassen sich die Events des Loggers selber unterdrücken.

Viele Grüße

Tim

timmib:
Hier ein paar Worte zu der Design-Entscheidung die Geräte und Reading Filter in den Logger und nicht wie bei Dblog an die zu loggenden Devices zu packen:

Der Hintergrund hängt stark damit zusammen wie klassischen SQL Datenbanken aufgebaut sind und vor allem wie sie aufgesetzt werden. Und zwar recht aufwändig. Ohne das Schema zu definieren passiert recht wenig. Außerdem kennen klassiche SQL Datenbanken keine "Retention Policies" also zu Deutsch Vorhaltefristen.

Das ist bei InfluxDB beides anders. Hier wird eigentlich nur die leere Datenbank angelegt und die Messreihen und "Spalten" entstehen von alleine. Zum anderen sind "Retention Policies" Einwohner erster Güte. D.h. zur Defnition einer Datenbank gehört auch, wie lange die Daten dort drin zurückreichen.

Entsprechend ist es nicht unüblich verschiedenen Daten in verschiedenen Datenbanken zu schreiben. Da dies a) kein Aufwand ist und b) erlaubt die Daten unterschiedlich lang auzuheben.

Nun kommen wir endlich zu FHEM. Da man die Datenbank am Logger definiert, macht es Sinn auch dort den Kreis an Devices und Readings anzugeben welche geloggt werden sollen. Andersherum wie bei Dblog funktioniert das auch schlecht. Den die Auswahl der Datenbank und damit der Retention Policy über das Device was Loggen will wäre etwas Umständlich. Besonders, dann wenn aus dem selben Device Readings teilweise in die eine und in die andere Datenbank gehören.

Was denkt ihr?

plin:

--- Zitat von: timmib am 07 Oktober 2020, 23:31:09 ---Zum Thema "Sonstiges":

* Es werden true,yes und on und deren Gegenspieler in 1 bzw. 0 übersetzt
--- Ende Zitat ---

Wie kann ich die Liste erweitern (z.B. um open/closed)? Siehe auch https://forum.fhem.de/index.php/topic,71551.msg968874.html#msg968874

timmib:
Habe ich übersehen. Wird eingebaut.

timmib:
Es gibt Neuigkeiten:


* Das Attribut readingRegEx heißt jetzt readingInclude und es gibt nun auch readingExclude. Bitte entsprechend vorsichtig migrieren!
* Es gibt nun ein Attribut conversion. Das ist Kommagetrennte Liste von Ersetzungen e.g. open=1,closed=0,tilted=2 oder true|on|yes=1,false|off|no=0
* Es wird nun nichts mehr automatisch konvertiert!
* Nicht numerische Readings werden jetzt garnicht erst zur Datenbank geschickt. Aber lokal gezählt als "dropped" und die letzte Meldung angezeigt.
* Deutsch und englische Doku habe ich entsprechend angepasst
Viele Erfolg beim Testen

Navigation

[0] Themen-Index

[#] Nächste Seite

Zur normalen Ansicht wechseln