"Warn" Logeinträge InfluxDB-Adapter

OstfrieseUnterwegs

@haus-automatisierung Stimmt wohl.
Wenn das Query so von Flot generiert wird, kann man wohl nichts machen.

haus-automatisierung

@ostfrieseunterwegs Naja, man könnte jetzt schauen warum der Flot-Adapter den gesamten Zeitraum von 2 Jahren abfragt, nur um den letzten Wert zu holen (Bug im Flot-Adapter ?) oder den Aufbau des Statements im InfluxDB Adapter in getHistory ändern, sodass das Statement performanter aufgebaut wird.

OstfrieseUnterwegs

@haus-automatisierung Ja genau, aber das ist wahrscheinlich nichts, was wir end-user machen können. Das müsste jemand analysieren, der den Adapter kennt. So, wie in diesem Fall, wenn nur ein Attribut geholt wird, scheint mir das Pivot überflüssig zu sein. Auch beim Schreiben nach influxdb wird meiner Meinung nach nicht unbedingt das Optimale herausgeholt. Führt in diesem Thread aber zuweit.

blacksheep587

@ostfrieseunterwegs @haus-automatisierung
Also, da ich erst letzte Woche InfluxDB aufgesetzt habe, war der Datenverlust überschaubar, weswegen ich jetzt die Datenbank/das Bucket gelöscht und neu aufgesetzt habe.
Ich habe jetzt großzügige Blockzeiten gewählt, alle Logging-Punke nochmal durchgesehen und bis jetzt läuft alles flüssig.

apollon77

