FHEM Forum

FHEM - Hausautomations-Systeme => Unterstützende Dienste => Thema gestartet von: timmib am 07 Oktober 2020, 23:31:09

Titel: Neues Modul InfluxDBLogger
Beitrag von: timmib am 07 Oktober 2020, 23:31:09
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 (https://forum.fhem.de/index.php/topic,71551.msg1073087.html)), aber es:

Deswegen habe ich nun ein neues Modul geschrieben welches:

Zum Thema "konfigurierbar":

Zum Thema "Statistik":

Zum Thema "Sonstiges":

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 (https://fhem.de/commandref.html#readingFnAttributes) unterstützt. (Danke nochmal an gvzdus)
Damit lassen sich die Events des Loggers selber unterdrücken.

*** UPDATE 04.02.2022 ***
Es werden nun Zeichenketten als Wert und die originalen Zeitstempel unterstützt - siehe (https://forum.fhem.de/index.php/topic,114860.msg1205868.html#msg1205868 (https://forum.fhem.de/index.php/topic,114860.msg1205868.html#msg1205868) und Dank an msome)

Viele Grüße

Tim

Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 10 Oktober 2020, 19:58:04
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?
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: plin am 11 Oktober 2020, 09:11:45
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

Wie kann ich die Liste erweitern (z.B. um open/closed)? Siehe auch https://forum.fhem.de/index.php/topic,71551.msg968874.html#msg968874
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 12 Oktober 2020, 19:17:03
Habe ich übersehen. Wird eingebaut.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 12 Oktober 2020, 21:08:24
Es gibt Neuigkeiten:


Viele Erfolg beim Testen
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: kadettilac89 am 12 Oktober 2020, 22:27:51
Zitat 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)  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.

Ich schreibe mal hier weiter. Hier kann ich editieren.

Es ist die Frage was gewollt ist. Devspec kann auch folgendes ... <readingname>=<Wert oder regex>. Das ist der große Vorteil von devspec. Das kann notifydev nicht. Das macht "nur" regex auf Devicename.

Ich finde es verwirrend wenn Regex auf Devicename und dann später Regex auf Reading. Regex-Syntax ist nicht so ohne. Da hast du dann laufend Supportprobleme mit Leuten die mit Regex nicht umgehen können. Nicht jeder ist Entwickler ....

Wie gesagt, devspec wäre eine feine Sache da mächtig und schon gut dokumentiert. Jetzt müsstest du bei Init einmalig ein Array füllen und puffern. devspec2array füllt ein Array mit allen Devices auf die devspec zutrift.

Das Array ist statisch bis sich die Definition ändert. Beim Aufruf von Notify ... in der Sub die das Filtern auf die Events macht .... kannst dann als ersten Schritt ein grep -w oder eine andere Perl Funktion rufen die prüft ob das event-device im Array vorkommt. An der Stelle, an der ich quck'n'dirty auch devspec2array eingebaut habe ... siehe Kommentar im anderen Thread.

Ich habe mich noch nie mit den Dev-Richtlinien in Fhem beschäftigt. Es müsste aber funktionieren ein array als element in der list (hash->{xxxx})  zu setzen und dann später zu prüfen, $hash ist überall verfügbar.

Speicher des Arrays sollte nicht viel sein. Wenn ich mal UTF-8 nehme mit max 4 bytes pro Char, Dev-Namen mit 30 Zeichen und 200 Devices auf das devspec filtert wären das worst case 24 KB Ram wenn ich jetzt nicht falsch gerechnet habe. Also akzeptabel.

Ich denke das Array wäre schnell eingebaut mit weniger Aufwand als selber was auszuwerten. Im Idealfall 2 Zeilen Code.

Ich meine so in etwa. Ich habe kein Fhem hier an dem ich testen kann. Die Syntax wie man auf Array in der Liste zugreift weiß ich jetzt nicht, ggf. fehlt irgendwo ein @ oder % zum referenzieren ...


sub InfluxDBLogger_Initialize($) {
    my ($hash) = @_;
    $hash->{DefFn}    = "InfluxDBLogger_Define";
    $hash->{NotifyFn} = "InfluxDBLogger_Notify";
    $hash->{SetFn} = "InfluxDBLogger_Set";
    $hash->{RenameFn} = "InfluxDBLogger_Rename";
    $hash->{AttrList} = "disable:1,0 security:basic_auth,none username readingInclude readingExclude conversions deviceTagName";
    $hash ->{DevSpecArray} = devspec2array($hash->{REGEX}); <<<<---- Array füllen
    Log3 undef, 2, "InfluxDBLogger: Initialized new";
}



in **notify

my $devName = $dev_hash->{NAME}; # Device that created the events
my $events = deviceEvents($dev_hash, 1);

return "" if not grep { $_ eq $devName } $own_hash->{devSpecArray};     #<< -------   check if device in array

    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 InfluxDBLogger
Beitrag von: timmib am 12 Oktober 2020, 22:42:53
Wäre schön, wenn ich nur 200 Devices hätte  ::)

Dein Plan hat nur einen Haken. Alle Definition die anschließend erstellt werden würden nicht erkannt werden. Beim Neustart ist das ganze womöglich noch schlimmer.

Demnach https://wiki.fhem.de/wiki/DevelopmentModuleIntro (https://wiki.fhem.de/wiki/DevelopmentModuleIntro) kann ich das $hash->{NOTIFYDEV} auch einfach selber setzen und FHEM macht das.

Ich probier das mal kurz in der Entwicklungs VM.

Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 12 Oktober 2020, 22:53:20
Klappt wunderbar. Habe die neue Version an die Themeneröffnung angehangen. Musste nur eine Zeile ändern und eine löschen.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: kadettilac89 am 13 Oktober 2020, 06:29:42
du hast jetzt in der Definition auf {NOTIFYDEV} gewechselt. Bei mir schein das devspec dann zu  funktionieren.

was meinst du mit a,b,c Beispiel, wie sieht da die Definition und das Event aus, oder was willst du filtern? .. .dein Kommentar im anderen Thread.

Zitat von: timmib am 12 Oktober 2020, 21:17:50
Ich sehe grad beim meinem a,b,c Beispiel setzt der das NOTIFYDEV nicht. Laut
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 13 Oktober 2020, 09:05:33
Ich meinte mit a,b,c sowas wie hier wie in meinem konkreten produktiven Beispiel. Dort reduziere ich in der Definition auf die drei Klima-Geräte.

defmod influxer_klima InfluxDBLogger http://hostname:8086 klima klimaKindControl,klimaBueroControl,klimaSchlafzimmerControl
attr influxer_klima readingInclude pwr_hour_last:.*


Daraus hat der vorher nicht von alleine mittles notifyRegexpChanged eine NOTIFYDEV gemacht. In der Doku steht ja auch
ZitatEs kann durchaus vorkommen, dass kein Eintrag in NOTIFYDEV gesetzt wird, da nicht zweifelsfrei zwischen Definitionsnamen und Event unterschieden werden kann.
Wobei ich nicht gedacht hätte, das er a,b,c nicht als devspec erkennen würde.

Egal, jetzt geht es.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: kadettilac89 am 13 Oktober 2020, 10:10:46
Zitat von: timmib am 13 Oktober 2020, 09:05:33
Ich meinte mit a,b,c sowas wie hier wie in meinem konkreten produktiven Beispiel. Dort reduziere ich in der Definition auf die drei Klima-Geräte.

defmod influxer_klima InfluxDBLogger http://hostname:8086 klima klimaKindControl,klimaBueroControl,klimaSchlafzimmerControl
attr influxer_klima readingInclude pwr_hour_last:.*


Daraus hat der vorher nicht von alleine mittles notifyRegexpChanged eine NOTIFYDEV gemacht. In der Doku steht ja auch  Wobei ich nicht gedacht hätte, das er a,b,c nicht als devspec erkennen würde.

Egal, jetzt geht es.

Du meinst "klima klimaKindControl,klimaBueroControl,klimaSchlafzimmerControl" ist dein devspec? Wenn du das zerlegst hast du in "$hash->{NOTIFYDEV} = $a[4];" nur den String "kind" ... das Leerzeichen setzt "klimaKindControl,klimaBueroControl,klimaSchlafzimmerControl" in element $a[5]. Das wird aber nicht verwendet.

Ggf. eine Prüfung ob mehr als 4 Parameter im Def. angegeben wurden.

Siehe Doku devspec "die Spezifikation kann keine Leerzeichen enthalten."

Du kann die sevspec testen indem du "list <devspec>" in die Eingabezeile gibst. Dann siehst du was gefunden wird. In deinem Fall wahrscheinlich sogar einen Fehler.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 13 Oktober 2020, 12:10:12
Nene, das ist schon richtig so.

Zwischen der URL und der devspec kommt ja der Datenbankname. Da ist kein Leerzeichen in der devspec.

Siehe Hilfe:
Usage: define devname InfluxDBLogger [http|https]://IP_or_Hostname:port dbname devspec
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: mh76 am 07 November 2020, 20:40:32
Erstmal vorneweg ein Danke das jemand weiter an der Anbindung von Influxdb an FHEM arbeitet.

Ich habe das Modul gerade installiert und es läuft soweit stabil und tut was es soll,
das alte Modul InfluxDBLog habe ich etwa seit einem halben Jahr am laufen.

Was mich bei beiden Modulen stört, das als Tag nur "site_name" bzw. "device", mit ein paar Änderungen im Code, gesetzt wird.

Da ich Influxdb aus der Monitoring, Visualisierung und Reporting Sicht kenne, weiß ich wie wichtig die vergabe von Tags ist,
da jeder eine andere Sciht auf Daten via Grafana oder oder hat und haben will.

Momentan lasse ich mir die Daten meiner ESP (ESPEasy) direkt via UDP in eine andere Influxdb schreiben, dort sieht meine Übergabe in etwa so aus:

%valname%,site=G13,floor=OG2,room=Office,sensor=%tskname%,device=%sysname% value=%value%

so kann ich mir dann im Grafana meine Dashboards bzw. Graphen bauen und diese werden dann auf Basis der Tags dynamisch erweitert. Kommt einer neuer ESP dazu landet er im SYSINFO Dashboard und wird den Graphen für VCC, RSSI und Load automatisch hinzugefügt. Ebenso ein neuer Temperatursensor im Gebäude 13 und OG2 usw.

Ich hoffe das Tags bzw. an den Devices vorhandene Räume, Gruppen, Aliase etc auch mal übergeben werden können an Influxdb.


Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: plin am 07 November 2020, 21:01:41
Wie wär's mit einem globalen Attribut in dem dann für jedes Device die Tags festgelegt werden können. Am besten auch über Variable wie room=$room etc.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 08 November 2020, 09:44:55
Hallo,

man muss nichts am Code ändern um das device tag zu ändern. Es gibt ein Attribut "deviceTagName".

Dir schwebt aber zusätzliches ein Attribut am Logger vor wie:
additionalTags welches dann mit room=%room%,hans=%franz%

..gesetzt wird.

Das in %% sollten dann readings,attribute oder internals sein.
Dies könnte man auch zusätzlich als global defnieren.

Richtig verstanden?


Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: mh76 am 08 November 2020, 20:09:56
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.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 08 November 2020, 21:27:35
Das InfluxDB das kann ist mir bewusst. Siehe https://docs.influxdata.com/influxdb/v1.8/write_protocols/line_protocol_tutorial/ (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 (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.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: Andreasgs am 16 November 2020, 13:24:11
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
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 16 November 2020, 15:14:24
Guten Tag,

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

Viel Erfolg

Tim

Titel: Antw:Neues Modul InfluxDBLogger
Beitrag 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
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: kadettilac89 am 18 November 2020, 10:21:24
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
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: kadettilac89 am 18 November 2020, 10:28:06
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
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: EinEinfach am 18 November 2020, 11:00:23
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ß
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 18 November 2020, 11:02:18
Der Stack mit Influx ist da schneller. Das war auch meine Motivation.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: Hogi am 20 November 2020, 19:42:21
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.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 20 November 2020, 20:07:46
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 (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/ (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


Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: Hogi am 21 November 2020, 10:45:38
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.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: Hogi am 21 November 2020, 12:28:47
Habe die Excludes nun mit folgendem regex Ausdruck hinbekommen:

(battery:\s.+|batteryState:\s.+|lowtemp:\s.+|mode:\s.+|warnings:\s.+|window:\s.+|windowsensor:\s.+)
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 21 November 2020, 14:44:13
Sehr gut, danke für die Hinweise bzgl. Doku.

Klappt auch das Konvertieren der Prozentwerte?
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: Hogi am 21 November 2020, 15:58:17
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.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 21 November 2020, 16:56:45
Wenn die Zeile 117 so aussieht geht es:

$value =~ s/@ab[0]/eval(@ab[1])/ei;

Das Problem war, dass der das sonst schon ersetzt aber mit $1, weil $1 nicht richtig ausgewertet wird. Hilft Dir evtl als Workaround. Ich muss mal in Gänze gucken ob das so ideal ist.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: kadettilac89 am 21 November 2020, 17:14:28
Zitat von: Hogi am 21 November 2020, 15:58:17
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.
Unabhängig von der Convert-Routine. Wenn im Reading das % ohne Leerzeichen drin ist scheint das ein Problem im Modul zu sein. Du kannst hierzu auch einen Thread zum entsprechenden Modul öffnen. Es sollte nicht nötig sein, die Einheit vom Reading zu entfernen.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: Hogi am 21 November 2020, 17:41:03
Mit dem Workaround in Zeile 117 funktioniert es für mich nun perfekt. Habe in der InfluxDB noch aufgeräumt und alle unnötigen Series gedropt, so dass auch dort nur noch die Measurements vorhanden sind, die vom Modul übertragen werden. Alles nun tip top. Vielen Dank, Tim. Was'n geiler Tag  ;D
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 21 November 2020, 20:33:47
ZitatAlles nun tip top. Vielen Dank, Tim. Was'n geiler Tag
@Hogi Freut mich.

ZitatEs sollte nicht nötig sein, die Einheit vom Reading zu entfernen.

@kadettilac89
Wieso? Versteheh ich nicht. InfluxDB logged Skalare Werte. Was soll die Datenbank mit %, °C, km usw. anfangen? Welche Aufgabe siehst Du da am Modul?
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: kadettilac89 am 21 November 2020, 20:55:17


Zitat von: timmib am 21 November 2020, 20:33:47
@kadettilac89
Wieso? Versteheh ich nicht. InfluxDB logged Skalare Werte. Was soll die Datenbank mit %, °C, km usw. anfangen? Welche Aufgabe siehst Du da am Modul?

Zitat von: Hogi am 20 November 2020, 19:42:21
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.

Das Konvertieren eines Readings mit Wert 100% sollte überhaupt nicht nötig sein. Es gibt oder gab ein paar Module in denen die Readings nicht korrekt aufgebaut sind und das Leerzeichen zwischen <value> und <unit> fehlt. Das hat zur Folge das im Filelog, DB-Log oder hier in deinem Modul ein String statt einem reinem Zahlenwert verarbeitet wird.

Darum meine Empfehlung den Modulauto vom FHT80-Modul zu fragen ob das ein Fehler ist. Oder wie andere damit umgehen.

In HM-Thermostaten wird das vergleichbare Reading (valvePosition) mit z. B. mit  10 % ausgegeben. Da ist dann kein Zusatzaufwand nötig.

Alternativ ein UserREading mit ReadingsNum o. ä.. Wäre einfacher als regex auf % und so ...
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 21 November 2020, 23:26:55
Ahso - kapiert.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: gvzdus am 24 November 2020, 22:19:30
Hi Tim,

ich habe mir 1-2 Tagen endlich den Ruck gegeben, auch mal mit Grafana & Co. auf Schönheit zu achten, und auf die Schnelle was bei Amazon als Datensenke für meinen FHEM-Raspi aufgesetzt. Was soll ich sagen: Mit dem Beispiel auf Seite 1 gelang es sofort, vielen Dank!
Spaßeshalber füttere ich gerade die Werte meines Stromzählers (6 Werte / Sekunde) hoch - klappt.
Mit HTTPS zieht es allerdings etwas viel CPU.

Egal. Auf jeden Fall hat es auf Anhieb und gut geklappt - Danke!!
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 24 November 2020, 22:22:46
Influx macht halt einfach Spaß. Ich kann nur jedem auch den Kapacitor ans Herz legen. Der kann auch per MQTT zurück nach FHEM "telefonieren".
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: gvzdus am 26 November 2020, 08:25:22
Moin, also, natürlich ist Dein Modul das beste der Welt :-)

Was wäre denn d.E. die "Best practise", um massenhaft Events zu schaufeln?
Mein Usecase ist aktuell, die Daten auf einen AWS EC2-Server mit Ubuntu mit InfluxDB + Grafana zu schaufeln. Das umfasst aktuell alles rund um die MAX-Thermostate und Strom (Stromzähler und Solarproduktion).

Im Moment gönne ich mir spaßeshalber, die Stromzählerwerte komplett - also sekündlich und mit allen 3 Phasen - "hochzupusten".
Dass das per HTTPS für eine RPi 3 nicht die beste Idee ist, habe ich schon festgestellt und auf HTTP umgestellt.

Variante 1) Ich stelle auf was Anderes um
Variante 2) Ich pfusche an Deinem Modul herum und überlege mal, ob man da so was wie Aggregieren und Bulkupload hinbekommt. (Z.B. 5 Sekunden sammeln, dann pusten).

Was meinst Du?

Ansonsten, um vielleicht dem einen oder anderen Zeit zu sparen:

Meine Vorgehensweise für Datenquellen:
1) Device-Spezifikation anpassen und gucken, ob die Live-Daten in InfluxDB ankommen.
2) Alt-Daten vom File-Logger hinterherblasen.

Mikro-Perlscript "influxconv":
#!/usr/bin/perl

use Time::Local;

while (<>) {
  next unless (/^(\d{4})-(\d\d)-(\d\d)_(\d\d):(\d\d):(\d\d) (\S+) (\S+): ([0-9.]+)\s*$/);
  my $time = timelocal($6, $5, $4, $3, $2-1, $1);
  print "$8,site_name=$7 value=$9 $time"."000000000\n";
}


... und dann mit beispielsweise:

egrep '(temperature|desiredTemperature|valveposition)' eg_wohnz_wt1-2020.log  | influxconv | curl -XPOST -i http://<meine-url>/write?db=fhem --data-binary @-

hochpusten. Klappt selbst für geschwätzigere Geräte wie die Wandthermostate in einem Rutsch.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 26 November 2020, 08:36:57
Hi,

das geht runter wie Öl.

Also in Antwort #16 war ja schonmal die Idee:
ZitatMan 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.
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.

Damit wäre ein Bulk möglich. Muss man wie geschrieben halt aufpassen, sonst kommt Murks bei raus, in dem Sinne, dass alte Werte geschrieben werden würden.

Soll ich das mal einbauen?
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: gvzdus am 26 November 2020, 09:29:11
Naja, InfluxDB arbeitet ja auf Nanosekundenbasis. Grundsätzlich hat ggf. der Zielserver die genauere Uhrzeit als der FHEM-Raspi. Aber in meinem Fall macht das keinen Unterschied. Daher würde ich zu jedem Event die Uhrzeit im Buffer mitspeichern und diese mit übergeben.

Ich muss jetzt sagen: Beim schnellen Lesen verstehe ich den Source nicht ganz. Ich sehe, dass Du die Events als Array und nicht zwingend einzeln bekommst, und mein gebrochenes Perl, die Größe des Arrays auszugeben, führt hierzu:

Eingefügt habe ich (kaputt):
<code>
    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
    Log3 $name, 4, "InfluxDBLogger: [$name] notified about " . ((@#{$events})+1) . " events";
    foreach my $event (@{$events}) {
</code>
(Ich wollte die Arraygröße verstehen).

Das führt zu folgendem Logging:
2020.11.26 09:25:34 4: InfluxDBLogger: [influxfhem] notified about 1 events
2020.11.26 09:25:34 4: InfluxDBLogger: [influxfhem] notified from device MT175 about total_consumption: 357889.7
2020.11.26 09:25:34 4: InfluxDBLogger: [influxfhem] Sending data total_consumption,site_name=MT175 value=357889.7 to http://<myurl>/write?db=fhem
2020.11.26 09:25:34 4: InfluxDBLogger: [influxfhem] notified from device MT175 about total_consumption_Ch1: 357889.7
2020.11.26 09:25:34 4: InfluxDBLogger: [influxfhem] Sending data total_consumption_Ch1,site_name=MT175 value=357889.7 to http://<myurl>/write?db=fhem
2020.11.26 09:25:34 4: InfluxDBLogger: [influxfhem] notified from device MT175 about power: 304
2020.11.26 09:25:34 4: InfluxDBLogger: [influxfhem] Sending data power,site_name=MT175 value=304 to http://<myurl>/write?db=fhem
2020.11.26 09:25:34 4: InfluxDBLogger: [influxfhem] notified from device MT175 about 1.0.36.7.0.255: 312
2020.11.26 09:25:34 4: InfluxDBLogger: [influxfhem] Sending data 1.0.36.7.0.255,site_name=MT175 value=312 to http://<myurl>/write?db=fhem
2020.11.26 09:25:34 4: InfluxDBLogger: [influxfhem] notified from device MT175 about 1.0.56.7.0.255: -62
2020.11.26 09:25:34 4: InfluxDBLogger: [influxfhem] Sending data 1.0.56.7.0.255,site_name=MT175 value=-62 to http://<myurl>/write?db=fhem
2020.11.26 09:25:34 4: InfluxDBLogger: [influxfhem] notified from device MT175 about 1.0.76.7.0.255: 52
2020.11.26 09:25:34 4: InfluxDBLogger: [influxfhem] Sending data 1.0.76.7.0.255,site_name=MT175 value=52 to http://<myurl>/write?db=fhem


Also offenbar schon ein Array (auch wenn mein "((@#{$events})+1)") offenbar falsch ist), aber Du machst einzelne Writes daraus. Das wäre also schon einmal der erste Aggregationslayer.

Der zweite Aggregationslayer wäre dann ein Buffern für z.B: 1 Sekunde oder maximal z.B. 30 Messwerte, whatever first.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 26 November 2020, 10:50:58
Hi,

der Witz ist das pro aktualisiertem Reading in FHEM ein Event kommt. Wenn man nun das "additionalFields" einbaut, würde dies AKTIV beim auslösenden Device die Readingsnachlesen um dann alle zusammen (das aus dem Event und die nachgelesenen) an Influx zu schicken. Das setzt wie gesagt aber vorraus, das diese nachgelesenen Werte genau so aktuell sind wie das was den Event auslöst. Sonst werden alte Daten verschickt.

Viele Grüße

Tim
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: gvzdus am 26 November 2020, 11:07:03
Nee, wir reden aneinander vorbei.

Was ich möchte: Weniger HTTP-Operationen. Im Falle meines Stromzählers erhälst Du *einen* Notify-Aufruf mit mehreren Events. Die würde ich lieber in einem Rutsch hochgeblasen sehen, also das Ergebnis von InfluxDBLogger_BuildData erst zu einem String zusammenzuführen, und dann außerhalb der
foreach my $event (@{$events}) {
-Schleife - wenn der String nicht leer ist - als eine Operation hochzuladen.
Im Moment erhalte ich vom Stromzähler etwa 1 Notify pro Sekunde, und Du machst daraus 4-6 Writes, weil das @{$events} 4-6 Werte enthält.

Was Du erwähnst: Zusätzlich noch Readings auszulesen.

Was mh73 (?) m.E. wollte: Einzelreadings, die aus komplexen Key/Values bestehen, zu splitten.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 26 November 2020, 11:08:14
Aber das sind doch weniger HTTP Operationen wenn man mehrere Readings in ein Write packt.

Man kann natürlich auch den Kram aus einem Notify sammeln, aber das wird wohl wenig bringen weil selten zufällig geloggete Geräte gleichzeitig auslösen und inhaltlich es es auch ungünstig die Werte von einem Gerät zu splitten auf mehrer Measurements.

https://docs.influxdata.com/influxdb/v1.8/guides/write_data/#writing-multiple-points (https://docs.influxdata.com/influxdb/v1.8/guides/write_data/#writing-multiple-points)
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: gvzdus am 26 November 2020, 11:21:11
Schau Dir doch bitte noch einmal mein obiges Posting an:
Ich habe eine Zeile in Dein Modul eingebaut, die die Anzahl der Events loggen sollte, das aber nicht getan hat ("1" statt richtigem Wert). Das ist aber egal, weil man im darunterstehenden Aufruf erkennt, dass im events-Array mehrere "Zeilen" waren. Der Grund ist, dass das OBIS-Modul sauber aufgebaut ist und mit "BulkUpdate" mehrere geänderte Readings zu einem Block zusammenfasst.

Daher bekommst "Du" auch ein Array von x events. Du machst daraus aber unnötigerweise x HTTP-Aufrufe.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 28 November 2020, 22:56:36
Guten Tag,

wie oben beschrieben gibt es eine neue Version.

Zitat*** 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.

Man kann nun alles verstellen wie das Schema aussieht.
Aus dem Standard:

Kann man nun z.B.

machen.

Dafür setzt man z.B. die Attribute so:
attr influx fields $READINGNAME=$READINGVALUE
attr influx measurement $DEVICE
attr influx tags x=y,a=b


Außerdem wird nun nurnoch ein HTTP-Call pro Notify gemacht.

Viel Spaß beim Ausprobieren.

In meiner Testumgebungs klappt es super.

VG

Tim



Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: gvzdus am 28 November 2020, 23:24:20
Moin, wo Tim schon so fleißig Perl geschrieben hat, schreibe ich mal, warum das prima ist:

Ich bin bei InfluxDB Neuling, aber es leuchtet mir ein, dass es effektiver ist:

Zeit A: Wert1 = x1, Wert2 = x2, Wert 3 = x3

anstelle von

Zeit A1: Wert1 = x1
Zeit A2: Wert2 = x2
Zeit A3: Wert3 = x3

wegzuschreiben. Das genau erzielt die Umstellungsmöglichkeit auf "Device = Measurement" - sofern ein Device mehrere Readings hat, die geloggt werden sollen. In meinem Szenario trifft das auf die Shellys, auf den OBIS-Stromzähler und auf die Solarbilanz je Minute zu.

Selbst, wenn man es nicht so "fährt", führt durch das Notify-Bundling in einen HTTP-Request das neue Modul ohne Änderung dazu, dass für die im Beispiel drei Werte nur ein HTTP-Aufruf gemacht wird. Das ist besonders dann erheblich, wenn es um HTTPS statt HTTP geht - denn da ging mein Raspi 3B+ sofort um 25% in der CPU hoch.

Deswegen ist das m.E. ein großartiger Fortschritt - vielen Dank, Tim!
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: Wurstwasser am 01 Dezember 2020, 16:01:41
Hi,
super Modul! :)

Ich habe es schon zum Laufen bekommen, allerdings hätte ich auch noch gerne den Alias meines Devices als Tag.
Gibt es da eine Möglichkeit? Z.B. $DEVICEALIAS ?
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 01 Dezember 2020, 16:32:37
Hi,

noch gibt es das nicht. Ich hatte geplant einfach den Zugriff auf alle Internals und Attribute zu erlauben. Dann wäre der Alias ja mit drin.

Ok?

Viele Grüße

Tim
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 01 Dezember 2020, 21:14:51
Hier die neue Version zum Testen.

attr influx tags device={AttrVal($device, "alias", "fallback")}

In die geschweiften Klammern kann jeder Perl-Ausdruck der eine Zeichenkette zurück gibt. $name, $device, $reading, $value stehen als Variablen zur Verfügung.

Bitte schön  :)


Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: Karflyer am 04 Dezember 2020, 10:38:45
Hallo Tim,

klasse Modul was du hier entwickelts. Um einiges besser als die bisherige Anbindung von FHEM an influxdb. Nachdem influxdb in der Version 2.0 nun offiziell ist, habe ich in den letzten Wochen einige Zeit mit der neuen Version gearbeitet und muss sagen, dass die um einiges komfortabler im Handling ist. Insbesondere dann, wenn man wie ich influxdb in einem Docker-Container laufen hat. Hier sind nun die Module 'influxdb', 'chronograf' und 'kapacitor' unter einem Dach (in einem Container) zusammengefasst. Und auch sonst hat sich einiges getan. Influxdb 2.0 arbeitet bei dem Datenzugriff nun nicht mehr mit 'name' und 'password' sondern mit einem Token. Ich würde natürlich gerne auch FHEM an influxdb 2.0 anbinden. Wäre es möglich, dass du das Szenario mit dem Token in dein Modul einbaust?

Grüße
Stefan
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 04 Dezember 2020, 12:11:34
Hi,

freut mich zu hören.

Das wäre dann eine neue Option in security wo heute nur basic_auth und none unterstützt wird.

Kann ein paar Tage dauern, da ich mir eine VM mit Influx2 bzw. mit Token Authorisierung einrichten muss. Ich gebe ungern Sachen raus, die ich nicht selber testen kann.

VG

Tim
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 05 Dezember 2020, 22:45:54
Hallo, bitte mal testen ob das bei Dir klappt.

Das token muss ähnlich wie das Password per Set gespeichert werden, damit es verschlüsselt wird.

Ich habe es lokal getestet, da ging es.

Viele Grüße

Tim
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: Karflyer am 06 Dezember 2020, 21:29:28
ZitatHallo, bitte mal testen ob das bei Dir klappt.

Das token muss ähnlich wie das Password per Set gespeichert werden, damit es verschlüsselt wird.

Ich habe es lokal getestet, da ging es.

Viele Grüße

Tim

Das funktioniert bei mir leider so noch nicht. Im Log wird die folgende Fehlermeldung geworfen:
2020.12.06 21:19:04 4: InfluxDBLogger: [influxdb_log] notified from device LaCrosse_0A
2020.12.06 21:19:04 4: InfluxDBLogger: [influxdb_log] notified from device LaCrosse_0A about temperature: 23.1
2020.12.06 21:19:04 5: InfluxDBLogger: [influxdb_log] set ?
2020.12.06 21:19:04 5: InfluxDBLogger: [influxdb_log] set ?
2020.12.06 21:19:04 5: InfluxDBLogger: [influxdb_log] set ?
2020.12.06 21:19:04 5: InfluxDBLogger: [influxdb_log] set ?
2020.12.06 21:19:04 4: InfluxDBLogger [influxdb_log] - Read token from file
2020.12.06 21:19:04 4: InfluxDBLogger: [influxdb_log] Sending data temperature,site_name=LaCrosse_0A value=23.1
to http://192.168.2.168:8086/write?db=fhem
2020.12.06 21:19:04 1: InfluxDBLogger: [influxdb_log] Error = 404 Not Found
2020.12.06 21:19:04 5: InfluxDBLogger: [influxdb_log] set ?


Ich denke, dass beim schreiben der Daten die Angabe der Organisation fehlt. unter Python sieht der Aufruf folgendermaßen aus:

write_api.write(bucket, org, influx_json_prototyp)

'Bucket' ist Datenbank und 'org' die Organisation die man initial angegeben hat.
Hier auch ein List meines Devices. Vielleicht habe ich bei der Definition einen Fehler gemacht.

Internals:
   CFGFN     
   DATABASE   fhem
   DEF        http://192.168.2.168:8086 fhem LaCrosse_0A
   FUUID      5fcd3415-f33f-bb67-e8c2-80a0dd5f1725795a
   NAME       influxdb_log
   NOTIFYDEV  LaCrosse_0A
   NR         9935
   NTFY_ORDER 50-influxdb_log
   STATE      Statistics: t=153 s=0 f=123
   TYPE       InfluxDBLogger
   URL        http://192.168.2.168:8086
   token      saved
   READINGS:
     2020-12-06 20:47:20   dropped_writes  9
     2020-12-06 20:47:20   dropped_writes_last_message LaCrosse_0A state T
     2020-12-06 21:28:15   failed_writes   123
     2020-12-06 21:28:15   failed_writes_last_error 404 Not Found
     2020-12-06 21:28:15   state           Statistics: t=153 s=0 f=123
     2020-12-06 21:28:15   total_writes    153
Attributes:
   DbLogExclude .*
   disable    0
   readingInclude temperature:.*
   room       Log
   security   token
   verbose    5


Grüße
Stefan
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 06 Dezember 2020, 22:01:17
Hi, du musst das mapping auf Datenbanken in Influx2 machen.

VG Tim
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 06 Dezember 2020, 22:09:10
siehe hier https://docs.influxdata.com/influxdb/v2.0/query-data/influxql/#map-unmapped-buckets (https://docs.influxdata.com/influxdb/v2.0/query-data/influxql/#map-unmapped-buckets)
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: Karflyer am 07 Dezember 2020, 08:34:33
ZitatHi, du musst das mapping auf Datenbanken in Influx2 machen.

VG Tim

Ah. Man lernt nie aus. Das Thema kannte ich noch nicht. Nachdem ich das Mapping gesetzt habe, läuft es nun wie am  Schnürchen.
Danke dir Tim!

Grüße
Stefan
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: Karflyer am 07 Dezember 2020, 13:38:30
ZitatHier die neue Version zum Testen.

Code: [Auswählen]
attr influx tags device={AttrVal($device, "alias", "fallback")}

In die geschweiften Klammern kann jeder Perl-Ausdruck der eine Zeichenkette zurück gibt. $name, $device, $reading, $value stehen als Variablen zur Verfügung.

... das habe ich so eingegeben. Hat bei mir Anfangs nicht funktioniert. Bei mir setzt sich der 'Alias' häufig aus zwei Wörtern zusammen z.B. 'Temperatur Wohnzimmer'. Das mag influxdb nicht und gibt ein '400 Bad Request' zurück. Ich habe es dann durch ein entsprechendes regex gelöst:
device={my $str = AttrVal($device,"alias",$device); $str =~ s/\s/_/g; return $str;}

Würdest du es als sinnvoll erachten, wenn du in deinem Modul prüfst ob sich das Tag aus mehreren Wörtern zusammensetzt und du die Leerzeichen durch einen Unterstrich (_) direkt im Modul ersetzt?

Grüße Stefan
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 08 Dezember 2020, 20:03:49
Hallo Karflyer,

ich würde das sogar so lassen. Andernafalls würde das Modul ja immer auf Suche nach Leerzeichen etc. gehen.

Viele Grüße

Tim
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: Karflyer am 08 Dezember 2020, 21:15:05
Hallo Tim,

beim Neustart von FHEM erhalte ich die folgenden Fehlermeldungen im Log:
2020.12.08 21:10:13 1: PERL WARNING: Scalar value @ab[1] better written as $ab[1] at ./FHEM/93_InfluxDBLogger.pm line 264, <$fh> line 3819.
2020.12.08 21:10:13 1: PERL WARNING: Scalar value @ab[0] better written as $ab[0] at ./FHEM/93_InfluxDBLogger.pm line 264, <$fh> line 3819.
2020.12.08 21:10:13 2: InfluxDBLogger: Initialized new
2020.12.08 21:10:13 1: PERL WARNING: Use of uninitialized value in regexp compilation at ./FHEM/93_InfluxDBLogger.pm line 41, <$fh> line 3819.
2020.12.08 21:10:13 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/93_InfluxDBLogger.pm line 46, <$fh> line 3819.


Das tut dem weiteren Betrieb des Moduls anscheinend aber nicht weh.

Grüße
Stefan
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 09 Dezember 2020, 09:29:59
.. aber mir tut das weh. :)

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

Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: red81 am 11 Dezember 2020, 09:04:21
Edit: Problem erstmal hier raus genommen
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 11 Dezember 2020, 10:03:45
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.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: gvzdus am 11 Dezember 2020, 14:20:31
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.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 11 Dezember 2020, 14:52:08
Das war ja auch die Motivation das neu zu schreiben.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: cthil am 11 Dezember 2020, 18:11:01
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
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 11 Dezember 2020, 19:29:47
Super, schaue ich mir an.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: meier81 am 12 Dezember 2020, 08:50:31
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 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 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
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 12 Dezember 2020, 17:49:48
Zitat von: cthil am 11 Dezember 2020, 18:11:01
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
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 12 Dezember 2020, 17:54:04
Zitat von: meier81 am 12 Dezember 2020, 08:50:31
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 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?

