Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[Stefan Falt]

@ro75
JA, der "kecontact" ist die Keba Wallbox und "smartmeter" der hichi IR Reader am Stromzähler. Beide sind immer recht gesprächig - aber das ist ja nur alle paar Sekunden.

Sollte das zuviel sein? Ich bin kein Profi - aber das sehe ich nicht.

Datenpunkte habe ich ca. 10 Stück. Alle Temperatur Sensoren, Strom ins Netz vom Netz und zwei Steckdosen.

kopfkratz Ich weis nicht was ich noch tun muss. Als nächstes würde ich alles neu auf eine SSD installieren.

[Ro75]

@stefan-falt ist jetzt von mir keine exakte Wissenschaft, aber beim PI gibt es doch die grüne LED. Wie oft blinkt oder leuchtet sogar länger?

Ro75.

[Stefan Falt]

@ro75
Dioe grüne LED blinkt unregelmäßig 0 bis 10 mal pro Sekunde.

[Ro75]

@stefan-falt

Hast du bei den DP schon mal mit der Blockzeit gearbeitet? Für mich würde es reichen, wenn ich aller 10 Sekunden Daten zur Auswertung erfassen würde und nicht wenn der Adapter mir sekündlich oder vielleicht noch öfters Daten bringt. Für nen PI mit SD-Karte kann das schon zuviel werden.

Stelle doch mal bei Blockzeit was zwischen 5000 und 10000 ein. Beobachte das ganze dann mal.

Eine SSD tat meinem PI damals auch mehr als gut. Damit flutschte alles besser.

Ro75.

[Stefan Falt]

@ro75
Hallo,
unverändert. Eine SSD ist bestellt, ich versuchs mal zwischenzeitlich mit einer alten 2,5" Festplatte :)
Ich werde sehen was passiert ....

Danke + MfG
Wolfgang

[OliverIO]

@stefan-falt
Hast du schon mal probiert die query direkt auf der influx ui auszuführen?
Da könnte man die Fehlerursachen mehr eingrenzen.
Auch ein Blick in das influxlog könnte helfen.
Das der request in ein timeout läuft kann mehrere Ursachen haben

• query läuft zu lange
• query bricht wegen Serverfehler ab
• ?
  Das sieht man dieser Fehlermeldung nicht an

So wie es aussieht sucht ihr hier immer den Fehler im iobroker. Influx ist aber ein zusätzliches System das ja auch separat installiert wird. Iobroker bzw der Adapter ist nur ein Client für den DB server

[Stefan Falt]

@oliverio Hallo, danke für das Mitdenken.

influx ui
Werde ich tun, wenn die nächste Probleme auftreten.

Ich habe jetzt eine 2,5" Festplatte angeschlossen, da die bestellte SSD erst am Samstag kommt und ioBroker neu aufgesetzt. Das geht übrigens überraschend gut.

Damit hatte ich allerdings aber auch diese "Query timeout" probleme. Jetzt habe ich den Query Timeout von 30000ms auf 60000ms gestellt, noch geht alles gut.

Ich werde weiter berichten.

MfG
StefanFalt

[Stefan Falt]

@stefan-falt
Hallo, auch mit der neuen Installation auf der 2,5" HDD habe ich den gleichen Fehler. Das ist echt Seltsam.
Ein Typischer Fehler ist:

influxdb.0
	2024-08-13 21:49:26.683	warn	Error in query "from(bucket: "iobroker") |> range(start: 2024-08-12T19:49:00.000Z, stop: 2024-08-13T19:49:00.000Z) |> filter(fn: (r) => r["_measurement"] == "modbus.0.inputRegisters.100.842_Battery_Power_(System)") |> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value") |> sort(columns:["_time"], desc: false)": RequestTimedOutError: Request timed out

Wenn ich die DB Abfrage in den Data Explorer kopiere, macht die DB genau das gleiche. Der Fehler ist also Systematiisch.
Wenn ich die Daten der letzten 3 Stunden anschauen will, klappt es manchmal. Es sieht so aus, als ob die DB unendlich langsam wäre.

