Monatsrückblick Oktober 2026 ist online!

[stenmic]

@Bluefox die Auswahl wäre mit der neuen Version für mich ok.
Leider funktioniert das löschen nicht.

Auswahl:

Nach "JETZT LÖSCHEN" kommt bei mir:

2026-10-28 15:38:13.925 - warn: influxdb.1 (244851) Cannot remove xxx.aaa: RequestTimedOutError: Request timed out
2026-10-28 15:39:13.929 - warn: influxdb.1 (244851) Cannot remove xxx.bbb: RequestTimedOutError: Request timed out
2026-10-28 15:39:17.583 - warn: influxdb.1 (244851) Cannot remove xxx.ccc: RequestTimedOutError: Request timed out

[Bluefox]

Danke für den Log, damit war die Ursache schnell klar.

Bei InfluxDB 2.x gibt es kein „DROP MEASUREMENT“. Der Adapter löscht deshalb alle Werte des Datenpunkts über die Delete-API. Dabei geht InfluxDB jeden Shard des Buckets durch, und bei einem Bucket mit Daten aus mehreren Jahren dauert das schnell mehrere Minuten. Der Adapter hat aber nur so lange gewartet, wie das normale „Request timeout“ erlaubt (Standard 30 Sekunden), und dann mit RequestTimedOutError abgebrochen.

Ab Version 5.2.3 bekommen Löschvorgänge eine eigene Verbindung und dürfen bis zu 10 Minuten dauern. Das gilt für das Aufräumen in der Statistik und auch für delete, deleteRange und deleteAll. Schreiben und Abfragen behalten das eingestellte Timeout. Die Version ist veröffentlicht und sollte in Kürze im Latest-Repository auftauchen.

Wer nicht warten möchte: In den Instanzeinstellungen das „Request timeout“ vorübergehend auf z. B. 600000 (10 Minuten) setzen, aufräumen, danach wieder zurückstellen.

Das Löschen kann je nach Größe des Buckets trotzdem einige Minuten dauern. Bitte den Dialog so lange offen lassen.

Kannst du mit 5.2.3 noch einmal aufräumen und kurz Bescheid geben, ob es jetzt durchläuft? Falls einzelne Datenpunkte weiter fehlschlagen, bitte den Log-Ausschnitt dazu posten.

[stenmic]

@Bluefox sagte:

Danke für den Log, damit war die Ursache schnell klar.

Bei InfluxDB 2.x gibt es kein „DROP MEASUREMENT“. Der Adapter löscht deshalb alle Werte des Datenpunkts über die Delete-API. Dabei geht InfluxDB jeden Shard des Buckets durch, und bei einem Bucket mit Daten aus mehreren Jahren dauert das schnell mehrere Minuten. Der Adapter hat aber nur so lange gewartet, wie das normale „Request timeout“ erlaubt (Standard 30 Sekunden), und dann mit RequestTimedOutError abgebrochen.

Ab Version 5.2.3 bekommen Löschvorgänge eine eigene Verbindung und dürfen bis zu 10 Minuten dauern. Das gilt für das Aufräumen in der Statistik und auch für delete, deleteRange und deleteAll. Schreiben und Abfragen behalten das eingestellte Timeout. Die Version ist veröffentlicht und sollte in Kürze im Latest-Repository auftauchen.

Wer nicht warten möchte: In den Instanzeinstellungen das „Request timeout“ vorübergehend auf z. B. 600000 (10 Minuten) setzen, aufräumen, danach wieder zurückstellen.

Das Löschen kann je nach Größe des Buckets trotzdem einige Minuten dauern. Bitte den Dialog so lange offen lassen.

Kannst du mit 5.2.3 noch einmal aufräumen und kurz Bescheid geben, ob es jetzt durchläuft? Falls einzelne Datenpunkte weiter fehlschlagen, bitte den Log-Ausschnitt dazu posten.

mit der 5.2.3 funktioniert es, danke

[MondieuX]

Hallo

Wollte kein eigenes Thema aufmachen.
Wenn nicht BITTE schreiben wohin. DANKE.

