Neues Modul InfluxDBLogger

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

Vorheriges Thema - Nächstes Thema

mh76

Ja, das hast du richtig verstanden. Wobei ich heute festgestellt habe, das room und group ungünstig sind.
Diese attribute dürfen dürfen mehrere Einträge haben die durch Komma getrennt werden.
Das ist zwar grundlegend erlaubt, muss aber escaped werden, siehe hier -> https://influxdbcom.readthedocs.io/en/latest/content/docs/v0.9/write_protocols/write_syntax/
Ich vermute mal das sich das dann auch ungünstig macht in den Grafana abfragen usw.

Hab das deviceTagName mal zum testen etwas missbraucht, um ein paar weitere Tags mit zu übergeben ;-)
Bei mir steht aktuell zu testen, das hier "deviceTagName room=fhem,site=G13,device" drin,
einfach führend alle Tags rein die mitgegeben werden sollen und als letztes den tatsächlcihen deviceTagNamen.

Apropo es ist durchaus erlaubt mehrere Tags und Values an einen Measurement und Timestamp zu hängen,
da das Value nicht value heissen muss, es kann auch vcc, load, temp, tempmax, tempmin usw. heissen.
Also so ein Reading mit mehreren Values
2020-11-08 19:56:09 ESPEasy ESPEasy_ESP021_SYSINFO loa: 5.91 rss: -60.00 upt: 1776.00 vcc: 3.28
würde man z.B. so übergeben:
sysinfo,site=Zuhause,room=ESPEasy load=5.91,rssi=-60.00,uptime=1776.00,vcc=3.28 timestamp
Das macht insbesondere Sinn wenn man Werte in Korrelation zueinander haben will, Temperatur, Luftfechte, Luftdruck, Taupunkt oder eben cpu, mem und load.

Bei meinen OWX Devices für die Aquarien hab ich temphigh und templow gesetzt.
Wenn man jetzt quasi alle drei, temphigh, templow und das reading temp mit dem gleichen timestamp übergibt, kann man das schön in Grafana einbauen.

timmib

Das InfluxDB das kann ist mir bewusst. Siehe https://docs.influxdata.com/influxdb/v1.8/write_protocols/line_protocol_tutorial/

Man könnte natürlich zusätzlich zu dem additionalTags Attribut, auch ein additionalFields Attribut machen, nur müssten diese dann zeitgleich oder besser vor dem auslösenden Reading aktualisiert worden sein.

Verstehst Du was ich meine?

Sonst passt der Zeitpunkt nicht. Müsste man mal testen. Oft werden Readings ja im Bulk aktualisiert. https://wiki.fhem.de/wiki/DevelopmentModuleAPI#readingsEndUpdate
In den Fällen würde das dann passen.

Das primäre ValueFieldName könnte man natürlich auch konfigurabel machen.

Andreasgs

Hallo,

Welcher InfluxDB - Version betreibt ihr das Modul?

Ich bekomme aktuell die InfluxDB Version 2.0 nicht zum laufen. D.h. über Localhost:8086 kann ich nicht auf das WebModul zugreifen, und eine initial angelegtes Bucket kann ich nicht erreichen. Kennt ihr das? Habt ein ähnliches Problem?

Mir hat es die 2 Jahre laufende VM zusammegelegt und musste jetzt aktualisieren, und hab mir eben die neueste Version geholt, die aber leider nicht läuft... Soll ich auf die "Alte" 1.x Version zurück?

Grüße
Andreas

timmib

Guten Tag,

ich nutze 1.8.2. Die 2er habe ich nie probiert, weil ich mit der "Alten" glücklich bin.

Viel Erfolg

Tim


EinEinfach

Hallo zusammen,

schreibt das Modul die Zahlenwerte als String in die Datenbank rein, oder findet hier eine entsprechende Umwandlung in den int, float usw. vorher statt?

Gruß
Alexander
fhem auf Intel NUC6CAYH mit Proxmox im LXC (Debian 10), KNX mit knxd über MDT SCN-IP000.02, Buderus GB192-15i über KM100, Solaredge WR SE9K über Modbus-TCP

kadettilac89

Zitat von: Andreasgs am 16 November 2020, 13:24:11

Ich bekomme aktuell die InfluxDB Version 2.0 nicht zum laufen. D.h. über Localhost:8086 kann ich nicht auf das WebModul zugreifen, und eine initial angelegtes Bucket kann ich nicht erreichen. Kennt ihr das? Habt ein ähnliches Problem?


The migration will need adjustments, many InfluxDB v1 functionalities are replaced or removed in version 2. ... https://www.sqlpac.com/referentiel/docs-en/influxdb-v2-getting-started-setup-preparing-migration-from-version-1.7.html

