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:
- wurde nicht weiter gepflegt
- blockierte den Main-Loop
- war kaum konfigurierbar
- intransparent was wirklich passierte
- das Passwort wurde im Klartext gespeichert
Deswegen habe ich nun ein neues Modul geschrieben welches:
- nicht den Main-Loop blockiert, da es die HTTPUtils verwendet
- konfigurierbarer ist
- transparent statistik-readings und logs produziert
- das Passwort ordentlich gespeichert
Zum Thema "konfigurierbar":
- Man kann die devspec und eine separate optionale regex für die readings definieren.
- Bei einer devspec die auf alles matched disabled sich das Modul erstmal selber, weil es sonst die DB zumüllt.
- Man kann über ein Attribut die Art der Security wählen (bisher basicAuth und keine, InfluxDB unterstützt aber auch Token
- Das Passwort setzt man über set password, der user über ein Attribut
- Man kann den Namen des Tags wählen wo der Devicename gespeichert wird. Um alte Datenschätze nicht zu stören ist der default wie beim alten Modul 'site_name'
Zum Thema "Statistik":
- Es werden die Gesamtzahl die Erfolge und Mißerfolge gezählt
- Es wird der letzte Fehler als Reading angezeigt
- Es werden DNS, HTTP und Influx Fehler als Fehler erkannt
- Man kann die Statisik über set resetStatistics zurücksetzen
Zum Thema "Sonstiges":
- Es werden true,yes und on und deren Gegenspieler in 1 bzw. 0 übersetzt
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
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?
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
Habe ich übersehen. Wird eingebaut.
Es gibt Neuigkeiten:
- Das Attribut readingRegEx heißt jetzt readingInclude und es gibt nun auch readingExclude. Bitte entsprechend vorsichtig migrieren!
- Es gibt nun ein Attribut conversion. Das ist Kommagetrennte Liste von Ersetzungen e.g. open=1,closed=0,tilted=2 oder true|on|yes=1,false|off|no=0
- Es wird nun nichts mehr automatisch konvertiert!
- Nicht numerische Readings werden jetzt garnicht erst zur Datenbank geschickt. Aber lokal gezählt als "dropped" und die letzte Meldung angezeigt.
- Deutsch und englische Doku habe ich entsprechend angepasst
Viele Erfolg beim Testen
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
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.
Klappt wunderbar. Habe die neue Version an die Themeneröffnung angehangen. Musste nur eine Zeile ändern und eine löschen.
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
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.
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.
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
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.
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.
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?
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.
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.
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
Guten Tag,
ich nutze 1.8.2. Die 2er habe ich nie probiert, weil ich mit der "Alten" glücklich bin.
Viel Erfolg
Tim
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
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
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
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ß
Der Stack mit Influx ist da schneller. Das war auch meine Motivation.
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.
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
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.
Habe die Excludes nun mit folgendem regex Ausdruck hinbekommen:
(battery:\s.+|batteryState:\s.+|lowtemp:\s.+|mode:\s.+|warnings:\s.+|window:\s.+|windowsensor:\s.+)
Sehr gut, danke für die Hinweise bzgl. Doku.
Klappt auch das Konvertieren der Prozentwerte?
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.
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.
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.
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
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?
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 ...
Ahso - kapiert.
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!!
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".
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.
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?
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.
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
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.
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)
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.
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:
- measurement pro reading
- tag als device
- nur ein field 'value' gleich reading.
Kann man nun z.B.
- measurement pro device
- mehrere tags frei wählbar
- mehrere fields reading=wert
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
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!
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 ?
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
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 :)
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
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
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
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
Hi, du musst das mapping auf Datenbanken in Influx2 machen.
VG Tim
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)
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
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
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
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
.. aber mir tut das weh. :)
Hier die neue Version ohne Warnings und dafür mit vollständiger Doku.
Edit: Problem erstmal hier raus genommen
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.
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.
Das war ja auch die Motivation das neu zu schreiben.
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
Super, schaue ich mir an.
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
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
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
Hallo zusammen,
Übrigens ist das Modul nun im FHEM SVN eingecheckt. 8)
Das heißt für die Nutzer, dass bei einem update all
die 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
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...
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
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
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.
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:
- event-on-change-reading, siehe https://wiki.fhem.de/wiki/Event-on-change-reading
- event-aggregator
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.
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
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).
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
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 :-\
Siehst Du für die Userreadings Events?
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?
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 ...
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?
@kadettilac89: Danke für den Tip - schaue ich mir an
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 :-/
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.
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
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
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);
}
Danke!
Habe zwar 'ne Weile gebraucht, bis ich das fehlerfrei in 99_myUtils umgesetzt hatte aber es funktioniert - freu.
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.
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 :)
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.
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
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.
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
Danke! Jetzt geht alles. Super
Mit dem Alias als Tag funktioniert wunderbar, wenn man Leerzeichen ersetzt. Danke!
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
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
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
Oder du machst dir mehrere influxdblogger devices
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
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.
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
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.
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
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)
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
Ich nutze dafür Grafana im IFrame I'm TabletUI.
Freut mich, dass es gefällt.
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 ;)
Hallo Markus,
ich habe es übernommen und commited.
Vielen Dank
Tim
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:
- jegliche Security
- jegliches Löschen des Tasks
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)
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
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
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 ;)
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.
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
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
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.
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):.*
Wie oben geschrieben, Pack doch einfach den Doppelpunkt dahinter.
temperature:
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.
Ich vermute du hast beide Varianten probiert und nicht gleichzeitig. Das ist komisch.
Ich gucke nacher nochmal.
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.
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?
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.
Da steht doch wind: und nicht windDirection: !!
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 ;)
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.
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:
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.
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
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
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.
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
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
Kosten neue Threads bei euch Gebühren? :o
Egal.
Hol mich mal grad ab. Du bist gedanklich bei dem Log Attribut a la DbLogInclude?
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)
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.
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
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
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.
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?
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...
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
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
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.
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
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
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
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 ;-)
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
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
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
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
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
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 °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
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 °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?
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 °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.
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.
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!
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.
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
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?
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.
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.
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
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.
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
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
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
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]
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
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.
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 ;)
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
Ich bin neugierig: Wie hast Du es denn konkret lösen können?
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.
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.
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?
Hi,
leider kommt dor ein Bad reqest bei raus.
Eigentlich sollte die doch eine normale Anforderung an das Modul sein oder?
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.
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
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.
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")}
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?
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
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...
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?
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?
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.
Ah, jetzt ja, verstehe.
Ja macht Sinn. Baue ich die Tage gerne ein.
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.
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 );
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
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
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.
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
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
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".
Guten Abend,
ich habe die neue Version nun nach SVN commited.
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
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.
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.
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
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... ?
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 :')
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.
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:.*)
Ja, nimm das Attribut readingExclude
.
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 nachmachenBeim 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.
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
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
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
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?
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)
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?
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ß
ok, super. ich dachte nur das es noch in Beta war und noch nicht in main stream. Danke!
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 ?
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.
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!
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.
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.
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
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
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)
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
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?
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
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
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.
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
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*
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
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.
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
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. :)
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
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
Readingsinclude im influxdb logger oder in den devices?
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).
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
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.
Ich meine mehrere Definition in fhem die in eine Datenbank schreiben
Ob das funktioniert kann ich dir gar nicht sagen, könnte sein das die sich beim schreiben gegenseitig hindern.
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!
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.
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.
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.
Übrigens sorry, dass ich erst jetzt reagiere. Habe die Forum Benachrichtigungen wohl falsch eingestellt.
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
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
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.
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.
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?
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.
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.
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
Zitat von: Weisswurstverkäufer am 17 Februar 2023, 13:37:12
Allerdings kann man die Tags nicht einbinden.
Wo einbinden?
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!
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
Hallo rob,
ja schau ich mir die Tage an.
Viele Grüße
Tim
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!
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
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.
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.
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.
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.
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!
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
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:
- readingTimeStamps: 1
- precision habe ich nicht definiert
Viele Grüße!
Philipp
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ß
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.
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
Klasse, vielen Dank!
Werde mir das heute Abend mal anschauen 👍🏽
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.
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.
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?
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 ;)
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
Zitat von: rob am 12 Mai 2023, 21:26:56Zitat 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.
Zitat von: rob am 12 Mai 2023, 21:50:47Zitat 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.
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.
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
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 ;)
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 ;)
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)) {
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 ;)
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
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.