Neues Modul: 93_InfluxDBLog

Begonnen von d.schoen, 05 Mai 2017, 11:52:12

Vorheriges Thema - Nächstes Thema

KernSani

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...
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

KernSani

@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
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

pitre

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.

KernSani

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
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

wopl

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
Haussteuerung mit 300 Devices, Kopplung mit Wago SPS, InfluxDB (Grafana), HomeMatic, Tinkerforge (Fensterkontakte), SmartMeter, Heizungsüberwachung/-logging... Installation in QNAP NAS Docker container vollautomatisiert mit Ansible und GITlab

kadettilac89

#140
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});

wopl

Dank Dir !
Ja, jetzt funktioniert die Abfrage auch mit HTTPS.  :)
War ja wirklich einfach !

Gruß Wolfram
Haussteuerung mit 300 Devices, Kopplung mit Wago SPS, InfluxDB (Grafana), HomeMatic, Tinkerforge (Fensterkontakte), SmartMeter, Heizungsüberwachung/-logging... Installation in QNAP NAS Docker container vollautomatisiert mit Ansible und GITlab

spcqike

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 :)

volschin

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.
Intel NUC+Ubuntu 22.04+Docker+FHEM6
HomeMatic: HM-MOD-RPI-PCB+HM-USB-CFG2+hmland+diverse, HUE: Hue-Bridge, RaspBee+deCONZ+diverse
Amzn Dash-Buttons, Siro Rollos
4xRPi, 4xCO20, OWL+USB, HarmonyHub, FRITZ!Box 7590, Echo Dots+Show8, Logi Circle 2, HomeBridge
TIG Stack (Telegraf, InfluxDB, Grafana)

timmib

#144
Guten Morgen,

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

ZitatDas 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

kadettilac89

Zitat 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?

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.

timmib

Zitatjeder 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.

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

kadettilac89

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

kadettilac89

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

timmib

#149
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

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.