Der neue Adapter ist SUPER !!! Gratulation und DANKE.
Endlich eine einfache Möglichkeit Datenfehler oder kleine Lücken zu füllen

Für micht gehören die beiden Reiter "Datenbrowser und Statistik" als eigener Eintrag nach LINKS ins Menü (So wie zb. Zigbee2Mqtt).

Was ich mir wünschen würde...
Ich komme immer wieder auf neue Möglichkeiten wie ich schon lange vorhandene Datenreihen berechnen und in Grafana darstellen kann.
Wenn ich jetzt eine kleines Blockly schreibe das mehrere Datenpunkte laufend zu einem wert berechnet, hab ich erst ab diesem Augenblick den neuen Wert.
Jetzt wäre schön wenn es auch den CSV-Export und Import (den es in Influx-GUI schon mal gab) geben würde.
Dann könnte man zB. historische Daten in Excel berechnen und diese wieder in die Influx Importieren.

Als letzter Punkt hab ich noch ein Problem.
Konnte bis jetzt nur "Datenbrowser"Reiter testen.
Wenn ich auf Statistik klicke läuft mein Influxdb-Container innerhalb von Sekunden voll und ist nicht mehr erreichbar.
Adapterversion ist v5.2.3

Nach einiger Zeit kommt im Adpter

• connect EHOSTUNREACH 192.168.???.???:8086 (errno: -113)
• Die Datenbank enthält noch keine Datenpunkte.

Hab schon 3 Stunden gewartet ... Was mache ich falsch ???

DANKE für Info und Hilfe-

[OliverIO]

@MondieuX

Ist die Speicher und SWAP Auslastung bei dir der Normal-Zustand oder nur ein Ergebnis irgendwelcher vorhergehender Aktionen?
Wahrscheinlich wurden Prozesse außer der Reihe beendet, weil das RAM zu ende war.

[MondieuX]

Hallo

Nein, das erste Bild hab ich beim Fehler nachstellen gemacht.
Diese folgenden sind der Normal-Betreib.

Der erste Ausreißer war ob das Problem noch vorhanden ist. Der zweite lange Ausreißer ob es vielleicht doch nach 2 Stunden wieder normal wird.

Wenn man den Container mit STOP beendet und wieder startet läuft alles ohne Probleme weiter ... ausser man steht im ioBroker immer noch am Statistik-Reiter ... dann geht es von vorne los.

DANKE.

[Snopy_16]

@MondieuX @bluefox bei mir ganz dasselbe mit RAM Auslastung im Container

Habs mit der Version 5.2.3 probiert, dasselbe Problem.

---

Und auch in der History Instanz:
Dort finden sich unter Statistik gar keine Daten, obwohl im Reiter Datenbrowser alle vorhanden sind.

[Bluefox]

@Snopy_16 sagte:

@MondieuX @bluefox bei mir ganz dasselbe mit RAM Auslastung im Container

Habs mit der Version 5.2.3 probiert, dasselbe Problem.

---

Und auch in der History Instanz:
Dort finden sich unter Statistik gar keine Daten, obwohl im Reiter Datenbrowser alle vorhanden sind.

Wie soll ich das untersuchen? Logs? Bei mir geht es:

[Snopy_16]

@Bluefox
Mehr kommt nicht, obwohl es eine Menge Daten geben muss.

Nach Klick auf Aufräumen kommt dann sowas

wird etwa in einem falschen Verzeichnis gesucht?

Im LOG steht gar nichts.

[Bluefox]

Geht das überhaupt bei jemandem ausser bei mir?

[mrjeschke]

@Bluefox
Bei meiner kleinen Datenbank mit 40000 Werten sehe ich keine Probleme.
Mit der grossen Datenbank mit 150 Mio. Werten gibt es bei mir auch Probleme mit dem RAM (4BG)
Wenn ich die Statistikseite mehrfach kurz nacheinander anzeigen lasse, ist der RAM voll und
es kommen keine Daten mehr auf der Statistikseite.
Dann muss ich ein paar Minuten warten bis der RAM sich wieder beruhigt hat.
Ich habe dem LXC-Container jetzt 8GB RAM gegeben und damit läuft es jetzt.
Statistik wird angezeigt und aufräumen klappt auch.