Zitat von: meier81 am 12 Dezember 2020, 08:50:31Eine 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
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 12 Dezember 2020, 17:57:49
Hallo zusammen,

Übrigens ist das Modul nun im FHEM SVN eingecheckt.  8)

Das heißt für die Nutzer, dass bei einem 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
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: cthil am 12 Dezember 2020, 18:32:10
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...
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: meier81 am 12 Dezember 2020, 21:18:24
Zitat von: timmib am 12 Dezember 2020, 17:54:04
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 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:
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
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 13 Dezember 2020, 08:38:26
Zitat von: cthil am 12 Dezember 2020, 18:32:10

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
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 13 Dezember 2020, 12:44:32
Habe das jetzt so gemacht, dass die Events separat gezählt werden.

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


Fünfmal war die Test-Datenbank nicht gestartet  :P

Siehe Anhang.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: gvzdus am 14 Dezember 2020, 11:58:35
Moin,
ich wollte meinen Senf zum "defaultMinInterval" geben:
Warum soll das in das InfluxDB-Modul rein? Besser ist doch, das Problem an der Quelle zu lösen.
Zur Datenreduktion bietet sich an:
Gerade bei Werten wie "power" kommt es doch auf gescheite Mittelwert-Bildung an!

Es ist m.E. nicht hilfreich, wenn es in FHEM eine weitere Möglichkeit gibt, ein Problem spezifisch zu lösen, wenn es schon eine existierende, universelle Möglichkeit gibt.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: meier81 am 14 Dezember 2020, 14:16:20
Hallo,

kann dein Argument verstehen, hatte es ja nur als Vorschlag gebracht da es dies auch im DBLog Modul gibt. Verstehe aber deine Argumentation, event-on-change habe ich sitzen bei mir, bringt hier leider nicht viel da sich der Wert halt alle paar Sekunden ein wenig ändert.

Den event-aggregator muss ich zu meiner Schande gestehen kannte ich noch nicht, werde das aber auf jeden Fall probieren heute Abend. Denke aber das Problem ist damit zu lösen und von daher keine Erweiterung hier nötig.

Was ich allerdings super fände wenn man wie ich oben schon geschrieben habe mit einem Set-Befehl die Möglichkeit hat Readings in influx zu schreiben. Dann funktioniert das wie bisher event getriggert oder ich kann es zusätzlich per Set triggern.

Gruß Markus
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: kadettilac89 am 14 Dezember 2020, 14:34:43
Zitat von: meier81 am 14 Dezember 2020, 14:16:20
Hallo,

kann dein Argument verstehen, hatte es ja nur als Vorschlag gebracht da es dies auch im DBLog Modul gibt. Verstehe aber deine Argumentation, event-on-change habe ich sitzen bei mir, bringt hier leider nicht viel da sich der Wert halt alle paar Sekunden ein wenig ändert.

Den event-aggregator muss ich zu meiner Schande gestehen kannte ich noch nicht, werde das aber auf jeden Fall probieren heute Abend. Denke aber das Problem ist damit zu lösen und von daher keine Erweiterung hier nötig.

Was ich allerdings super fände wenn man wie ich oben schon geschrieben habe mit einem Set-Befehl die Möglichkeit hat Readings in influx zu schreiben. Dann funktioniert das wie bisher event getriggert oder ich kann es zusätzlich per Set triggern.

Gruß Markus

event-on-change reading hat einen Threshold, nur wenn der neue Wert weiter abweicht als Threshold wird ein Event erzeugt.

Das glätten der Werte kannst ggf. auch per User Reading machen. Je nach anforderung und dann nur das loggen was im Userreadings ist

set Befehl zum schreiben? Hast du mal den fhem Befehl "trigger" getestet? Damit erzeugst du ein Event. Addlog Routine macht das selbe (s. Wiki).
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 14 Dezember 2020, 14:44:01
Zitat von: meier81 am 14 Dezember 2020, 14:16:20

Was ich allerdings super fände wenn man wie ich oben schon geschrieben habe mit einem Set-Befehl die Möglichkeit hat Readings in influx zu schreiben. Dann funktioniert das wie bisher event getriggert oder ich kann es zusätzlich per Set triggern.

Hi Markus,

wie oben geschrieben, habe ich noch nicht so recht verstanden wie das funktionieren soll. Dafür müsste ja der Logger anhand der DevSpec alle Geräte durchgehen und alle Readings auswerten. Ist es nicht einfacher zeitgesteuert ein get auf die Betroffenen Geräte/Readings zu machen um so die Events auszulösen?

Viele Grüße

Tim
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: gromeck am 14 Dezember 2020, 15:10:15
Hallo,

erstmal danke für dieses Modul -- das geht ja schon mal in die richtige Richtung  :)

Ich habe festgestellt, dass UserReadings offenbar nicht an die InfluxDB übertragen werden.

Use Case: mein PV-Inverter ist vom Modul-Typ KOSTALPICO und liefert in den Readings u.a. Current und Voltage. Ich berechne daraus die Energie in einem Trigger und lege die dann als UserReading ab. Und genau diese werden nicht an die InfluxDB geschickt.

Ich habe auch readingsInclude ausprobiert. Diese sorgen aber auch nicht dafür, dass UserReadings erfasst werden, ist aber auch klar, denn ist ist ja eher eine WhiteList :-\
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 14 Dezember 2020, 15:35:18
Siehst Du für die Userreadings Events?
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: Omega am 14 Dezember 2020, 15:46:58
Auch von mir erst einmal ein dickes Dankeschön für dein Modul - SUPER.

Zum Them "set...".
Aus 99_myUtils heraus verwende ich u.a. folgende Anweisung: fhem "setreading E3DC_Control fc1_Prognose $fc1_Prognose";
Diese so geschriebenen Readings werden dann in der InfluxDB gespeichert. Das ist doch eigentlich das gewünschte Verhalten.

LG
Holger

Nachtrag:
userreadings werden auch geschrieben (zumindest bei folgender Definition):
attr E3DC_Control userReadings lastUpdate {ReadingsVal("Wetter_Wennigsen","obsTime",0)}


Dabei fällt mir folgendes gerade auf: obsTime hat den Wert 11:00, in der InfluxDB kommt aber nur 11 an (da ja nur Zahlen akzeptiert werden). Hat einer eine Idee, wie ich den Minutenanteil (ohne über 99_myUtils gehen zu müssen) in eine Dezimalzahl umgewandelt bekomme?
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: kadettilac89 am 14 Dezember 2020, 16:09:31
Zitat von: Omega am 14 Dezember 2020, 15:46:58

Dabei fällt mir folgendes gerade auf: obsTime hat den Wert 11:00, in der InfluxDB kommt aber nur 11 an (da ja nur Zahlen akzeptiert werden). Hat einer eine Idee, wie ich den Minutenanteil (ohne über 99_myUtils gehen zu müssen) in eine Dezimalzahl umgewandelt bekomme?

https://wiki.fhem.de/wiki/Zeitangaben,_rechnen_mit

time_str2num("YYYY-MM-DD HH:MM:SS") wandelt einen FHEM-Zeitstempel in Sekunden um [2] ... teste mal format ("HH:MM"), Sunden dann noch durch 3600 ... ansonsten, 99_myutils und einzelne Variablen für HH, MM ... und dann wieder zusammen bauen ...
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: Omega am 14 Dezember 2020, 16:14:28
Und schon kommt meine nächste Frage ...  :)

Aus 99_myUtils heraus schreibe ich hintereinander weg 9 Readings per setreading.
Die InfluxDB, mit der ich teste, ist folgendermaßen definiert:
Internals:
   CFGFN     
   DATABASE   E3DC_Control
   DEF        http://192.168.33.181:8086 E3DC_Control E3DC_Control
   FUUID      5fd713fe-f33f-bbf3-de66-d8a750a96501d62a
   NAME       influxDB.E3DC_Control
   NOTIFYDEV  E3DC_Control
   NR         275341
   NTFY_ORDER 50-influxDB.E3DC_Control
   STATE      Statistics: t=66 s=61 f=2
   TYPE       InfluxDBLogger
   URL        http://192.168.33.181:8086
   READINGS:
     2020-12-14 08:45:03   failed_writes   2
     2020-12-14 08:45:03   failed_writes_last_error database not found: "E3DC_Control"
     2020-12-14 15:45:03   state           Statistics: t=66 s=61 f=2
     2020-12-14 15:45:03   succeeded_writes 61
     2020-12-14 15:45:03   total_writes    66
Attributes:
   DbLogExclude .*
   fields     $READINGNAME=$READINGVALUE
   measurement $DEVICE
   room       Server
   tags       -


Schaue ich in die DB (s. Hardcopy), sehe ich, dass jedes Reading einzeln gespeichert wird. Kann ich das irgendwie zusammenfassen zu einer einzigen DB-Zeile? Und falls ja, wie?

Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: Omega am 14 Dezember 2020, 16:19:20
@kadettilac89: Danke für den Tip - schaue ich mir an
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: gromeck am 14 Dezember 2020, 16:34:22
Zitat von: timmib am 14 Dezember 2020, 15:35:18
Siehst Du für die Userreadings Events?

Nein, und ich habe keine Ahnung warum.
Ich habe alle Readings in dem Device mit event-on-change-reading versehen und beim Setzen des userReadings mit readingsSingleUpdate() ist das Flag für die Events gesetzt.
Im UserReading kommt der gesetzte/berechnete Wert korrekt an, aber es wird eben kein Event ausgelöst :-/
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: kadettilac89 am 14 Dezember 2020, 16:42:20
Zitat von: Omega am 14 Dezember 2020, 16:14:28

Schaue ich in die DB (s. Hardcopy), sehe ich, dass jedes Reading einzeln gespeichert wird. Kann ich das irgendwie zusammenfassen zu einer einzigen DB-Zeile? Und falls ja, wie?
Möglichkeit ... to be tested ...

https://wiki.fhem.de/wiki/DevelopmentModuleIntro#Readings
Schlagwort .... readingsBulkUpdate ... damit werden die Readings in einem Aufwasch gesetzt. Dadurch sollte der Timestamp auch identisch sein ...

hash müsstest so in etwa bekommen (Referenz auf das entsprechende Device)
https://www.ethersex.de/index.php/Nutzung_in_FHEM_(Deutsch)#DHT22_Temperatur-.2FFeuchtesensoren

Ungetestet, musst ggf. etwas im Forum suchen.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: kadettilac89 am 14 Dezember 2020, 16:45:05
Zitat von: gromeck am 14 Dezember 2020, 16:34:22
Nein, und ich habe keine Ahnung warum.
Ich habe alle Readings in dem Device mit event-on-change-reading versehen und beim Setzen des userReadings mit readingsSingleUpdate() ist das Flag für die Events gesetzt.
Im UserReading kommt der gesetzte/berechnete Wert korrekt an, aber es wird eben kein Event ausgelöst :-/
Ist der gesetzte Wert unterschiedlich zum vorherigen? Teste mal ohne event-on-change reading oder andere Filter ob dann das Event im Event-Monitor auftaucht
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 14 Dezember 2020, 16:50:16
Hallo,

ich habe ein große Bitte/Vorschlag an euch.

Lass uns diesen Thread hier beenden und für die verschiedenen Themen jeweils einen eigenen Thread machen. Ich verliere heir sonst total die Übersicht, wenn alles durcheinander geht.

Das Modul ist ja nun auch in SVN drin und somit ist die "Beta-Phase" quasi feierlich beendet. Jetzt beginnt der normale Support und die Weiterentwicklung.

Viele Grüße

Tim
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: gvzdus am 14 Dezember 2020, 18:38:34
Komm', wir machen eben noch den Omega fertisch :-):

@Omega:
Bei mir stehen sie sauber als Tupel mit gleicher Zeit in der DB. Und ja, bei mir geht es auch um Solar-Gedöns:

Definition meines at-Jobs, der dann auch via InfluxDB loggt:

+*00:05:00 {
my $power5min = $defs{"power5min"};
my $whneu=ReadingsVal("MT175","total_consumption","--");
my $whalt=ReadingsVal("power5min","kwh","--");
my $watt=sprintf("%.1f", ($whneu-$whalt)*12);
my $fwhneu=ReadingsVal("MT175","total_feed","--");
my $fwhalt=ReadingsVal("power5min","kwhfeed","--");
my $fwatt=sprintf("%.1f", ($fwhneu-$fwhalt)*12);
readingsBeginUpdate($power5min);
readingsBulkUpdate($power5min, "kwh", $whneu);
readingsBulkUpdate($power5min, "watt", $watt);
readingsBulkUpdate($power5min, "kwhfeed", $fwhneu);
readingsBulkUpdate($power5min, "wattfeed", $fwatt);
readingsEndUpdate($power5min, 1);
}
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: Omega am 15 Dezember 2020, 15:39:51
Danke!
Habe zwar 'ne Weile gebraucht, bis ich das fehlerfrei in 99_myUtils umgesetzt hatte aber es funktioniert - freu.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 16 Dezember 2020, 16:46:33
Es werden nun https://fhem.de/commandref.html#readingFnAttributes (https://fhem.de/commandref.html#readingFnAttributes) unterstützt. (Danke nochmal an gvzdus)
Damit lassen sich die Events des Loggers selber unterdrücken.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: meier81 am 17 Dezember 2020, 21:46:41
Hab jetzt das Modul auch am laufen und bin fleißig am testen. Hab eine Frage zu "readingInclude": Ich habe bei mir die "readingInclude" folgendermaßen gesetzt:

\b(temperature|humidity|dewpoint|absoluteHumidity|pct|brightness|rainRate|wind|pressureAbs|Power_.*__kW|DesiredSupplyTemp|OutdoorTemp|Power|PowerModulation|PumpModulation|ReturnTemp|SupplyTemp|WaterDesiredTemp|WaterTemp|ENERGY_Power)\b


Jetzt habe ich in meinen Tasmota-MQTT-Devices das reading "TELEMETRY". Dieses entspricht ja keineswegs der readingInclude-Definition von oben, trotzdem bekomme ich die Meldung
dropped_writes_last_message   Trockner TELEMETRY {"Time"

Im reading "TELEMETRY" steht folgendes:
{"Time":"2020-12-17T21:41:25","ENERGY":{"TotalStartTime":"2019-01-22T17:26:26","Total":814.368,"Yesterday":2.379,"Today":0.413,"Period":0,"Power":0,"ApparentPower":0,"ReactivePower":0,"Factor":0.00,"Voltage":231,"Current":0.000}}

Hier findet sich der Name "Power" wieder vom "readingInclude", der hat ja aber eigentlich nichts mit dem reading-Namen zu tun, ist ja der Inhalt des readings.

Könnte das evtl. noch ein Fehler sein, hab das jetzt erstmal beim "readingExclude" gesetzt, denke aber das sollte ohne readingExclude auch nicht kommen.

Ansonsten erstmal alles super, super Modul  :)
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: meier81 am 17 Dezember 2020, 22:38:13
Was mir eben zudem aufgefallen ist, es ist nicht möglich eine "readingInclude"-Definition mit ^ am Anfang und $ am Ende zu machen, das habe ich ansonsten häufig verwendet, musste ich hier auch mit \b am Anfang und am Ende machen.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: meier81 am 18 Dezember 2020, 09:37:51
Zitat von: meier81 am 17 Dezember 2020, 21:46:41
Jetzt habe ich in meinen Tasmota-MQTT-Devices das reading "TELEMETRY". Dieses entspricht ja keineswegs der readingInclude-Definition von oben, trotzdem bekomme ich die Meldung
dropped_writes_last_message   Trockner TELEMETRY {"Time"

Hab gesehen warum das so ausgewertet wird, hast du ja in der commandref angegeben
Hinweis - das Format eines Ereignisses sieht so aus: 'state: on'

Zitat von: meier81 am 17 Dezember 2020, 22:38:13
Was mir eben zudem aufgefallen ist, es ist nicht möglich eine "readingInclude"-Definition mit ^ am Anfang und $ am Ende zu machen, das habe ich ansonsten häufig verwendet, musste ich hier auch mit \b am Anfang und am Ende machen.

Hat sich dadurch natürlich auch geklärt, das geht so dann natürlich auch nicht.

Ist es aber nicht sinnvoller das wirklich nur auf den reading-Namen zu beschränken, weiß leider nicht wie aufwändig das ist dies einzufügen.

Gruß Markus
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: Omega am 18 Dezember 2020, 16:56:24
Gibt es Probleme mit Dummy-Devices?

Ich habe folgende Definition:
Internals:
   CFGFN     
   DATABASE   SmartMeter
   DEF        http://192.168.33.181:8086 SmartMeter sm.Heizungskeller,sm.Vorratskeller, d.PV
   FUUID      5fdccb3f-f33f-4155-18e0-b52e424fbb7b6c91
   NAME       influxDB.SmartMeter
   NOTIFYDEV  sm.Heizungskeller,sm.Vorratskeller,
   NR         67
   NTFY_ORDER 50-influxDB.SmartMeter
   STATE      Statistics: t=1387 s=155 f=0
   TYPE       InfluxDBLogger
   URL        http://192.168.33.181:8086
   READINGS:
     2020-12-18 16:47:57   state           Statistics: t=1387 s=155 f=0
     2020-12-18 16:47:57   succeeded_writes 155
     2020-12-18 16:47:57   total_writes    1387
Attributes:
   fields     $READINGNAME=$READINGVALUE
   measurement $DEVICE
   readingExclude total_feed_old
   room       Server
   tags       -


Änderungen von Readings im Dummy-Device d.PV werden nicht geloggt.
Auch das Internal "NOTIFYDEV" ignoriert das Device d.PV.
Auch nach einem shutdown restart finde ich folgenden Hinweis im Log:
020.12.18 16:31:11 3: InfluxDBLogger: [influxDB.SmartMeter] defined with server http://192.168.33.181:8086 database SmartMeter notifydev sm.Heizungskeller,sm.Vorratskeller,
wobei das Device d.PV auch hier nicht aufgeführt wird.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: meier81 am 18 Dezember 2020, 17:16:29
Zitat von: Omega am 18 Dezember 2020, 16:56:24
Internals:
   DEF        http://192.168.33.181:8086 SmartMeter sm.Heizungskeller,sm.Vorratskeller, d.PV

Du hast da ein Leerzeichen vor d.PV, das geht so natürlich nicht, probier das mal ohne.

Gruß

Markus
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: Omega am 18 Dezember 2020, 17:21:11
Danke! Jetzt geht alles. Super
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: Wurstwasser am 21 Dezember 2020, 08:12:04
Mit dem Alias als Tag funktioniert wunderbar, wenn man Leerzeichen ersetzt. Danke!
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: baumix am 08 Januar 2021, 18:37:50
Moin zusammen,

bevor ihr hier zu macht und ich das gut finden kann (die Idee an sich ist super!): entweder bin ich zu doof oder ich übersehe etwas Essentielles:

Internals:
   CFGFN     
   DATABASE   fhem
   DEF        http://influxdb.local.domaene.de:8086 fhem Heinzelmann:(battery|cleaning|consumables|device|error|event|fan|history_0|in|last|state|total|wifi).*
   FUUID      5ff88972-f33f-dfd6-553e-22f8ff02f7a138c6
   NAME       dbloginflux
   NOTIFYDEV  Heinzelmann:(battery|cleaning|consumables|device|error|event|fan|history_0|in|last|state|total|wifi).*
   NR         713
   NTFY_ORDER 50-dbloginflux
   STATE      Statistics: t=0 s=0 f=0 e=0
   TYPE       InfluxDBLogger
   URL        http://influxdb.local.domaene.de:8086
   passwd     saved
   READINGS:
     2021-01-08 17:42:52   dropped_writes  0
     2021-01-08 17:42:52   dropped_writes_last_message <none>
     2021-01-08 17:42:52   failed_writes   0
     2021-01-08 17:42:52   failed_writes_last_error <none>
     2021-01-08 17:42:52   state           Statistics: t=0 s=0 f=0 e=0
     2021-01-08 17:42:52   succeeded_writes 0
     2021-01-08 17:42:52   total_events    0
     2021-01-08 17:42:52   total_writes    0
Attributes:
   alias      Datenbank-Log InfluxDB neu
   api        v1
   conversions open=1,closed=0,tilted=2,true|on|yes=1,false|off|no=0
   disable    0
   icon       security
   readingInclude .*
   room       92_Database
   security   basic_auth
   username   fhem
   verbose    5


Ich nutze die Version, die mit fhem kommt. Was muss ich den mindestens konfigurieren, damit das funktioniert? Hier wird noch nicht mal versucht, eine Verbindung zur Datenbank aufzubauen. Im Log sehe ich nur ganz selten mal:


2021.01.08 18:22:33 5: InfluxDBLogger: [dbloginflux] set ?
2021.01.08 18:22:41 5: InfluxDBLogger: [dbloginflux] set ?


Die devspec habe ich schon massiv reduziert, die funktioniert unter influxlog aber ohne Probleme. Aber selbst die Minimal-Variante ändert nichts ... Events kommen definitiv ...
Hostname habe ich mehrfach geprüft, Usernamen und Passwort auch ... aber selbst mit falschem Account müsste ich zumindest mal Pakete auf Port 8086 rausgehen/ankommen sehen, selbst das ist nicht der Fall. Laut Stats wird es aber auch gar nicht versucht. Definition gelöscht und neu angelegt, keine Änderung ...
Wäre für jeden Tipp dankbar!

Grüße und danke

Baumix
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: meier81 am 08 Januar 2021, 21:35:00
Hallo Baumix,

ich glaube dein Problem könnte sein das du bei der Definition
http://influxdb.local.domaene.de:8086 fhem Heinzelmann:(battery|cleaning|consumables|device|error|event|fan|history_0|in|last|state|total|wifi).*
schon die Readings mit angibst, laut commandref werden hier aber nur die Devices angegeben. Müsste dann bei dir so aussehen:
http://influxdb.local.domaene.de:8086 fhem Heinzelmann

und dann definierst du noch das Attribut "readingInclude":
readingInclude (battery|cleaning|consumables|device|error|event|fan|history_0|in|last|state|total|wifi)

Hab dir mal meine Definition angehängt:
Internals:
   DATABASE   fhem
   DEF        http://127.0.0.1:8086 fhem Fuehler.*,Rolladen.*,Wetterstation,Strom_Haus,Buderus,Waschmaschine,Trockner
   FUUID      5fdb0036-f33f-c2d2-c41a-42af5de16fb6d519
   FVERSION   93_InfluxDBLogger.pm:0.233660/2020-12-16
   NAME       InfluxDB
   NOTIFYDEV  Fuehler.*,Rolladen.*,Wetterstation,Strom_Haus,Buderus,Waschmaschine,Trockner
   NR         244
   NTFY_ORDER 50-InfluxDB
   STATE      Statistics: t=143007 s=143006 f=1 e=223830
   TYPE       InfluxDBLogger
   URL        http://127.0.0.1:8086
   READINGS:
     2020-12-31 05:38:27   dropped_writes  24
     2020-12-31 05:38:27   dropped_writes_last_message Wetterstation temperature n/a
     2020-12-21 01:29:22   failed_writes   1
     2020-12-21 01:29:22   failed_writes_last_error read from http://127.0.0.1:8086 timed out
     2021-01-08 21:32:52   state           Statistics: t=143007 s=143006 f=1 e=223830
     2021-01-08 21:32:52   succeeded_writes 143006
     2021-01-08 21:32:52   total_events    223830
     2021-01-08 21:32:52   total_writes    143007
Attributes:
   conversions closed=0,open=1,tilted=2,false|off|no=0,true|on|yes=1
   deviceTagName device_name
   icon       time_note
   readingExclude TELEMETRY|ASC_ShadingMessage|command
   readingInclude \b(temperature|humidity|dewpoint|absoluteHumidity|pct|brightness|rainRate|wind|pressureAbs|Power_.*__kW|DesiredSupplyTemp|OutdoorTemp|Power|PowerModulation|PumpModulation|ReturnTemp|SupplyTemp|WaterDesiredTemp|WaterTemp|ENERGY_Power)\b


Die "\b" am Anfang und am Ende habe ich dazugemacht das wirklich nur readings benutzt werden die wirklich genauso heißen und nicht z.B. windGusts

Gruß

Markus
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: baumix am 08 Januar 2021, 23:15:41
Hallo Markus,

danke für die prompte Hilfe, das habe ich doch tatsächlich überlesen und bin einfach davon ausgegangen, dass es wie bei logdb und influxlog gehandhabt wird ...  :-[
Dank Deines Beispiels läuft das jetzt. Da habe ich ja noch einiges an Arbeit vor mir, um das wieder auseinander zu dröseln.
Ich verstehe das aber richtig, dass ich dann keine direkte Zuordnung mehr zwischen den Devices und den Readings habe, d. h. in den einem Device z. B. nur das Reading "temperature" und in dem anderen nur das Reading "humidity" geht dann nicht, sondern immer nur beides? Ich kann das natürlich über die Events in den Devices steuern  8)

Dann werde ich das mal am Wochenende ausführlich testen ...

Danke und schönes Wochenende

Baumix
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: fischit am 09 Januar 2021, 12:04:17
Oder du machst dir mehrere influxdblogger devices
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 09 Januar 2021, 12:41:31
Zitatbevor ihr hier zu macht

Hallo,

ich plädiere weiterhin dazu, diesen Thread zu schliessen und alles Weitere in eigenen Threads zu behandeln.

Kostet ja nix und ich beobachte auch das komplette Subforum deswegen.

Viele Grüße

Tim
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: MarkusN am 14 Januar 2021, 11:13:54
Sind conversions case sensitive oder würde folgende definition auch ein ON zu 1 übersetzen?


true|on|yes|open|opened=1,false|off|no|close|closed=0


Für mich sieht es so aus als wäre es case sensitive, will aber ein Fehler auf meiner Seite nicht ausschliessen.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 15 Januar 2021, 16:09:59
ZitatSind conversions case sensitive oder würde folgende definition auch ein ON zu 1 übersetzen?

Die Conversions sind unabhängig von der Groß und Kleinschreibung. TRUE und On und oN usw. würden in Deinem Beispiel also auch auf 1 konvertiert.

Viele Grüße

Tim
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: volschin am 25 Januar 2021, 01:06:19
Cooles Modul. Danke für die tolle Arbeit. Ich stelle gerade mein influxlog auf das neue Modul um.
Das ist dann gerade rechtzeitig, um für influxdb 2.0 gerüstet zu sein.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: Karflyer am 25 Januar 2021, 16:11:06
Nach einem Neustart von FHEM erhalte ich vielfach (ca. 160 Zeilen) die folgende Fehlermeldung im Log:
InfluxDBLogger: [influxdb_climate] Error = write to http://xxxxxxxxxx:8086 timed out
bzw.
InfluxDBLogger: [influxdb_meter] Error = read from http://xxxxxxxxxxx:8086 timed out

Danach laufen die beiden InfluxDBLogger-Instanzen normal weiter. Kann es sein, dass das FHEM-System den Neustart noch nicht abgeschlossen und InflußDBLogger bereits versucht die Datenbank zu erreichen, was dann fehlschlägt?

Grüße
Stefan
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 25 Januar 2021, 18:33:53
Ne, das reagiert erst wenn die Initialisierung durch ist.
https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/93_InfluxDBLogger.pm#L56 (https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/93_InfluxDBLogger.pm#L56)
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: tomleitner am 26 Januar 2021, 15:39:01
Super Modul ... klappt hervorragend. Danke an den/die Entwickler !!!

Hatte damit in ca. 1 Stunde schon die ersten Plots via InfluxDb und Grafana erzeugt. Letzere beide als Docker Container auf meinem NAS.

Aktuell hab ich auch ein DbLog auf PostgreSQL -- das will ich aber eher los werden weil es ja keinen Sinn macht alles doppelt zu loggen. Darüberhinaus wird mit dbLog ohnehin zu viel unnützes Zeug geloggt.

Leider kann man nun aber mit InfluxDB keine Plots in Fhem machen. Oder irre ich mich da? Jedenfalls habe ich nichts derartiges gefunden.  Aktuell kann man bei Plots nur "Logfile" oder "logDb" auswählen ... super wäre eben auch wenn dort  das InfluxDbLogger Device aufscheinen würde.

Gibts da Pläne diesbezüglich?

Danke // Tom
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 26 Januar 2021, 18:26:26
Ich nutze dafür Grafana im IFrame I'm TabletUI.

Freut mich, dass es gefällt.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: meier81 am 26 Januar 2021, 22:28:37
Hallo Tim,

ich hab ja jetzt seit einigen Wochen dein Modul im Einsatz, läuft soweit echt gut und ohne Probleme. Hatte gestern Mal ein reload des Moduls gemacht und ein paar Fehlermeldungen erhalten:

Too many arguments for main::InfluxDBLogger_GetPassword at ./FHEM/93_InfluxDBLogger.pm line 116, near "$name)"
Too many arguments for main::InfluxDBLogger_GetMeasurement at ./FHEM/93_InfluxDBLogger.pm line 187, near "$value)"
Too many arguments for main::InfluxDBLogger_GetTagSet at ./FHEM/93_InfluxDBLogger.pm line 188, near "$value)"
Too many arguments for main::InfluxDBLogger_GetFieldSet at ./FHEM/93_InfluxDBLogger.pm line 189, near "$value)"
Too many arguments for main::InfluxDBLogger_ResetStatistics at ./FHEM/93_InfluxDBLogger.pm line 395, near "$name)"


Ich hab dann mal in die Moduldatei reingeschaut, ich glaube da fehlen ein paar $-Zeichen in den subs. Hab folgende Zeilen angepasst:


Zeile 195: sub InfluxDBLogger_GetMeasurement($$$$$)
Zeile 214: sub InfluxDBLogger_GetTagSet($$$$$)
Zeile 233: sub InfluxDBLogger_GetFieldSet($$$$$)
Zeile 379: sub InfluxDBLogger_Set($$$@)
Zeile 403: sub InfluxDBLogger_ResetStatistics($$)
Zeile 424: sub InfluxDBLogger_GetPassword($$)


Bei folgenden subs sind gar keine Übergabeparameter definiert:


Zeile 439: sub InfluxDBLogger_StoreSecret
Zeile 470: sub InfluxDBLogger_ReadSecret


Ich denke dort sollen dann auch jeweils die dazu passenden Übergabeparameter mit dazu, habe das alles mal angepasst, dann restart fhem, anschließend bringt ein reload des Moduls keinen Fehler mehr.

Das könntest du vielleicht an deinem Modul noch anpassen, dann sind die reload-Fehler auch behoben.

Gruß Markus

edit: Hab dir mal noch die Datei mit den Änderungen angefügt  ;)
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 26 Januar 2021, 22:43:46
Hallo Markus,