Ich werde das ganze mal auf SSD installieren und dann weiterschauen ....
Gibt es noch andere beschreibungen die DB zu installieren als die von Eddy? Vielleicht ist ja in der Beschreibung ein Fehler ....

https://www.youtube.com/watch?v=abV4YRHXb5I&t=1040s

[Ro75]

@stefan-falt welche Version von influxdb läuft? Aktuell ist 2.7.9. Bei einer Vorversion gab es ein Problem 2.7.x Falls die 2.7.6 laufen sollte, könnte das

https://github.com/influxdata/influxdb/issues/25157

die Ursache sein.

Ro75

[OliverIO]

@stefan-falt

Im Zweifel immer die Beschreibung des Herstellers
https://docs.influxdata.com/influxdb/v2/install/?t=Linux

Kannst du die query evtl neu aufbauen?
Bin mit influx query nicht firm, aber auch mit sql kann mann query’s bauen die im nirwana landen. Wenn ich da sehe „pivot“ dann ist das schon aufwändig, da ja die Anzahl der Spalten erst ermittelt werden müssen.

Ich sehe auch das du als rowkey time verwendest, das erzeugt je nach datenumfang auch ne Menge rows. Versuche mal testweise die auf eine Zeitscheibe zu aggregieren, also bspw 5 Minuten. Von da kannst dich dann steigern und schauen wo die Datenbank aussteigt, falls es ein performance/speicherproblem sein sollte.

[Stefan Falt]

@ro75 said in Datenbankfehler - egal wie oft ich neu installiere:

@stefan-falt welche Version von influxdb läuft? Aktuell ist 2.7.9. Bei einer Vorversion gab es ein Problem 2.7.x Falls die 2.7.6 laufen sollte, könnte das

https://github.com/influxdata/influxdb/issues/25157
die Ursache sein.
Ro75

Hallo,
Inzwischen habe ich die Installation auf der 2,5" HDD wieder verworfen und bin wieder auf den MicroSD Speicherchip gagangen.
-> gleiche Fehler.

ioBroker@raspberrypi:~ $ influx version
Influx CLI dev (git: a79a2a1b825867421d320428538f76a4c90aa34c) build_date: 2024-04-16T14:34:26Z

ioBroker@raspberrypi:~ $ curl -sL -I localhost:8086/ping
HTTP/1.1 204 No Content
Vary: Accept-Encoding
X-Influxdb-Build: OSS
X-Influxdb-Version: v2.7.9
Date: Wed, 14 Aug 2024 19:14:49 GMT

... und die Fehler sind unverändert:

influxdb.0
	2024-08-14 21:11:07.235	warn	Error in query "from(bucket: "iobroker") |> range(start: 2024-07-31T19:11:00.000Z, stop: 2024-08-14T19:11:00.000Z) |> filter(fn: (r) => r["_measurement"] == "modbus.0.inputRegisters.100.842_Battery_Power_(System)") |> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value") |> sort(columns:["_time"], desc: false)": RequestTimedOutError: Request timed out

Kann es sein, dass die Datenbank es nicht mag wenn in Zeiträumen gesucht wird, in denen keine Daten vorhanden sind? Kann ich mir aber nicht vorstellen, dann muss ja das Ergebnis "null" sein. (so war es zumindestens in einem früheren Leben auf der Oracle 10g Datenbank)

Bald kommt der 40€ 500GB SSD Stick ... Oo

[Ro75]

@stefan-falt oder einfach viel zu viele Datensätze für den Rechner. Kannst du in Erfahrung bringen, wie viele wes sind?

Ro75.

[OliverIO]

@stefan-falt

Du zeigst immer nur das Iobroker log.
Was sagt das influx log?
https://docs.influxdata.com/influxdb/v2/admin/logs/

Hast du den mal die Daten aggregiert? Das ist das ähnliche was @Ro75 auch meinte.

Wenn du es schon mit 2 Speichermedien probiert hast, wird ein 3. wahrscheinlich kein anderes Ergebnis bringen.

[Wildbill]