[Bluefox]

@mrjeschke sagte:

@Bluefox
Bei meiner kleinen Datenbank mit 40000 Werten sehe ich keine Probleme.
Mit der grossen Datenbank mit 150 Mio. Werten gibt es bei mir auch Probleme mit dem RAM (4BG)
Wenn ich die Statistikseite mehrfach kurz nacheinander anzeigen lasse, ist der RAM voll und
es kommen keine Daten mehr auf der Statistikseite.
Dann muss ich ein paar Minuten warten bis der RAM sich wieder beruhigt hat.
Ich habe dem LXC-Container jetzt 8GB RAM gegeben und damit läuft es jetzt.
Statistik wird angezeigt und aufräumen klappt auch.

Dann gibt es RAM Problem: @snopy_16

Na ja... Ich kann nicht zaubern. Und man braucht mehr RAM

[Snopy_16]

@Bluefox
Influxdb in eigenem Container mit 2GB Ram leuchtet mir ein.
Aber History läuft unter iobroker in einer VM mit 8GB Ram, das sollte dann doch mal reichen.

[peterfido]

Bei meiner kleinen Datenbank, welche einige Werte für drei Monate speichert, kein Problem. Bei der großen Datenbank baut sich die Statistik nicht auf. Ich habe den RAM von 4 auf 8, von 8 auf 16 GB erhöht. Bei 16 sind dann noch 4,5 GB im Cache. Trotzdem reicht es nicht, da der Request-Timeout zuerst greift.

[peterfido]

Mit 16 GB RAM und Request-Timeout auf 60000 geht es dann. Am Ende sind weiterhin 4,5 GB im Cache, sodass 12GB RAM wohl reichen würden .

[rscsb]

@peterfido sagte:

Mit 16 GB RAM und Request-Timeout auf 60000 geht es dann.

Es ist ja wirklich jedem selbst überlassen, was er so ein seine DB schreibt.
Aber 60 Mio. Werte für eine CPU-Temperatur wären mir der Speicherverbrauch und die Verarbeitungszeit nicht wert.

[Rushmed]

@Bluefox sagte:

Geht das überhaupt bei jemandem ausser bei mir?

Ja bei mir.

[ofri2607]

@Bluefox
Ja, bei mir problemlos.
Edit: Pi4 mit 8GB

[OliverIO]

Ich habe von der influxdb eigentlich keine Ahnung.
Kenne mich hauptsächlich mit relationalen Datenbanken aus.

Das Problem liegt wahrscheinlich an sehr großen Datenbanken und wo die Berechnung der Anzahl der Datensätze in einem gewissen Zeitraum tatsächlich abläuft.
Im schlimmsten Fall müssen alle Datensätze gelelesen werden (am schlimmsten wenn sie zum iobroker geladen werden).
Bei relationalen Datenbanken nennt sich das Full table scans, was man bei großen Datenbanken vermeiden sollte.
Als Gegenmaßnahme legt man entsprechende indizies auf die Felder, nachdem man suchen möchte, an. Aber auch hier müssen die entsprechenden Indices in den RAM passen, ansonsten muss auch dieser geladen werden.

Wie influxdb seine Tabellen organisiert, weiß ich nicht, aber eventuell wären das Ansatzpunkte das dahingehend zu optimieren.

Allerdings muss man sagen, dass ein ioBroker Adapter nur begrenzt ein Datenbank Management Tool sein kann.

[peterfido]

@rscsb sagte:

Es ist ja wirklich jedem selbst überlassen, was er so ein seine DB schreibt.
Aber 60 Mio. Werte für eine CPU-Temperatur wären mir der Speicherverbrauch und die Verarbeitungszeit nicht wert.

Dafür gibt es jetzt die zweite Datenbank, welche nur noch drei Monate speichert. Da ziehen alle solche Werte demnächst hin um.

Der NUC 12 bekommt öfter mal Schnappatmung, dann muss ich den wieder reinigen.

Allerdings soll der Wert nur jede Minute kommen. Da muss ich mal schauen, wo die Menge an Werte herkommt. Somit hat sich die Statistik für mich schon gelohnt.