Neues Modul InfluxDBLogger

[timmib]

.. aber mir tut das weh.

Hier die neue Version ohne Warnings und dafür mit vollständiger Doku.

[red81]

Edit: Problem erstmal hier raus genommen

[timmib]

Hallo,

Bitte mach einen eigenen Thread auf. Am besten direkt mit stellen die du als Indiz identifiziert hast.

Um das Influxmodul auszuschließen kannst du ja das disable Attribut auf 1 setzen, oder das Modul komplett löschen.

[gvzdus]

Da wir ja noch im kleinen Kreis sind: Das Modul läuft bei mir absolut sauber, und hat trotz sekündlicher Datenübertragung auch schon einen Timeout-Fehler über mehrere Stunden des Zielservers ausgehalten, ohne dass FHEM blockiert gewesen wäre.

[timmib]

Das war ja auch die Motivation das neu zu schreiben.

[cthil]

Hallo zusammen,

ich hatte direkt zum Release von InfluxDB 2.0 eine Variante des FHEM-Moduls gebastelt, was die v2-API und auch Token-Authentifizierung nutzt. Vielleicht kann man die angehängten Änderungen zusammenführen (Wahl ob "Legacy" v1-API bzw. v2-API für InfluxDB 2).

Das Token wird anstelle des Passwortes gespeichert. Die InfluxDB-Organization wird als Attribut "organization" gespeichert, ebenso die Präzision der Daten im Attribut "precision" (z. B. Wert "s").

Insgesamt war nicht viel zu tun, und es läuft seit fast einem Monat mit zwei Instanzen in einem FHEM ohne Probleme.

Viele Grüße,
Christophe

[timmib]

Super, schaue ich mir an.

[meier81]

Hi und guten Morgen,

bin gestern zufällig über dein Modul gestolpert, fand InfluxDB schon immer interessant in Kombination mit Grafana.

Ich habe bei mir seit Jahren das MySQL-Logging in Gebrauch, würde aber gerne auf InfluxDB umstellen. Hab mir deshalb gestern mal zum testen dein Modul installiert, funktioniert soweit erstmal einwandfrei.

Hätte noch eine Verbesserung falls dies Möglich ist: Ich habe bei mir ein DOIF eingerichtet das jede Nacht um 23:59 und um 00:00 Uhr ausgeführt wird um händisch die Werte in die DB zu schreiben, wenn du dann mit Grafana die Auswertungen machst bekommst du bei den Kurven den Anfang und das Ende immer sauber angezeigt. Ist das bei deinem Modul auch machbar das einzubauen, z.B. mit einem

Code Auswählen Erweitern

set <name> AddLog. Man muss ja nicht wie bei DBLog noch die Datenpunkte noch hinter AddLog aufführen, diese sind ja eigentlich in der Moduldefinition schon definiert.

Eine andere Frage ist noch ob es möglich ist wie bei DBLog einen Mininterval einzubauen, ich habe hier einige MQTT-Devices die im Sekundentakt Werte liefern, die muss ich ja nicht alle mitloggen, da hatte ich bei DBLog ein

Code Auswählen Erweitern

defaultMinInterval    TYPE=MQTT_DEVICE::60::force gesetzt, damit wurden die Werte von MQTT nur alle 60 Sekunden geloggt.

Ich werde auf jeden Fall mal weiter testen.

Gruß

Markus

[timmib]

Hallo zusammen,

ich hatte direkt zum Release von InfluxDB 2.0 eine Variante des FHEM-Moduls gebastelt, was die v2-API und auch Token-Authentifizierung nutzt. Vielleicht kann man die angehängten Änderungen zusammenführen (Wahl ob "Legacy" v1-API bzw. v2-API für InfluxDB 2).

Das Token wird anstelle des Passwortes gespeichert. Die InfluxDB-Organization wird als Attribut "organization" gespeichert, ebenso die Präzision der Daten im Attribut "precision" (z. B. Wert "s").

Insgesamt war nicht viel zu tun, und es läuft seit fast einem Monat mit zwei Instanzen in einem FHEM ohne Probleme.

Viele Grüße,
Christophe

Hi Christophe,

ich habe nun v2 Support eingebaut. Deine Datei beruhte leider auf einer sehr alten Version vom Modul, deswegen musst ich es neu implementieren.

Die Dokumentation habe ich angepasst.

Hier nochmal in Kürze.
bucket = database
org = "privat" oder per Attribute "org" zu ändern.

Präzision ist nun auch für beide API Versionen unterstützt.

Gibt bitte Bescheid ob ihr damit glücklich seit. In der Sandbox und meinen VMs läuft es.

Viele Grüße

Tim

[timmib]

Hätte noch eine Verbesserung falls dies Möglich ist: Ich habe bei mir ein DOIF eingerichtet das jede Nacht um 23:59 und um 00:00 Uhr ausgeführt wird um händisch die Werte in die DB zu schreiben, wenn du dann mit Grafana die Auswertungen machst bekommst du bei den Kurven den Anfang und das Ende immer sauber angezeigt. Ist das bei deinem Modul auch machbar das einzubauen, z.B. mit einem

Code Auswählen Erweitern

set <name> AddLog. Man muss ja nicht wie bei DBLog noch die Datenpunkte noch hinter AddLog aufführen, diese sind ja eigentlich in der Moduldefinition schon definiert.

Hallo Markus,