@blacksheep587 Das war recht blöd muss ich ehrlich sagen weil es generell jegliches Debugging des Thema jetzt sehr schwer macht :-(

Ich wollte gerade um ein Debug log der flot Anfrage bitten das man mal die Parameter und so sieht ... keine Ahnung ob das jetzt noch so sinn macht

mango1402

Grüß Euch,
hab das selbe Problem, nur mit dem ECharts.....
Aufbau von 2 24h-Linien dauert ca. 15sec (im Vergleich: unter V1 grad mal max. 2s.....)
Wenn dann noch Messungen mit dabei sind, die in den letzten 24h keine Werte geliefert haben wird's noch länger....

Gibt dazu schon einige andere Leidgeplagte hier im Forum, z.B. https://forum.iobroker.net/post/958441

Ich denke, das Thema müsste höchstprior behandelt werden.
Wenn Ihr loggings braucht, einfach melden.

lg Manfred

Homoran

@mango1402 sagte in "Warn" Logeinträge InfluxDB-Adapter:

das Thema müsste höchstprior behandelt werden.

bitte detailliertere Infos

@mango1402 sagte in "Warn" Logeinträge InfluxDB-Adapter:

Aufbau von 2 24h-Linien

enthält wie viele Datenpunkte?
in welcher Datenbank?
wie angebunden?
mit welcher Aggregation?
auf welchem Frontend?
wie angebunden?
für welche Auflösung?
in welcher Widgetgröße?
Welche Art der Darstellung?
mit Schatten oder anderen Gimmicks?

und viele mögliche Gründe mehr

mango1402

@homoran said in "Warn" Logeinträge InfluxDB-Adapter:

enthält wie viele Datenpunkte?

alle 10s eine Messung -> 8640 pro Messreihe und Tag?

in welcher Datenbank?

InfluxDb V2.6

wie angebunden?

Influx-Adapter, V3.2.0

mit welcher Aggregation?

??

auf welchem Frontend?

ECharts - direkt im IoBroker
aber auch mit Flot geht's nicht flotter.....

wie angebunden?

??

für welche Auflösung?
in welcher Widgetgröße?

--

Welche Art der Darstellung?

Linie, minmax

mit Schatten oder anderen Gimmicks?

nein

und viele mögliche Gründe mehr

Homoran

@mango1402 sagte in "Warn" Logeinträge InfluxDB-Adapter:

mit welcher Aggregation?

??

minmax, mittel, usw. Und Aggregation auf Zeit oder Anzahl.
diese Dinge werden auf dem Backend aufbereitet

apollon77

Ganz kurz: minmax ist mit influxdb eine Wahl die länger dauern muss!

Alle Standardaggregationen wir average, min, max, percentiles und sowas werden direkt von der DB berechnet. Das ist üblicherweise sehr performant.

Da "minmax" eine "ioBroker eigene Art" der Datenaufbereitung ist werden hier ALLE Daten selektiert und dann im Adapter aggregiert. Das dauert etwas länger.

Homoran

@mango1402 sagte in "Warn" Logeinträge InfluxDB-Adapter:

wie angebunden?

Influx-Adapter, V3.2.0

eher: wo liegt die? Müssen die Daten irgendwo und irgendwie transferiert werden?

@mango1402 sagte in "Warn" Logeinträge InfluxDB-Adapter:

auf welchem Frontend?

ECharts - direkt im IoBroker

das ist das Backend

@mango1402 sagte in "Warn" Logeinträge InfluxDB-Adapter:

für welche Auflösung?
in welcher Widgetgröße?

--

hier geht es um die Rechenintensität auf dem Frontend.
die von Flot berechneten Daten gehen erst einmal davon aus, dass ausreichend Grafikpunkte für die Darstellung vorhanden sind.
bei 8650 Datenpunkten und einer Linienstärke von 3px, braucht es 5px um 2 Punkte getrennt darstellen zu können.
Da dein Chart garantiert keine 45000 Pixel breit ist, rechnet jetzt dein Frontend wieder alles zurück.

mango1402

@homoran
ist doch alles irrelevant:
selbes Chart bei unterschiedlichen Datenquellen:
Influx V1: 2s
Influx V2: 15s
Ich glaub nicht dass ECharts einen Unterschied macht ob die Daten von V1 oder V2 kommen, oder?
Datenpunkte sind sie selben, werden online zyklisch in beide Versionen geschreiben

Homoran

@mango1402 sagte in "Warn" Logeinträge InfluxDB-Adapter:

Ich glaub nicht dass ECharts einen Unterschied macht ob die Daten von V1 oder V2 kommen, oder?

da gibt es bereits einen Thread mit influx und flot.
irgendwas läuft/lief da mit der query schief.
ob das jetzt erst bei v2 aufgetreten war weiß ich bicht.
Vielleicht kann @apollon77 sich da noch dran erinnern.

edit: ich wrde alt! ist ja hier der Thread
https://forum.iobroker.net/post/958609

mango1402

anbei noch das logging für die 24h-Abfrage meiner 2 Kurven:

2023-03-09 09:17:05.552 - debug: influxdb.1 (461) PING OK
2023-03-09 09:17:08.856 - debug: influxdb.1 (461) Incoming message getHistory from system.adapter.admin.0
2023-03-09 09:17:08.856 - debug: influxdb.1 (461) 0_userdata.0.Zaehler.SmartMeter.Zaehlerstand16783498288560.08961875976288836 getHistory message: {"id":"0_userdata.0.Zaehler.SmartMeter.Zaehlerstand","options":{"start":1678263440688,"end":1678349840688,"aggregate":"minmax","from":false,"ack":false,"q":false,"addID":false,"count":300,"instance":"system.adapter.influxdb.1","sessionId":155,"user":"system.user.admin"}}
2023-03-09 09:17:08.857 - debug: influxdb.1 (461) Query to execute:
from(bucket: "iobrokerV2")
|> range(start: 2023-03-08T08:17:20.688Z, stop: 2023-03-09T08:17:20.688Z)
|> filter(fn: (r) => r["_measurement"] == "0_userdata.0.Zaehler.SmartMeter.Zaehlerstand" and contains(value: r._value, set: [true, false]))
|> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value")
|> group()
2023-03-09 09:17:08.947 - debug: influxdb.1 (461) Query to execute: from(bucket: "iobrokerV2")
|> range(start: 2022-03-08T08:17:20.688Z, stop: 2023-03-08T08:17:20.687Z)
|> filter(fn: (r) => r["_measurement"] == "0_userdata.0.Zaehler.SmartMeter.Zaehlerstand")
|> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value")
|> group()
|> sort(columns: ["_time"], desc: true)
|> limit(n: 1)
2023-03-09 09:17:14.910 - debug: influxdb.1 (461) Query to execute: from(bucket: "iobrokerV2") |> range(start: 2023-03-08T08:17:20.688Z, stop: 2023-03-09T08:17:20.688Z) |> filter(fn: (r) => r["_measurement"] == "0_userdata.0.Zaehler.SmartMeter.Zaehlerstand") |> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value") |> sort(columns:["_time"], desc: false)
2023-03-09 09:17:15.024 - debug: influxdb.1 (461) Query to execute: from(bucket: "iobrokerV2")
|> range(start: 2023-03-09T08:17:20.689Z)
|> filter(fn: (r) => r["_measurement"] == "0_userdata.0.Zaehler.SmartMeter.Zaehlerstand")
|> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value")
|> group()
|> sort(columns: ["_time"], desc: false)
|> limit(n: 1)
2023-03-09 09:17:15.098 - debug: influxdb.1 (461) Send: 600 of: 7632 in: 6242ms
2023-03-09 09:17:15.238 - debug: influxdb.1 (461) Incoming message getHistory from system.adapter.admin.0
2023-03-09 09:17:15.238 - debug: influxdb.1 (461) 0_userdata.0.Zaehler.SmartMeter.aktuelleLeistung16783498352380.47825413161981967 getHistory message: {"id":"0_userdata.0.Zaehler.SmartMeter.aktuelleLeistung","options":{"start":1678263440688,"end":1678349840688,"aggregate":"minmax","from":false,"ack":false,"q":false,"addID":false,"count":300,"instance":"system.adapter.influxdb.1","sessionId":155,"user":"system.user.admin"}}
2023-03-09 09:17:15.240 - debug: influxdb.1 (461) Query to execute:
from(bucket: "iobrokerV2")
|> range(start: 2023-03-08T08:17:20.688Z, stop: 2023-03-09T08:17:20.688Z)
|> filter(fn: (r) => r["_measurement"] == "0_userdata.0.Zaehler.SmartMeter.aktuelleLeistung" and contains(value: r._value, set: [true, false]))
|> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value")
|> group()
2023-03-09 09:17:15.328 - debug: influxdb.1 (461) Query to execute: from(bucket: "iobrokerV2")
|> range(start: 2022-03-08T08:17:20.688Z, stop: 2023-03-08T08:17:20.687Z)
|> filter(fn: (r) => r["_measurement"] == "0_userdata.0.Zaehler.SmartMeter.aktuelleLeistung")
|> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value")
|> group()
|> sort(columns: ["_time"], desc: true)
|> limit(n: 1)
2023-03-09 09:17:20.502 - debug: influxdb.1 (461) Query to execute: from(bucket: "iobrokerV2") |> range(start: 2023-03-08T08:17:20.688Z, stop: 2023-03-09T08:17:20.688Z) |> filter(fn: (r) => r["_measurement"] == "0_userdata.0.Zaehler.SmartMeter.aktuelleLeistung") |> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value") |> sort(columns:["_time"], desc: false)
2023-03-09 09:17:20.552 - debug: influxdb.1 (461) PING OK
2023-03-09 09:17:20.592 - debug: influxdb.1 (461) Query to execute: from(bucket: "iobrokerV2")
|> range(start: 2023-03-09T08:17:20.689Z)
|> filter(fn: (r) => r["_measurement"] == "0_userdata.0.Zaehler.SmartMeter.aktuelleLeistung")
|> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value")
|> group()
|> sort(columns: ["_time"], desc: false)
|> limit(n: 1)
2023-03-09 09:17:20.644 - debug: influxdb.1 (461) Send: 1130 of: 7295 in: 5406ms
2023-03-09 09:17:35.553 - debug: influxdb.1 (461) PING OK

nicht verwirren lassen: Instanz '1' vom influxdb-Adapter ist auf die Influx-V2-db verbunden.

Warum werden eingentlich pro measurement 4 Querys abgeschickt?

im Vergleich dazu die selben 2 measurements mit den komplett selben Parametern, jedoch aus Influx-V1:

2023-03-09 09:28:06.403 - debug: influxdb.0 (391) Incoming message getHistory from system.adapter.admin.0
2023-03-09 09:28:06.403 - debug: influxdb.0 (391) 0_userdata.0.Zaehler.SmartMeter.Zaehlerstand16783504864030.7789047989952527 getHistory message: {"id":"0_userdata.0.Zaehler.SmartMeter.Zaehlerstand","options":{"start":1678264098244,"end":1678350498244,"aggregate":"minmax","from":false,"ack":false,"q":false,"addID":false,"count":300,"instance":"system.adapter.influxdb.0","sessionId":156,"user":"system.user.admin"}}
2023-03-09 09:28:06.404 - debug: influxdb.0 (391) Query to execute: SELECT value from "0_userdata.0.Zaehler.SmartMeter.Zaehlerstand" WHERE time <= '2023-03-08T08:28:18.244Z' ORDER BY time DESC LIMIT 1;SELECT * from "0_userdata.0.Zaehler.SmartMeter.Zaehlerstand" WHERE time > '2023-03-08T08:28:18.244Z' AND time < '2023-03-09T08:28:18.244Z' ORDER BY time ASC;SELECT value from "0_userdata.0.Zaehler.SmartMeter.Zaehlerstand" WHERE time >= '2023-03-09T08:28:18.244Z' LIMIT 1
2023-03-09 09:28:06.484 - debug: influxdb.0 (391) Send: 602 of: 7669 in: 81ms
2023-03-09 09:28:06.935 - debug: influxdb.0 (391) Incoming message getHistory from system.adapter.admin.0
2023-03-09 09:28:06.936 - debug: influxdb.0 (391) 0_userdata.0.Zaehler.SmartMeter.aktuelleLeistung16783504869360.16072003977466132 getHistory message: {"id":"0_userdata.0.Zaehler.SmartMeter.aktuelleLeistung","options":{"start":1678264098244,"end":1678350498244,"aggregate":"minmax","from":false,"ack":false,"q":false,"addID":false,"count":300,"instance":"system.adapter.influxdb.0","sessionId":156,"user":"system.user.admin"}}
2023-03-09 09:28:06.937 - debug: influxdb.0 (391) Query to execute: SELECT value from "0_userdata.0.Zaehler.SmartMeter.aktuelleLeistung" WHERE time <= '2023-03-08T08:28:18.244Z' ORDER BY time DESC LIMIT 1;SELECT * from "0_userdata.0.Zaehler.SmartMeter.aktuelleLeistung" WHERE time > '2023-03-08T08:28:18.244Z' AND time < '2023-03-09T08:28:18.244Z' ORDER BY time ASC;SELECT value from "0_userdata.0.Zaehler.SmartMeter.aktuelleLeistung" WHERE time >= '2023-03-09T08:28:18.244Z' LIMIT 1
2023-03-09 09:28:07.003 - debug: influxdb.0 (391) Send: 1122 of: 7328 in: 67ms

apollon77

Am Ende macht der Adapter bei InfluxDB 1 das gleiche.

4 Queries weil:
1.) Spezieller check wegen Datentypenkram um zu sehen was für Daten drin stehen weil boolean und Zahlen anders selektiert erden müssen
2.) Ein Wert VOR dem eigentlichen Zeitraum
3.) Der Zeitraum
4.) Ein Wert NACH dem eigentlichen Zeitraum

