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

[bitwicht]

@Marc-Berg

Wenn ich neun Nullen anhänge und auf Nanosekunden stelle, kommt wieder der Fehler:

PV-SEWeb-Ertrag-Tag value="15.616" 1704376800000000000

Wie könnten wir den Fehler debugen?
Da steht ja einfach nur "unknown error".
Steht in der Shell oder Log mehr?

[Marc Berg]

@bitwicht sagte in Ertrag (Tag, Monat, Jahr) berechnen und in Datei speichern:

Wie könnten wir den Fehler debugen?
Da steht ja einfach nur "unknown error".
Steht in der Shell oder Log mehr?

ja, das ginge. Dazu müsstest du mit einem Editor deiner Wahl die Datei

 /etc/influxdb/config.toml

um den Eintrag

log-level = "debug"

ergänzen. Danach DB neu starten

sudo systemctl stop influxdb
sudo systemctl start influxdb

Dann kannst du dir den Output mit

journalctl -u influxdb -n 30

anschauen.

[Marc Berg]

@bitwicht
Ein anderer Ansatz, sich des Problems zu nähern: Du legst einfach mal ein neues, temporäres Bucket an und versuchst, da rein zu importieren. Kannst du ja gleich wieder löschen.

[bitwicht]

@Marc-Berg

interessant.
Ich habe ein neues Bucket (test01) angelegt.
Hier konnte ich ohne Probleme die PV-SEWeb-Ertrag-Tag value="15.616" 1704376800 in Sekunden schreiben.

Nur was ist jetzt das Problem mit dem andren Bucket ?

[Marc Berg]

@bitwicht sagte in Ertrag (Tag, Monat, Jahr) berechnen und in Datei speichern:

Nur was ist jetzt das Problem mit dem andren Bucket ?

du bist nicht allein mit dem Prob: https://community.influxdata.com/t/influxdb-2-1-1-internal-server-error-timestamp-related/23994

Abhilfe bietet wohl ein Umkopieren der gesamten Daten in ein neues Bucket, löschen des alten, wieder anlegen und zurückkopieren.

from(bucket: "iobroker")
  |> range(start: -10y)
  |> to(bucket: "iobroker_tmp")

[bitwicht]

@Marc-Berg

Habs gerade gelesen. In Beitrag schreibt aber jemand ich muss dann auch die Tokens neu anlegen ?

Ich teste das mal.

Ich lege ein neues Bucket an.
Berechtige die Tokens auf das neue.
Lösche das alte
Lege das alte neue an
Berechtige die Tokens vom neuen auf das "alte-neu-angelegte"

Vielleicht kann ich die bestehendes Tokens so übernehmen

[Marc Berg]

@bitwicht sagte in Ertrag (Tag, Monat, Jahr) berechnen und in Datei speichern:

Habs gerade gelesen. In Beitrag schreibt aber jemand ich muss dann auch die Tokens neu anlegen ?

Nein, das ist nicht so. Es sei denn, du hättest Bucket-bezogene Berechtigungen vergeben, was ich nicht glaube.

[bitwicht]

@marc-berg

Ich hab den Befehl ausgeführt.

Allerdings sind im Bucket iobroker viel mehr measurements wie im iobroker_tmp.

Er bleibt immer bei ca. 21s hängen - falls das % sein sollen

Den influx Adapter hatte ich beendet während er kopiert.

[Marc Berg]

@bitwicht sagte in Ertrag (Tag, Monat, Jahr) berechnen und in Datei speichern:

Er bleibt immer bei ca. 21s hängen - falls das % sein sollen

Oh dear, schwere Geburt! :-)

Wahrscheinlich ist dein System zu langsam, um die Aktion innerhalb des Timeout-Zeitraums zu beenden. Du könntest jetzt Measurement für Measurement kopieren, indem du eine Filterbedingung einfügst:

from(bucket: "iobroker")
  |> range(start: -10y)
  |> filter(fn: (r) => r["_measurement"] == "test")
  |> to(bucket: "iobroker_tmp")

Hiermit kannst du alle Measurements inkl. der Anzahlen ausgeben lassen (wenn es denn dein System schafft):

from(bucket: "iobroker")
|> range(start: -10y)
|> filter(fn: (r) => r["_field"] == "value")
|> count()
|> group()
|> keep(columns: ["_measurement", "_value"])
|> sort(columns: ["_value"], desc: true)
|> rename(columns: {_value: "Anzahl"})

[bitwicht]

@Marc-Berg

