UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[haus-automatisierung]

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

dass Flot Warnung von Queries generiert wäre mir neu (aber nicht auszuschließen).

Naja Flot wird einfach nur getHistory gegen den InfluxDB-Adapter aufrufen. Und läuft dann wegen sehr vielen Daten in einen Timeout. Wobei das schon extrem viel sein muss, wenn die 30 Sekunden im Standard erreicht werden. Oder wurde da etwas anderes konfiguriert?

[blacksheep587]

@haus-automatisierung Ne, iobroker hat mir angeboten, das Timeout auf 60s zu verlängern; "eine langsame Verbindung wurde erkannt"
Ich habe aber ohnehin seit der Installation von InfluxDB Probleme mit meinem System. Wenn ich in der InfluxDB arbeiten will, oder Daten abrufen, dann geht der Raspberry in die Knie.
Ich hatte bei der Blockzeit bis dato 0 drin stehen und habe dann manuell auf 5000ms gestellt um die Datenmengen zu reduzieren.
Im Masterkurs hatte ich ja gefragt, wegen der großen Datenmengen und dem Migrationsskript. Vielleicht muss ich meine Datenbanken nochmal komplett löschen?!

"Warn" Logeinträge InfluxDB-Adapter:

Insgesamt ist das Statement aber nicht besonders schön gebaut. Da müsste man mal gucken woher das kommt. Alle Daten abzurufen, dann andersrum zu sortieren und nur einen Wert zu holen ist ja extrem ineffizient. Besser wäre last().

Kann ich das standardmäßig irgendwo konfigurieren, dass ich last() drinstehen hab? ich habe das in Grafana jetzt immer erst "per Hand" umgeschrieben.

@Homoran Die Meldung kann ich provozieren, wenn ich in Flot von sql auf influx umstelle:

[haus-automatisierung]

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

Ne, iobroker hat mir angeboten, das Timeout auf 60s zu verlängern

Das war aber der Admin-Adaper und nicht der InfluxDB-Adapter :)

Du kannst das Statement von oben ja mal kopieren und manuell im Data Explorer von InfluxDb ausführen. Dann siehst Du wie lange es braucht um ein Ergebnis zu liefern.

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

Im Masterkurs hatte ich ja gefragt, wegen der großen Datenmengen und dem Migrationsskript.

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.

[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 :-D

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

[Ein ehemaliger Benutzer]

@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