ich habe es übernommen und commited.

Vielen Dank

Tim
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 26 Januar 2021, 23:58:47
Hallo liebe Freunde von InfluxDB,

das neue Modul ermöglicht die effektive Übertragung von InfluxDB "Fields" nach FHEM.
Dies ist sehr nützlich um Werte,die direkt nach InfluxDB geschrieben werden (ohne FHEM) trotzdem in FHEM nutzbar zu machen. So entsteht anstatt einer Doppellieferung nach InfluxDB und FHEM eine Kette.

Und nicht nur das, es kann die volle Macht von Kapacitor dabei ausgenutzt werden. Kapacitor erlaubt z.B. gleitende Mittelwerte über bestimmte Zeitfenster uvm.

Das Modul registriert automatisch einen einfachen Task beim Kapacitor und stellt einen TCP-Server bereit um die Werte zu empfangen. Dieser Task wird sogar automatisch aktualisiert, wenn ihr die Attribute ändert.

TODOs:

Viel Spaß beim Testen und Feedback schreiben.

Tim

siehe hier https://forum.fhem.de/index.php?topic=118208.msg1126288#msg1126288 (https://forum.fhem.de/index.php?topic=118208.msg1126288#msg1126288)
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: meier81 am 27 Januar 2021, 12:17:12
Hallo Tim,

ich hätte noch einen Verbesserungsvorschlag bezüglich readingExclude und readingInclude.

Ich fände es sinnvoll hier nicht das Event auszuwerten sondern nur das Reading, habe bei mir nämlich den Fall das ich bei readingInclude z.B. "wind" definiert habe, ich dann aber alle Werte mit "wind" bekomme, also "wind", "windChill", "windDirection", etc.

Hab auch schon versucht das ganze mal mit einzubauen, hab da allerdings noch ein paar kleine Probleme zur Zeit.

Was meinst du denn zu dem Vorschlag, denke wäre dann auch eindeutig, vom Namen her (readingInclude) gehe ich eigentlich von der Funktion aus. Ansonsten müsste es eigentlich eher "eventInclude" heißen.

Gruß Markus
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 27 Januar 2021, 13:33:35
Hi Markus,

wenn Du nur auf den Readingnamen matchen möchtest stelle bitte ein ^ voran. Siehe https://perldoc.perl.org/perlrequick (https://perldoc.perl.org/perlrequick)
Also in Deinem Falle:
^wind

Um das Ganze noch stärker einzuschränken könnte man die RegEx noch weiter ausfeilen.

Ein Reading besteht in meinen Augen aus Name und Wert. Insofern ist die Bezeichnung korrekt.

Viele Grüße

Tim
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: meier81 am 27 Januar 2021, 13:52:12
Zitat von: timmib am 27 Januar 2021, 13:33:35
Hi Markus,

wenn Du nur auf den Readingnamen matchen möchtest stelle bitte ein ^ voran. Siehe https://perldoc.perl.org/perlrequick (https://perldoc.perl.org/perlrequick)
Also in Deinem Falle:
^wind

Hi Tim, das dachte ich ja ursprünglich auch, funktioniert bei diesem Modul aber leider nicht (siehe Antwort 92-94 hier im Beitrag).

Wie gesagt ich finde es nur komisch das hier der event dafür benutzt wird, das kenn ich eigentlich so nicht von anderen Modulen. War bislang immer so wenn du readings einschränkst sich das dann immer nur auf den readingnamen beschränkt.

Falls es doch angepasst werden sollte, habe den Fehler in meiner Skriptanpassung gefunden, läuft jetzt rund ;)
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: meier81 am 27 Januar 2021, 15:40:21
Falls du dir mal die Änderungen anschauen willst, hab dir mal die Datei angehängt.

Die Änderungen sind zwischen Zeile 137 und 159.

Ist aktuell include-vorrangig, d.h. trägst du das gleiche reading bei include und exclude überwiegt include, das kann ja aber einfach umgedreht werden.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 27 Januar 2021, 16:16:15
Hi,

also ich filtere auf
test:.* und es klappt wunderbar

Auch ^test sorgt dafür das wrong: test nicht inkludiert wird.

Viele Grüße

Tim
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 27 Januar 2021, 16:21:11
ZitatFalls du dir mal die Änderungen anschauen willst, hab dir mal die Datei angehängt.

Habe ich mir angeschaut.

Da diese Funktion bei JEDEM Event aufgerufen wird von JEDEM Device der auf die devspec matcht sollte sie so effizient wie möglich sein.
Da auch noch die Werte ignoriert werden, also es so weniger Funktion hat, würde ich eher dafür plädieren es so zu lassen wie es ist und einfach entsprechend eure RegExn anpassen.

Tim
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: meier81 am 27 Januar 2021, 16:50:44
Zitat von: timmib am 27 Januar 2021, 16:21:11
Habe ich mir angeschaut.

Da diese Funktion bei JEDEM Event aufgerufen wird von JEDEM Device der auf die devspec matcht sollte sie so effizient wie möglich sein.
Da auch noch die Werte ignoriert werden, also es so weniger Funktion hat, würde ich eher dafür plädieren es so zu lassen wie es ist und einfach entsprechend eure RegExn anpassen.

Tim

Das ist denke ich Ansichtssache, ich denke beide Varianten haben ihre Vor- und Nachteile. Prinzipiell hast du ja nicht weniger Funktion, ich will ja nicht die Werte filtern sondern die readings. Wie gesagt Ansichtssache. Vom Skript her kann das auch nicht all zu falsch sein, kommt so auch im DBLog vor, was ja auch bei jeden Event von jeden Device getriggert wird.

Bezüglich des Filters hier mal eine Übersicht meines aktuellen Filters:

readingInclude: \b(temperature|humidity|dewpoint|absoluteHumidity|pct|brightness|rainRate|wind|pressureAbs|Power_.*__kW|DesiredSupplyTemp|OutdoorTemp|Power|PowerModulation|PumpModulation|ReturnTemp|SupplyTemp|WaterDesiredTemp|WaterTemp|ENERGY_Power|SunAlt)\b

readingExclude: TELEMETRY|ASC_ShadingMessage|command


Mein Problem was ich hier habe ist das ich z.B. temperature als include haben will, nicht aber temperaturInside. Deswegen geht ^temperature schonmal nicht. Hab dann ja nach einigem hin- und hertesten herausgefunden das ich in diesem Fall mit \b am Anfang und Ende filtern muss. Dann hatte ich aber das Problem das ich bei meinen Tasmota-Geräten ein reading habe welches SENSOR heißt, in den steht dann folgende Daten:
"Time":"2021-01-27T16:44:42","ENERGY":{"TotalStartTime":"2019-01-22T17:26:26","Total":872.756,"Yesterday":0.003,"Today":0.004,"Period":0,"Power":0,"ApparentPower":0,"ReactivePower":0,"Factor":0.00,"Voltage":233,"Current":0.000}

Da es hier eine Position Namens "Power" gibt schlägt natürlich der include-Filter zu und versucht das reading zu loggen, was natürlich abgeschnitten wird aber am Modul eine dropped_writes Meldung verursacht. In exclude kann ich sie aber nicht setzen sonst gehen die Power-Messwerte der Steckdosen nicht mehr.

Das war deswegen eigentlich der Grund meiner Anpassung nur die readings auszuwerten und nicht die events, lässt sich halt wesentlich besser uns feiner filtern. Die Werte will ich ja nicht filtern, die sollen ja wenn das reading passt geloggt werden.

Wie schon gesagt ist Ansichtssache. Was mich nur wundert das ich da der einzige bin der die Problematik besitzt bzw. die Filter halt so genau setzen will.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: meier81 am 27 Januar 2021, 16:58:40
Hab eben auch nochmal folgendes include probiert, da wird aber gar nichts mehr geloggt:

(temperature|humidity|dewpoint|absoluteHumidity|pct|brightness|rainRate|wind|pressureAbs|Power_.*__kW|DesiredSupplyTemp|OutdoorTemp|Power|PowerModulation|PumpModulation|ReturnTemp|SupplyTemp|WaterDesiredTemp|WaterTemp|ENERGY_Power|SunAlt):.*
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 27 Januar 2021, 19:52:58
Wie oben geschrieben, Pack doch einfach den Doppelpunkt dahinter.

temperature:
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: meier81 am 27 Januar 2021, 20:23:36
Zitat von: timmib am 27 Januar 2021, 19:52:58
Wie oben geschrieben, Pack doch einfach den Doppelpunkt dahinter.

temperature:

Das funktioniert leider nicht. Wenn ich jetzt nicht irgendwo einen Denkfehler habe weiß ich nicht was ich noch probieren soll.

Hier nochmal meine DEF:

define InfluxDB InfluxDBLogger http://127.0.0.1:8086 fhem Fuehler.*,Rolladen.*,Wetterstation,Strom_Haus,Buderus,Waschmaschine,Trockner,Astro

Habe jetzt das Attribut readingExclude gelöscht und bei readingInclude folgendes probiert:

windDirection:
windDirection:.*


Mein reading in dem Device "Wetterstation" heißt "windDirection" und ändert sich alle 60 Sekunden. Es wird nicht geschrieben, bei keiner der beiden Varianten.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 27 Januar 2021, 20:29:42
Ich vermute du hast beide Varianten probiert und nicht gleichzeitig. Das ist komisch.

Ich gucke nacher nochmal.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: meier81 am 27 Januar 2021, 20:36:03
Zitat von: timmib am 27 Januar 2021, 20:29:42
Ich vermute du hast beide Varianten probiert und nicht gleichzeitig. Das ist komisch.

Ich gucke nacher nochmal.

Richtig, beides separat von einander probiert.

Wit gesagt habe hier schon ettliches probiert, hat aber nie wirklich genau mein erwartetes Ergebnis erbracht, das war dann eigentlich auch mit der Hauptgrund warum ich das ja auf reading-Match umgebaut habe.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 27 Januar 2021, 20:39:41
Das mit
test:.*

habe ich heute nochmal hin und her probiert, in meiner Perl Sandbox. (Testtreiber+Modul ohne FHEM)

Hast du im Eventmonitor den Event gesehen in der schreibweise?
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: meier81 am 27 Januar 2021, 20:44:47
Zitat von: timmib am 27 Januar 2021, 20:39:41
Hast du im Eventmonitor den Event gesehen in der schreibweise?

Gerade frisch geschaut, der Event sieht so aus:

2021-01-27 20:45:29.907 WS980 Wetterstation windDirection: 346

FHEM ist aktuell einschließlich aller Module.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 27 Januar 2021, 20:46:29
Da steht doch wind: und nicht windDirection: !!
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: meier81 am 27 Januar 2021, 20:47:24
Zitat von: timmib am 27 Januar 2021, 20:46:29
Da steht doch wind: und nicht windDirection: !!

Hab´s eben korrigiert, war in der Zeile verrutscht. Du hast´s zu schnell gelesen  ;)
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: meier81 am 27 Januar 2021, 20:51:40
Zitat von: meier81 am 27 Januar 2021, 20:44:47
Gerade frisch geschaut, der Event sieht so aus:

2021-01-27 20:45:29.907 WS980 Wetterstation windDirection: 346

FHEM ist aktuell einschließlich aller Module.

Das heißt das ist das richtige Event im Eventmonitor. Hatte wie gesagt die falsche Zeile rauskopiert.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 27 Januar 2021, 21:16:50
So, habe es jetzt nochmal in meine FHEM Testinstanz probiert und es klappt mit test:

attr influxEn readingInclude test:

2021-01-27 20:05:48 dummy d3 test: 2
2021-01-27 20:05:51 InfluxDBLogger influxEn failed_writes_last_error: 192.168.178.106: No route to host (113)
2021-01-27 20:05:51 InfluxDBLogger influxEn failed_writes: 2
2021-01-27 20:05:51 InfluxDBLogger influxEn Statistics: t=2 s=0 f=2 e=2
2021-01-27 20:06:27 Global global ATTR influxEn readingInclude test:
2021-01-27 20:06:55 InfluxDBLogger influxEn total_writes: 3
2021-01-27 20:06:55 InfluxDBLogger influxEn total_events: 3
2021-01-27 20:06:55 InfluxDBLogger influxEn Statistics: t=3 s=0 f=2 e=3
2021-01-27 20:06:55 dummy d3 test: 3
2021-01-27 20:06:56 InfluxDBLogger influxEn failed_writes_last_error: 192.168.178.106: No route to host (113)
2021-01-27 20:06:56 InfluxDBLogger influxEn failed_writes: 3
2021-01-27 20:06:56 InfluxDBLogger influxEn Statistics: t=3 s=0 f=3 e=3
2021-01-27 20:11:03 Global global SAVE
2021-01-27 20:12:10 Global global ATTR influxEn readingInclude fest:
2021-01-27 20:12:13 Global global SAVE
2021-01-27 20:12:26 dummy d3 test: 4


Vor dem letzten Eintrag habe ich mal den negativ Test gemacht und entsprechend fehlt der Versuch es zu schreiben.

attr influxEn readingInclude fest:
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: meier81 am 27 Januar 2021, 21:38:26
Tut mir Leid aber funktioniert nicht. Habe eben meine DEF angepasst und nur ein Device verwendet:
define InfluxDB InfluxDBLogger http://127.0.0.1:8086 fhem Trockner

Das sollte ja hoffentlich so richtig sein, hinten mit dem Trockner, ohne weitere Zeichen.

Mein Trocknerdevice ist so definiert:
define Trockner MQTT2_DEVICE DVES_B1D9CA

Passt also auch soweit. Attribut exclude nicht gesetzt, Attribut include sieht so aus:
attr InfluxDB readingInclude ENERGY_Power:

Eventmonitor enthält mehrfach folgenden Eintrag:
2021-01-27 21:34:32.415 MQTT2_DEVICE Trockner ENERGY_Power: 1

Da ist mein Latein echt am Ende, die Events der Devices funktionieren auch alle richtig, werden ja auch für Schaltungen etc. verwendet. Das Modul ist ja auch richtig definiert. Ich bau das jetzt von dir mit dem dummy 1:1 nach.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: meier81 am 27 Januar 2021, 22:07:48
Also ich habe das exakt genauso wie du mit einem dummy mit dem gleichen reading durchgeführt, kein Erfolg. Ohne includ und exclude Definition geht alles, include definiert und nichts wird geloggt.

Jetzt kommt der Hammer: Habe einen reload des Moduls ausgeführt, jetzt geht alles. Ich schmeiß mich weg. Heute Morgen Update durchgeführt, anschließend FHEM neu gestartet. Das Modul mit reload geladen um zu sehen ob die Meldungen weg sind, auch alles okay. Was jetzt bei dem reload anderst war und warum es jetzt geht und vorher nie ging wissen die Götter.

Ich berichte auf jeden Fall weiter.

Gruß Markus
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: tomleitner am 30 Januar 2021, 16:36:06
Hallo,

Ich hab gestern von Influxdb 1.8.3 auf 2.0.3 upgegraded. Hat soweit geklappt ( hat etwas gedauert bis ich das Konzept mit dem Token verstanden habe und auch eine database auf ein bucket gemappt habe). 

Problem nun aber: readings die keine reinen Zahlen sind werden nun abgelehnt. Mit Influxdb 1.x hat das geklappt.  Im Anhang ein Screenshot wo man sieht das der String "state T" gedropped wird.

Kann sein das es sich immer um Strings handelt die ein Leerzeichen beinhalten? Vielleicht ist das quoting im Modul nicht richtig gemacht?

Hier noch meine Definition:


defmod InfluxDB InfluxDBLogger http://tominas.fritz.box:8086 fhem USV.*,Sensor_.*,Pool.*,Zisterne.*,\
Multisensor_.*,WohnzimmerTemperature,\
Airpurifier,WohnzimmerHelligkeit,DustSensor,Rasenmaeher,AussenSensor,\
GlashausHeizung,Glashaus_Temperature,TerrasseSued_Temperature,Entfeuchter_.*,\
Waschmaschine,SolarThermie,SolarPumpe,awattar,Alarmanlage
attr InfluxDB api v1
attr InfluxDB conversions true|on|yes=1,false|off|no=0
attr InfluxDB disable 0
attr InfluxDB readingExclude battdate|ip|IPAddress
attr InfluxDB room System
attr InfluxDB security token
attr InfluxDB username tom


Das war vorher nicht der Fall ... was ist zu tun?

Danke // Tom
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 30 Januar 2021, 17:27:53
Hallo Tom,

also "droppen" tut das Modul und nicht Influx. Das hat also nichts mit dem Upgrade zu tun. Wenn Du nicht numerische Werte in die Datenbank schreiben möchtest musst du "tags" dafür verwenden. (siehe gleichnamiges Attribut)

Viele Grüße

Tim

P.S. Bitte eigenen Thread starten.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: tomleitner am 30 Januar 2021, 21:53:37
Hallo Tim,

Danke für Deine Antwort ... also muss ich mich täuschen wenn ich einen Unterschied zu vor dem Upgrade festgestellt habe ....

Danke für den Hinweis mit den Tags ... ich werde das versuchen für jene Readings die ich auch in der Db haben will ...

Danke // Tom
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: meier81 am 02 Februar 2021, 21:07:05
Zitat von: meier81 am 27 Januar 2021, 22:07:48
Also ich habe das exakt genauso wie du mit einem dummy mit dem gleichen reading durchgeführt, kein Erfolg. Ohne includ und exclude Definition geht alles, include definiert und nichts wird geloggt.

Jetzt kommt der Hammer: Habe einen reload des Moduls ausgeführt, jetzt geht alles. Ich schmeiß mich weg. Heute Morgen Update durchgeführt, anschließend FHEM neu gestartet. Das Modul mit reload geladen um zu sehen ob die Meldungen weg sind, auch alles okay. Was jetzt bei dem reload anderst war und warum es jetzt geht und vorher nie ging wissen die Götter.

Ich berichte auf jeden Fall weiter.

Gruß Markus

Nabend Tim,

wollte dir nur kurz Bescheid geben, Modul läuft seit dem wir über das Problem geschrieben hatten einwandfrei, keine Ahnung warum es vorher nie ging und das Abend dann der ausschlaggebende reload war. Von daher, alles super.

Ich wollte dich nochmal nach deiner Meinung bezüglich einer AddLog-Funktion fragen, das wäre das einzige was ich an dem Modul noch vermisse. Es ist halt eine einfache Art für einen Anstoß zum schreiben der definierten Daten. Ich habe das jetzt mal zum testen in der myUtils nachgebaut (wie ja auch z.B. im Wiki beschrieben), das ganze triggert aber und das wird ja nicht benötigt, es soll lediglich der aktuell in dem angegebenen reading stehende Wert mit dem aktuellen Zeitstempel in die InfluxDB geschrieben werden. Zudem braucht das myUtils für meine 86 Werte ca. 12 Sekunden Laufzeit, in denen geht erstmal nichts mehr. Von daher kommt die Variante eh nicht in Frage.

Ich habe auch schon das DbLog-Modul durchforstet und alle wichtigen Stellen rauskopiert und vorbereitet, das aber funktionsfähig bei dir ins Modul einzubauen sind meine Kenntnisse dann doch zu wenig.

Kannst ja wie gesagt mal Bescheid geben.

Gruß Markus 
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 02 Februar 2021, 22:57:42
Kosten neue Threads bei euch Gebühren? :o

Egal.

Hol mich mal grad ab. Du bist gedanklich bei dem Log Attribut a la DbLogInclude?





Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: meier81 am 03 Februar 2021, 18:09:29
Zitat von: timmib am 02 Februar 2021, 22:57:42
Kosten neue Threads bei euch Gebühren? :o

Egal.

Hol mich mal grad ab. Du bist gedanklich bei dem Log Attribut a la DbLogInclude?

Dann lass uns doch einfach hier weitermachen, habe ich ja schon einen erstellt  ;)
https://forum.fhem.de/index.php/topic,118049.0.html (https://forum.fhem.de/index.php/topic,118049.0.html)
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: Weisswurstverkäufer am 11 Februar 2021, 13:58:13
Hallo Tim,

habe das Modul heute auch mal eingerichtet. Ist zwar etwas kompliziert wenn man bei 0 anfängt - wenn es einmal eingerichtet ist scheint es aber gut zu funktionieren  :)

Was ich ein bisschen schade finde ist dass nur numerische Werte funktionieren. Wäre es nicht möglich eine Whitelist für andere Werte einzubauen? Ist irgendwie unschön dass ich jetzt open auf 1 und closed auf 0 mappen muss, nur um es dann in Grafana ("discrete"-Plugin) wieder zurück umwandeln zu müssen.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 11 Februar 2021, 14:35:38
Hallo WWV,

das ist Konzept bedingt bei InfluxDB so.

Dort sind Texte meist als Tag abgebildet.
Das wird von dem Modul mittels dem Attribut tags auch unterstützt.

Viele Grüße

Tim
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: Weisswurstverkäufer am 11 Februar 2021, 14:41:07
Zitat von: timmib am 11 Februar 2021, 14:35:38
Das wird von dem Modul mittels dem Attribut tags auch unterstützt.

So richtig schlau werde ich aus dem commandref dazu leider nicht. Kannst Du mir vielleicht als Beispiel nennen wie das für Fenstersensoren (state open/closed) aussehen müsste (das Beispiel würde ja auch gut ins commandref passen)? Das lässt sich dann ja auch auf Bewegungsmelder (motion/nomotion) übertragen
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 11 Februar 2021, 15:13:30
Ein Beispiel, ist es den Alias auszuwerten oder einfach fest das Tag auf "logger1" zu setzen wenn man aus mehreren Loggern heraus auf das selbe measurement logt.

In deinem Fall, wo es eigentlich um Readings geht, könnt man das mit Perlausdrücken hinbekommen. Das ist aber wenig ratsam.

Grundsätzlich unterstützt InfluxDB ja auch Strings als Fieldvalue nur keine Mischung. Also wenn alle Readings mit unterschiedlichem Tag in das selbe Feld schreiben. Dies ist das Standardverhalten des Moduls aus Legacy Gründen.

Wenn man das Attribut fields auf $ReadingName=$ReadingValue hat, müsste es eigentlich gehen. Das Modul verhindert das aber zur Zeit - zu Unrecht.

Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: atmelfreak am 14 Februar 2021, 16:28:09
Erstmal vielen Dank für das tolle Modul. Ich habe es seit ein paar Tagen im Einsatz und es läuft soweit sehr gut.
Leider habe ich ein kleines Problem: Es treten sporadisch Timeouts auf:

Internals:
   CFGFN     
   DATABASE   fhem
   DEF        http://192.168.2.188:8086 fhem myElectricityCalculator,myGasCalculator,Thermometer.*,Solar,SteckdoseTV,Zirkulationspumpe
   FUUID      6027ce14-f33f-b66c-2893-25d9615b16533d81
   NAME       InfluxDB
   NOTIFYDEV  myElectricityCalculator,myGasCalculator,Thermometer.*,Solar,SteckdoseTV,Zirkulationspumpe
   NR         150
   NTFY_ORDER 50-InfluxDB
   STATE      Statistics: t=58279 s=56110 f=2142 e=91059
   TYPE       InfluxDBLogger
   URL        http://192.168.2.188:8086
   passwd     saved
   READINGS:
     2021-02-13 23:59:55   dropped_writes  18
     2021-02-13 23:59:55   dropped_writes_last_message Thermometer_Aussen statVoltageDayLast Min
     2021-02-14 15:16:56   failed_writes   2142
     2021-02-14 15:16:56   failed_writes_last_error write to http://192.168.2.188:8086 timed out
     2021-02-14 16:23:50   state           Statistics: t=58279 s=56110 f=2142 e=91059
     2021-02-14 16:23:44   succeeded_writes 56110
     2021-02-14 16:23:50   total_events    91059
     2021-02-14 16:23:50   total_writes    58279
Attributes:
   conversions ON|on|true|yes|up=1,false|OFF|off|no|down=0
   deviceTagName device
   readingExclude (^STAT_.*|^SENSOR.*Id:.*|.*TempUnit:.*|.*Time:.*)
   room       ZZ-Intern


Die InfluxDB läuft auf einem 2. RPI, aber eigentlich habe ich keine Netzwerkprobleme, beide RPIs sind per Ethernet verbunden.
Kann man irgendwo die Timeouts erhöhen?
Bedeutet es, dass 2142 Messwerte nicht in die Datenbank geschrieben wurden oder wird das Schreiben im Fehlerfall wiederholt?
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: atmelfreak am 14 Februar 2021, 16:43:32
Das FHEM Log schaut so aus:

2021.02.14 12:40:56 1: InfluxDBLogger: [InfluxDB] Error = write to http://192.168.2.188:8086 timed out
2021.02.14 12:40:56 1: InfluxDBLogger: [InfluxDB] Error = write to http://192.168.2.188:8086 timed out
2021.02.14 12:40:56 1: InfluxDBLogger: [InfluxDB] Error = write to http://192.168.2.188:8086 timed out
2021.02.14 13:02:55 1: InfluxDBLogger: [InfluxDB] Error = write to http://192.168.2.188:8086 timed out
2021.02.14 13:40:56 1: InfluxDBLogger: [InfluxDB] Error = write to http://192.168.2.188:8086 timed out
2021.02.14 13:40:56 1: InfluxDBLogger: [InfluxDB] Error = write to http://192.168.2.188:8086 timed out
2021.02.14 14:08:55 1: InfluxDBLogger: [InfluxDB] Error = write to http://192.168.2.188:8086 timed out
2021.02.14 14:08:55 1: InfluxDBLogger: [InfluxDB] Error = write to http://192.168.2.188:8086 timed out
2021.02.14 14:08:55 1: InfluxDBLogger: [InfluxDB] Error = write to http://192.168.2.188:8086 timed out
2021.02.14 14:08:55 1: InfluxDBLogger: [InfluxDB] Error = write to http://192.168.2.188:8086 timed out
2021.02.14 14:08:55 1: InfluxDBLogger: [InfluxDB] Error = write to http://192.168.2.188:8086 timed out
2021.02.14 14:08:55 1: InfluxDBLogger: [InfluxDB] Error = write to http://192.168.2.188:8086 timed out
2021.02.14 14:08:55 1: InfluxDBLogger: [InfluxDB] Error = write to http://192.168.2.188:8086 timed out
2021.02.14 14:08:55 1: InfluxDBLogger: [InfluxDB] Error = write to http://192.168.2.188:8086 timed out
2021.02.14 14:08:55 1: InfluxDBLogger: [InfluxDB] Error = write to http://192.168.2.188:8086 timed out
2021.02.14 14:08:55 1: InfluxDBLogger: [InfluxDB] Error = write to http://192.168.2.188:8086 timed out
2021.02.14 14:08:55 1: InfluxDBLogger: [InfluxDB] Error = write to http://192.168.2.188:8086 timed out
2021.02.14 14:08:55 1: InfluxDBLogger: [InfluxDB] Error = write to http://192.168.2.188:8086 timed out
2021.02.14 14:08:55 1: InfluxDBLogger: [InfluxDB] Error = write to http://192.168.2.188:8086 timed out
2021.02.14 14:12:55 1: InfluxDBLogger: [InfluxDB] Error = write to http://192.168.2.188:8086 timed out
2021.02.14 14:12:55 1: InfluxDBLogger: [InfluxDB] Error = write to http://192.168.2.188:8086 timed out
2021.02.14 14:12:55 1: InfluxDBLogger: [InfluxDB] Error = write to http://192.168.2.188:8086 timed out
2021.02.14 14:12:55 1: InfluxDBLogger: [InfluxDB] Error = write to http://192.168.2.188:8086 timed out
2021.02.14 14:12:55 1: InfluxDBLogger: [InfluxDB] Error = write to http://192.168.2.188:8086 timed out
2021.02.14 14:12:55 1: InfluxDBLogger: [InfluxDB] Error = write to http://192.168.2.188:8086 timed out
2021.02.14 14:12:55 1: InfluxDBLogger: [InfluxDB] Error = write to http://192.168.2.188:8086 timed out
2021.02.14 14:12:55 1: InfluxDBLogger: [InfluxDB] Error = write to http://192.168.2.188:8086 timed out
2021.02.14 14:12:55 1: InfluxDBLogger: [InfluxDB] Error = write to http://192.168.2.188:8086 timed out
2021.02.14 14:12:55 1: InfluxDBLogger: [InfluxDB] Error = write to http://192.168.2.188:8086 timed out
2021.02.14 14:12:55 1: InfluxDBLogger: [InfluxDB] Error = write to http://192.168.2.188:8086 timed out
2021.02.14 15:16:56 1: InfluxDBLogger: [InfluxDB] Error = write to http://192.168.2.188:8086 timed out
2021.02.14 15:16:56 1: InfluxDBLogger: [InfluxDB] Error = write to http://192.168.2.188:8086 timed out
2021.02.14 15:16:56 1: InfluxDBLogger: [InfluxDB] Error = write to http://192.168.2.188:8086 timed out
2021.02.14 15:16:56 1: InfluxDBLogger: [InfluxDB] Error = write to http://192.168.2.188:8086 timed out


Also sporadisch immer wieder Timeouts...
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 14 Februar 2021, 18:45:02
Hi,

freut mich zu hören.

Zu den Timeouts kann ich leider nicht viel sagen, außer das es entweder ein Problem in deinem Netz gibt(unwahrscheinlich) oder der InfluxDB-Server etwas viel zu tun hat von Zeit zu Zeit.

Viele Grüße

Tim
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: atmelfreak am 14 Februar 2021, 19:53:05
Hi Tim,

werden abgebrochene Inserts nachgeholt oder gehen die Daten verloren?

Ich habe mir die Sache mit den Timeouts mal angeschaut. Da du beim Aufruf von HttpUtils_NonblockingGet keinen Timeout angibst, zieht der Default von 4 Sekunden. Ich habe testweise den Timeout auf 10 Sekunden gesetzt und incrementalTimout auf 1 gesetzt. Bisher sind keine Timeouts mehr aufgetreten, aber ich muss es noch weiter beobachten.

Hier meine Änderung an deinem Code:
        my $reqpar = {
                    url => InfluxDBLogger_BuildUrl($own_hash),
                    method => "POST",
                    data => $data,
                    hideurl => 1,
                    incrementalTimout => 1,
                    timeout => 10,
                    hash => $own_hash,
                    callback => \&InfluxDBLogger_HttpCallback
        };
        InfluxDBLogger_AddSecurity($own_hash,$name,$reqpar);

        Log3 $name, 4, "InfluxDBLogger: [$name] Sending data ".$reqpar->{data}." to ".$reqpar->{url};
        HttpUtils_NonblockingGet($reqpar);


Könntest Du den Timeout und den incrementalTimout als Attributes in dein Modul einbauen?

Viele Grüße
Frank
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 14 Februar 2021, 22:43:14
Hallo Frank,

ne das wird leider nix gepuffert oder ähnliches. alles was nicht zugestellt werden konnte ist verloren.

Die Timeouts kann man ja als Attribut einbauen.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: atmelfreak am 15 Februar 2021, 09:34:12
Hi Tim,

nach dem Setzen des Timeouts auf 10 Sekunden (Standard war 4 Sekunden) und setzen des incrementalTimeout Parameters (Achtung Schreibfehler in der Doku!) auf 1 habe ich seit gestern Nachmittag keinen einzigen Timeout Abbruch mehr gehabt.

Es wäre toll, wenn Du die beiden Attribute in der nächsten Version Deines Moduls einbauen könntest.

Viele Grüße
Frank
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: Tazz am 13 Mai 2021, 19:49:37
Hallo

Ich benutze den sysmon, um von Raspberry u.a. die RAM Auslastung zu ermitteln.
Jetzt übertragt dieser aber die RAM Auslastung ungünstig per Reading als großen String:
Zitat2021-05-13 19:39:06 SYSMON sysmon ram: Total: 926.08 MB, Used: 368.40 MB, 39.78 %, Free: 144.43 MB

Ich möchte aber einzeln ram_total, ram_used und ram_free in die InfluxDB v2 schicken und dies für site_name = raspberry

Mit meiner Definiton wird gar nichts übertragen
Zitatdropped_writes_last_message sysmon ram Total
state Statistics: t=0 s=0 f=0 e=0
Die Verbindung zur InfluxDB2 funktioniert aber.

Was mache ich falsch?

defmod influxdb2_sysmon_ram_total InfluxDBLogger http://192.168.1.118:8086 fhem sysmon
attr influxdb2_sysmon_ram_total api v2
attr influxdb2_sysmon_ram_total measurement ram_total
attr influxdb2_sysmon_ram_total conversions Total:\s?([0-9]*[.]?[0-9]+)=$1
attr influxdb2_sysmon_ram_total readingInclude ram.*
attr influxdb2_sysmon_ram_total tags raspberry


Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: choenig am 24 Juni 2021, 13:39:22
Hi,

ich habe gerade angefangen, den InfluxDBLogger zu verwenden, und dann beim rename ein FHEM-Crash :(

Undefined subroutine &main::InfluxDBLogger_ReadPassword called at ./FHEM/93_InfluxDBLogger.pm line 557.

Ein rename scheint nicht so häufig vorzukommen ;)

LG
Christian
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: macfly am 24 Juli 2021, 20:46:06
Zitat von: choenig am 24 Juni 2021, 13:39:22
Hi,

ich habe gerade angefangen, den InfluxDBLogger zu verwenden, und dann beim rename ein FHEM-Crash :(

Undefined subroutine &main::InfluxDBLogger_ReadPassword called at ./FHEM/93_InfluxDBLogger.pm line 557.

Ein rename scheint nicht so häufig vorzukommen ;)

LG
Christian

Lustig, ist mir genau heute auch passiert. Ich habe dann einfach fhem gestoppt und in der fhem.cfg und fhem.save das Device umbenannt ;-)

Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: tamash am 30 September 2021, 07:30:37
Hallo!

Ich habe eine grundlegende Frage zur Benutzung des Moduls!
Definiert ihr in der Regel ein InfluxDBLogger-Device für jedes Device das ihr logen wollt oder ein InfluxDBLogger-Device für alle Devices?

Meine Frage ergibt sich aus folgender Problematik die vielleicht einem Verständnisproblem meinerseits zu Grunde liegt.
2 Devices:
  - Lichtschalter01
  - Lichtdimmer01

Ich will vom Device 'Lichtschalter01' nur das Reading 'state' logen und vom Device 'Lichtdimmer01' nur das Reading 'pct' loggen.
Sofern ich das richtig versteh lässt sich das mit nur einem InfluxDBLogger-Device nicht realisieren, oder?

LG
Tom
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: meier81 am 30 September 2021, 09:44:04
Hallo Tom,

bezüglich deiner Frage fürchte ich wirst du wohl 2 Influx-Devices benötigen, falls du nicht damit leben kannst dann z.B. vom Lichtdimmer01 auch den "state" mitzuloggen.

Also ich habe bei mir 5 Influx-Devices am laufen, damit kann man halt auch in influx die Daten etwas "sortiert" ablegen.

Ich habe z.B. eine für meine Raumsensoren, eine für die Heizung, eine für Energiezähler, eine für das Wetter und eine allgemeine. Um die Größe der Datenbank brauchst du dir auch erstmal keine großen Gedanken zu machen, ich habe glaube ich von knapp über 3 Jahren Daten drin und bin aktuell bei einer Größe von ca. 75 MB.

Gruß

Markus
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: tamash am 05 Oktober 2021, 20:30:11
Hi!

Vielen Dank für deine ausführliche Antwort.
Hab ich also doch nicht irgendwas falsch verstanden.
Dann werde ich das wohl so umbauen bei mir.

Danke nochmals.
LG
Tom
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: rob am 13 Oktober 2021, 10:39:01
Hallo.

Kurze Info zur commandref vom Modul: Unter hier/here scheint sich im Link ein "fhem/docs/" zuviel eingeschlichen zu haben.
ZitatFor details about devspec see here. If you use a wildcard devspec, the device will be disabled on default in order to let you specify a readings-regex to reduce the log-amount.

Aus https://fhem.de/fhem/docs/commandref.html#devspec müsste ein https://fhem.de/commandref.html#devspec werden
bzw. lokal aus http://localhost:8083/fhem/docs/fhem/docs/commandref_DE.html#devspec ein http://localhost:8083/fhem/docs/commandref_DE.html#devspec

Nix wildes/ eiliges. Wollt es nur rückmelden :)

Viele Grüße
rob
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: rob am 14 Oktober 2021, 09:10:12
Hallo Leute.

Jetzt muss ich leider doch mit Fragen nerven. Ich habe gestern den Tag rumprobiert und kam vom Hölzchen aufs Stöckchen.
Habe Influx 1.8.10 via Docker gestartet, bekam in Fhem aber keinen Zugriff. egal, ob mit oder ohne auth.

2021.10.13 11:35:31 1: InfluxDBLogger: [myTestInflux] Error = 404 Not Found

Also bin ich auf V2 gewechselt. Das Mappen der Buckets wie laut Link (https://forum.fhem.de/index.php/topic,114860.msg1108143.html#msg1108143) angegeben klappte aber nicht, weil man im Cli-Command auch org angeben muss. Und das klappte wieder nicht, weil man zuvor eine aktive Config setzen muss usw. etc. pp.

Naja, habe es letztlich geschafft. Fhem hatte dann Zugriff und schrieb fleißig Werte. Also wollte ich mit Grafana testweise einen Graphen erstellen. Hatte dann mit Grafana zunächst keinen Zugriff auf die V2 (V1 war easy). Erst mit Custom HEAD klappte das.

Die von Fhem geschriebenen Werte konnte ich nur leider nicht finden. Manuell via Curl geschriebene Werte konnte ich sehen, aber nix von Fhem. Dann habe ich es gestern Abend ersteinmal aufgegeben.
Offensichtl. habe ich Fehler begangen und/ oder mir fehlten noch Schritte  :o




jetzt versuche ich es noch einmal von vorn:
- Docker Testinstanz InfluxDB 1.8.2

docker run -d \
   --rm \
   --name=influxdb \
   --net=testnet \
   --network-alias myinfluxdb \
   -p 8086:8086 \
   -v ~/docker/influxdb:/var/lib/influxdb \
   -v /etc/localtime:/etc/localtime:ro \
   -v /etc/timezone:/etc/timezone:ro \
   -e INFLUXDB_DB=hupe \
   -e INFLUXDB_ADMIN_USER=admin \
   -e INFLUXDB_ADMIN_PASSWORD=hupe \
   -e INFLUXDB_USER=hupe \
   -e INFLUXDB_USER_PASSWORD=hupe \
   influxdb:1.8.2


- Defintion in Fhem (list -r)

define myTestInflux InfluxDBLogger http://192.168.1.160:8086/ hupe DS18B20.*,WH1080
attr myTestInflux api v1
attr myTestInflux conversions open=1,closed=0,tilted=2,true|on|yes|ok=1,false|off|no|low=0
attr myTestInflux org hupe
attr myTestInflux readingExclude state
attr myTestInflux room 66_Experimente
attr myTestInflux security basic_auth
attr myTestInflux username hupe

setstate myTestInflux Statistics: t=6 s=0 f=6 e=37
setstate myTestInflux 2021-10-14 08:10:06 dropped_writes 8
setstate myTestInflux 2021-10-14 08:10:06 dropped_writes_last_message WH1080 battery ok
setstate myTestInflux 2021-10-14 08:10:52 failed_writes 6
setstate myTestInflux 2021-10-14 08:10:52 failed_writes_last_error 404 Not Found
setstate myTestInflux 2021-10-14 08:10:52 state Statistics: t=6 s=0 f=6 e=37
setstate myTestInflux 2021-10-14 08:09:15 succeeded_writes 0
setstate myTestInflux 2021-10-14 08:10:52 total_events 37
setstate myTestInflux 2021-10-14 08:10:52 total_writes 6


- Log sagt:

2021.10.14 08:09:11 3: InfluxDBLogger: [myTestInflux] defined with server http://192.168.1.160:8086/ database hupe notifydev DS18B20.*,WH1080
2021.10.14 08:09:17 1: InfluxDBLogger: [myTestInflux] Error = 404 Not Found
2021.10.14 08:09:52 1: InfluxDBLogger: [myTestInflux] Error = 404 Not Found
2021.10.14 08:10:06 1: InfluxDBLogger: [myTestInflux] Error = 404 Not Found
2021.10.14 08:10:06 1: InfluxDBLogger: [myTestInflux] Error = 404 Not Found
2021.10.14 08:10:16 1: InfluxDBLogger: [myTestInflux] Error = 404 Not Found
2021.10.14 08:10:52 1: InfluxDBLogger: [myTestInflux] Error = 404 Not Found


- Schreiben via curl klappt:

curl -i -XPOST 'http://192.168.1.160:8086/write?db=hupe' --data-binary 'waffel value=123'
HTTP/1.1 204 No Content
Content-Type: application/json
Request-Id: 1635fb13-2cb4-11ec-8001-0242ac120002
X-Influxdb-Build: OSS
X-Influxdb-Version: 1.8.2
X-Request-Id: 1635fb13-2cb4-11ec-8001-0242ac120002
Date: Thu, 14 Oct 2021 06:00:52 GMT

- mit Grafana kann ich zugreifen und diesen Wert auch sehen

Hat jmd. eine Idee, wo mein Lapsus liegt? Muss ich an Influx noch irgendwas vorbereiten/ einstellen? Soll ich ggf. doch wieder mit V2 weiter machen?

Vielen Dank und beste Grüße
rob

Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: netpirat am 02 November 2021, 19:54:38
Hallo,

ich versuche gerade meine Temperaturwerte die über das Modul KNX kommen in die Datenbank zu speisen. Ich bekomme immer

unable to parse 'TMP_BU_Temperatur,site_name=TMP_BU_Temperatur getG1=20.00,last-sender=1.1.2,state=20.00': invalid number

Ich befürchte es liegt am 1.1.2. Jemand ne Idee wie man das wegbekommt? ICh bein Neuling, das installieren hat gut geklappt aber hier komme ich nicht weiter.


Readings
dropped_writes

8560

2021-11-02 19:52:16
dropped_writes_last_message

TMP_GA_Temperatur state 13.10 &deg;C

2021-11-02 19:52:16
failed_writes

2779

2021-11-02 19:52:17
failed_writes_last_error

unable to parse 'TMP_BU_Temperatur,site_name=TMP_BU_Temperatur getG1=20.00,last-sender=1.1.2,state=20.00': invalid number

2021-11-02 19:52:17
state

Statistics: t=2779 s=0 f=2779 e=2843

2021-11-02 19:52:17
succeeded_writes

0

2021-11-01 21:53:36
total_events

2843

2021-11-02 19:52:17
total_writes

2779

2021-11-02 19:52:17
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: kadettilac89 am 02 November 2021, 21:39:27
Zitat von: netpirat am 02 November 2021, 19:54:38
Hallo,

ich versuche gerade meine Temperaturwerte die über das Modul KNX kommen in die Datenbank zu speisen. Ich bekomme immer

unable to parse 'TMP_BU_Temperatur,site_name=TMP_BU_Temperatur getG1=20.00,last-sender=1.1.2,state=20.00': invalid number

Ich befürchte es liegt am 1.1.2. Jemand ne Idee wie man das wegbekommt? ICh bein Neuling, das installieren hat gut geklappt aber hier komme ich nicht weiter.


Readings
dropped_writes

8560

2021-11-02 19:52:16
dropped_writes_last_message

TMP_GA_Temperatur state 13.10 &deg;C

2021-11-02 19:52:16
failed_writes

2779

2021-11-02 19:52:17
failed_writes_last_error

unable to parse 'TMP_BU_Temperatur,site_name=TMP_BU_Temperatur getG1=20.00,last-sender=1.1.2,state=20.00': invalid number

2021-11-02 19:52:17
state

Statistics: t=2779 s=0 f=2779 e=2843

2021-11-02 19:52:17
succeeded_writes

0

2021-11-01 21:53:36
total_events

2843

2021-11-02 19:52:17
total_writes

2779

2021-11-02 19:52:17


Zeig mal ein List von der InfluxDB definition und vom Device das du loggen willst. Ist "last-sender=1.1.2" ein Reading? Gehen andere Devices, oder wird überhaupt nichts geloggt?
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: netpirat am 03 November 2021, 16:55:19
Hallo kadettilac89,

erstmal danke für deine Hillfe.

Hier mein InfluxDBLogger


Internals
DATABASE

TEMPERATUREN
DEF
http://192.168.254.25:8086 TEMPERATUREN TMP.*
FUUID

61804aaa-f33f-3e4f-1fd1-5f50c0e48f5848ff
NAME

INF_TEMPERATUREN
NOTIFYDEV

TMP.*
NR

460
NTFY_ORDER

50-INF_TEMPERATUREN
STATE

Statistics: t=3008 s=0 f=3008 e=3158
TYPE

InfluxDBLogger
URL

http://192.168.254.25:8086




Attributes
disable

0


room

901 Logging



Readings
dropped_writes

24970

2021-11-03 16:36:42
dropped_writes_last_message

TMP_AU_Temperatur last-sender fhem

2021-11-03 16:36:42
failed_writes

5457

2021-11-03 16:36:42
failed_writes_last_error

unable to parse 'last-sender,site_name=TMP_KI_Temperatur value=1.1.54': invalid number

2021-11-03 16:36:42
state

Statistics: t=5457 s=0 f=5457 e=5607

2021-11-03 16:36:42
succeeded_writes

0

2021-11-01 21:53:36
total_events

5607

2021-11-03 16:36:42
total_writes

5457

2021-11-03 16:36:42


Und nun  das Device

DeviceOverview
Temperatur Buero

19.70
TMP_BU_Temperatur
TMP_BU_Temperatur
Internals
DEF
6/0/6:dpt9
DEVNAME

TMP_BU_Temperatur
FIRSTGADNAME

g1
FUUID

603dedcb-f33f-887b-9171-1cab7829111fe2d5
GETSTRING

g1:noArg
IODev

KNX
KNX_MSGCNT

235
KNX_RAWMSG

C01138w0600607b2
KNX_TIME

2021-11-03 15:46:39
LASTInputDev

KNX
MSGCNT

235
NAME

TMP_BU_Temperatur
NR

295
SETSTRING

g1:slider,-274,6710,670760
STATE

19.70 &deg;C
TYPE

KNX
model

dpt9
Readings
IODev

KNX

2021-11-02 20:44:35
getG1

19.70

2021-11-03 16:42:36
last-sender

1.1.56

2021-11-03 16:42:36
state

19.70

2021-11-03 16:42:36
TMP_BU_Temperatur
Attributes
IODev

KNX

deleteattr
alias

Temperatur Buero

deleteattr
group

Temperatur

deleteattr
room

007 Buero,805 Temperatur

deleteattr


Das last sender ist gleich die Physikalische Adresse des senders des Telegramms vom KNX Bus.

Ich habe mal eine Abfrage über alles gemacht. Einstellungen sind passend. Readings und Noifys gehen teilweise durch aber nicht direkt vom Device also eine Abfrage direkt von der Hardware, zum Beispiel einem Glastaster.



Internals
DATABASE

DBSYSTA
DEF
http://192.168.254.25:8086 DBSYSTA .*
FUUID

618048c3-f33f-3e4f-fb7b-b562dd8cf1461583
NAME

DB_Log
NOTIFYDEV

.*
NR

459
NTFY_ORDER

50-DB_Log
STATE

Statistics: t=47657 s=43853 f=3804 e=47693
TYPE

InfluxDBLogger
URL

http://192.168.254.25:8086


Am Ende tippe ich darauf, dass die Zeile die in die Datenbank geschrieben wird entsprechend "aufbereitet" werden muss. Mir ist aber noch nicht ganz klar mit welchen tools ich das machen kann.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: kadettilac89 am 03 November 2021, 19:03:53
Zitat von: netpirat am 03 November 2021, 16:55:19
Hallo kadettilac89,

erstmal danke für deine Hillfe.

Hier mein InfluxDBLogger

Das last sender ist gleich die Physikalische Adresse des senders des Telegramms vom KNX Bus.

Ich habe mal eine Abfrage über alles gemacht. Einstellungen sind passend. Readings und Noifys gehen teilweise durch aber nicht direkt vom Device also eine Abfrage direkt von der Hardware, zum Beispiel einem Glastaster.


Am Ende tippe ich darauf, dass die Zeile die in die Datenbank geschrieben wird entsprechend "aufbereitet" werden muss. Mir ist aber noch nicht ganz klar mit welchen tools ich das machen kann.

Ich gehe davon aus, dass du nur die Temperatur loggen willst. Du flutest aktuell die Datenbank mit allen Readings, egal ob die Sinn machen oder nicht.

Du hast 2 Möglichkeiten. Entweder du gibts bei der Definition des Loggingdevices (Die InfluxDB) den Filter an oder du machst das per "event-on-change reading". Dann werden nur die entsprechenden Readings, in dem FAll die Temperatur geschickt und geloggt.

Deine Def., hier schränkst du auf alles ein, was mit TMP beginnt.

http://192.168.254.25:8086 TEMPERATUREN TMP.*


Hier mal meine Def. mit etlichen Readings. Ich logge per Readingnamen. z. B. XHR, actuator. Egal wie das Device heißt.

   DEF        influxdb 8086 fhem <<<password>>>  .*:(XHR|actuator|desired-temp|measured-temp|download|upload|ping|presence|pressure|brightness|temperature|humidity|wind_speed|wind_direction|batVoltage|DbFileSize|location_real|light|twilight|twilight_weather|countHistory|door|Super_E5|Diesel|active_zone|box_rateDown_kbit|box_rateUp_kbit|todayR|todayS).*
   FH


Generell würde ich auch die Events filtern. Im Beispiel unten wird nur ein Event geschickt wenn der Wert geändert wird. Beispiel eines meiner Temperatursensoren mit mehreren Readings

attr HMTempSensor4 event-on-change-reading humidity,temperature,battery,batVoltage,brightness


Für event-on-change-reading - Fhem Doku, da sind genügend Beispiele. Definition der InfluxDB-Def ist auch in der Doku was drin.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: netpirat am 04 November 2021, 19:03:47
Hallo,

das genau war die Lösung. Ich habe das event-on-change-reading auf state gesetzt. Dann habe ich unter KNX nur noch den Wert bekommen. Dieser ist dann so durchgeflutscht. Ohne einen einzigen Fehler seit gestern Abend. Zudem habe ich noch die Tags Room=XXX,Art=XXX,Bezeichnung=XXXX angelegt. Nun kann ich das in Grafana einfacher zuordnen.

Ich habe mal in der Commandref geschaut. SOweit ich das Beurteilen kann, kann man leider nicht für das Reading den "Room" mitnehmen. So muss man wohl für jeden Raum eine Abfrage separat machen.

Oder kennt da jemand eine eleganterer Lösung?

Vielen Dank an kadettilac89.  Als Laie ist man oft unsicher ob man den richtigen weg geht. Wenn man weiß wo man ansetzen muss ist es dann ganz leicht. Als nächstes Versuche ich mal Modbus zu protokollieren. Meine Erfahrungen mit KNX werde ich versuchen im Winter mal in eine Art Doku zu verfassen, damit möglichst viele hier im Forum daran teilhaben können.

Und last but not least, Danke an Tim für dieses coole Modul! Er war lange nicht Online aber ich hoffe er kommt uns bald wieder besuchen. Wir brauchen so kluge Köpfe! Danke Euch!
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: kadettilac89 am 04 November 2021, 21:36:41
Zitat von: netpirat am 04 November 2021, 19:03:47
Ich habe mal in der Commandref geschaut. SOweit ich das Beurteilen kann, kann man leider nicht für das Reading den "Room" mitnehmen. So muss man wohl für jeden Raum eine Abfrage separat machen.


was willst du erreichen? Ein Reading mit dem Attribut "Room"? Vertauscht du die Begriffe ... Fhem Attribut, Internal, Reading .. Influxdb Tag, Measurement ...? Wie soll das Reading aussehen. Zauberwort vermutlich userreadings.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: rob am 15 November 2021, 11:24:45
OK, habe meine Probleme gelöst bekommen und bin nun auf Influx V1 unterwegs. Werte kommen an.

Frage in die Runde: Was habt Ihr sinnvollerweise für RP's und CQ's auf den Datenbanken eingerichtet. Oder macht Ihr ggf. gar kein Downsampling?

Vielen Dank und beste Grüße
rob
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: kadettilac89 am 15 November 2021, 15:00:37
Zitat von: rob am 15 November 2021, 11:24:45
OK, habe meine Probleme gelöst bekommen und bin nun auf Influx V1 unterwegs. Werte kommen an.

Frage in die Runde: Was habt Ihr sinnvollerweise für RP's und CQ's auf den Datenbanken eingerichtet. Oder macht Ihr ggf. gar kein Downsampling?

Vielen Dank und beste Grüße
rob
Retention Period hab ich im Einsatz. Eigene Datenbank mit eigenem InfluxDB-Device in Fhem. Für Daten die nur kurzzeitig relevant sind, z. B. CPU, Ram ... Retention 14d

Continuous Queries habe ich nicht im Einsatz. Mein Ordner ist nur 800 MB groß, und nur ein Teil davon gehört zu Fhem. Durch Timeseries Konzept sollten große Datenbanken dennoch kaum Performanceeinbußen haben. Ich versuche durch vernünftige event-on-change ... Settings nur zu loggen was nötig ist.

Hasdt du Probleme, oder "nur" Vermutung mit Hang zur Perfektion?
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: rob am 15 November 2021, 15:25:36
Zitat von: kadettilac89 am 15 November 2021, 15:00:37
Hasdt du Probleme, oder "nur" Vermutung mit Hang zur Perfektion?
Nur Unwissenheit  ;D
Ich schließe daraus, dass ich mir darum keinen großen Kopf machen muss. Korrekt?

Meine Überlegung war, dass ich ggf. über mehrere Jahre hinweg fleißig Daten schreibe. Wie in FHEM prinzipiell auch, doch dort habe ich im LOG festgelegt, wie lange es lebt und ab wann es wegarchiviert wird. Ergo, so dachte ich, müsste ich ähnliches auch mit Influx tun. Hatte irgendwo den Hinweis gelesen, man solle sich tunlichst darüber Gedanken machen.
800MB sind im Vergleich nicht schlimm. Um ein Gefühl zu bekommen: Wie lange schreibst Du schon in die DB? Mit welcher Frequenz  in etwa (sekündl./ minütl.)? Mit eocr kann ich ja festlegen, dass z.B. mind. alle 2Min geschrieben wird usw.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: kadettilac89 am 15 November 2021, 16:13:32
Zitat von: rob am 15 November 2021, 15:25:36
Nur Unwissenheit  ;D
Ich schließe daraus, dass ich mir darum keinen großen Kopf machen muss. Korrekt?

Meine Überlegung war, dass ich ggf. über mehrere Jahre hinweg fleißig Daten schreibe. Wie in FHEM prinzipiell auch, doch dort habe ich im LOG festgelegt, wie lange es lebt und ab wann es wegarchiviert wird. Ergo, so dachte ich, müsste ich ähnliches auch mit Influx tun. Hatte irgendwo den Hinweis gelesen, man solle sich tunlichst darüber Gedanken machen.
800MB sind im Vergleich nicht schlimm. Um ein Gefühl zu bekommen: Wie lange schreibst Du schon in die DB? Mit welcher Frequenz  in etwa (sekündl./ minütl.)? Mit eocr kann ich ja festlegen, dass z.B. mind. alle 2Min geschrieben wird usw.

Es kommt auf die darunter liegende Hardware an. Bei mir läuft es auf einem Nuc mit Proxmox und einer 512 GB Platte. Da langweilt sich die CPU und Speicher. Ein Raspberry wäre da vielleicht am Limit.

Ich würde es beobachten, ich logge seit 2017 Heizkörper, Wetter, Temperaturen und Luftfeuchte in Räumen. Habe alles von MySQL in InfluxDB importiert. Beim Import habe ich mal verglichen und da war die InfluxDB kleiner als MySql.

Wie geschrieben, es macht mehr Sinn die Events vernünftig in Fhem zu begrenzen als in der DB krampfhaft auf zu räumen. Daten von einer DB ohne auf eine DB mit Retention Period kannst du immer noch schieben. Von welcher Datenmenge redest du aktuell, wie groß ist die DB? Meine reine Fhem ist um die 80, die mit den 14 Tagen ca. 60. Alleine die _internal ist bei mir über 200 groß, das ist die in der sich InfluxDB selber Daten hält.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: rob am 15 November 2021, 16:33:12
Danke Dir für die Infos, das hilft mir schon weiter. Hab das alles aufm Raspi. Die totalen Grafana Auswertungen mache ich da eher weniger, aber es wird wie so oft wachsen...

Zitat von: kadettilac89 am 15 November 2021, 16:13:32
Von welcher Datenmenge redest du aktuell, wie groß ist die DB?
Lächerlich klein ist meine noch, nicht einmal 1MB. Hab ja grad erst angefangen (knapp 14Tage) mit grad mal 2x Devices. Ohne Imports usw. Wollte mir halt das einmal einrichten und quasi vergessen ;)
Ja, stimmt, verschieben kann ich jeder zeit.
Parallel überwache ich das System selbst mit Prometheus, das ist auch noch nicht wirklich groß - nur der verwirft per default eh alle 15Tage.