das habe ich noch nicht verstanden. Soll AddLog das schreiben der Werte erzwingen ohne Event? Woher soll das Modul wissen welche Readings?

Eine andere Frage ist noch ob es möglich ist wie bei DBLog einen Mininterval einzubauen, ich habe hier einige MQTT-Devices die im Sekundentakt Werte liefern, die muss ich ja nicht alle mitloggen, da hatte ich bei DBLog ein

Sowas könnte man machen.

Viele Grüße

Tim

[timmib]

Hallo zusammen,

Übrigens ist das Modul nun im FHEM SVN eingecheckt. 

Das heißt für die Nutzer, dass bei einem

Code Auswählen Erweitern

update alldie Version aus dem SVN gezogen wird und händisch hineinkopierte flöten gehen.

Deswegen, wäre es super Feedback zu den hier geposteten Versionen zu geben, damit ich die auch ins SVN packen kann.

Viele Grüße

Tim

[cthil]

Hallo,

vielen Dank für das Integrieren der v2-API.
Allerdings klappt es noch nicht ganz glatt: Ich habe ein Log-Device, das die Notifies mit einer readingInclude-Regex filtert. Das ging mit der alten Version problemlos, aber jetzt wird für nicht matchende Readings ein Aufruf ohne Content an die Datenbank gesendet (succeeded_writes != total_writes, aber (dropped|failed)_writes = 0). Im Log erscheinen Hinweise: HTTP/1.0 204 No Content

Edit: Vielleicht stimmt obiges nicht ganz, ich werde aus dem Log noch nicht schlau. Feststellung: Logdevice 1 hat eine readingInclude-Regex "ValvePosition:.+", Logdevice 2 hat "(temperature|humidity):.+". #2 verursacht das oben beschriebene Verhalten.

Edit 2: Vielleicht ist das ja das gewünschte Verhalten Ich hatte die Diskussion, mehrere Reading in ein DB-Insert zusammenzufassen, nicht mitbekommen. In der DB kommen ja auch offenbar alle Werte an. Sorry wenn ich das falsch verstanden hatte, aber ohne Erklärung klingt succeeded_writes != total_writes erstmal nach Fehler.

Könntest Du da bitte nochmal nachfassen?

Und darüber, dass das Modul im SVN ist bin ich gleich gestolpert update gemacht und die gerade rüberkopierte Version war mit einem alten Stand von SVN überschrieben...

[meier81]

Hallo Markus,

das habe ich noch nicht verstanden. Soll AddLog das schreiben der Werte erzwingen ohne Event? Woher soll das Modul wissen welche Readings?

Hallo Tim,

ich glaube ich weiß was du meinst, ich gebe ja im Modul an welche Readings und Devices ich zulasse, das Modul weiß ja aber nicht welche Devices es gibt und welche nicht. Dann müsste man das auch so machen wie im DBLog-Modul, dort kann ich sagen

Code Auswählen Erweitern

set <name> addLog <devspec>:<Reading>, damit gebe ich ja dann das Device und das Reading an das geloggt werden soll. Mache ich bei mir mit einem DOIF, hier mal mein DOIF als Beispiel:

Code Auswählen Erweitern

defmod di_Plotabriss DOIF ([23:59] or [00:00])\
   (set DbLog addLog Buderus:(DesiredSupplyTemp|OutdoorTemp|Power|PowerModulation|PumpModulation|ReturnTemp|SupplyTemp|WaterDesiredTemp|WaterTemp)\
   ,set DbLog addLog Fuehler.*:(temperature|humidity|dewpoint|absoluteHumidity)\
   ,set DbLog addLog (Waschmaschine|Trockner):ENERGY_Power\
   ,set DbLog addLog Wetterstation:(temperature|humidity|dewpoint|absoluteHumidity|brightness|rainRate|wind|pressureAbs)\
   ,set DbLog addLog Astro:SunAlt\
   ,set DbLog addLog Rolladen.*:pct\
   ,set DbLog addLog Strom_Haus:Power_.*__kW)
attr di_Plotabriss do always

Das müsste so doch dann realisierbar sein oder was meinst du dazu?

Gruß

Markus

[timmib]

Edit 2: Vielleicht ist das ja das gewünschte Verhalten Ich hatte die Diskussion, mehrere Reading in ein DB-Insert zusammenzufassen, nicht mitbekommen. In der DB kommen ja auch offenbar alle Werte an. Sorry wenn ich das falsch verstanden hatte, aber ohne Erklärung klingt succeeded_writes != total_writes erstmal nach Fehler.

Könntest Du da bitte nochmal nachfassen?

Ja, das ist mir auch ein Dorn im Auge. Man könnte beim Senden aufhören die Events zu zählen und auch nur die Writes zählen. Dann würde es passen.

Dadurch, dass man nun so viel konfigurieren kann und auch die Anzahl im Response nicht mit zurück kommt, kann man die Events als Basis nicht nehmen.

Was sagt ihr? So lassen, dann sieht man wieviel zusammengefasst wurde, oder auf Writes ändern?

Die Events kann man auch zusätzlich in die Statistik mit aufnehmen, dann hätte man beide Vorteile.

Viele Grüße

Tim

[timmib]

Habe das jetzt so gemacht, dass die Events separat gezählt werden.

Code Auswählen Erweitern

state
Statistics: t=6 s=1 f=5 e=6


Fünfmal war die Test-Datenbank nicht gestartet 

Siehe Anhang.