2 und 4 sind dazu da das wir für die Grafische Darstellung im zweifel den Wert vor als ersten Wert zum Zeitraumstart einfügen können und am Ende einen ans Ende. Sonst würde der Chart irgendwann erst nach dem startdatum einen ersten Wert haben und vor dem Ende enden (oder den ersten /letzten Wert fälschlicherweise als "der galt auf davor/danach" annehmen und damit verfälschen.

Wer weiss und rausfindet wie man diese Queries mit fluxQL optimieren kann gern Zeit investieren - genau dafür haben ich aktuell eher keine Zeit und dazu muss man kein Entwickler sein.

Nehmt die Query aus dem Log prüft was rauskommt und schaut ob es bessere/performantere Queries gibt die das gleiche Ergebnis liefern.

mango1402

@apollon77
So, dies ist der Übeltäter:

from(bucket: "iobrokerV2")
|> range(start: 2022-03-08T08:17:20.688Z, stop: 2023-03-08T08:17:20.687Z)
|> filter(fn: (r) => r["_measurement"] == "0_userdata.0.Zaehler.SmartMeter.aktuelleLeistung")
|> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value")
|> group()
|> sort(columns: ["_time"], desc: true)
|> limit(n: 1)

benötigt im Influx-Frontend 5,24s. Ein bisserl lang für genau einen Wert.... (OK, durchsucht ja auch ein ganzes Jahr ;) )