Vielen Dank für den Input  8)
VG
rob
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: kadettilac89 am 15 November 2021, 16:45:17
Ich habe auch beruflich mit Architektur von Server und Systemen zu tun. Oft macht man den Fehler und versucht von Anfang an jede Eventualität abzudecken.

Würde einfach anfangen und dann schauen wo es Probleme gibt und diese dann beheben wenn diese auftreten. Meistens kracht es sowieso an Stellen die nicht bedacht wurden.
Titel: vielen Dank
Beitrag von: wopl am 17 Dezember 2021, 20:47:26
Großen Dank für die "Neu-Interpretation" des InfluxDBLoggers. Habe gerade das völlig veraltete Modul abgelöst.
Nach ein wenig Knobeln klappt es jetzt wie am Schnürchen.
Ganz viele Temperatur und Stromwerte werden jetzt in die InfluxDB geschrieben und mit Grafana angezeigt.

Edit: und jetzt kommen doch noch Fragen:
- ich habe einen typischen Temperatur/Feuchtesensor. Ich möchte gerne alles andere verwerfen und nur "temp" und "hum" in die InfluxDB schicken.
- mach ich das jetzt mit Attribut measurement (wie gebe ich hier beide an? einfach durch Komma getrennt?) oder ist es das Attribut readingInclude?
- oder sind es doch die Fields? ... jetzt bin ich doch ein wenig verwirrt.
- kann mir jemand mal bitte die attr. Zeile als Beispiel geben?

So ganz komme ich mit den Begriffen measurement und reading dann doch noch nicht klar.
Freue mich auf ein wenig Unterstützung.

Schöne Grüße aus Köln,
Wolfram
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: rob am 20 Dezember 2021, 11:34:51
Hallo Wolfram.

Es gibt imho mehrere Möglichkeiten:
- im Sensor mit event-on-change-reading nur dort ein Event zulassen, wo Du es brauchst
- im Define zum Influx-Device explizit in die Liste aufnehmen, was Du magst
- im attr readingExclude das rausfiltern, was weg haben willst oder mit readingInclude umgekehrt nur das reinnehmen, was explizit haben willst (beides muss zum define passen)

Wahrscheinlich ist eine Kombination aus allem sinnvoll.

Beispiel für event-on-change-reading + event-min-interval im Sensor

attr TempSensor event-min-interval temperature:120,humidity:120,myAbsoluteHumidity:120
attr TempSensor event-on-change-reading temperature:1,battery,humidity:1,myAbsoluteHumidity:1


Beispiel für define

define myTestInflux InfluxDBLogger http://influx-ip:8086 myweatherdb TempSensor.*,DS18B20.*,WH1080


Beispiel für Exclude

attr myTestInflux readingExclude state|.*windDirectionText.*


VG
rob
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: wopl am 22 Dezember 2021, 09:54:38
Hallo rob,
mit dem event-on-change-reading und event-min-interval hatte ich bis jetzt noch nichts eingestellt. Wird in meine zukünfitigen Änderungen ganz sicher einfließen.

Meine initiale Frage ist damit mit dem readingExclude / readingInclude beantwortet. Klappt jetzt prima.
Vielen Dank,
Wolfram
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: okuegerl am 17 Januar 2022, 17:44:42
Geschätzte InfluxDBLogger - Community:
Ich würde gerne InfluxDB verwenden schaffe es aber leider nicht daher erlaube ich mir euch um Rat zu fragen:


Datenbankname: fhemtestdb
user: fhem
psw:  12345

open terminal:
==============
influx
create database fhemtestdb
create user fhem with password '12345' with all privileges
grant all privileges on fhemtestdb to fhem

show users

user admin
---- -----
fhem true

use fhemtestdb
exit

fhemtestdb ist unter http://192.168.1.37:8086 erreichbar

testen was zurück kommt:
============================
curl -G http://192.168.1.37:8086/query --data-urlencode "u=fhem" --data-urlencode "p=12345" --data-urlencode "q=SHOW DATABASES"

{"results":[{"statement_id":0,"series":[{"name":"databases","columns":["name"],"values":[["_internal"],["fhemtestdb"]]}]}]}


###################
## FHEM
###################
define testdummy dummy
  attr testdummy readingList a b value
  attr testdummy stateFormat Wert: value
setreading testdummy value 1


define influxtest InfluxDBLogger http://192.168.1.37:8086 fhemtestdb testdummy
   set influxtest password 12345
  attr influxtest api v1
  attr influxtest security basic_auth
  attr influxtest username fhem
  attr influxtest verbose 5

Internals:
   CFGFN     
   DATABASE   fhemtestdb
   DEF        http://192.168.1.37:8086 fhemtestdb testdummy
   FUUID      61e597bf-f33f-960b-f1c7-511c3e6bc31aa4ca
   NAME       influxtest
   NOTIFYDEV  testdummy
   NR         57
   NTFY_ORDER 50-influxtest
   STATE      Statistics: t=16 s=0 f=16 e=16
   TYPE       InfluxDBLogger
   URL        http://192.168.1.37:8086
   passwd     saved
   READINGS:
     2022-01-17 17:28:48   failed_writes   16
     2022-01-17 17:28:48   failed_writes_last_error connect to http://192.168.1.37:8086 timed out
     2022-01-17 17:28:48   state           Statistics: t=16 s=0 f=16 e=16
     2022-01-17 17:28:44   total_events    16
     2022-01-17 17:28:44   total_writes    16
Attributes:
   api        v1
   security   basic_auth
   username   fhem

jetzt setzte ich zum Testen ein paar Readingswerte
setreading testdummy value 1
setreading testdummy value 2
setreading testdummy value 3

... es wird aber nichts in die Datenbak geschrieben und ich erhalte die Meldung "failed_writes_last_error: connect to http://192.168.1.37:8086 timed out"

FÜR JEDE HILFE BIN ICH SEHR DANKBAR - DANKESCHÖN!

Events:
=======
2022-01-17 17:27:18.717 dummy testdummy value: 1
2022-01-17 17:27:21.504 InfluxDBLogger influxtest total_writes: 12
2022-01-17 17:27:21.504 InfluxDBLogger influxtest total_events: 12
2022-01-17 17:27:21.504 InfluxDBLogger influxtest Statistics: t=12 s=0 f=10 e=12
2022-01-17 17:27:21.507 dummy testdummy value: 2
2022-01-17 17:27:22.721 InfluxDBLogger influxtest failed_writes_last_error: connect to http://192.168.1.37:8086 timed out
2022-01-17 17:27:22.721 InfluxDBLogger influxtest failed_writes: 11
2022-01-17 17:27:22.723 InfluxDBLogger influxtest Statistics: t=12 s=0 f=11 e=12
2022-01-17 17:27:24.246 InfluxDBLogger influxtest total_writes: 13
2022-01-17 17:27:24.246 InfluxDBLogger influxtest total_events: 13
2022-01-17 17:27:24.246 InfluxDBLogger influxtest Statistics: t=13 s=0 f=11 e=13
2022-01-17 17:27:24.249 dummy testdummy value: 3
2022-01-17 17:27:25.509 InfluxDBLogger influxtest failed_writes_last_error: connect to http://192.168.1.37:8086 timed out
2022-01-17 17:27:25.509 InfluxDBLogger influxtest failed_writes: 12
2022-01-17 17:27:25.512 InfluxDBLogger influxtest Statistics: t=13 s=0 f=12 e=13
2022-01-17 17:27:28.254 InfluxDBLogger influxtest failed_writes_last_error: connect to http://192.168.1.37:8086 timed out
2022-01-17 17:27:28.254 InfluxDBLogger influxtest failed_writes: 13
2022-01-17 17:27:28.257 InfluxDBLogger influxtest Statistics: t=13 s=0 f=13 e=13

[/font][/size][/color]
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: meier81 am 17 Januar 2022, 19:57:16
Hallo okuegerl,

also ich habe bei mir in FHEM das wie folgt definiert:


define NN_xx_SW_InfluxDB_Energie InfluxDBLogger http://127.0.0.1:8086 Energie KG_hr_SZ_Haus
attr NN_xx_SW_InfluxDB_Energie alias InfluxDB Energie
attr NN_xx_SW_InfluxDB_Energie conversions closed=0,open=1,tilted=2,false|off|no=0,true|on|yes=1
attr NN_xx_SW_InfluxDB_Energie deviceTagName device_name
attr NN_xx_SW_InfluxDB_Energie icon time_note
attr NN_xx_SW_InfluxDB_Energie readingExclude (ENERGY_ApparentPower|ENERGY_ReactivePower):.*
attr NN_xx_SW_InfluxDB_Energie readingInclude (Power_.*__kW|ENERGY_Power):.*


Ich habe das bei mir ohne user, password, api und security gemacht, funktioniert einwandfrei.

Vermute das es bei dir Probleme gibt mit der Authentifizierung.

influxdb hatte ich lediglich folgendes gemacht auf der shell:


sudo apt install influxdb influxdb-client
influx
CREATE DATABASE Energie


Eventuell kann dir jemand anderes weiterhelfen bezüglich der Authentifizierung, war für mich jetzt kein Problem die Daten so abzulegen. Wollte eigentlich mal auf influxdb 2 umsteigen, da bin ich aber leider auch bislang gescheitert.

Gruß Markus
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: kadettilac89 am 17 Januar 2022, 20:19:34
Zitat von: okuegerl am 17 Januar 2022, 17:44:42
Geschätzte InfluxDBLogger - Community:
Ich würde gerne InfluxDB verwenden schaffe es aber leider nicht daher erlaube ich mir euch um Rat zu fragen:



du hast verbose schon auf 5. Zeige mal das Log an. Ich vermute, dass dein Dummy nur on/off hat und das in der DB nicht gespeichert werden kann. InfluxDb erwartet numerische Werte. Versuche mal Devices mit Nummern als Reading oder den Parameter "conversions", Beispiel ist im Post von meier81 dabei.

Die Meldung "Timeout" habe ich auch obwohl die DB erreichbar ist. Vielleicht ist die nur irreführend. Authentication mit User+Passwort funktioniert, die habe ich auch aktiv. Ich habe aber api-Version nicht gesetzt da per Default sowieos v1 ist.



Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: rob am 17 Januar 2022, 20:42:34
Soweit ich weiß, löst
setreading testdummy value blabla
kein Event aus. Das brauchst Du aber, damit der Logger was zu loggen hat  ;D

Ergänze Deinen Dummy mal bitte um dies:

attr testdummy readingList value
attr testdummy setList value

und lass dann in der Kommandozeile soetwas los
set testdummy value 1

Vielleicht kommt dann schon etwas an.

PS: Magst Du die Detailinfos in Deinem Post noch in Codetags setzen? Ist dann leichter zu lesen  ;)
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: okuegerl am 18 Januar 2022, 12:31:42
Geschätzte Community - vielen Dank für Euer rasches und wertvolles Feedback; ich konnte in der Zwischenzeit mein Problem lösen und möchte mich hiermit bei ALLEN in aller gebotenen Form recht herzlich bedanken, es ist mir eine grosses Privileg dieses Forum nutzen zu dürfen - Dankeschön
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: rob am 18 Januar 2022, 12:35:52
Ich bin neugierig: Wie hast Du es denn konkret lösen können?
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: kadettilac89 am 18 Januar 2022, 16:24:21
Zitat von: okuegerl am 18 Januar 2022, 12:31:42
Geschätzte Community - vielen Dank für Euer rasches und wertvolles Feedback; ich konnte in der Zwischenzeit mein Problem lösen und möchte mich hiermit bei ALLEN in aller gebotenen Form recht herzlich bedanken, es ist mir eine grosses Privileg dieses Forum nutzen zu dürfen - Dankeschön

Das ist mal eine Dankeshymne! Wenn du das beibehältst wird dir jedesmal gerne geholfen :) .... weißt ja, so wie man in den Wald hineinschreit ....

Die Helfenden sind schon nach einem einfachen "Danke" glücklich.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: m-d-ley am 19 Januar 2022, 07:20:25
Hallo, ich habe ein Problem Tags zu erstellen.

Und zwar möchte ich aus dem zu loggendem Device mehrere ReadingsVal in mehrere Tas unterbringen.
Sämtliche Versuche daran schlugen bis jetzt fehl.
Derzeit sieht das Attribute so aus:
name=$DEVICE,{"unit=".ReadingsVal("$device", "unit", 0),"serial=".ReadingsVal("$device", "serial", 0) }

Allerdings werden nur die Tags für name und serial geschrieben. Das Tag unit wird ignoriert. Drehe ich das Attribute allerdings, sodass erst serial und dann unit geplottet werden soll :

name=$DEVICE,{"serial=".ReadingsVal("$device", "serial", 0), "unit=".ReadingsVal("$device", "unit", 0) }

wird nur unit als Tag angelegt. Wo liegt hier der Fehler?

Danke schonmal.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: rob am 20 Januar 2022, 07:09:06
Hallo.

Vielleicht meldet sich noch wer, der sich mit den tags besser auskennt als ich. Möchte Dich aber auch nicht hängen lassen :)

Nach meinem Verständnis sollte das so klappen:

attr yourInfluxDBlogger tags name=$DEVICE,serial={ReadingsVal($device, "serial", 0)},unit={ReadingsVal($device, "unit", "")}

Legt hoffentlich die drei tags an: name, serial und unit. Setzt natürlich voraus, dass serial und unit jeweils in den anliefernden Devices als Reading vorhanden sind. Wenn nicht, wird bei serial "0" gesetzt und bei unit nichts (->"").
Magst Du das kurzerhand testen?
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: m-d-ley am 20 Januar 2022, 07:53:17
Hi,
leider kommt dor ein Bad reqest  bei raus.
Eigentlich sollte die doch eine normale Anforderung an das Modul sein oder?
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: rob am 20 Januar 2022, 08:51:38
Zumindest ist es in der Doku zum Modul als solche aufgeführt  :-\
Wie genau schaut denn Deine Definition des Influxloggers aus? Und könntest Du bitte auch die Fehlermeldung/ LOG-Meldung posten? Aktuell kann ich mir kein konkretes Bild machen. Vielleicht lässt sich mehr erkennen.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: rob am 20 Januar 2022, 10:39:59
mmmh, ich war jetzt mal neugierig und habe in docker fhem, influx und grafana testweise hochgefahren. Die tags so wie oben definiert: klappt wunderbar. Mit Einschränkungen.

das klappt:
attr myTestInflux tags mytag1=$DEVICE,mytag2=prima,mytag3=supa

das klappt bedingt:
attr myTestInflux tags mytag1=$DEVICE,mytag2=$READINGNAME,mytag3=supa weil $READINGNAME nicht aufgelöst wird, es wird "$READINGNAME" als tag in Grafana sichtbar
Ich habe die Hinweise aus der cref so verstanden, dass die Variable aufgelöst werden sollte.

das klappt:
attr myTestInflux tags mytag1=$DEVICE,mytag2={ReadingsVal($device,"quarks",0)},mytag3=supa

das klappt nicht:
attr myTestInflux tags mytag1=$DEVICE,mytag2={ReadingsVal($device,"quarks",0)},mytag3={ReadingsVal($device,"neutrons",0)}
Es kommt eine Fehlermeldung:
2022.01.20 10:25:50.542 1: InfluxDBLogger: [myTestInflux] Error = unable to parse 'quarks,mytag1=mydummy,mytag2= value=7': missing tag value

Habe mehrere Kombinationen versucht. Es scheint, als würde das Parsing immer dann funktionieren, solange nur ein Perl-Ausdruck enthalten ist. Sind es mehr, wird geschimpft.
Habe ich da einen Denkfehler?




meine Test-Devices:
dummy

define mydummy dummy
attr mydummy readingList value quarks neutrons electrons
attr mydummy setList value quarks neutrons electrons

setstate mydummy value 1
setstate mydummy 2022-01-20 10:29:45 electrons 5
setstate mydummy 2022-01-20 10:12:03 neutrons 3
setstate mydummy 2022-01-20 10:29:48 quarks 7
setstate mydummy 2022-01-20 09:42:13 value 2


influx

define myTestInflux InfluxDBLogger http://myinfluxdb:8086 fhem_db mydummy
attr myTestInflux api v1
attr myTestInflux tags mytag1=$DEVICE,mytag2={ReadingsVal($device,"quarks",0)},mytag3={ReadingsVal($device,"neutrons",0)},mytag3={ReadingsVal($device,"electrons",0)}

setstate myTestInflux Statistics: t=14 s=10 f=4 e=14
setstate myTestInflux 2022-01-20 10:11:21 dropped_writes 0
setstate myTestInflux 2022-01-20 10:11:21 dropped_writes_last_message <none>
setstate myTestInflux 2022-01-20 10:29:48 failed_writes 4
setstate myTestInflux 2022-01-20 10:29:48 failed_writes_last_error unable to parse 'quarks,mytag1=mydummy,mytag2= value=7': missing tag value
setstate myTestInflux 2022-01-20 10:29:48 state Statistics: t=14 s=10 f=4 e=14
setstate myTestInflux 2022-01-20 10:23:46 succeeded_writes 10
setstate myTestInflux 2022-01-20 10:29:48 total_events 14
setstate myTestInflux 2022-01-20 10:29:48 total_writes 14


Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: m-d-ley am 20 Januar 2022, 10:43:13
Ich habe den Fehler gefunden:

Sobald man sich im Perlmodus befindet muss man auch dort bleiben.

{"device=$device,serial=" .ReadingsVal("$device", "serial", 0).",unit=" .ReadingsVal("$device", "unit", 0).",scalefactor=" .ReadingsVal("$device", "scalefactor", 0).",value_unscaled=" .ReadingsVal("$device", "value_unscaled", 0).",name=" .ReadingsVal("$device", "name", 0)}

So passt es.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: rob am 20 Januar 2022, 11:19:00
Naja, Du setzt dadurch alles in Perl zu einem String zusammen. OK. Und glücklicherweise wird dies akzeptiert/ aufgelöst. Sehe ich mehr als Workaround an. Lass mich aber gern vom Gegenteil überzeugen  ;)

Die cref lese ich jedenfalls so, dass das nicht nötig sein sollte. Insbesondere wird ja ein Beispiel entspr. gezeigt.
Zitat
tags attr <name> tags <x,y>
Dies ist the Liste der tags die an InfluxDB mitgesendet werden. Das Schlüsselwort $DEVICE wird ersetzt durch den Gerätenamen. Wenn dieses Attribut gesetzt ist wird das Attribut deviceTagName nicht berücksichtigt. Standard ist site_name=$DEVICE. Um keine Tags zu schreiben (insbesondere, weil measurement auf $DEVICE und fields auf $READINGNAME=$READINGVALUE steht) bitte ein "-" eintragen. Es können Perl-Ausdrücke in geschweiften Klammern verwendet werden um z.B. Attribute als tag zu nutzen. $name, $device, $reading, $value stehen dabei als Variable zur Verfügung. attr influx tags device={AttrVal($device, "alias", "fallback")}
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: msome am 28 Januar 2022, 17:16:27
Hi, ich bin seit kurzem dabei bestimmte Daten statt in MySQL in die Influx DB zu senden.
Mit ein paar InfluxLogger Devices funktioniert das auch schon ganz schön, aber ich habe ständig dropped_writes .

Nachdem ich mich gerade ein bisserl im Code umgesehen habe, scheint das Problem darin zu liegen,
dass non-numeric values in InfluxDBLogger_BuildData explizit als "incompatible" verworfen werden. It's not a bug, it's a feature.

Leider habe ich aber halt Readings in Textform die ich auch gerne mit in der Influx DB hätte um nicht 90% Readings in Influx + 10% in MySQL haben zu müssen.
Kann sich jemand erinnern warum diese Beschränkung im Code eingebaut wurde?
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: meier81 am 28 Januar 2022, 17:46:38
Hallo msome,

das ist ganz einfach, soweit ich mich erinnere kann influxdb nur zahlen loggen, keinen String, etc.

Es gibt die Möglichkeit das du mit dem Attribut "conversions" arbeitest, da kannst du "Ersetzungen" machen, hier mal eine von mir:

closed=0,open=1,tilted=2,false|off|no=0,true|on|yes=1

Somit wandle ich z.B. "yes" oder "true" in 1 um, "no" oder "false" in "0" und für meine Fenster mache ich halt "0,1,2".

Anders wäre mir nicht bekannt das hier was geht, das ist halt der "einzige" Nachteil von influxdb. Da aber für mich die Vorteile überwiegen (einfacher konfigurierbar in Grafana, DB-Größe ist um ein vielfacher kleiner, etc.) gehe ich diesen "Verlust" gerne ein.

Gruß Markus
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: msome am 28 Januar 2022, 19:01:14
Hi,

dann war das wohl früher mal so.  Aktuell scheint es zu funktionieren.

influx
use Zzz_test
insert testStrings,site_name=daham value="test test test"


Dann werd ich wohl mal versuchen müssen die Limitierung auszubauen...
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: Weisswurstverkäufer am 03 Februar 2022, 18:19:16
Hallo,

kann es sein dass das Modul beim erzeugen der Einträge in InfluxDB nicht den Zeitpunkt des Readings in FHEM nutzt sondern einfach den aktuellen Timestamp?

Das scheint teilweise zu Problemen zu führen wenn Readings nicht nur auftauchen wenn sie entstehen sondern auch mal zeitversetzt. Bei mir ist das z. B. der Fall bei Netatmo. Da werden manchmal pro Update mehrere Readings geladen. In FHEM sind die dann mit ihrem korrektem Timestamp. In der InfluxDB landen sie aber alle zu einem Zeitpunkt. Das ist irgendwie ein bisschen blöd - Netatmo ist zwischendurch auch gerne mal nicht erreichbar und es kommen dann Daten für 1-2 Stunden auf einmal in FHEM an und dadurch so blöd in die InfluxDB.

Könnte das vielleicht noch irgendwie verbessert werden?
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 03 Februar 2022, 18:24:02
Hi,

ja das ist richtig die Uhrzeit wird nicht mitgegeben. Die Schnittstelle gäbe es aber her.

Bei mir nutze ich einen lokalen NTP Server um alle Systemzeiten gleich zu halten auf allen Systemen. Deswegen hätte es bei mir so gut wie keinen Effekt.

Nutzt du lokal NTP für FHEM und Influx?
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: Weisswurstverkäufer am 03 Februar 2022, 18:28:52
Zitat von: timmib am 03 Februar 2022, 18:24:02
Hi,

ja das ist richtig die Uhrzeit wird nicht mitgegeben. Die Schnittstelle gäbe es aber her.

Bei mir nutze ich einen lokalen NTP Server um alle Systemzeiten gleich zu halten auf allen Systemen. Deswegen hätte es bei mir so gut wie keinen Effekt.

Nutzt du lokal NTP für FHEM und Influx?

Ich vermute ich habe das falsch ausgedrückt. Die Netatmo Station schickt die Werte ins Internet. Das Modul holt sie alle 15 Minuten oder so ab. Teilweise liegen dann aber mehrere Messwerte bereit. Das Netatmo FHEM Modul scheint die Readings aber mit dem korrekten (= von Netatmo abgerufenen) timestamp zu setzen.

Beispiel: ich hatte letztens einen Tag kein Internet. Die Netatmo Station hat aber alle Werte gespeichert und als Internet wieder da war hochgeladen. FHEM hat die Werte dann abgerufen und die Readings erzeugt. Im dblog ist auch alles richtig, in der influxdb sind aber alle Messwerte von dem Tag zur gleichen Sekunde angekommen.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 03 Februar 2022, 18:29:46
Ah, jetzt ja, verstehe.

Ja macht Sinn. Baue ich die Tage gerne ein.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 04 Februar 2022, 12:38:56
Ich hab mir das grad mal angeschaut und festgestellt, das es doch ein etwas größere Sache ist.

Das Problem ist, dass das Modul bei einem Notify eine Zusammenfassung aller events in einen POST request zusammenfasst und darin alle readings, die zum gleichen measurement(default ist reading) und tagset(default ist site_name=DEVICE) in eine Zeile packt.
Das measurement kann dabei alles sein, DEVICE, READING, oder sogar das Ergebnis eines PERL Ausdrucks.

Das Problem ist nun, von welchem Reading schreibe ich nun den TimeStamp?
Es bleibt also in dem Falle, wo der Zeitstempel vom Reading genommen werden soll nichts anderes übrig als dann nicht Zeilen zusammenzufassen.

Hinzu kommt, das laut https://wiki.fhem.de/wiki/DevelopmentModuleAPI#readingsBulkUpdate (https://wiki.fhem.de/wiki/DevelopmentModuleAPI#readingsBulkUpdate) es für ein Modul garnicht so einfach möglich ist den Timestamp eines Readings zu manipulieren.

Kannst Du mir den Modulnamen/Quelle mal schicken? Dann guck ich da mal in den Code rein.

Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 04 Februar 2022, 12:48:46
OK, die machen es in 38_netatmo.pm wirklich. Kannte ich nicht

      readingsBeginUpdate($hash);
      $hash->{".updateTimestamp"} = FmtDateTime($reading->[0]);
      readingsBulkUpdate( $hash, $reading->[1], $reading->[2] );
      $hash->{CHANGETIME}[0] = FmtDateTime($reading->[0]);
      readingsEndUpdate($hash,1);
      $latest = $reading->[0] if( $reading->[0] > $latest );
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: Weisswurstverkäufer am 04 Februar 2022, 13:32:24
Ich habe gar keine Ahnung wie das in FHEM alles funktioniert. Ich habe mir nur mal irgendwann in Python einen Import für meine Solarthermieanlage gehackt. Da ist die Quelle eine CSV-Datei in der auch der Timestamp drin steht. Da mache ich dann wohl einfach so:


                point = {"measurement": metric, "time": timestamp, "fields": fields, "tags": tags}
                datapoints.append(point)

                response = client.write_points(datapoints)


... und habe trotz nur einem großen Requests für alle Werte den korrekten Timestamp
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 04 Februar 2022, 17:26:26
Hi,

schaut euch mal die neue BETA-Version an.

Diese kann nun Strings (Danke an msome) UND originale Zeitstempel

Bitte beides inklusive Doku testen und zurückmelden, damit ich das nach SVN schieben kann.

ZitatstringValuesAllowed attr <name> stringValuesAllowed [0|1]
If enabled (1) it allows to write strings as value, if disabled(0) non-numeric values will be blocked (dropped). Default: 0 (non-numeric values are blocked)
readingTimeStamps attr <name> readingTimeStamps [0|1]
If enabled(1) the ReadingTimestamp from FHEM is send to InfluxDB, Default is off(0). This is useful for devices that publish the values later with the original timestamp delayed. Default: 0 (InfluxDB determines the timestamp on its own)

Viele Grüße

Tim
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: Weisswurstverkäufer am 07 Februar 2022, 08:03:11
Hallo Tim,

habe die Version jetzt (kurz) getestet. Sieht für mich perfekt aus (beide Funktionen). Besten Dank dafür!

Übrigens: wenn man stringValuesAllowed nutzen will muss man wohl die alten Daten löschen da sonst imkompatibel:

partial write: field type conflict: input field "value" on measurement "state" is type string, already exists as type float dropped=1

Falls noch Probleme auftreten würde ich sie noch melden.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: rob am 07 Februar 2022, 08:43:52
Hallo Tim.

Ich habe auch testweise die angehangene Datei geladen und im Test-FHEM ein "reload  93_InfluxDBLogger" ausgeführt. Anschl. bekam ich diese Hinweise:

Too many arguments for main::InfluxDBLogger_BuildDataDynamic at ./FHEM/93_InfluxDBLogger.pm line 197, near "$numeric)"
Too many arguments for main::InfluxDBLogger_BuildDataDynamic at ./FHEM/93_InfluxDBLogger.pm line 221, near "$numeric)"
Too many arguments for main::InfluxDBLogger_GetFieldSet at ./FHEM/93_InfluxDBLogger.pm line 249, near "$numeric)"

Dann kurzerhand doch FHEM restartet und es passt. Vielleicht lag es an meiner Testumgebung. Nix wildes, wollt es nur rückmelden, falls interessant.

Mit stringValuesAllowed 1 und 0 habe ich ein wenig rumprobiert - klappt auch bei mir prima  8)
Die cref könnte ggf. um einen Hinweis ergänzt werden, dass die conversions ziehen, falls gesetzt, und man nicht im Nachhinein von Werten auf Text und umgekehrt im selben Feld umschwenken sollte - wie von Weisswurstverkäufer schon beschrieben.

partial write: field type conflict: input field "value" on measurement "value" is type float, already exists as type string dropped=1
partial write: field type conflict: input field "value" on measurement "quarks" is type string, already exists as type float dropped=1


Vorschlag:
stringValuesAllowed attr <name> stringValuesAllowed [0|1]
If enabled (1) it allows to write strings as value, if disabled(0) non-numeric values will be blocked (dropped). Default: 0 (non-numeric values are blocked)
Conversions are still in effect, if set. Influx doesn't let you write conversed text as value when a field was already written as text and vice versa.


Bei den conversions könnte ich nun meinen, soetwas müsste auch gehen:
attr myTestInflux conversions xyz=aaa,1=bbb
Wird auch klaglos in die DB geschrieben, allerdings ist value dann null (mit distinct in Grafana nachgeschaut).
Wann man die conversions auch für Text nutzen könnte, wäre es ggf. nicht nötig alle Daten zu löschen, falls man doch aus irgendwelchen Gründen umschwenken muss. Mir fällt allerdings kein schönes Beispiel ein :)

Viele Grüße
rob
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 07 Februar 2022, 14:40:30
Hi,

vielen Dank für das Feedback. Den Hinweis zum Umschalten kommt in die Doku, gute Idee.

ZitatBei den conversions könnte ich nun meinen, soetwas müsste auch gehen:

Ja, geht auch, weil vorher konvertiert wird. Man muss nur es nur in "" packen, ich verstehe im Moment noch nicht warum er das nicht automatisch macht.

attr influx conversions 1="eins"
attr influx stringValuesAllowed 1


Viele Grüße

Tim
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 07 Februar 2022, 17:08:07
Zitatich verstehe im Moment noch nicht warum er das nicht automatisch macht.

.. so das hab ich jetzt auch kapiert.

Der Witz ist, dass hier auf der rechten Seite vom = auch Perl code geschrieben werden kann. Leider habe ich versäumt das in die Doku zu schreiben.
Damit kann man z.B. sowas machen.
attr influx conversions 1={ return 2*2;; }
Was immer wenn eine 1 als Wert eines Readings auftritt 2*2 also 4 in die Datenbank schreibt.
Der sinnvolle Usecase ist das Ersetzen von Werten mit RegEx Gruppe um z.B. Werte von ihrer Einheit zu befreien. Siehe hierzu: https://forum.fhem.de/index.php/topic,114860.msg1103001.html#msg1103001 (https://forum.fhem.de/index.php/topic,114860.msg1103001.html#msg1103001)
([0-9]+)%=$1