Ohje, das sind ca. 120 measurements.
Da bin ich ja fast am aufgeben :-(

Wenn ich mich in die CLI auf der Shell einlese, ist da auch ein Timeout ?

[Marc Berg]

@bitwicht sagte in Ertrag (Tag, Monat, Jahr) berechnen und in Datei speichern:

Wenn ich mich in die CLI auf der Shell einlese, ist da auch ein Timeout ?

Das muss serverseitg gemacht werden, d.h. in der config.toml. Müsste ich selbst googeln.

Wenn du dich mit Regex auskennst, könntest du auch mehrere Measurements in einer Abfrage selektieren. Z.B. das ganze Alphabet durch.

  |> filter(fn: (r) => r["_measurement"] =~ /^A/)
  |> filter(fn: (r) => r["_measurement"] =~ /^B/)

[bitwicht]

@marc-berg

Das habe ich gefunden:

Hello, I bumped at this post since I wanted to do the same. In order to set longer timeout there are two settings that need to be configured: session-renew-disabled session-length Steps: In /etc/influxdb/config.toml file add: session-renew-disabled = true session-length = 1440 # session renewa…

Das teste ich gleich mal.

Ich würde es auch mal per Shell versuchen.
Wäre das so richtig zusammengebaut:

sudo influx query --token xxxxxxxxxxxxxxxxxxxx 'from(bucket:"iobroker") |> range(start: 1970-08-28T22:00:00Z) |> to(bucket: "iobroker_tmp")'

[Marc Berg]

@bitwicht sagte in Ertrag (Tag, Monat, Jahr) berechnen und in Datei speichern:

Ich würde es auch mal per Shell versuchen.
Wäre das so richtig zusammengebaut:

sieht gut aus.

[Marc Berg]

@bitwicht

Ich würde ja sagen, dass es am schnellsten ginge, das Bucket zu löschen und das Backup zurückzuspielen. Ich halte es aber nicht für unwahrscheinlich, dass der Fehler danach wieder drin steckt.

[bitwicht]

@Marc-Berg

Backup geht wohl nicht, hat schon jemand gemacht.
Über die Shell läuft es seit 1 Minute.
Wenn nicht muss ich den Timeout in der Config hoch setzen oder deaktivieren.

[bitwicht]

@Marc Berg

ich glaube das macht so keinen Sinn. Der Kopiert wohl noch 2 Tage ....
Ich merke gerade ich schreibe alle meine Datenpunkte nahezu pro Sekunde in die Influx.

Ich glaube ich muss die DB neu aufbauen mit diesen Downsampling-Bucket:
https://forum.iobroker.net/topic/58462/datenaufzeichnung-retention-influxdb-2-0/21

[Marc Berg]

@bitwicht sagte in Ertrag (Tag, Monat, Jahr) berechnen und in Datei speichern:

Ich merke gerade ich schreibe alle meine Datenpunkte nahezu pro Sekunde in die Influx.

Ja, das bricht wohl jeder Hardware irgendwann den Hals. Ich denke auch, in dieser Situation ist es das Beste, grundsätzlich neu anzufangen, die vorhandenen Daten aggregiert in ein anderes Bucket zu schreiben und sich zu überlegen, wie man schon ganz am Anfang die Datenflut begrenzen kann. Der Adapter bietet da ja einige Möglichkeiten.

[bitwicht]

@Marc-Berg

Immerhin, wieder etwas gelernt.

Wenn ich den Datenpunkt in die Influx schreiben lasse gibt es die Option: Blockzeit

Verstehe ich das richtig, dass ich hier 5 Min einstellen könnte und er dann nur alle 5 Minuten einen Wert wegschreibt auch wenn es davon eine Veränderung gab?

Damit könnte ich die Datenflut auch etwas eingrenzen.

[Marc Berg]

@bitwicht sagte in Ertrag (Tag, Monat, Jahr) berechnen und in Datei speichern:

Verstehe ich das richtig, dass ich hier 5 Min einstellen könnte und er dann nur alle 5 Minuten einen Wert wegschreibt auch wenn es davon eine Veränderung gab?

Das ist eine Möglichkeit, ja. Ich persönlich finde es besser, den Haken "Nur Änderungen aufzeichnen" zu setzen und zusätzlich ausschließlich die minimale Differenz (je nach Eingangsdaten) einzutragen. Damit kann ich z.B. Temperaturänderungen von kleiner 0.2K ausfiltern, bekomme aber trotzdem kurzfristige signifikante Schwankungen mit, die mir mit der Blockzeit ggf. verloren gingen. Das ist aber natürlich sehr von den Eingangsdaten abhängig.

[bitwicht]

@Marc-Berg

Wenn ich ein neues Bucket anlege und den iobroker darauf umstelle, werden die measuremnts glaube automatisch neu erstellt und mit daten gefüllt.

Wenn ich dann vom alten Bucket 2,3 measuremnts mit dem Befehl rüber kopiere, bleiben dann die neuen Daten erhalten? also wir das hinzugefügt ?

from(bucket: "iobroker")
  |> range(start: -10y)
  |> filter(fn: (r) => r["_measurement"] == "test")
  |> to(bucket: "iobroker_tmp")