@stefan-falt sagte in [Datenbankfehler - egal wie oft ich neu

Kann es sein, dass die Datenbank es nicht mag wenn in Zeiträumen gesucht wird, in denen keine Daten vorhanden sind? Kann ich mir aber nicht vorstellen, dann muss ja das Ergebnis "null" sein. (so war es zumindestens in einem früheren Leben auf der Oracle 10g Datenbank)

Bald kommt der 40€ 500GB SSD Stick ... Oo

Zumindest das kann ich Dir bestätigen. Als ich noch FLOT zur Visualisierung benutzt habe, bin ich auf Geräten mit Touchscreen oder Touchpad beim Versuch, einen anderen Zeitraum einzustellen, auch schon in Bereiche gerutscht, für die es (noch) keine Daten gab. Da kam in iobroker dann auch eine ähnliche Fehlermeldung. Habe ich leider nicht mehr genau im Kopf, aber irgendwas mit range war dabei.

Gruss, Jürgen

[Stefan Falt]

@oliverio said in Datenbankfehler - egal wie oft ich neu installiere:

@stefan-falt

Du zeigst immer nur das Iobroker log.
Was sagt das influx log?
https://docs.influxdata.com/influxdb/v2/admin/logs/

Hast du den mal die Daten aggregiert? Das ist das ähnliche was @Ro75 auch meinte.

Wenn du es schon mit 2 Speichermedien probiert hast, wird ein 3. wahrscheinlich kein anderes Ergebnis bringen.

Hallo Olliver,
danke für deine Zeit.

Das Verzeichnis /var/log/influxdb/ war leer, darum habe ich das logging eingeschaltet:

root@raspberrypi:/# influxd 1>/var/log/influxdb/influxd.log
WARN[0000]log.go:228 gosnowflake.(*defaultLogger).Warn DBUS_SESSION_BUS_ADDRESS envvar looks to be not set, this can lead to runaway dbus-daemon processes. To avoid this, set envvar DBUS_SESSION_BUS_ADDRESS=$XDG_RUNTIME_DIR/bus (if it exists) or DBUS_SESSION_BUS_ADDRESS=/dev/null.
Error: listen tcp :8086: bind: address already in use
See 'influxd -h' for help
root@raspberrypi:/# DBUS_SESSION_BUS_ADDRESS=/dev/null
root@raspberrypi:/#

Dann wollte ich Daten der letzten 24 Stunden Ansehen, dass wurde aber mit dem bekannten Timeout Quittiert.

influxdb.0
	2024-08-15 13:44:18.806	warn	Error in query "from(bucket: "iobroker") |> range(start: 2024-08-14T11:44:00.000Z, stop: 2024-08-15T11:44:00.000Z) |> filter(fn: (r) => r["_measurement"] == "modbus.0.inputRegisters.100.842_Battery_Power_(System)") |> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value") |> sort(columns:["_time"], desc: false)": RequestTimedOutError: Request timed out

Jetzt habe ich mal einen count gemacht und siehe da, ca. 51000 die letzten 24 Stunden. Oder? Da bin ich mich nicht ganz sicher ...

Ich würde jetzt den DB Inhalt löschen, und dann das Aufzeichnen neu starten, mit weniger Daten ...

Was muss ich denn da auswählen, damit nicht mehr so viele Daten anfallen, die Daten aber noch konsistent bleiben? Blockzeit auf 5000ms ???

Stichwort Log:
Das Log ist nach etwas rumspielen leer: "cat /var/log/influxdb/influxd.log"
Aber ich Denke wir haben das Problem gefunden -> Zu viele Datensätze. Oder?

Danke + MfG
Wolfgang

[Ro75]

@stefan-falt stelle die Blockzeit mal auf 5000. Dann werden immer noch genügend Daten geloggt. Aber, das hat keine Auswirkung auf die bisher gesammelte Datenflut und damit auf den Effekt. Das wirst du also erst nach Tagen, respektive auf deinen Zeitraum feststellen können. Also Geduld.

Ro75.

[Stefan Falt]

Danke für den Support bei der Lösungsfindung
Ro75, oliverio, Wildbill