Lange Rede - kurzer Sinn:
Bei 1=eins würde Perl eins ausführen mit dem Ergebnis leerer String.
Bei 1="eins" würde Perl "eins" ausführen mit dem Ergebnisstring "eins".

Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 07 Februar 2022, 20:42:03
Guten Abend,

ich habe die neue Version nun nach SVN commited.

Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: Weisswurstverkäufer am 08 Februar 2022, 06:15:50
Bei mir kam es heute Nacht mehrmals zu folgender Meldung:

partial write: field type conflict: input field "value" on measurement "temperature" is type string, already exists as type float dropped=1

Kann ich irgendwie rausfinden was das war? Temperatur als String ist ja irgendwie kurios
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: rob am 08 Februar 2022, 07:38:37
Hast Du vielleicht bei einem der abgefragten Devices einen formatierten Wert z.B. "5.1°C" dabei?
Tritt das nicht mehr auf? Wenn doch, dann ggf. mit verbose 4 mal loggen lassen, da wird es konkret woher das kommt.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 08 Februar 2022, 15:53:09
Genau, einfach das verbose Attribut auf 4 für diesen Logger stellen und dann nach sowas ausschau halten.

InfluxDBLogger: LOGGERNAME Sending data....

oder einfach alles von dem Logger hier posten.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: Weisswurstverkäufer am 09 Februar 2022, 07:47:08
Lustigweise kam das gestern den ganzen Tag nicht mehr vor. Heute Nacht dann aber wieder:

2022.02.09 00:25:19 1: InfluxDBLogger: [influxdb] Error = partial write: field type conflict: input field "value" on measurement "temperature" is type string, already exists as type float dropped=1

[...]

2022.02.09 07:09:10 1: InfluxDBLogger: [influxdb] Error = partial write: field type conflict: input field "value" on measurement "temperature" is type string, already exists as type float dropped=1


Ich stelle jetzt mal das influxdb-device auf Verbose 4 und schaue (das wird vermutlich ganz schön spammen, oder?)

2022.02.09 07:58:29 4: InfluxDBLogger: [influxdb] notified from device Regensensor
2022.02.09 07:58:29 4: InfluxDBLogger: [influxdb] notified from device Regensensor about temperature: -water
2022.02.09 07:58:29 4: InfluxDBLogger [influxdb] - Read passwd from file
2022.02.09 07:58:29 4: InfluxDBLogger: [influxdb] Sending data temperature,site_name=Regensensor value="-water" 1644389909000000000
to http://192.168.42.210:8086/write?db=fhem
2022.02.09 07:58:29 1: PERL WARNING: Argument "water" isn't numeric in numeric lt (<) at (eval 103215) line 1.
2022.02.09 07:58:29 4: InfluxDBLogger: [influxdb] notified from device Regensensor
2022.02.09 07:58:29 4: InfluxDBLogger: [influxdb] notified from device Regensensor about water: no_water
2022.02.09 07:58:29 4: InfluxDBLogger [influxdb] - Read passwd from file
2022.02.09 07:58:29 4: InfluxDBLogger: [influxdb] Sending data water,site_name=Regensensor value="no_water" 1644389910000000000
to http://192.168.42.210:8086/write?db=fhem
2022.02.09 07:58:29 1: InfluxDBLogger: [influxdb] Error = partial write: field type conflict: input field "value" on measurement "temperature" is type string, already exists as type float dropped=1
2022.02.09 07:58:29 4: InfluxDBLogger: [influxdb] HTTP Succeeded succeeded_writes: 133


Irgendwie kurios. Der Regensensor hat tempeature, aber das steht auf -1
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: msome am 09 Februar 2022, 08:16:06
Guten Morgen,
ich hatte eben auch so ein Problem und hab es durch Zufall direkt gesehen und konnte im Reading nachschauen. Bei mir ist es scheinbar das Zahlenformat.
Ab und zu werden in eines meiner Devices Readings mit E Format geschrieben - diese werden dann aber von InfluxLogger als String erkannt, und können daher nicht in das bestehende Float Geld eingefügt werden.

Beispiel:
state.accuexport.today
6.103515625e-05
2022-02-09 07:59:05

Da muss ich wohl mal sehen wie ich in die Erfassung (Jsonmod) eine Umwandlung reinbekomme damit das E Format nicht im Reading landet...
Ist aber schon ein bisschen Tricky; vor String Aktivierung gingen solche Fehler unter (dropped).

Viel Glück den Anderen bei der Suche.

@timmib , wenn solch ein Fehler Auftritt, könntest du dann den Wert des Readings der nicht geschrieben werden konnte, mit in der Fehlermeldung ausgeben? Das würde ein Logging mit hohem Verbose vermeiden, vor allem wenn der Fehler nur sporadisch auftritt. Das fehlgeschlagene Reading steht ja in der Fehlermeldung bereits drinnen... ?
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: Weisswurstverkäufer am 09 Februar 2022, 08:26:02
Ach, es liegt bestimmt an meiner

eventMap
0:no_water
1:water

dann macht er aus "temperature" -1 ein "temperature" -water?

Das ist ja irgendwie ein bisschen bekloppt :')
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 09 Februar 2022, 11:17:23
Eigentlich sollte er 6.103515625e-05 als numeric erkennen. Ich bin bisher nur von großen 'E' ausgegangen.
Füge mal das kleine "e" in Zeile 375 in die RegEx ein, ob Influx damit leben kann.
^[0-9,.eE-]+$.

Zitatdann macht er aus "temperature" -1 ein "temperature" -water?
Da kann ich leider nicht viel zu sagen. Aber beim InfluxDBLogger kommt es als solches an laut deinem log. So wie ich evetMap verstehen ist der Linke Teil eine RegEx und wird ersetzt.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: Weisswurstverkäufer am 09 Februar 2022, 11:23:54
Eigentlich egal - der temperature-Wert des Regensensors ist eh Quatsch. Nur blöd dass es dann im Log immer auftaucht. Kann ich das leicht excluden?

Mein aktuelles readingInclude ist:

(temperature:.*|humidity:.*|co2:.*|noise:.*|water:.*|.*open|.*closed|.*motion|.*nomotion|lux:.*|lightlevel:.*|dark:.*|daylight:.*)
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 09 Februar 2022, 11:28:06
Ja, nimm das Attribut readingExclude.

Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: rob am 10 Februar 2022, 09:32:03
Bezüglich der Devspec habe ich leider Verständnisprobleme. Ich möchte meine Definition in FHEM gerne generalisieren, damit weitere Devices mit passendem Reading automatisch ins Influx-Logging reinrutschen.
Den Ansatz von kadettilac89 aus Post #161 finde ich elegant und schlüssig:
Zitat von: kadettilac89 am 03 November 2021, 19:03:53
...
Hier mal meine Def. mit etlichen Readings. Ich logge per Readingnamen. z. B. XHR, actuator. Egal wie das Device heißt.

   DEF        influxdb 8086 fhem <<<password>>>  .*:(XHR|actuator|desired-temp|measured-temp|download|upload|ping|presence|pressure|brightness|temperature|humidity|wind_speed|wind_direction|batVoltage|DbFileSize|location_real|light|twilight|twilight_weather|countHistory|door|Super_E5|Diesel|active_zone|box_rateDown_kbit|box_rateUp_kbit|todayR|todayS).*
   FH

...

Adaptiere ich das von meinem expliziten Filter:
defmod myTestInflux InfluxDBLogger http://ip:8086 fhemdb DS18B20.*,WH1080
auf den impliziten Device-Filter analog dem Post:
defmod myTestInflux InfluxDBLogger http://ip:8086 fhemdb .*:(temperature|humidity|absHumidity).*
wird leider nichts mehr geloggt  :-\

In der cref wird auf devspec der cref verwiesen - von dort genannten Varianten habe ich einige auf meiner Testumgebung mit zwei Dummies + InfluxDBLogger versucht auszutüfteln, komme aber leider auf keinen grünen Zweig.
Habt Ihr eine Idee, wo mein Fehler liegen könnte?

Vielen Dank und beste Grüße
rob




meine dummies:

define crashtest1 dummy
attr crashtest1 readingList temperature humidity absHumidity
attr crashtest1 setList temperature humidity absHumidity

define crashtest2 dummy
attr crashtest2 readingList temperature humidity absHumidity
attr crashtest2 setList temperature humidity absHumidity

setstate crashtest1 2022-02-10 08:23:53 absHumidity 3.9
setstate crashtest1 2022-02-10 08:24:31 humidity 41
setstate crashtest1 2022-02-10 08:24:09 temperature -1.1

setstate crashtest2 2022-02-10 08:23:07 absHumidity 7.6
setstate crashtest2 2022-02-10 08:23:17 humidity 38
setstate crashtest2 2022-02-10 08:22:47 temperature 5.1


InfluxDBLogger - der klappt:
defmod myTestInflux InfluxDBLogger http://myinfluxdb:8086 fhem_db crashtest.*


klappt nicht:

defmod myTestInflux InfluxDBLogger http://myinfluxdb:8086 fhem_db .*:(temperature|humidity|absHumidity).*
defmod myTestInflux InfluxDBLogger http://myinfluxdb:8086 fhem_db .*:temperature.*
defmod myTestInflux InfluxDBLogger http://myinfluxdb:8086 fhem_db .*temperature.*


klappt teilweise:

http://myinfluxdb:8086 fhem_db r:temperature=..*,r:humidity=..*

die Readings werden erfasst, aber auch welche, die dort NICHT stehen (absHumidity)

nicht nachmachen
Beim Rumstochern bin ich vom rechten Weg abgekommen und dem bösen Wolf begegnet  :o :
Habe mich am "list" orientiert, weil dort ebenfalls devspec greift. Ein "list .* temperature" bringt z.B. beide Dummies. Im InfluxDBlogger ist das Leerzeichen ja nicht vorgesehen, also versuchte ich dies:
http://myinfluxdb:8086 fhem_db (.* temperature)
FHEM verabschiedet sich dann sofort mit einem Gruß im LOG und startet neu

2022.02.10 09:00:03.459 3: FHEMWEB WEB CSRF error: csrf_blabla ne csrf_blablabla for client WEB_balblaip / command modify myTestInflux http://myinfluxdb:8086 fhem_db (.* temperature). For details see the csrfToken FHEMWEB attribute.
Unmatched ( in regex; marked by <-- HERE in m/( <-- HERE .*/ at ./FHEM/93_InfluxDBLogger.pm line 42.


Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 10 Februar 2022, 10:12:30
Hallo Rob,

bei der DevSpec handelt es sich um eine Einschränkung auf Devices und nicht auf Readings. Dafür gibt es die Attribute ReadingInclude bzw. ReadingExclude.
Siehe hierzu auch die Doku.https://fhem.de/commandref_DE.html#devspec (https://fhem.de/commandref_DE.html#devspec)

Ich kann nur jedem raten, nicht zu sehr zu versuchen zu viel über einen InfluxDBLogger zu loggen. Das hat außer Bequemlichkeit keinerlei Vorteile - im Gegenteil die Konfiguration wird nur komplizierter. Effizienzgewinne oder so gibt es nicht.
Bei mir laufen produktiv acht InfluxDBLogger.

Viele Grüße

Tim
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: rob am 10 Februar 2022, 14:38:23
Hi Tim.

Vielen Dank für Deine flinke Rückmeldung. Das deckt sich auch mit meinen Experimenten :) Dann denk ich ist es mir klar, wie das soll bzw. was erlaubt ist.
So richtig viel Krams loggen möchte ich auch nicht. Überwiegend Umweltsensorik á la Temp/ Hum. Via event-on-change-reading schränke ich zusätzlich stark ein.

@kadettilac89: Wie hast Du das hinbekommen? Nutzt Du etwas anderes als den InfluxDBLogger?

VG
rob
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: msome am 12 Februar 2022, 13:08:49
Zitat von: timmib am 09 Februar 2022, 11:17:23
Eigentlich sollte er 6.103515625e-05 als numeric erkennen. Ich bin bisher nur von großen 'E' ausgegangen. Füge mal das kleine "e" in Zeile 375 in die RegEx ein, ob Influx damit leben kann.
^[0-9,.eE-]+$

Hi Tim, vielen Dank für den Korrekturvorschlag.
Die veränderte RegEx läuft bei mir seit Dienstag und funktioniert einwandfrei.
Es werden alle Werte eingefügt; kein Drop, keine Fehlermeldungen mehr.  :)
Gruß, Matthias
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: bartpl am 17 Februar 2022, 09:09:14
Ich habe eine Frage - kann dieser Modul auch non-numerische Werte ins Influx schicken? Influx2 unterstützt solche ohne Probleme... Mir würde konkret um die aus statistics Modul gehen, stat.*Last readings. Diese würde ich dann in Influx2 mittels tasks ins separate values trennen... Will keine extra readings in Fhem bei jeden Device schrauben müssen... aktuell sehe ich, das allein die readings ins influx gepackt werden, die numerisch sind.
Wäre so eine Änderung technisch schwierig?
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: Weisswurstverkäufer am 17 Februar 2022, 09:16:41
Zitat von: bartpl am 17 Februar 2022, 09:09:14
Ich habe eine Frage - kann dieser Modul auch non-numerische Werte ins Influx schicken? Influx2 unterstützt solche ohne Probleme... Mir würde konkret um die aus statistics Modul gehen, stat.*Last readings. Diese würde ich dann in Influx2 mittels tasks ins separate values trennen... Will keine extra readings in Fhem bei jeden Device schrauben müssen... aktuell sehe ich, das allein die readings ins influx gepackt werden, die numerisch sind.
Wäre so eine Änderung technisch schwierig?

Siehe

Zitat von: timmib am 04 Februar 2022, 17:26:26
Hi,

schaut euch mal die neue BETA-Version an.

Diese kann nun Strings (Danke an msome) UND originale Zeitstempel

Bitte beides inklusive Doku testen und zurückmelden, damit ich das nach SVN schieben kann.

Viele Grüße

Tim

(Ist mittlerweile keine Beta mehr)
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: bartpl am 17 Februar 2022, 10:03:08
Danke! da bin ich zeitlich sehr gut gekommen, das scheint eine extrem frische Sache zu sein :) Vielen Dank!

bzg. des Problem, das values die zuerst als int in influx angelegt werden, später zur string schwehr konwertierbar sind... Es gibt readings, die eigentlich strings sind, können aber ab und zu nur zahlen beinhalten und als int misinterpretiert werden... Wäre es nicht gut für das stringValuesAllowed noch ein extra Wert 2 implementieren, so das auch integer als strings abgeschickt werden? Dann wäre das Problem weg, jeder könnte für sich entscheiten ob er strings oder zahlen haben muss und es würde erzwungen werden...

Ich fange an die tests...
Ps. wo finde ich das Modul in irgend ein Repo?
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: meier81 am 17 Februar 2022, 18:57:41
Zitat von: bartpl am 17 Februar 2022, 10:03:08
Ps. wo finde ich das Modul in irgend ein Repo?

Die kommt automatisch wenn du ein update von fhem machst, einfach oben in die Leiste update eingeben und bestätigen, anschließend fhem neustarten mit shutdown+restart

Gruß
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: bartpl am 18 Februar 2022, 08:27:00
ok, super. ich dachte nur das es noch in Beta war und noch nicht in main stream. Danke!
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: kennymc.c am 20 Februar 2022, 16:46:42
Ich bin gerade dabei Daten von einer mySQL Datenbank auf Influxdb mit API v2 zu übertragen. Dazu habe ich das im Wiki verlinkte Skript von kadettilac89 etwas angepasst. Auf meinem Rechner selbst scheint das schreiben von Testdaten auch gut zu funktionieren aber wenn ich es im Fhem Docker Container ausführe, bekomme ich eine Zertifikatswarnung für Influxdb (Code 500), obwohl ich die Überprüfung absichtlich deaktiviert habe. Außerdem bekomme ich für Zeile 31 einen Error. Eventuell hat ja schon jemand selbst ein mit der API v2 kompatibles Skript gebaut. Ich habe meinen Versuch mal angehangen auch wenn ich mich nicht wirklich mit Perl auskenne und mich da eher an anderen Beispielen orientiert habe.

Außerdem tauchen immer wieder failed und dropped writes im Modul auf. Leider bekomme ich auch mit verbose 5 keine wirklich Infos dazu:

2022.02.20 17:03:42.777 4: InfluxDBLogger: [InfluxDB] notified from device SZ_xRouter
2022.02.20 17:03:42.777 4: InfluxDBLogger: [InfluxDB] notified from device SZ_xRouter about linkquality: 47
2022.02.20 17:03:42.779 5: InfluxDBLogger: [InfluxDB] set ?
2022.02.20 17:03:42.779 5: InfluxDBLogger: [InfluxDB] set ?
2022.02.20 17:03:42.779 4: InfluxDBLogger [InfluxDB] - Read token from file
2022.02.20 17:03:42.780 4: InfluxDBLogger: [InfluxDB] Sending data linkquality,site_name=SZ_xRouter value=47
to https://192.168.1.201:8087/api/v2/write?org=%2d&bucket=fhem
2022.02.20 17:03:42.788 1: InfluxDBLogger: [InfluxDB] Error = 
2022.02.20 17:03:42.790 5: InfluxDBLogger: [InfluxDB] set ?
2022.02.20 17:03:42.790 5: InfluxDBLogger: [InfluxDB] set ?
2022.02.20 17:03:42.791 5: InfluxDBLogger: [InfluxDB] set ?
2022.02.20 17:03:42.791 5: InfluxDBLogger: [InfluxDB] set ?
2022.02.20 17:03:42.791 1: InfluxDBLogger: [InfluxDB] Error = Statistics: t=11813 s=11729 f=166 e=12318
2022.02.20 17:03:42.792 5: InfluxDBLogger: [InfluxDB] set ?
2022.02.20 17:03:42.793 5: InfluxDBLogger: [InfluxDB] set ?
2022.02.20 17:03:42.793 5: InfluxDBLogger: [InfluxDB] set ?
2022.02.20 17:03:42.794 5: InfluxDBLogger: [InfluxDB] set ?
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: kennymc.c am 15 Mai 2022, 19:13:47
Schade, dass auch knapp 3 Monate später niemand die Error Log Meldungen erklären kann. Ich weiß immer noch nicht, wo der Fehler liegt, da das Modul einfach keine Infos ausgibt bei welchen Device(s) der Fehler auftritt.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: topa_LE am 16 Mai 2022, 16:51:52
Bin mir nicht sicher, ob der Entwickler für die Influx 2.0 das Modul weiterentwickelt oder getestet hat. M.E. nutzt er (wie auch ich) die V1.8 , also die api v1 als Attribut.

Schonmal damit probiert?

Aber auch ich bekomme meine Sonoff Plug Devices auch nicht 100% ans laufen. Zumindest in der InfluxDB ne ordentliche Struktur reinzubekommen.

Ob nun die attr fields, tags oder doch measurement besser sind, bin ich nicht schlüssig. Scheinbar gibt es ja mehrere Ansätze durch die damalige Weiterentwicklung.


Um grundsätzlich auch non numerisch zu loggen, ist das Attr stringValuesAllowed zu nutzen, besten Dank an Tim!

Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: kennymc.c am 16 Mai 2022, 17:25:52
Zitat von: topa_LE am 16 Mai 2022, 16:51:52
Bin mir nicht sicher, ob der Entwickler für die Influx 2.0 das Modul weiterentwickelt oder getestet hat. M.E. nutzt er (wie auch ich) die V1.8 , also die api v1 als Attribut.

Schonmal damit probiert?

Hab eigentlich erst vor kurzem alles bei mir auf v2 umgestellt und würde nur ungern wieder zurück. Zudem unterstützt das Modul ja offiziell die v2 API. Dann sollte die auch supported werden oder ein Hinweis in der Commandref ergänzt werden. Letztendlich sieht bei mir auch alles ok aus in den Graphen und ich erkenne auf den ersten Blick keine fehlenden Einträge. Aber da kann ich mich auch irren.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: topa_LE am 16 Mai 2022, 18:52:00
Zitat von: kennymc.c am 16 Mai 2022, 17:25:52
Hab eigentlich erst vor kurzem alles bei mir auf v2 umgestellt und würde nur ungern wieder zurück.

Leuchtet ein ;-) , dann müsste sich der Entwickler ggf. noch mal zu äußern.

Ich beende das nun auch hier erstmal, weil meine geloggten Werte nicht nach Wunsch in Grafana definiert werden können. Da müsste ich nun zu viel umcoden, was die NonNumerus Readings MQTT2 betrifft. Zuviel probiert und einfach den Überblick verloren, schade drum, weil das Modul ist gut!

Viel Erfolg für dich bei deiner Problembewältigung, ich kann da leider nicht helfen, da ich V2 nicht nutze.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: UdoR am 25 Mai 2022, 21:26:20
Hallo zusammen,

ich bekomme folgende Fehlermeldung:
2022.05.25 20:48:07 1: InfluxDBLogger: [influxDB] Error = unable to parse 'subnetMask,site_name=MQTT2_Schaukasten value=255.255.255.0 1653504486000000000': invalid number

die Ursache liegt offenbar in Zeile 375:
$map->{$deviceName}->{$readingName}->{"numeric"} = $readingValue =~ /^[0-9,.E-]+$/;

Hier wird nicht abgefangen, dass mehrere Punkte zu einer ungültigen Zahl führen. Daher folgende Korrektur des regulären Ausdrucks:
$map->{$deviceName}->{$readingName}->{"numeric"} = $readingValue =~ /^[-+]?[0-9]*[\.\,]?[0-9]+([eE][-+]?[0-9]+)?$/;


Gruß Udo
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: m-d-ley am 02 Juni 2022, 14:36:32
Hallo,
ist es irgendwie möglich einen eigenen Timestamp zu übergeben? Meine Idee ist es einen Dummy mit Setreading händisch zu füttern. Im Setreading würde ich den Timestamp mit angeben, allerdings übermittelt Influxdblogger natürlich den aktuellen Timestamp. Hat da jemand eine Idee?

Danke und Lg
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: Weisswurstverkäufer am 02 Juni 2022, 14:40:06
Zitat von: m-d-ley am 02 Juni 2022, 14:36:32
Hallo,
ist es irgendwie möglich einen eigenen Timestamp zu übergeben? Meine Idee ist es einen Dummy mit Setreading händisch zu füttern. Im Setreading würde ich den Timestamp mit angeben, allerdings übermittelt Influxdblogger natürlich den aktuellen Timestamp. Hat da jemand eine Idee?

Danke und Lg

Das sollte sein was Du suchst, oder?

ZitatreadingTimeStamps attr <name> readingTimeStamps [0|1]
If enabled(1) the ReadingTimestamp from FHEM is send to InfluxDB, Default is off(0). This is useful for devices that publish the values later with the original timestamp delayed. Default: 0 (InfluxDB determines the timestamp on its own)
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: JooNey am 27 Juli 2022, 18:50:15
Hallöchen zusammen,

ich würde auch gern meine Daten loggen, habe bei mir zu Hause aber eine KairosDB mit Cassandra laufen - deshalb einfach nur kurz die Frage, ob es mit den aktuellen Konfigurationsmöglichkeiten dieses Bausteins auch möglich ist an die KairosDB (statt an eine InfluxDB) zu loggen? (Für den interessierten Leser, hier die Info, wie man Datenpunkte hinzufügt: https://kairosdb.github.io/docs/restapi/AddDataPoints.html )

Falls es grundsätzlich möglich ist, würde ich mich tiefer in die Konfiguration des Moduls einlesen, falls nicht, wäre die Frage, ob es möglich wäre das Modul etwas anzupassen, sodass man evtl. auch auf die KairosDB loggen kann!?

Danke.

Beste Grüße
JooNey
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: JooNey am 30 Juli 2022, 09:56:26
Moin,

also ich habe jetzt mal ne InfluxDB aufgesetzt, und versuche da meine KNX-Daten reinzuschreiben, aber irgendwie mag es nicht wirklich klappen. Es kommen vereinzelte Werte an, aber nicht das, was ich haben will, also keine Temperaturen der Sensoren oder Prozente der Rollos z.B. Und auch von den Licht/Taster/Schalter Stati kommt nicht wirklich was.

Nachdem ich versucht habe über "$READINGNAME=$READINGVALUE" im influxDB dev sowie "attr event-on-change-reading state" bei den sendenden Devices zu verwenden, waren die meisten Fehler weg, dafür werden die Werte eigentlich alle gedropped.

Woran liegt das, was kann ich anders machen?

Hier mal das influxDB Device:
Internals:
   CFGFN     
   DATABASE   KNX
   DEF        http://192.168.11.31:8086 KNX
   FUUID      62e26d73-f33f-098d-2709-86d9079aa6f283ed
   NAME       influxDB
   NOTIFYDEV 
   NR         940
   NTFY_ORDER 50-influxDB
   STATE      Statistics: t=1789 s=666 f=1123 e=2175
   TYPE       InfluxDBLogger
   URL        http://192.168.11.31:8086
   eventCount 10892
   passwd     saved
   READINGS:
     2022-07-30 09:54:07   dropped_writes  6634
     2022-07-30 09:54:07   dropped_writes_last_message KNX_0301022 state 26.40 °C
     2022-07-29 22:13:02   failed_writes   1123
     2022-07-29 22:13:02   failed_writes_last_error unable to parse 'knx_S_Keller_Aussen,device=knx_S_Keller_Aussen last-sender=1.0.2,state=1,steuern-get=1': invalid number
     2022-07-30 09:50:00   state           Statistics: t=1789 s=666 f=1123 e=2175
     2022-07-30 09:50:00   succeeded_writes 666
     2022-07-30 09:50:00   total_events    2175
     2022-07-30 09:50:00   total_writes    1789
Attributes:
   api        v2
   conversions closed=0,open=1,tilted=2,false|off|no=0,true|on|yes=1
   fields     $READINGNAME=$READINGVALUE
   measurement $DEVICE
   org        JooNey
   readingInclude state
   room       InfluxDB
   tags       device={my $str = AttrVal($device,"alias",$device); $str =~ s/\s/_/g; return $str;}
   username   KNX
   verbose    5


Hoffe, ihr habt weiterführende Ideen.

Danke und Grüße
JooNey

P.S.: Wo finde ich eigentlich das InfluxDBLogger Device Logfile?
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: meier81 am 30 Juli 2022, 11:59:04
Hallo JooNey,

kannst du uns mal zeigen wie der state der Devices die du loggen willst aussieht, ich denke fast das hier schon das Problem sein könnte.

Anbei hab ich dir mal eine meiner Definitionen der InfluxDB Config angehängt:


Internals:
   DATABASE   Energie
   DEF        http://127.0.0.1:8086 Energie KG_hr_SZ_Haus,KG_hr_GZ_Haus,KG_wr_SD_Trockner,KG_wr_SD_Waschmaschine,KG_mr_SD_Entfeuchter
   FUUID      6175af97-f33f-1612-4877-6bd3d9deb3a58d17
   FVERSION   93_InfluxDBLogger.pm:0.256500/2022-02-07
   NAME       NN_xx_SW_InfluxDB_Energie
   NOTIFYDEV  KG_hr_SZ_Haus,KG_hr_GZ_Haus,KG_wr_SD_Trockner,KG_wr_SD_Waschmaschine,KG_mr_SD_Entfeuchter
   NR         92
   NTFY_ORDER 50-NN_xx_SW_InfluxDB_Energie
   STATE      Statistics: t=242052 s=242031 f=21 e=302459
   TYPE       InfluxDBLogger
   URL        http://127.0.0.1:8086
   eventCount 1950
   READINGS:
     2022-05-15 21:39:55   dropped_writes  0
     2022-05-15 21:39:55   dropped_writes_last_message <none>
     2022-07-30 11:49:02   state           Statistics: t=242052 s=242031 f=21 e=302459
     2022-07-30 11:49:02   succeeded_writes 242031
     2022-07-30 11:49:01   total_events    302459
     2022-07-30 11:49:01   total_writes    242052
Attributes:
   alias      InfluxDB Energie
   api        v2
   conversions closed=0,open=1,tilted=2,false|off|no=0,true|on|yes=1
   deviceTagName device_name
   icon       time_note
   org        privat
   readingExclude (ENERGY_ApparentPower|ENERGY_ReactivePower):.*
   readingInclude (Power_.*__kW|ENERGY_Power|Energy_total_T1__kWh|GAS_ENERGY_COUNTER):.*
   security   token


Ich logge bei mir halt nicht den state sondern readings der Devices, meistens ist der state ja aus mehreren Werten und Texten zusammengesetzt, das wird hier beim loggen zu Problemen führen.
Probiere es vielleicht auch mal mit einem reading des Device od das funktioniert.

Gruß

Markus
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: JooNey am 30 Juli 2022, 14:22:38
Hey Markus,

das reading heißt "state". :)

Siehe hier für einen der Temperaturfühler:

Internals:
   DEF        3/1/82:dpt9.001
   DEVNAME    KNX_0301082
   FIRSTGADNAME g1
   FUUID      602fd431-f33f-098d-cb62-9f3329bb1ec5c38d
   GETSTRING  g1:noArg
   IODev      KNX
   KNX_MSGCNT 44645
   KNX_RAWMSG C01215w031520cc9
   KNX_TIME   2022-07-30 14:19:44
   LASTInputDev KNX
   MSGCNT     44645
   NAME       KNX_0301082
   NR         27
   SETSTRING  g1:slider,-274,6710,670760
   STATE      24.50 °C
   TYPE       KNX
   eventCount 44594
   model      dpt9
   GADDETAILS:
     g1:
       CODE       03152
       GROUP      3/1/82
       MODEL      dpt9.001
       NO         1
       OPTION     
       RDNAMEGET  getG1
       RDNAMEPUT  putG1
       RDNAMESET  setG1
       SETLIST    :slider,-274,6710,670760
   GADTABLE:
     03152      g1
   READINGS:
     2022-07-28 23:34:00   IODev           KNX
     2022-07-30 14:19:44   getG1           24.50 °C
     2022-07-30 14:19:44   last-sender     1.2.21
     2022-07-30 14:19:44   state           24.50 °C
Attributes:
   IODev      KNX
   event-on-change-reading state
   event-on-update-reading state
   group      EG
   room       KNX_3_Heizung


Dazu gibt es dann noch den STATE als internal, das stimmt. Der bringt mir dann vermutlich die Fehler bei den devices, bei denen das alles in diesen STATE kommt.

Beste Grüße
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: meier81 am 30 Juli 2022, 20:41:38
Ich glaube dein Problem ist das im state 24.50 °C steht, das loggt influxdb standard nicht und dropped es da es keine reine Zahl ist sondern eine Zeichenkette. Du kannst zwar das Attribut STRINGVALUESALLOWED setzen dann loggt er auch Zeichenketten, ob du die dann aber so toll auslesen bzw. benutzen kannst aus der influxdb weiß ich nicht.