Version 2 ist noch nichtmal released, oder ist es schon RTC? Version 1.* funktioniert. Wenn du selber kein Entwickler bist, und für v2.0 entwickelst würde ich erstmal bei der aktuellsten 1.* Version bleiben

kadettilac89

Zitat von: EinEinfach am 18 November 2020, 10:14:26
Hallo zusammen,

schreibt das Modul die Zahlenwerte als String in die Datenbank rein, oder findet hier eine entsprechende Umwandlung in den int, float usw. vorher statt?

Gruß
Alexander

Das macht doch die Datenbank selbst, nur als Attribut vorgegebene Convert-Mappings werden gemacht. Bei der Übergabe per HTTP ist erstmal alles String. Hast du ein konkretest Problem, oder warum die Frage?


https://influxdbcom.readthedocs.io/en/latest/content/docs/v0.9/write_protocols/write_syntax/

Line Protocol
The syntax for the line protocol is

measurement[,tag_key1=tag_value1...] field_key=field_value[,field_key2=field_value2] [timestamp]

For example:

measurement,tkey1=tval1,tkey2=tval2 fkey=fval,fkey2=fval2 1234567890000000000

EinEinfach

ZitatHast du ein konkretest Problem, oder warum die Frage?

Ich nutze aktuell den DBLog-Modul mit einer MariaDB. Die Daten werden mit Grafana visualisiert. Dort muss ich jeden einzelnen Wert casten, weil die Daten als String abgelegt werden. Ich könnte mir vorstellen, dass bei der großen Datenmengen (lange Zeiträume) es evtl. unnötig länger dauern kann bis die Grafana es visualisieren kann. Deswegen die Überlegung umzusteigen.

Gruß
fhem auf Intel NUC6CAYH mit Proxmox im LXC (Debian 10), KNX mit knxd über MDT SCN-IP000.02, Buderus GB192-15i über KM100, Solaredge WR SE9K über Modbus-TCP

timmib

#23
Der Stack mit Influx ist da schneller. Das war auch meine Motivation.

Hogi

N'abend zusammen,

zunächst ein großes Dankeschön für die Arbeit und Mühe, die in dieses Modul gesteckt wurden. Ich suche schon lange nach einer Möglichkeit die FHEM Metriken in die Influx DB zu übertragen, um dann Grafana Dashboards zu erstellen. Nach ein paar Startschwierigkeiten funktioniert alles soweit prima. Top! Allerdings habe ich noch ein paar Detailfragen an die Expertenrunde hier:

1) Nachdem hier erwähnt wurde, dass es eine DE und EN Dokumentation gibt habe ich diese nicht sofort gefunden. Beschäftige mich leider nicht so regelmäßig mit Fhem, so dass ich erst im Source Code diese Doku gefunden habe. Soweit ich das verstehe müsste diese doch in der CommandRef bei mir lokal eigentlich auftauchen, richtig? Das tut es bei mir aber nicht. Ich habe das Modul in den FHEM Ordner kopiert und bin davon ausgegangen, dass sie damit nach einen "shutdown restart" auch in der CommandRef erscheint. Oder habe ich da einen Denkfehler?

2) Ich übertrage ein paar FHT80 Readings meiner Thermostate. Eines davon ist die Ventilöffnung, die in den Readings z.B mit "10%" angegeben sind. Über attr <name> conversion 0%=0, 1%=1, ... konvertiere ich die Strings in die numerischen Werte. Bei 0% bis 100% wird das aber Mühsam. Es gibt doch bestimmt einen kürzeren Weg aus einem Reading das "%" zu entfernen.

3) Ich möchte noch ein paar Readings ausschließen, aber bin mit der regex Syntax nicht so vertraut. Wie binde ich ein ReadingVal('BeispielReading1','BeispielReading1') als regex ein, so dass ich gleich mehrere Readings ausschließen kann? Ein Beispiel in der Doku hilft sicherlich auch anderen, die nicht so mit den Fhem/Perl Möglichkeiten vertraut sind. Wurde glaube ich schon im Thread angesprochen, das Regex zwar mächtig ist, aber nicht jedem hilft.

4) Im Source Code des Moduls habe ich eine Möglichkeit des Resets der Statistik gesehen. Wie führe ich das aus?

Was mir noch so aufgefallen ist: im Log bekomme ich ein paar Warnings:

PERL WARNING: Scalar value @ab[1] better written as $ab[1] at ./FHEM/93_InfluxDBLogger.pm line 117, <$fh> line 88.
PERL WARNING: Use of uninitialized value in regexp compilation at ./FHEM/93_InfluxDBLogger.pm line 41, <$fh> line 88.
PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/93_InfluxDBLogger.pm line 46, <$fh> line 88.

Nutze perl 5.28.1 auf einem Pi2 unter OSMC.
Vorab vielen Dank für ein paar Rückmeldungen.

timmib

#25
Hallo Hogi,

schön wenn das Modul jemanden hilft.

1. Die Hilfe zu einem Kommando findest Du rechts unten bei jedem Device von dem Typen. Da steht
ZitatDevice specific help
(siehe Anhang)
Damit das in der lokalen Commandref stehst musst die erst zusammenbauen lassen, wenn das Modul nicht mit FHEM mitgekommen ist. Siehe hier https://wiki.fhem.de/wiki/Guidelines_zur_Dokumentation

2. Das ist eine normale RegEx-Frage. Die ist hier im Thread nicht ganz richtig aufgehoben. Das Stichwort sind Gruppen. https://www.techrepublic.com/article/regular-expresssion-substitutions-in-perl/
Also sowas in der Art ([0-9]+)%=$1 Was soviel bedeutet, wie nimm das was in der ersten(1) Klammer matcht um pack es in das Ergebnis. Kann sein, dass du zwei %% schreiben musst damit der das nicht als Steuerzeichen erkennt sondern escaped.

3. RegEx in FHEM bzw. Perl nicht zu unterstützen ist so eine Art Vaterlandsverrat.  ;) Da muss man durch. attr logger readingExclude BeispielReading1:\s.+Wenn das nicht hilft meld dich nochmal.

4. set logger resetStatistics Müsste oben beim Device aber auch im Dropdown stehen.

Viele Grüße

Tim



Hogi

Danke fürs Feedback Tim,

zu 1) Habe den Link zur "Device specific help" gefunden. Beim Klick darauf ist die Webseite zunächst lediglich an den Seitenanfang (top) gesprungen. Das brachte mich darauf, dass die Referenz im HTML Content noch nicht vorhanden ist. Dann habe ich mit perl ./contrib/commandref_join.pl die Referenz neu aufbauen lassen. Dabei sind dann ein paar kleine Fehler in deinem Modul aufgetaucht:

*** EN FHEM/93_InfluxDBLogger.pm: ignoring text due to DOS encoding
*** DE FHEM/93_InfluxDBLogger.pm: ignoring text due to DOS encoding


Ich habe dann die Zeilenendezeilen CRLF in das unixtypisches LF am Ende gewandelt und die Referenz erneut aufbauen lassen. Jetzt wurde der Inhalt auch durchlaufen. Dann ist aufgefallen, dass in Zeile 439 und 522 das abschließende ul-Tag fehlte und am Ende der DE Doku "=end html" durch "=end html_DE" noch ersetzt werden muss. Ein erneutes Aufbauen der Referenz brachte dann keine Fehler mehr. Die Doku taucht nun in der CommandRef auf und auch die Device specific help springt dann direkt in die Doku zum Modul.

zu 3) Hier ging es mir eher darum, wie ich mehrere Excludes aufzähle. Ich hab es mit ack:\s.+ actuator1:\s.+ battery:\s.+ batteryState:\s.+ end-xmit:\s.+ lowtemp:\s.+ mode:\s.+ night-temp:\s.+ probiert, aber das scheint nicht zu greifen. Perfekt wäre es, wenn man die dropped Readings in der dropped_writes_last_message alle namentlich aufgeführt bekäme. Das vereinfacht die Optimierung. So muss ich erst die Statistik resetten und nach einem erneuten durchlauf schauen, ob noch etwas gedropt wird. Aber ich kann damit gut leben. Bin soweit mit dem Modul glücklich.

Hogi

Habe die Excludes nun mit folgendem regex Ausdruck hinbekommen:

(battery:\s.+|batteryState:\s.+|lowtemp:\s.+|mode:\s.+|warnings:\s.+|window:\s.+|windowsensor:\s.+)

timmib

Sehr gut, danke für die Hinweise bzgl. Doku.

Klappt auch das Konvertieren der Prozentwerte?

Hogi

Leider ein. Ich habe nun verschiedene Ausdrücke mit online Regex Testern ausprobiert und die Variante mit dem Grouping erscheint mir auch logisch richtig und wird auch von den Regex Testern als richtig angesehen. Aber mit

attr logger conversions ([0-9]+)%=$1

meldet dropped_writes_last_message immer noch "FHT_3e14 actuator: 0%", d.h. das Prozentzeichen wird immer noch übergeben.