Wenn man es so macht, kommt genau das selbe raus, aber in 0,01s:

from(bucket: "iobrokerV2")
|> range(start: 2022-02-08T08:28:18.244Z, stop: 2023-02-08T08:28:18.244Z)
|> filter(fn: (r) => r["_measurement"] == "0_userdata.0.Zaehler.SmartMeter.aktuelleLeistung")
|> last()
|> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value")
|> limit(n: 1)

Abfrage für den ersten Wert nach Bereich ließe sich auch optimieren und damit 0,06s rausholen:

from(bucket: "iobrokerV2")
|> range(start: 2023-02-09T08:17:20.689Z)
|> filter(fn: (r) => r["_measurement"] == "0_userdata.0.Zaehler.SmartMeter.aktuelleLeistung")
|> first()
|> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value")
|> limit(n: 1)

Der Datenabruf selbst schaut in Ordnung aus. Braucht bei 24h lediglich 0,10. Sollte noch im Rahmen sein.
Ob nun mit pivot und sortieren, oder ohne spielt keine Rolle.

Was ich noch nicht verstehe ist die erste Abfrage nach bool.
Bei mir macht es bei der 'Hauptabfrage' keinen Unterschied, welcher Datentyp gespeichert ist.

Jetzt wär's toll das Ganze in's coding zu bringen, dann kann ich es auch im Echtbetrieb ausprobieren.