Hast du nicht mal ein Device wo du ein reading hast mit einer reinen Zahl, meine Fühler sehen z.B. so aus:

Internals:
   DEF        000E9A498E8582:1
   FUUID      617b9334-f33f-1612-79e9-e81f1c3dc33ffd5e
   FVERSION   88_HMCCUCHN.pm:v5.0.0-s25675/2022-02-13
   IODev      NN_xx_SW_debmatic
   NAME       EG_ku_TF_Raum
   NR         126
   STATE      24.1
   TYPE       HMCCUCHN
   ccuaddr    000E9A498E8582:1
   ccudevstate active
   ccuif      HmIP-RF
   ccuname    HmIP-STHD 000E9A498E8582:1
   ccurolectrl HEATING_CLIMATECONTROL_TRANSCEIVER
   ccurolestate HEATING_CLIMATECONTROL_TRANSCEIVER
   ccusubtype STHD
   ccutype    HmIP-STHD
   eventCount 22
   firmware   2.6.0
   readonly   no
   READINGS:
     2022-07-30 19:31:19   ACTIVE_PROFILE  1
     2022-07-30 19:31:19   ACTUAL_TEMPERATURE 24.1
     2022-07-30 19:31:19   ACTUAL_TEMPERATURE_STATUS NORMAL
     2022-07-30 19:31:19   BOOST_MODE      false
     2022-07-30 19:31:19   BOOST_TIME      0
     2022-07-30 19:31:19   FROST_PROTECTION false
     2022-07-30 19:31:19   HEATING_COOLING HEATING
     2022-07-30 19:31:19   HUMIDITY        56
     2022-07-30 19:31:19   HUMIDITY_STATUS NORMAL
     2022-07-30 08:09:32   IODev           NN_xx_SW_debmatic
     2022-07-30 19:31:19   PARTY_MODE      false
     2022-07-30 08:09:48   PARTY_SET_POINT_TEMPERATURE 0.0
     2022-07-30 08:09:48   PARTY_TIME_END 
     2022-07-30 08:09:48   PARTY_TIME_START
     2022-07-30 19:31:19   QUICK_VETO_TIME 0
     2022-07-30 19:31:19   SET_POINT_MODE  auto
     2022-07-30 19:31:19   SET_POINT_TEMPERATURE 21.0
     2022-07-30 19:31:19   SWITCH_POINT_OCCURED false
     2022-07-30 19:31:19   WINDOW_STATE    closed
     2022-07-30 19:31:20   absoluteHumidity 12.2
     2022-07-30 19:31:20   activity        alive
     2022-07-30 19:31:20   battery         ok
     2022-07-30 19:31:19   control         21.0
     2022-07-30 19:31:19   desired-temp    21.0
     2022-07-30 19:31:20   devstate        ok
     2022-07-30 19:31:20   dewpoint        14.8
     2022-07-30 19:31:20   hmstate         24.1
     2022-07-30 19:31:19   humidity        56
     2022-07-30 19:31:19   measured-temp   24.1
     2022-07-30 19:31:20   rssidevice      -54
     2022-07-30 08:09:48   rssipeer        -68
     2022-07-30 19:31:19   state           24.1
     2022-07-30 19:31:19   temperature     24.1
     2022-07-30 19:31:20   voltage         2.8


Da siehst du ja bei den readings stehen immer nur Werte, ohne Einheit.

Gruß Markus

Ach, habe ich auch eben gesehen du hast die Attribute
event-on-change-reading state
event-on-update-reading state


beide gleichzeitig gesetzt, wenn du keines der beiden setzt verhält es sich standard wie event-on-update-reading, d.h. jedes Mal wenn das reading aktualisiert wird (auch wenn sich der Wert nicht geändert hat) wird getriggert, also in die influxdb geloggt. Mit dem Attribut event-on-change-reading wird nur getriggert wenn sich der Wert geändert hat, ansonsten erfolgt kein Eintrag in die influxdb. Wenn du beide Attribute gleichzeitig setzt und das auch auf das gleiche reading ist event-on-update-reading das höher wirkende Attribut und überstimmt event-on-change-reading. Das heißt du kannst in den Fall beide Attribute auch weglassen. Beide Attribute zusammen machen nur Sinn wenn du z.B. event-on-change-reading .* setzt und dann event-on-update-reading state, dann werden alle readings nur auf Änderung getriggert bis auf das reading state, das wird bei Aktualisierung getriggert.

Und nochwas: du musst bei READINGINCLUDE dann state:.* und nicht nur state angeben, siehe commandref:

READINGINCLUDE attr <name> readingInclude <regex>
Nur Ereignisse die zutreffen werden geschrieben. Hinweis - das Format eines Ereignisses sieht so aus: 'state: on'


Aber wie gesagt da steht bei dir dann auch noch das °C drin, das gibt dann weiterhin Probleme.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: JooNey am 31 Juli 2022, 13:13:58
Hey meier81,

danke für den Hinweis. Kann ich denn ein Reading generieren, bei dem die Einheit nicht mit angegeben wird? (edit: lese gerade den Wiki Eintrag zu userreadings.) Ich gehe mal davon aus, das kommt aus der Definition der KNX Gruppenadressen.

Bzw. einfacher wäre ja, wenn ich das Readinginclude so matchen könnte, dass er die Einheiten einfach weglässt. Aber da weiß ich nicht, wie das Matching funktioniert. Nach normalen RegExp könnte ich ja sowas hier angeben, und würde die Zahlen als Ergebnis bekommen:
state:.(\d+(?:[\.\,]\d{1,2})?)[A-Za-z° ]*

Ginge das hier auch? Dann hätte ich ja mit ner ordentlich angelegten Expression alles erschlagen.

Beste Grüße
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: JooNey am 31 Juli 2022, 15:43:38
Ok, kurz mal was ausprobiert:

attr KNX_0301082 userReadings fTemp:state:.* { ReadingsNum("KNX_0301082","state",0) }

um ein userReading zu erzeugen, welches dann die Temperatur ohne Einheiten hat, und beim influxDB "readingInclude fTemp:.*" gesetzt. Scheint aber auch nicht zu klappen. Es steht zwar im Log, dass influxDB notified wird, aber es kommt rein gar nix mehr durch. Vermutlich "sieht" er fTemp nicht. *seufz*
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: meier81 am 31 Juli 2022, 16:15:11
Zitat von: JooNey am 31 Juli 2022, 13:13:58
Hey meier81,

danke für den Hinweis. Kann ich denn ein Reading generieren, bei dem die Einheit nicht mit angegeben wird? (edit: lese gerade den Wiki Eintrag zu userreadings.) Ich gehe mal davon aus, das kommt aus der Definition der KNX Gruppenadressen.

Bzw. einfacher wäre ja, wenn ich das Readinginclude so matchen könnte, dass er die Einheiten einfach weglässt. Aber da weiß ich nicht, wie das Matching funktioniert. Nach normalen RegExp könnte ich ja sowas hier angeben, und würde die Zahlen als Ergebnis bekommen:
state:.(\d+(?:[\.\,]\d{1,2})?)[A-Za-z° ]*

Ginge das hier auch? Dann hätte ich ja mit ner ordentlich angelegten Expression alles erschlagen.

Beste Grüße

Da bin ich leider auch der falsche Ansprechpartner, mit den regex Ausdrücken breche ich mir auch regelmäßig die Finger  :)

Ich glaube ich habe eben auch noch einen Fehler bei deiner Definition entdeckt, du hast ja dein influxdb Device so definiert:

http://192.168.11.31:8086 KNX

Da fehlt aber das Device noch, muss ja define <name> InfluxDBLogger [http|https]://IP_or_Hostname:port dbname devspec definiert werden, das heißt bei dir fehlt die devspec.

Probiere mal die Definition bei dir so:

define influxDB InfluxDBLogger http://192.168.11.31:8086 KNX KNX.*
attr influxDB api v2
attr influxDB conversions closed=0,open=1,tilted=2,false|off|no=0,true|on|yes=1
attr influxDB org JooNey
attr influxDB readingInclude fTemp:.*
attr influxDB room InfluxDB
attr influxDB username KNX


Gruß Markus
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: JooNey am 31 Juli 2022, 17:32:59
Naja, wenn das "includeReading" nicht "matched", also den Ausdruck in den Klammern als Ergebnis nimmt, dann bringt das Beste RegEx nix. Das, was ich da geschrieben habe, würde normalerweise alles Matchen, was ne Zahl vorn hat, und dann hinten dran nix oder eine beliebige Zeichenkette inkl. °. Und dieser Wert müsste dann übergeben werden.

Der Fehler scheint aber viel subtiler. Die Definition der userReadings muss exakt auf das Leerzeichen passen, sonst passiert gar nichts. Ich habe das jetzt mehrfach ausprobiert, und festgestellt, dass wenn es nicht exakt so geschrieben wird wie hier, gar nix passiert:
attr KNX_0701002 userReadings KNX_value:getG1:.* {ReadingsNum($name,"getG1",2)}

Leerzeichen in den { } oder gar ; oder fehlendes Leerzeichen nach dem *, sorgt alles dafür, dass das userReading zwar "angelegt" wird, aber das eigentliche Reading niemals auftaucht. Warum? Keine Ahnung, aber nachdem ich es so gemacht habe, wird die influxDB mit Werten gefüllt. Da ich gerade nix hab, was alle Sekunde da was reinschiebt, werde ich mal ein, zwei Tage warten. Temperaturen oder Schaltstati von Leuchten sind da ganz gut. Mal sehen, ob meine Wetterstation sich auch immer schön meldet. :)

Ich melde mich mit nem Update, wie gut es nun klappt.

Beste Grüße

P.S.: event-on-change-Reading habe ich erstmal rausgenommen - es sollen ja Werte in die DB fließen. Wenn das alles klappt, dann kann ich das einstellen.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: meier81 am 31 Juli 2022, 18:40:06
Zitat von: JooNey am 31 Juli 2022, 17:32:59
Leerzeichen in den { } oder gar ; oder fehlendes Leerzeichen nach dem *, sorgt alles dafür, dass das userReading zwar "angelegt" wird, aber das eigentliche Reading niemals auftaucht.

Ja, das mit dem Leerzeichen nach dem Stern muss natürlich sein, das war ja aber in deinem Beispiel weiter oben richtig gewesen. Und im Perl-Ausdruck in den geschweiften Klammern darf kein Leerzeichen haben, das ging mir auch durch. Aber wenn´s jetzt passt ist ja super  ;)

Bin mal gespannt was du berichtest.

Gruß Markus
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: topa_LE am 22 September 2022, 10:56:18
Zitat von: UdoR am 25 Mai 2022, 21:26:20

Hier wird nicht abgefangen, dass mehrere Punkte zu einer ungültigen Zahl führen. Daher folgende Korrektur des regulären Ausdrucks:
$map->{$deviceName}->{$readingName}->{"numeric"} = $readingValue =~ /^[-+]?[0-9]*[\.\,]?[0-9]+([eE][-+]?[0-9]+)?$/;



Hatte ich auch schon gemerkt. Eventuell kann es der Entwickler im Modul anpassen.

Funktioniert so perfekt. :)
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: sash.sc am 29 September 2022, 10:53:16
Hallo zusammen.

Kann man bei einem Device auch nur ein bestimmtes Reading an den influxdblogger übergeben?
Standart werden ja alle Reading (die nummerischen) geloggt.

Gruß und danke
Sascha
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: meier81 am 29 September 2022, 18:14:50
Zitat von: sash.sc am 29 September 2022, 10:53:16
Hallo zusammen.

Kann man bei einem Device auch nur ein bestimmtes Reading an den influxdblogger übergeben?
Standart werden ja alle Reading (die nummerischen) geloggt.

Gruß und danke
Sascha

Hallo Sascha,

ja das geht, ist recht einfach. Hier mal ein List eines meiner Influx-Devices:

Internals:
   DATABASE   Raumsensoren
   DEF        http://127.0.0.1:8086 Raumsensoren .*TF.*
   FUUID      6175b067-f33f-1612-1364-97a8be91be2e0b14
   FVERSION   93_InfluxDBLogger.pm:0.256500/2022-02-07
   NAME       NN_xx_SW_InfluxDB_Raumsensoren
   NOTIFYDEV  .*TF.*
   NR         94
   NTFY_ORDER 50-NN_xx_SW_InfluxDB_Raumsensoren
   STATE      Statistics: t=36710 s=36673 f=37 e=122564
   TYPE       InfluxDBLogger
   URL        http://127.0.0.1:8086
   eventCount 2067
   READINGS:
     2022-05-15 21:39:43   dropped_writes  0
     2022-05-15 21:39:43   dropped_writes_last_message <none>
     2022-09-17 00:00:04   failed_writes   37
     2022-09-17 00:00:04   failed_writes_last_error read from http://127.0.0.1:8086 timed out
     2022-09-29 18:09:15   state           Statistics: t=36710 s=36673 f=37 e=122564
     2022-09-29 18:09:15   succeeded_writes 36673
     2022-09-29 18:09:15   total_events    122564
     2022-09-29 18:09:15   total_writes    36710
Attributes:
   alias      InfluxDB Raumsensoren
   api        v2
   conversions closed=0,open=1,tilted=2,false|off|no=0,true|on|yes=1
   deviceTagName device_name
   icon       time_note
   org        privat
   readingInclude (temperature|humidity|dewpoint|absoluteHumidity):.*
   security   token


Du machst bei "DEF" ja die Einschränkung der Devices und mit den Attributen readingInclude bzw. ReadingExclude gibst du die Readingnamen mit die geloggt bzw. nicht geloggt werden sollen. Wichtig ist hier aber die Schreibweise (readingname):.*, sonst geht´s nicht.

Gruß Markus
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: sash.sc am 29 September 2022, 20:00:05
Readingsinclude im influxdb logger oder in den devices?
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: meier81 am 29 September 2022, 21:44:36
Zitat von: sash.sc am 29 September 2022, 20:00:05
Readingsinclude im influxdb logger oder in den devices?

Im influxdb Device. Hier das Attribut "readingInclude" nutzen (siehe mein List meines Influx Devices).
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: sash.sc am 30 September 2022, 20:25:06
Also wäre es sinnvoll evtl. mehrere Definitionen bzw Instanzen vom Influxdblogger zu definieren? Um eine Übersicht zu behalten. Sonst, denke ich, wird es schnell unübersichtlich.

gruß
Sascha
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: meier81 am 30 September 2022, 20:42:14
Zitat von: sash.sc am 30 September 2022, 20:25:06
Also wäre es sinnvoll evtl. mehrere Definitionen bzw Instanzen vom Influxdblogger zu definieren? Um eine Übersicht zu behalten. Sonst, denke ich, wird es schnell unübersichtlich.

gruß
Sascha

Hi Sascha,

so habe ich es zumindest mal gemacht. Dann hast du auch mehrere Influx-Datenbanken, dann hat man hier z.B. die Möglichkeit unterschiedliche retention policy einzustellen.

Ich hab bei mir zur Zeit 5 verschiedene influx Instanzen, läuft alles super.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: sash.sc am 30 September 2022, 21:17:05
Ich meine mehrere Definition in fhem die in eine Datenbank schreiben
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: meier81 am 30 September 2022, 21:22:00
Ob das funktioniert kann ich dir gar nicht sagen, könnte sein das die sich beim schreiben gegenseitig hindern.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: pitre am 12 Januar 2023, 20:39:53
Sehr cooles Modul! Erstmal Danke für die ganze Mühe.

Ich bin gerade dabei von FileLog umzustellen und hatte dort das Attribut "accepted range" 1:2000, weil selten auch "0" daherkommt und das haut die Grafik dann zusammen. - Kann ich so eine Ausgrenzung von Daten auch bei InfluxDBLogger definieren?

Danke für die Hilfe!
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 10 Februar 2023, 09:09:47
Zitat von: sash.sc am 30 September 2022, 20:25:06
Also wäre es sinnvoll evtl. mehrere Definitionen bzw Instanzen vom Influxdblogger zu definieren? Um eine Übersicht zu behalten. Sonst, denke ich, wird es schnell unübersichtlich.

gruß
Sascha

Ja unbedingt. So ist es gedacht. Ich selber habe 11 InfluxDBLogger Devices um Ordnung zu halten.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 10 Februar 2023, 09:14:10
Zitat von: topa_LE am 22 September 2022, 10:56:18
Hatte ich auch schon gemerkt. Eventuell kann es der Entwickler im Modul anpassen.

Funktioniert so perfekt. :)

Ja, schau ich mir am Wochenende an.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 10 Februar 2023, 09:16:07
Zitat von: pitre am 12 Januar 2023, 20:39:53
Sehr cooles Modul! Erstmal Danke für die ganze Mühe.

Ich bin gerade dabei von FileLog umzustellen und hatte dort das Attribut "accepted range" 1:2000, weil selten auch "0" daherkommt und das haut die Grafik dann zusammen. - Kann ich so eine Ausgrenzung von Daten auch bei InfluxDBLogger definieren?

Danke für die Hilfe!


Ja, ich würde es mit
readingExclude machen, da dort ja bespezifische Reading-Wer Paare ausgefiltert werden können.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 10 Februar 2023, 09:22:57
Übrigens sorry, dass ich erst jetzt reagiere. Habe die Forum Benachrichtigungen wohl falsch eingestellt.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 10 Februar 2023, 09:32:58
Zitat von: kennymc.c am 15 Mai 2022, 19:13:47
Schade, dass auch knapp 3 Monate später niemand die Error Log Meldungen erklären kann. Ich weiß immer noch nicht, wo der Fehler liegt, da das Modul einfach keine Infos ausgibt bei welchen Device(s) der Fehler auftritt.

Hi,

mir ist nicht ganz klar ob es hier um das Skript geht oder das Modul. Scheinbar beides. Ich nutzte selber (leider) selber immer noch nicht InfluxDB 2. Was ist denn genau das Problem?

Viele Grüße

Tim
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: Matthias182 am 10 Februar 2023, 16:27:10
Hallo zusammen,

ich habe das Modul schon eine Weile bei mir im Gebrauch und jetzt finde ich immer wieder diese Meldungen bei im Log:


2023.02.10 16:25:11 1: InfluxDBLogger: [InfluxDB] Error = 400 Bad Request
2023.02.10 16:25:12 1: PERL WARNING: Use of uninitialized value $readingValue in pattern match (m//) at ./FHEM/93_InfluxDBLogger.pm line 375.
2023.02.10 16:25:12 1: PERL WARNING: Use of uninitialized value $value in concatenation (.) or string at ./FHEM/93_InfluxDBLogger.pm line 230.


Könnt ihr mir ein wenig auf die Sprünge helfen? Ich habe nicht den Ansatz einer Idee wo ich anfangen könnte zu suchen.


Danke und Gruß
Matthias
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: kennymc.c am 10 Februar 2023, 19:51:08
Zitat von: timmib am 10 Februar 2023, 09:32:58
Hi,

mir ist nicht ganz klar ob es hier um das Skript geht oder das Modul. Scheinbar beides. Ich nutzte selber (leider) selber immer noch nicht InfluxDB 2. Was ist denn genau das Problem?

Viele Grüße

Tim

Es geht um beides.
Im Modul sind es die failed writes. Dropped writes hab ich mittlerweile keine mehr. Ohne irgendeine Fehlermeldung hinter Error kann ich nicht herausfinden woran es liegt.
Das Import Script habe ich seitdem nicht mehr ausprobiert aber vielleicht hat ja jemand anders eine Lösung zu dem Problem.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 11 Februar 2023, 21:36:41
Zitat von: UdoR am 25 Mai 2022, 21:26:20
Hallo zusammen,

ich bekomme folgende Fehlermeldung:
2022.05.25 20:48:07 1: InfluxDBLogger: [influxDB] Error = unable to parse 'subnetMask,site_name=MQTT2_Schaukasten value=255.255.255.0 1653504486000000000': invalid number

die Ursache liegt offenbar in Zeile 375:
$map->{$deviceName}->{$readingName}->{"numeric"} = $readingValue =~ /^[0-9,.E-]+$/;

Hier wird nicht abgefangen, dass mehrere Punkte zu einer ungültigen Zahl führen. Daher folgende Korrektur des regulären Ausdrucks:
$map->{$deviceName}->{$readingName}->{"numeric"} = $readingValue =~ /^[-+]?[0-9]*[\.\,]?[0-9]+([eE][-+]?[0-9]+)?$/;


Gruß Udo

Viele Dank an Udo. Ist jetzt in SVN.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 11 Februar 2023, 21:39:23
Zitat von: kennymc.c am 10 Februar 2023, 19:51:08
Es geht um beides.
Im Modul sind es die failed writes. Dropped writes hab ich mittlerweile keine mehr. Ohne irgendeine Fehlermeldung hinter Error kann ich nicht herausfinden woran es liegt.
Das Import Script habe ich seitdem nicht mehr ausprobiert aber vielleicht hat ja jemand anders eine Lösung zu dem Problem.

Was steht denn in failed_writes_last_error?
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: kennymc.c am 12 Februar 2023, 12:50:56
Zitat von: timmib am 11 Februar 2023, 21:39:23
Was steht denn in failed_writes_last_error?

Da steht auch nichts drin, aktualisiert sich aber zeitgleich mit den Error Einträgen aus dem Log.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: Weisswurstverkäufer am 17 Februar 2023, 13:37:12
Hallo,

ich habe versucht mit dem Modul mein Nuki in die InfluxDB zu bringen um das in Grafana anzeigen zu können. Bisher hatte ich einfach doorsensorState:* und stateName:* und hatte dann dazu den Wert als String (z. B. door closed, locked, etc). Das hatte ich in Grafana in einer State-Timeline und sah eigentlich auch ganz cool aus.

Jetzt wollte ich aber mal einen Alert machen wenn die Tür länger als 5 Minuten offen steht. Dafür brauchte ich also den numerischen Wert. Das lässt sich ja leicht über die Conversions machen:

unknown=255,removed=240,uncalibrated=16,calibrating=5,door state unknown=4,door opened=3,door closed=2,deactivated=1,uncalibrated=0

Allerdings fehlt mir dann der Wert als Text für meine State Timeline. Das habe ich mir dann über als Tag mit reingeholt. Allerdings kann man die Tags nicht einbinden.

Meine Definition sieht jetzt so aus:


attr influxdb_nuki_doorsensorstate conversions unknown=255,removed=240,uncalibrated=16,calibrating=5,door state unknown=4,door opened=3,door closed=2,deactivated=1,uncalibrated=0
attr influxdb_nuki_doorsensorstate fields value=$READINGVALUE
attr influxdb_nuki_doorsensorstate measurement NukiDoorSensorState
attr influxdb_nuki_doorsensorstate readingInclude doorsensorState:.*
attr influxdb_nuki_doorsensorstate readingTimeStamps 1
attr influxdb_nuki_doorsensorstate room InfluxDB
attr influxdb_nuki_doorsensorstate tags site_name=$device,doorsensorState={my $str = ReadingsVal($device,"doorsensorState","-");;;; $str =~ s/\s/_/g;;;; return $str;;;;}


und dabei raus kommt

> select * from NukiDoorSensorState;
name: NukiDoorSensorState
time                 doorsensorState site_name           value
----                 --------------- ---------           -----
2023-02-17T12:20:10Z door_closed     NUKIDevice 2
2023-02-17T12:20:25Z door_closed     NUKIDevice 2
2023-02-17T12:20:55Z door_closed     NUKIDevice 2


Eigentlich hätte ich den "doorsensorState" aber lieber als zweites field (neben value) und am liebsten auch ohne die Unterstriche.

doorsensorState={my $str = ReadingsVal($device,"doorsensorState","-");;;; $str =~ s/\s/_/g;;;; return $str;;;;} in fields statt tags zu packen hat leider nicht funktioniert.

Kann man das so wie ich es will überhaupt umsetzen?

Edit: Das Mapping einfach in Grafana wieder andersrum zu machen geht (in meiner jetzigen Implementierung) übrigens nicht - weil sich der numerische State für Lock Status und Door Status überschneidet. Dann müsste ich 2 Panels machen was irgendwie auch blöd wäre.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 17 Februar 2023, 13:48:35
Hallo Weisswurstverkäufer,

ich würde
a) offenstehende Türen mit FHEM implementieren mit DOIF und dem Attribut "wait".
b) wenn man gerne nummerische Werte und den String haben möchte einfach einen zweiten InfluxDBLogger in Betracht ziehen. Damit sind die Werte zwar nicht im gleichem Measurement aber das ist ja nicht tragisch.
c) Mit userreadings in FHEM arbeiten, damit man das Reading doppelt hat.

Viele Grüße

Tim
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 17 Februar 2023, 13:50:29
Zitat von: Weisswurstverkäufer am 17 Februar 2023, 13:37:12
Allerdings kann man die Tags nicht einbinden.

Wo einbinden?
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: Weisswurstverkäufer am 17 Februar 2023, 14:30:15
Zitat von: timmib am 17 Februar 2023, 13:50:29
Wo einbinden?

In Grafana kann man im SELECT (wohl) keine Tags auswählen, nur fields.

Habe jetzt rausgefunden dass man meinen Anwendungsfall ganz einfach mit Telegraf machen kann (das setze ich eh schon ein). Das macht einfach einen API Call auf die Nuki Bridge und speichert das JSON in der InfluxDB. Jetzt habe ich sogar alle Werte in einem Measurement. Für meinen Anwendungsfall wohl die bessere Wahl :)

Trotzdem danke für die Hilfe!
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: rob am 03 März 2023, 09:09:18
Hallo Tim.

Die zwei Rückmeldungen zum Crash in https://forum.fhem.de/index.php/topic,114860.msg1163840.html#msg1163840 (https://forum.fhem.de/index.php/topic,114860.msg1163840.html#msg1163840) und https://forum.fhem.de/index.php/topic,114860.msg1167704.html#msg1167704 (https://forum.fhem.de/index.php/topic,114860.msg1167704.html#msg1167704) scheinen leider unter gegangen zu sein.

Das Problem besteht reproduzierbar leider schon noch. Einfach ein rename loslassen und mit Enter drücken ist FHEM weg
rename myTestInflux myTestInflux01

Im Log erscheint analog obigem Post:
Undefined subroutine &main::InfluxDBLogger_ReadPassword called at ./FHEM/93_InfluxDBLogger.pm line 612.

Magst Du bitte bei Gelegenheit schauen, ob sich das fixen lässt?

Vielen Dank und beste Grüße
rob
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 03 März 2023, 19:23:46
Hallo rob,

ja schau ich mir die Tage an.

Viele Grüße

Tim
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: cthil am 08 März 2023, 18:30:46
Funktioniert aktuell readingTimeStamps=1 nicht? Ich erhalte immer einen 400 Bad Request mit der InfluxDBv2 sobald ich das Attribut auf 1 setze.
Version ist $Id: 93_InfluxDBLogger.pm 27204 2023-02-11 20:33:46Z timmib $

Ok, der Grund war wohl recht einfach :) Ich habe precision=s gesetzt, im Modul wird der Timestamp aber hardcoded auf Nanosekunden umgerechnet (Zeile 200, $data .= " " . $timestamp ."000000000" # nanoseconds). Das sollte wohl auch in Abhängigkeit vom Attribut precision funktionieren. Wenn ich die 0er entferne übernimmt InfluxDB den vorgegebenen Zeitstempel (wahrscheinlich auch wenn ich das Attribut precision auf ns umstelle -> funktioniert auch).

Heißt, aktuell funktioniert readingTimeStamps=1 nur ohne die Angabe von precision oder mit precision=ns.

Die Umrechnung in Abhängigkeit von precision wäre noch eine sinnvolle Erweiterung!
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: Ballaststoff am 10 März 2023, 09:04:22
Guten Morgen zusammen,

ich habe eben erst gesehen, dass es hier einen eigenen Thread zum InfluxDBLogger gibt.

Ich hatte hier bereits mein Problem geschildert, sorry:
https://forum.fhem.de/index.php/topic,132629.0.html

Würde mich über einen Tipp freuen.

Danke und viele Grüße!
Philipp
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 18 März 2023, 15:46:46
Zitat von: cthil am 08 März 2023, 18:30:46
Funktioniert aktuell readingTimeStamps=1 nicht? Ich erhalte immer einen 400 Bad Request mit der InfluxDBv2 sobald ich das Attribut auf 1 setze.
Version ist $Id: 93_InfluxDBLogger.pm 27204 2023-02-11 20:33:46Z timmib $

Ok, der Grund war wohl recht einfach :) Ich habe precision=s gesetzt, im Modul wird der Timestamp aber hardcoded auf Nanosekunden umgerechnet (Zeile 200, $data .= " " . $timestamp ."000000000" # nanoseconds). Das sollte wohl auch in Abhängigkeit vom Attribut precision funktionieren. Wenn ich die 0er entferne übernimmt InfluxDB den vorgegebenen Zeitstempel (wahrscheinlich auch wenn ich das Attribut precision auf ns umstelle -> funktioniert auch).

Heißt, aktuell funktioniert readingTimeStamps=1 nur ohne die Angabe von precision oder mit precision=ns.

Die Umrechnung in Abhängigkeit von precision wäre noch eine sinnvolle Erweiterung!

Das mit der precision ist zur Zeit etwas krum. InfluxDB speichert intern ohnehin alles in nano-Sekunden. Die Angabe bezieht sich alleine auf das Format was übertragen wird und das ist zur Zeit immer nano-Sekunden was sinnlos mit Nullen aufgefüllt wird. Andererseits die Nullen weg lassen um zu sagen es sind Sekunden hilft auch keinem da der payload ziemlich der Gleiche ist. Aber das kann ich gerne einbauen, ich frag mich nur wofür.

Ich baue für Philipp einen readingTimeStampResolver ein dann macht auch die Angabe Sinn, da dann die Ermittlung des Zeitstempels in Custom-Perlcode liegt.




Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 18 März 2023, 15:47:48
Zitat von: rob am 03 März 2023, 09:09:18
Hallo Tim.

Die zwei Rückmeldungen zum Crash in https://forum.fhem.de/index.php/topic,114860.msg1163840.html#msg1163840 (https://forum.fhem.de/index.php/topic,114860.msg1163840.html#msg1163840) und https://forum.fhem.de/index.php/topic,114860.msg1167704.html#msg1167704 (https://forum.fhem.de/index.php/topic,114860.msg1167704.html#msg1167704) scheinen leider unter gegangen zu sein.

Das Problem besteht reproduzierbar leider schon noch. Einfach ein rename loslassen und mit Enter drücken ist FHEM weg
rename myTestInflux myTestInflux01

Im Log erscheint analog obigem Post:
Undefined subroutine &main::InfluxDBLogger_ReadPassword called at ./FHEM/93_InfluxDBLogger.pm line 612.

Magst Du bitte bei Gelegenheit schauen, ob sich das fixen lässt?

Vielen Dank und beste Grüße
rob

Das habe ich hier gefixt. Bitte testen.
Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 18 März 2023, 16:12:08
Zitat von: Ballaststoff am 10 März 2023, 09:04:22
Guten Morgen zusammen,

ich habe eben erst gesehen, dass es hier einen eigenen Thread zum InfluxDBLogger gibt.

Ich hatte hier bereits mein Problem geschildert, sorry:
https://forum.fhem.de/index.php/topic,132629.0.html

Würde mich über einen Tipp freuen.

Danke und viele Grüße!
Philipp

Hier schaumal ob es so klappt. Noch werden die Nullen für Nanosekunden noch angehangen. Doku gibt es noch nicht. Einfach wie üblich in geschweifete Klammern setzen.

Titel: Antw:Neues Modul InfluxDBLogger
Beitrag von: timmib am 18 März 2023, 21:07:08
Ich habe das Ganze nochmal überarbeitet.

Die "precision" ist nun automatisch aus "s", wenn man die Zeitstempel der FHEM Readings nutzt. Die sinnlosen Nullen gehören nun der Vergangenheit an.
Wenn man readingTimeStampsResolver nutzt ist der Standard auch "s" aber man kann es überschreiben mit dem Attribut.

Ich habe Dokumentation zu readingTimeStampsResolver ergänzt. Bitte einmal lesen ob man das versteht.

Der Code ist bezüglich Zeitstempelermittlung etwas optimiert worden.
Titel: Aw: Neues Modul InfluxDBLogger
Beitrag von: Ballaststoff am 21 März 2023, 08:55:37
Guten Morgen Tim,

danke für deine Mühe!
Ich sehe es mir in den nächsten Tagen an (liege leider gerade mit Grippe flach) und melde mich dann wieder.

Viele Grüße!
Titel: Aw: Neues Modul InfluxDBLogger
Beitrag von: rob am 22 März 2023, 10:58:11
Zitat von: timmib am 18 März 2023, 15:47:48Das habe ich hier gefixt. Bitte testen.
Hi.

Vielen Dank fürs flinke Kümmern  8)

