"Warn" Logeinträge InfluxDB-Adapter

[blacksheep587]

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

Ja, und darauf hatte ich geantwortet, dass man die Daten ggf. während der Migration direkt aggrieren sollte, wenn es sehr viele sind. Würde sich ja anbieten nur den Durchschnitt oder den Maximalwert alle x Minuten zu behalten.

Meine trivialen Fragen zeigen dir, dass das meine aktuelle Kompetenz überschreitet

[blacksheep587]

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

Dann siehst Du wie lange es braucht um ein Ergebnis zu liefern.

52,53Sekunden. Ein nochmaliges Aufrufen der Daten habe ich nach 2min abgebrochen.

[haus-automatisierung]

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

52,53Sekunden.

Okay, und das ist mindestens 50 Sekunden zu viel. Die Frage wäre, wo man hier am besten ansetzt. Was genau möchtest du denn in flot wissen? Klingt irgendwie ziemlich unnötig, dass der gesamte Zeitraum von 2 Jahren geladen wird, nur um den letzten Wert zu holen.

Also entweder ein "Bug" im InfluxDB-Adapter (ineffizienter Query) oder Optimierungspotenzial von flot.

[blacksheep587]

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

Also entweder ein "Bug" im InfluxDB-Adapter (ineffizienter Query)

Ich tippe auf Bug, weil auch mit der Standardabfrage in InfluxDB hat sich der Raspberry grad aufgehängt.
Du siehst im Flot-Graph auch die Logging-Ausfälle durch den Datenbank-Zugriff
Flot soll eigentlich sterben, da Grafana deutlich mehr Möglichkeiten hat.

Aktuell visualisiere ich meine PV Anlage und diverse Messwerte in- und um das Haus.

[haus-automatisierung]

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

Flot soll eigentlich sterben, da Grafana deutlich mehr Möglichkeiten hat.

Flot wird (soweit ich weiß) auch nicht mehr weiter entwickelt. eCharts die Ablösung dafür innerhalb von ioBroker. Klar, mit Grafana kannst Du noch mehr machen - musst aber auch mehr wissen und können.

[Homoran]

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

Flot soll eigentlich sterben, da Grafana deutlich mehr Möglichkeiten hat.

was hat das miteinander zu tun?
Grafana hat nichts mit ioBroker zu tun. Das ist ein professionelles 3rd Party Programm.

[blacksheep587]

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

Flot wird (soweit ich weiß) auch nicht mehr weiter entwickelt. eCharts die Ablösung dafür innerhalb von ioBroker. Klar, mit Grafana kannst Du noch mehr machen - musst aber auch mehr wissen und können.

Okay, gute Info bzgl. Flot.

Die deutlich höhere Komplexität von Grafana ist mir bewusst, es gibt aber auch sehr viel Input im Netz, die meine Usecases gut abdecken.
Mein Problem bleibt aber scheinbar weiterhin meine Datenbank. Wie beschrieben, geht beim Datenabgriff mein komplettes System in die Knie. Jetzt wäre meine Frage: Wie kann ich mehr Input liefern, um den Root Cause zu ermitteln? Die Installation habe ich nach "Masterkurs" durchgeführt, die Migration der Daten habe ich nach einem Versuch sein lassen.

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

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

Flot soll eigentlich sterben, da Grafana deutlich mehr Möglichkeiten hat.

was hat das miteinander zu tun?
Grafana hat nichts mit ioBroker zu tun. Das ist ein professionelles 3rd Party Programm.

Naja erstmal nichts, außer dass beide Programme auf die InfluxDB zugreifen.

[OstfrieseUnterwegs]

@blacksheep587
Du könntest mal das böse Query in das userinterface von Influx eingeben und schauen, was passiert

from(bucket: "iobroker_data") 
    |> range(start: 2021-03-05T23:00:00.000Z, stop: 2023-03-05T22:59:59.999Z) 
    |> filter(fn: (r) => r["_measurement"] == "0_userdata.0.Photovoltaik.DC-Leistung_gesamt") 
    |> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value") 
    |> group() |> sort(columns: ["_time"], desc: true) 
    |> limit(n: 1)

von oben kopiert...
Das Pivot könnte influx in die Knie zwingen.

[haus-automatisierung]

@ostfrieseunterwegs Hat er doch schon (siehe oben) und die Ausführung hat ~53 Sek gedauert.

[A Former User]

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

Naja erstmal nichts, außer dass beide Programme auf die InfluxDB zugreifen.

Moin,

auch influxDB ist ein 3rd Party Produkt und hat nur indirekt etwas mit dem ioBroker zu tun.

Ich würde Dir raten, die influxDB nicht auf demselben System zu betreiben, auf dem auch ioBroker läuft und wie oben schon gesagt wurde, reduziere die Daten.

VG
Bernd

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