mango1402

So, hab nun selbst gebastelt und den Adapter mal angepasst.
Ergebnis:

2023-03-11 10:28:33.910 - debug: influxdb.1 (3577787) Incoming message getHistory from system.adapter.admin.0
2023-03-11 10:28:33.910 - debug: influxdb.1 (3577787) 0_userdata.0.Zaehler.SmartMeter.Zaehlerstand16785269139100.18926732151144776 getHistory message: {"id":"0_userdata.0.Zaehler.SmartMeter.Zaehlerstand","options":{"start":1678440515587,"end":1678526915587,"aggregate":"minmax","from":false,"ack":false,"q":false,"addID":false,"count":300,"instance":"system.adapter.influxdb.1","sessionId":5,"user":"system.user.admin"}}
2023-03-11 10:28:33.911 - debug: influxdb.1 (3577787) Query to execute:
from(bucket: "iobrokerV2")
|> range(start: 2023-03-10T09:28:35.587Z, stop: 2023-03-11T09:28:35.587Z)
|> filter(fn: (r) => r["_measurement"] == "0_userdata.0.Zaehler.SmartMeter.Zaehlerstand" and contains(value: r._value, set: [true, false]))
|> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value")
|> group()
2023-03-11 10:28:34.012 - debug: influxdb.1 (3577787) Query to execute: from(bucket: "iobrokerV2")
|> range(start: 2022-03-10T09:28:35.587Z, stop: 2023-03-10T09:28:35.586Z)
|> filter(fn: (r) => r["_measurement"] == "0_userdata.0.Zaehler.SmartMeter.Zaehlerstand")
|> last()
|> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value")
2023-03-11 10:28:34.030 - debug: influxdb.1 (3577787) Query to execute: from(bucket: "iobrokerV2") |> range(start: 2023-03-10T09:28:35.587Z, stop: 2023-03-11T09:28:35.587Z) |> filter(fn: (r) => r["_measurement"] == "0_userdata.0.Zaehler.SmartMeter.Zaehlerstand") |> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value") |> sort(columns:["_time"], desc: false)
2023-03-11 10:28:34.181 - debug: influxdb.1 (3577787) Query to execute: from(bucket: "iobrokerV2")
|> range(start: 2023-03-11T09:28:35.588Z)
|> filter(fn: (r) => r["_measurement"] == "0_userdata.0.Zaehler.SmartMeter.Zaehlerstand")
|> first()
|> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value")
2023-03-11 10:28:34.237 - debug: influxdb.1 (3577787) Send: 602 of: 7557 in: 327ms
2023-03-11 10:28:34.445 - debug: influxdb.1 (3577787) Incoming message getHistory from system.adapter.admin.0
2023-03-11 10:28:34.445 - debug: influxdb.1 (3577787) 0_userdata.0.Zaehler.SmartMeter.aktuelleLeistung16785269144450.6908542122702093 getHistory message: {"id":"0_userdata.0.Zaehler.SmartMeter.aktuelleLeistung","options":{"start":1678440515587,"end":1678526915587,"aggregate":"minmax","from":false,"ack":false,"q":false,"addID":false,"count":300,"instance":"system.adapter.influxdb.1","sessionId":5,"user":"system.user.admin"}}
2023-03-11 10:28:34.446 - debug: influxdb.1 (3577787) Query to execute:
from(bucket: "iobrokerV2")
|> range(start: 2023-03-10T09:28:35.587Z, stop: 2023-03-11T09:28:35.587Z)
|> filter(fn: (r) => r["_measurement"] == "0_userdata.0.Zaehler.SmartMeter.aktuelleLeistung" and contains(value: r._value, set: [true, false]))
|> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value")
|> group()
2023-03-11 10:28:34.542 - debug: influxdb.1 (3577787) Query to execute: from(bucket: "iobrokerV2")
|> range(start: 2022-03-10T09:28:35.587Z, stop: 2023-03-10T09:28:35.586Z)
|> filter(fn: (r) => r["_measurement"] == "0_userdata.0.Zaehler.SmartMeter.aktuelleLeistung")
|> last()
|> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value")
2023-03-11 10:28:34.556 - debug: influxdb.1 (3577787) Query to execute: from(bucket: "iobrokerV2") |> range(start: 2023-03-10T09:28:35.587Z, stop: 2023-03-11T09:28:35.587Z) |> filter(fn: (r) => r["_measurement"] == "0_userdata.0.Zaehler.SmartMeter.aktuelleLeistung") |> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value") |> sort(columns:["_time"], desc: false)
2023-03-11 10:28:34.664 - debug: influxdb.1 (3577787) Query to execute: from(bucket: "iobrokerV2")
|> range(start: 2023-03-11T09:28:35.588Z)
|> filter(fn: (r) => r["_measurement"] == "0_userdata.0.Zaehler.SmartMeter.aktuelleLeistung")
|> first()
|> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value")
2023-03-11 10:28:34.716 - debug: influxdb.1 (3577787) Send: 1111 of: 7198 in: 271ms

Ergebnis: laut Debugs Verbesserung der Laufzeit von 11,8s auf 0,8s.

apollon77

@mango1402 Goil ... machste einen PR? oder wenigstens die Infos bitte ins GitHub Issue.

DANKE!

Homoran

@apollon77 passt das dann auch zu history und flot?
da gibt es einige Threads, dass das zu lange dauert.

apollon77

@homoran Ja klar ... wenn die alle sich um InfluxDB drehen dann betrifft der Fix dort alle

Community Forum

NEWS

"Warn" Logeinträge InfluxDB-Adapter

Support us

215

32.4k

81.4k

1.3m