Hab kurzerhand in der Testinstanz ein Device angelegt via altem Modul und rename ausgeführt. Mit alter Version Restart v. FHEM, Device nicht umbenannt. Mit Testversion kein Restart und Device umbenannt. Schaut also gut aus  :)

Vielen Dank und beste Grüße
rob
Titel: Aw: Neues Modul InfluxDBLogger
Beitrag von: Ballaststoff am 23 März 2023, 11:14:06
Zitat von: timmib am 18 März 2023, 21:07:08Ich habe das Ganze nochmal überarbeitet.

Die "precision" ist nun automatisch aus "s", wenn man die Zeitstempel der FHEM Readings nutzt. Die sinnlosen Nullen gehören nun der Vergangenheit an.
Wenn man readingTimeStampsResolver nutzt ist der Standard auch "s" aber man kann es überschreiben mit dem Attribut.

Ich habe Dokumentation zu readingTimeStampsResolver ergänzt. Bitte einmal lesen ob man das versteht.

Der Code ist bezüglich Zeitstempelermittlung etwas optimiert worden.

Hallo zusammen,

irgendwo steckt noch der Wurm drin (vielleicht auch in meiner Unfähigkeit ;) )
Im Reading "date" eines jeden $device steckt der UNIX-Zeitcode der übernommen werden soll.
Entsprechend habe ich readingTimeStampsResolver wie folgt definiert:
{AttrVal($device, "date", "")}
In Influx kommt folgendes an:
Zeitstempel Influx    date            (date lesbar)
2023-03-23T10:01:11Z    1679565659    23.03.2023 10:00:59
2023-03-23T10:01:12Z    1679565660    23.03.2023 10:01:00
2023-03-23T10:01:13Z    1679565662    23.03.2023 10:01:02
2023-03-23T10:01:14Z    1679565663    23.03.2023 10:01:03
2023-03-23T10:01:15Z    1679565664    23.03.2023 10:01:04
...

Folgende Attribute habe ich noch gesetzt:

Viele Grüße!
Philipp
Titel: Aw: Neues Modul InfluxDBLogger
Beitrag von: C0mmanda am 27 März 2023, 07:22:39
Moin moin,

überlege auch auf Influxdb zu wechseln und würde gern meine Daten aus der SQL-Datenbank migrieren.
Hat hier jemand ggf. ein Script oder ein Link zu einer Anleitung parat wie ich das bewerkstelligen könnte?
Möglich scheint das ja zu sein.

Vielen Dank!

Gruß
Titel: Aw: Neues Modul InfluxDBLogger
Beitrag von: marvin78 am 27 März 2023, 07:55:45
Schau mal ins Wiki zum Modul. Da gibt es ein paar Links auf Beiträge hier im Forum. Ein wenig individuell selbst basteln bleibt aber nicht aus.
Titel: Aw: Neues Modul InfluxDBLogger
Beitrag von: kadettilac89 am 27 März 2023, 12:45:52
Zitat von: C0mmanda am 27 März 2023, 07:22:39Moin moin,

überlege auch auf Influxdb zu wechseln und würde gern meine Daten aus der SQL-Datenbank migrieren.
Hat hier jemand ggf. ein Script oder ein Link zu einer Anleitung parat wie ich das bewerkstelligen könnte?
Möglich scheint das ja zu sein.

Vielen Dank!

Gruß

Für das "andere" Influx-Modul habe ich mal ein Script gebaut. Das kannst dir zurecht basteln wenn du dieses Influx-Modul hier verwenden willst.

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

Titel: Aw: Neues Modul InfluxDBLogger
Beitrag von: C0mmanda am 27 März 2023, 14:21:43
Klasse, vielen Dank!
Werde mir das heute Abend mal anschauen 👍🏽
Titel: Aw: Neues Modul InfluxDBLogger
Beitrag von: kadettilac89 am 27 März 2023, 15:30:55
Zitat von: C0mmanda am 27 März 2023, 14:21:43Klasse, vielen Dank!
Werde mir das heute Abend mal anschauen 👍🏽
Hinweis, solltest du Influx v2 nutzen ... https://forum.fhem.de/index.php?topic=71551.msg1263626#msg1263626 ... er hat "mein" Script bentzt und dann nach v2 migriert.
Titel: Aw: Neues Modul InfluxDBLogger
Beitrag von: lewej am 11 Mai 2023, 21:39:37
Hallo timmib,

Ich hätte einen feature request, weiss aber nicht ob es hier im Modul Beitrag richtig angesiedelt ist oder doch nach fhem an sich gehört.
Folgendes Szenario:

Möchte man PV Daten in der InfluxDB richtig aggregieren ist es wichtig das die Werte alle den selben Zeitstempel aufweisen.

Gerade wenn man Autarkie oder auch Eigenverbrauch/ Gesamtverbrauch berechnen möchte, ist es relavant das PV Produktion, Einspeisung und Selbstverbrauch den selben Zeitstempel immer aufweisen.

Aktuell wird bei mir aber dann nach InfluxDB geschrieben, wenn ein reading sich geändert hat oder es wurde ein neuer einlese Prozess gestartet. Es wird aber jedes reading für sich selber weggeschrieben.


Wäre es interessant, wenn man im Modul angeben kann, welche readings zusammen hängen und diese zur gleichen Zeit gemeinsam weggeschrieben werden?

Beispiel:

Zusammenhängendreading: PVErtrag,PVGrid,PVExport

Egal welcher der drei readings jetzt upgedatet werden, es wird immer auch der Wert der beiden anderen readings mit übertragen. Zeitstempel wird immer vom reading genommen der als erstes das Event getriggert hat.


Titel: Aw: Neues Modul InfluxDBLogger
Beitrag von: cc13 am 12 Mai 2023, 10:21:09
Hallo,

hoffentlich wurde meine Frage nicht schon hier im Thread besprochen, denn ich habe ihn überflogen und nichts gefunden.

Mein Device ist definiert mit:

defmod influxDB InfluxDBLogger http://192.168.0.225:8086 FHEM MQTT2_Kaffeemaschine,MQTT2_Schreibtisch_Kueche,MQTT2_Ladegeraet
Alles klappt soweit. Nun ist ein viertes MQTT-Device hinzugekommen. Im Wiki vom Modul steht geschrieben, dass man mehrere InfluxDBLogger Instanzen laufen lassen kann. Das möchte ich nicht, sondern das neue (vierte) Device zum bestehenden InfluxDBLogger hinzufügen. Wie mache ich das am einfachsten? Das bestehendes löschen und mit 4 Devices unter gleichem Namen anlegen?
Titel: Aw: Neues Modul InfluxDBLogger
Beitrag von: rob am 12 Mai 2023, 21:26:56
Zitat von: cc13 am 12 Mai 2023, 10:21:09Das bestehendes löschen und mit 4 Devices unter gleichem Namen anlegen?
Brauchst nix löschen. Gehe mal bitte in die Anzeige vom Influx-Device "influxDB". Unter "Internals" steht dort DEF und rechts daneben Deine obige Definition. Wenn Du auf DEF klickst, öffnet sie sich und Du ergänzt hinten dran Dein viertes MQTT-Device getrennt mit einem Komma.
Dann mit Klick auf "modify influxDB" bestätigen - fäddich :)

Gibt natürlich noch mehr Wege ;)
Titel: Aw: Neues Modul InfluxDBLogger
Beitrag von: rob am 12 Mai 2023, 21:50:47
Zitat von: lewej am 11 Mai 2023, 21:39:37Aktuell wird bei mir aber dann nach InfluxDB geschrieben, wenn ein reading sich geändert hat oder es wurde ein neuer einlese Prozess gestartet.
Ja, InfluxDB triggert Event-basiert. Mit event-on-change-reading u. Co. kannst Du das beeinflussen, aber Events kommen wie sie fallen ;)
Imho bringt FHEM alles mit was Du erreichen möchtest. Du könntest z.B. via readingsProxy zunächst alles sammeln was Du brauchst und dort dann mit event-aggregator arbeiten zum Glätten. Influx lässt Du dann nur auf das readingsProxy triggern.
Wahrscheinlich gibts wieder viele Wege nach Rom  ;D
Titel: Aw: Neues Modul InfluxDBLogger
Beitrag von: cc13 am 15 Mai 2023, 10:12:19
Zitat von: rob am 12 Mai 2023, 21:26:56
Zitat von: cc13 am 12 Mai 2023, 10:21:09Das bestehendes löschen und mit 4 Devices unter gleichem Namen anlegen?
Brauchst nix löschen. Gehe mal bitte in die Anzeige vom Influx-Device "influxDB". Unter "Internals" steht dort DEF und rechts daneben Deine obige Definition. Wenn Du auf DEF klickst, öffnet sie sich und Du ergänzt hinten dran Dein viertes MQTT-Device getrennt mit einem Komma.
Dann mit Klick auf "modify influxDB" bestätigen - fäddich :)

Gibt natürlich noch mehr Wege ;)


Top, danke. Das hat geholfen.
Titel: Aw: Neues Modul InfluxDBLogger
Beitrag von: lewej am 24 Mai 2023, 16:57:14
Zitat von: rob am 12 Mai 2023, 21:50:47
Zitat von: lewej am 11 Mai 2023, 21:39:37Aktuell wird bei mir aber dann nach InfluxDB geschrieben, wenn ein reading sich geändert hat oder es wurde ein neuer einlese Prozess gestartet.
Ja, InfluxDB triggert Event-basiert. Mit event-on-change-reading u. Co. kannst Du das beeinflussen, aber Events kommen wie sie fallen ;)
Imho bringt FHEM alles mit was Du erreichen möchtest. Du könntest z.B. via readingsProxy zunächst alles sammeln was Du brauchst und dort dann mit event-aggregator arbeiten zum Glätten. Influx lässt Du dann nur auf das readingsProxy triggern.
Wahrscheinlich gibts wieder viele Wege nach Rom  ;D

Leider triggert das readingproxy selber keine events, da es nur ein Hilfsmodul ist.

Das heisst ich kann das readingproxy nicht im influx logger als Device angeben, es würde dann keine events produzieren.
Titel: Aw: Neues Modul InfluxDBLogger
Beitrag von: rob am 25 Mai 2023, 09:00:10
Das readingsProxy hatte ich vorgeschlagen, um die benötigten Readings herauszuschälen und jew. ein übersichtliches Device zu bekommen (z.B. power1, power2). Influx dann triggern lassen auf z.B. power.*
Das Atrribut event-aggregator hatte ich ebenfalls dort gesehen, damit die orig. Devices unangetastet bleiben können und nur im Proxy nach Bedarf modifiziert wird.

Warum bei Dir der Proxy keine Events auslöst, weiß ich nicht.
In meinem Test kommen Events, wenn ich in den Dummys etwas eingebe:
2023-05-25 08:18:08.198 readingsProxy power1 410
2023-05-25 08:18:08.198 dummy powermeter power: 410
2023-05-25 08:22:51.407 readingsProxy power1 430
2023-05-25 08:22:51.407 dummy powermeter power: 430
2023-05-25 08:42:09.768 readingsProxy power1 420
2023-05-25 08:42:09.768 dummy powermeter power: 420
2023-05-25 08:42:19.555 readingsProxy power2 340
2023-05-25 08:42:19.555 dummy solar total_power: 340

Wenn ich Dich richtig verstanden hatte, dann sollen beim Triggern eines Readings einer Auswahl (Events) immer auch der Rest an Readings dieser Auswahl gelesen werden, auch wenn die gerade nicht aktualisiert wurden, sodass immer zur selben Zeit eine Influx-Erfassung erfolgen kann.

Diese Ansätze müssten das auch unterstützen:

- AT oder DOIF, was periodisch (z.B. alle Minute) die Readings holt oder auf eines der readings triggert (dev1:reading.*|dev2.reading.*; [dev1:reading] or [dev2:reading] usw.) und dann den Rest auch abholt
- mit setreading wieder ins jew. Device reintun/ oder woanders reinschreiben (z.B. dummy)
- inlux-Device auf die Devices triggern lassen wenn setreading, oder halt auf dummy

- analog müsste das mit userreadings im jew. Device auch klappen, wäre imho nur etwas unübersichtlicher
- influx auf die devices triggern lassen ggf. per whitelist eingrenzen

Wären also vier Ansätze letztlich mit gleichem Timestamp vom Influx-Device in die DB schreiben zu lassen. Details müssten natürlich noch ausgeknobelt werden.
Du hast dann allerdings nur eine Scheingenauigkeit, weil der nicht-triggernde Wert noch immer derselbe sein wird, wie beim letzten Event - außer Du machst Berechnungen á la Durchschnittswert o.ä. per event-aggregator & Co..

Ertrag und Eigenverbrauch etc. visualisiere ich auch mit Grafana. Ich synchronisiere die Timestamps jedoch nicht. Ich bin nicht sicher, ob Dir der Aufwand am Ende mehr bringt.
Titel: Aw: Neues Modul InfluxDBLogger
Beitrag von: lewej am 25 Mai 2023, 21:36:54
Hallo rob,

das ist interessant. Könntest du mir deine Definition vom ProxyReading zur Verfügung stellen. Wenn bei dir Events getriggert werden, dann müsste das ja theoretisch auch bei mir gehen.

Gruss und Danke
Titel: Aw: Neues Modul InfluxDBLogger
Beitrag von: rob am 26 Mai 2023, 07:17:21
Ich hatte die so aufgebaut:
define power1 readingsProxy powermeter:power
attr power1 event-aggregator state:120:none:v

define power2 readingsProxy solar:total_power
attr power2 event-aggregator state:120:none:v

define powermeter dummy
attr powermeter readingList power
attr powermeter setList power

define solar dummy
attr solar readingList total_power
attr solar setList total_power

setstate power1 420
setstate power1 2023-05-26 06:29:59 state 420

setstate power2 340
setstate power2 2023-05-26 06:29:59 state 340

setstate powermeter 2023-05-25 08:42:09 power 420

setstate solar 2023-05-25 08:42:19 total_power 340
Aber lass Dich nicht zu sehr auf dem Proxy festnageln. Wenn es nicht will, investierst Du im Zweifel dort unnötig Zeit, ohne beim eigentl. Thema weiter zu kommen.

Ich hab mal ganz auf die Schnelle einen Sammeldummy + Notify geschustert. Zum Verdeutlichen. Wenn Du anstelle meiner zwei Dummys oben Deine echten Devices nimmst, müsste das Notify in den Testdummy immer gleiche Timestamps schreiben. In meinem Aufbau der Fall. Welches der zwei Events gerade triggert ist wurscht. Denn das Notify reagiert auf beide --> löst 1 aus, werden 1+2 geschrieben; löst 2 aus, werden 1+2 geschrieben - das ist der eigentl. Kniff.
define dmy_test dummy
attr dmy_test readingList erzeugte_power bezogene_power
attr dmy_test setList erzeugte_power bezogene_power

define nfy_test notify solar:total_power:.*|powermeter:power:.*\
{\
my $solar_power = ReadingsNum('solar','total_power',0);;\
my $meter_power = ReadingsNum('powermeter','power',0);;\
\
fhem("setreading dmy_test bezogene_power $meter_power");;\
fhem("setreading dmy_test erzeugte_power $solar_power");;\
\
}

setstate dmy_test 2023-05-26 06:55:46 bezogene_power 310
setstate dmy_test 2023-05-26 06:55:46 erzeugte_power 100

setstate nfy_test 2023-05-26 06:55:46
setstate nfy_test 2023-05-26 06:55:39 state active
setstate nfy_test 2023-05-26 06:55:46 triggeredByDev powermeter
setstate nfy_test 2023-05-26 06:55:46 triggeredByEvent power: 310
Auf den Testdummy kannst dann testweise InfluxDB reagieren lassen:
defmod myTestInflux InfluxDBLogger http://<IP>:<PORT> myinfluxdb <yourdev1>,<yourdev2>.*,dmy_test
Bei dem Beispiel wäre event-aggregator im dmy_test gut aufgehoben.
Gibt ganz sicher noch viel ausgebufftere Varianten. Ich denke, das ist trotzdem ein solider Start ;)
Titel: Aw: Neues Modul InfluxDBLogger
Beitrag von: lewej am 27 Mai 2023, 10:19:45
Hallo rob,

Was soll ich sagen, einfach nur Super. Der notify macht das was ich will.
Alle Readings landen mit dem selben Zeitstempel in der influxx.

Ist zwar etwas umfangreich mit dem definieren aber man macht es eigentlich nur einmal.

Danke und Gruss

Zitat von: rob am 26 Mai 2023, 07:17:21Ich hatte die so aufgebaut:
define power1 readingsProxy powermeter:power
attr power1 event-aggregator state:120:none:v

define power2 readingsProxy solar:total_power
attr power2 event-aggregator state:120:none:v

define powermeter dummy
attr powermeter readingList power
attr powermeter setList power

define solar dummy
attr solar readingList total_power
attr solar setList total_power

setstate power1 420
setstate power1 2023-05-26 06:29:59 state 420

setstate power2 340
setstate power2 2023-05-26 06:29:59 state 340

setstate powermeter 2023-05-25 08:42:09 power 420

setstate solar 2023-05-25 08:42:19 total_power 340
Aber lass Dich nicht zu sehr auf dem Proxy festnageln. Wenn es nicht will, investierst Du im Zweifel dort unnötig Zeit, ohne beim eigentl. Thema weiter zu kommen.

Ich hab mal ganz auf die Schnelle einen Sammeldummy + Notify geschustert. Zum Verdeutlichen. Wenn Du anstelle meiner zwei Dummys oben Deine echten Devices nimmst, müsste das Notify in den Testdummy immer gleiche Timestamps schreiben. In meinem Aufbau der Fall. Welches der zwei Events gerade triggert ist wurscht. Denn das Notify reagiert auf beide --> löst 1 aus, werden 1+2 geschrieben; löst 2 aus, werden 1+2 geschrieben - das ist der eigentl. Kniff.
define dmy_test dummy
attr dmy_test readingList erzeugte_power bezogene_power
attr dmy_test setList erzeugte_power bezogene_power

define nfy_test notify solar:total_power:.*|powermeter:power:.*\
{\
my $solar_power = ReadingsNum('solar','total_power',0);;\
my $meter_power = ReadingsNum('powermeter','power',0);;\
\
fhem("setreading dmy_test bezogene_power $meter_power");;\
fhem("setreading dmy_test erzeugte_power $solar_power");;\
\
}

setstate dmy_test 2023-05-26 06:55:46 bezogene_power 310
setstate dmy_test 2023-05-26 06:55:46 erzeugte_power 100

setstate nfy_test 2023-05-26 06:55:46
setstate nfy_test 2023-05-26 06:55:39 state active
setstate nfy_test 2023-05-26 06:55:46 triggeredByDev powermeter
setstate nfy_test 2023-05-26 06:55:46 triggeredByEvent power: 310
Auf den Testdummy kannst dann testweise InfluxDB reagieren lassen:
defmod myTestInflux InfluxDBLogger http://<IP>:<PORT> myinfluxdb <yourdev1>,<yourdev2>.*,dmy_test
Bei dem Beispiel wäre event-aggregator im dmy_test gut aufgehoben.
Gibt ganz sicher noch viel ausgebufftere Varianten. Ich denke, das ist trotzdem ein solider Start ;)

Titel: Aw: Neues Modul InfluxDBLogger
Beitrag von: mlau am 04 Juli 2023, 18:49:42
Hallo,

Ich habe ein Problem mit dem logging von den meisten meiner KNX readings.
Das Problem scheint zu sein, dass das KNX Modul, abhängig vom Datentyp der Gruppenaddresse, auch gleich eine Einheit an den Wert hängt.
Das führt dann dazu, dass die Allermeisten KNX readings als nicht-numerisch eingestuft werden.

in Zeile 361, die Regex scheint nur nach dem ":" zu trennen; die Einheit wird nicht abgeschnitten:

356    sub InfluxDBLogger_Map($$$$)
357    {
358        my ($hash, $dev_hash, $event, $map) = @_;
359        my $name = $hash->{NAME};
360        my $deviceName = $dev_hash->{NAME};
361        my @readingAndValue = split(":[ \t]*", $event, 2);
362        my $readingName = $readingAndValue[0];
363        my $readingValue = $readingAndValue[1];
[...]
375        $map->{$deviceName}->{$readingName}->{"numeric"} = $readingValue =~ /^[-+]?[0-9]*[\.\,]?[0-9]+([eE][-+]?[0-9]+)?$/;

der $event ist z.b. "getG1: 300,5 W", die readingValue daher "300,5 W", und lt regex in 375 daher nicht numeric, was
später dazu führt dass das reading in BuildData() als incompatible verworfen wird.
Mein perl-fu ist null, daher hoffe ich dass der Ersteller des Moduls hier vielleicht etwas machen kann..

Danke!
  M.

EDIT: habs nun so gefixt:

--- 93_InfluxDBLogger.pm.orig   2023-07-04 19:13:47.334744323 +0200
+++ 93_InfluxDBLogger.pm        2023-07-04 19:12:49.212603906 +0200
@@ -360,7 +360,8 @@ sub InfluxDBLogger_Map($$$$)
     my $deviceName = $dev_hash->{NAME};
     my @readingAndValue = split(":[ \t]*", $event, 2);
     my $readingName = $readingAndValue[0];
-    my $readingValue = $readingAndValue[1];
+    my @readingValueUnit = split(" ", $readingAndValue[1], 2);
+    my $readingValue = $readingValueUnit[0];
 
     my $conversions = AttrVal($name, "conversions", undef);
     if ( defined($conversions)) {
Titel: Aw: Neues Modul InfluxDBLogger
Beitrag von: lewej am 28 September 2023, 17:38:31
Hallo rob,

Leider hab ich mich zu früh gefreut. Die Werte sind meistens auf die Sekunde genau, jedoch unterschiedlich sind die Millisekunden die in die InfluxDB weggeschrieben werden. Das heisst dort kann man die Werte nicht zueinander bringen.

Mit flux und der pivot Tabellen Funktion bleibt die Auswertung leer.

Als ich darüber nachgedacht habe, was ja beim setreading passiert, war mir auch klar sie Millisekunden auseinander laufen werden.

Es werden ja nur Befehle nach einander abgesetzt.
Hast du noch eine Idee oder jemand anders, wie ich Werte mit selben Zeitstempeln wegschreiben kann?

Gruss


Zitat von: lewej am 27 Mai 2023, 10:19:45Hallo rob,

Was soll ich sagen, einfach nur Super. Der notify macht das was ich will.
Alle Readings landen mit dem selben Zeitstempel in der influxx.

Ist zwar etwas umfangreich mit dem definieren aber man macht es eigentlich nur einmal.

Danke und Gruss

Zitat von: rob am 26 Mai 2023, 07:17:21Ich hatte die so aufgebaut:
define power1 readingsProxy powermeter:power
attr power1 event-aggregator state:120:none:v

define power2 readingsProxy solar:total_power
attr power2 event-aggregator state:120:none:v

define powermeter dummy
attr powermeter readingList power
attr powermeter setList power

define solar dummy
attr solar readingList total_power
attr solar setList total_power

setstate power1 420
setstate power1 2023-05-26 06:29:59 state 420

setstate power2 340
setstate power2 2023-05-26 06:29:59 state 340

setstate powermeter 2023-05-25 08:42:09 power 420

setstate solar 2023-05-25 08:42:19 total_power 340
Aber lass Dich nicht zu sehr auf dem Proxy festnageln. Wenn es nicht will, investierst Du im Zweifel dort unnötig Zeit, ohne beim eigentl. Thema weiter zu kommen.

Ich hab mal ganz auf die Schnelle einen Sammeldummy + Notify geschustert. Zum Verdeutlichen. Wenn Du anstelle meiner zwei Dummys oben Deine echten Devices nimmst, müsste das Notify in den Testdummy immer gleiche Timestamps schreiben. In meinem Aufbau der Fall. Welches der zwei Events gerade triggert ist wurscht. Denn das Notify reagiert auf beide --> löst 1 aus, werden 1+2 geschrieben; löst 2 aus, werden 1+2 geschrieben - das ist der eigentl. Kniff.
define dmy_test dummy
attr dmy_test readingList erzeugte_power bezogene_power
attr dmy_test setList erzeugte_power bezogene_power

define nfy_test notify solar:total_power:.*|powermeter:power:.*\
{\
my $solar_power = ReadingsNum('solar','total_power',0);;\
my $meter_power = ReadingsNum('powermeter','power',0);;\
\
fhem("setreading dmy_test bezogene_power $meter_power");;\
fhem("setreading dmy_test erzeugte_power $solar_power");;\
\
}

setstate dmy_test 2023-05-26 06:55:46 bezogene_power 310
setstate dmy_test 2023-05-26 06:55:46 erzeugte_power 100

setstate nfy_test 2023-05-26 06:55:46
setstate nfy_test 2023-05-26 06:55:39 state active
setstate nfy_test 2023-05-26 06:55:46 triggeredByDev powermeter
setstate nfy_test 2023-05-26 06:55:46 triggeredByEvent power: 310
Auf den Testdummy kannst dann testweise InfluxDB reagieren lassen:
defmod myTestInflux InfluxDBLogger http://<IP>:<PORT> myinfluxdb <yourdev1>,<yourdev2>.*,dmy_test
Bei dem Beispiel wäre event-aggregator im dmy_test gut aufgehoben.
Gibt ganz sicher noch viel ausgebufftere Varianten. Ich denke, das ist trotzdem ein solider Start ;)

Titel: Aw: Neues Modul InfluxDBLogger
Beitrag von: rob am 29 September 2023, 09:50:00
So ganz verstehe ich nicht, wie/ wo Du auswertest/ visualisierst. Würden Dein Solar und Powermeter beide jede Sekunde senden und Du hättest immer ein Event und es ginge beides jede Sekunde in die InfluxDB, dann wären die Millisekunden auch immer mal unterschiedlich. Will sagen, wie sollte das auch anders sein? Selbst wenn Du exakt zeitgleich sendest, würde es auf den Nanosekunden doch wieder auseinanderlaufen  ;)

Ich habe auch Powermeter + Solar und visualisiere in FHEM und in Grafana. Strom wird jede Minute und Solar spätestens nach 5 Minuten aktualisiert. Trotzdem klappen die Visualisierungen nebst Berechnungen wunderbar. Warum? Weil man doch meist eh aggregiert z.B. via Differenz oder Durchschnittswert usw.

Millisekunden sollten m.E. hier keine Rollen spielen - wir arbeiten ja nicht am LHC (https://de.wikipedia.org/wiki/CERN#Large_Hadron_Collider) - die wären sonst auch noch zu grob  ;D . Aus meiner Sicht lässt sich das FHEM-seitig nur schwer lösen. Du könntest beim Visualisieren z.B. in Grafana entweder zuvor die Millisekunden abschneiden oder schlicht aggregieren. InfluxDB v2 bietet z.B. Funktionen dafür an (https://docs.influxdata.com/flux/v0/data-types/basic/time/#truncate-timestamps-to-a-specified-unit). Grafana macht das automatisch beim aggregieren und FHEM sind die millisec eh Wurscht.

Zitat von: lewej am 28 September 2023, 17:38:31...Mit flux und der pivot Tabellen Funktion bleibt die Auswertung leer...
Liest sich so, als würdest Du direkt im Influx-WebIf auswerten. Ich hab die V2 nicht und deshalb auch kein Webif. Ich behaupte mal keck, die Auswertungen dort sind eher für grobe Sichtungen/ Checks gedacht und zeigen dafür mehr die Rohwerte.
Zum Visualisieren imho weniger geeignet/ nicht so gedacht - das können Plots in FHEM oder eben Grafana besser.

Aber vielleicht hat noch jmd. Ideen oder Tricks im Köcher.

Viele Grüße
rob
Titel: Aw: Neues Modul InfluxDBLogger
Beitrag von: lewej am 09 Oktober 2023, 22:30:57
Hier ist mal ein Beispiel:

from(bucket: "Strom")
    |> range(start: startTime, stop: fullHourTime)
    |> filter(fn: (r) => r._measurement == "pvdaten_proxy")
    |> filter(fn: (r) => r._field == "SMAHM_Einspeisung_Wirkleistung_Zaehler" or r._field == "SPOT_ETOTAL" or r._field == "priceIn")
    |> pivot(rowKey: ["_time"], columnKey: ["_field"], valueColumn: "_value")
    |> filter(fn: (r) => r.SMAHM_Einspeisung_Wirkleistung_Zaehler > 0 and r.SPOT_ETOTAL > 0)
    |> difference(columns: ["SMAHM_Einspeisung_Wirkleistung_Zaehler", "SPOT_ETOTAL"])
    |> map( fn: (r) => ({r with _value: (r.SPOT_ETOTAL - r.SMAHM_Einspeisung_Wirkleistung_Zaehler) / 1000.0 * r.priceIn}))

Wenn die Werte nicht mit gleichen Zeitstempel versehen sind, wird die pivotabelle nicht richtig befühlt und somit funktioniert es dann nicht.