Neues Modul InfluxDBLogger

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

Vorheriges Thema - Nächstes Thema

kennymc.c

#255
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.

timmib

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.

timmib

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?

kennymc.c

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.

Weisswurstverkäufer

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.

timmib

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

timmib


Weisswurstverkäufer

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!

rob

Hallo Tim.

Die zwei Rückmeldungen zum Crash in https://forum.fhem.de/index.php/topic,114860.msg1163840.html#msg1163840 und 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

timmib

Hallo rob,

ja schau ich mir die Tage an.

Viele Grüße

Tim

cthil

#265
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!

Ballaststoff

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

timmib

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.





timmib

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

timmib

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.