InfluxDB 2 und Umzug auf neuen PI

[StealthAngel]

Hallo,

um einen Hardwarecrash vorzubeugen habe ich mit Backitup ein Backup erstellt. (Hier lief eine InfluxDB Version 1.x)

Dann habe ich einen neuen PI aufgesetzt ioBroker und InfluxDB 2.x installiert und das Backup zurück gespielt.
Die Daten der Influx werden jetzt auf einem USB-Stick gespeichert (wegen zyklischem schreiben auf ein Flash. Ich hoffe das so nur der Stick stirbt und nicht die Flash-Karte im Pi).
Hat auch soweit erstmal funktioniert.

Allerdings gibt es jetzt in den Logs die Fehlermeldung

influxdb.0 2023-12-02 13:37:27.056	error	HttpError: runtime error @4:12-4:132: filter: type conflict: bool != string

Hat jemand eine Ahnung, wie ich herausbekomme, welches Objekt den Fehler verursacht?

Um jetzt für einen Hardwarecrash gewappnet zu sein, habe ich die SD-Karte geklont und in einen zweiten Pi gesteckt.
(Dieser hat einen zweiten (identisch großen) USB-Stick, der auch gleich gemountet wurde)

Dieser verweigert jetzt allerdings den Zugriff auf die Datenbank mit dem Fehler

influxdb.0 2023-12-02 13:30:29.066	error	HttpError: unauthorized access

Ich denke mal das in dem SuperUser Token für Influxdb 2.x evtl. die Hardware codiert ist?

Könnt Ihr mir sagen, was ich tun kann, damit ich Zugriff auf die Datenbank bekomme?

Vielen Dank....

[StealthAngel]

Für den 2. Teil hab ich glaube ich einen Lösungsansatz gefunden.

Die eigentliche Datenbank scheint auf dem 2. Stick noch nicht angelegt zu sein.
Muss mal schauen, wie ich die jetzt am besten klone

[Marc Berg]

@stealthangel sagte in InfluxDB 2 und Umzug auf neuen PI:

Dann habe ich einen neuen PI aufgesetzt ioBroker und InfluxDB 2.x installiert und das Backup zurück gespielt.

Und wo sind deine Daten von der InfluxDB 1.x jetzt?

Die Daten der Influx werden jetzt auf einem USB-Stick gespeichert (wegen zyklischem schreiben auf ein Flash. Ich hoffe das so nur der Stick stirbt und nicht die Flash-Karte im Pi).

Ich denke mal das in dem SuperUser Token für Influxdb 2.x evtl. die Hardware codiert ist?

Nein, noch nie. Ich bin mir nicht sicher, ob ich es richtig verstanden habe, aber wenn der 2. Stick leer ist, wird ein neuer Token angelegt. Das kann dann nicht mehr passen.

[StealthAngel]

@marc-berg said in InfluxDB 2 und Umzug auf neuen PI:

Und wo sind deine Daten von der InfluxDB 1.x jetzt?

Gar nirgends. Ich habe das Backup der 1.x Daten nicht zurück gespielt. Ich wollte mit einer leeren Datenbank starten.
So wie es aussieht wurden alle Objekte neu angelegt. Nur eines scheint Probleme zu machen, aber ich finde nicht heraus welches

[Marc Berg]

@stealthangel sagte in InfluxDB 2 und Umzug auf neuen PI:

Gar nirgends. Ich habe das Backup der 1.x Daten nicht zurück gespielt. Ich wollte mit einer leeren Datenbank starten.

So viel Aufwand, wie du betreibst dachte ich, dass dir die Daten wichtig sind, aber okay.

So wie es aussieht wurden alle Objekte neu angelegt. Nur eines scheint Probleme zu machen, aber ich finde nicht heraus welches

Einfach die Influx Instanz auf "Debug" schalten, dann siehst du es.

[StealthAngel]

Hmm, sieht so aus. Werde aber nicht schlau daraus:

2023-12-02 17:08:27.512 - debug: influxdb.0 (1500) Query to execute: from(bucket: "iobroker") |> range(start: 2023-11-30T16:08:27.406Z, stop: 2023-12-02T16:08:27.406Z) |> filter(fn: (r) => r["_measurement"] == "hm-rpc.1.00181D89B4E7B4.1.ILLUMINATION") |> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value") |> sort(columns:["_time"], desc: false)
2023-12-02 17:08:27.515 - debug: influxdb.0 (1500) Query to execute: from(bucket: "iobroker")
|> range(start: 2023-12-02T16:08:27.395Z)
|> filter(fn: (r) => r["_measurement"] == "hm-rpc.1.00181D89B4E7B4.1.HUMIDITY")
|> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value")
|> group()
|> sort(columns: ["_time"], desc: false)
|> limit(n: 1)
2023-12-02 17:08:27.553 - debug: influxdb.0 (1500) Query to execute: from(bucket: "iobroker") |> range(start: 2023-11-30T16:08:27.407Z, stop: 2023-12-02T16:08:27.407Z) |> filter(fn: (r) => r["_measurement"] == "0_userdata.0.NodeRedVar.Regenmenge_Heute") |> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value") |> sort(columns:["_time"], desc: false)
2023-12-02 17:08:27.570 - debug: influxdb.0 (1500) Query to execute: from(bucket: "iobroker")
|> range(start: 2023-12-02T16:08:27.407Z)
|> filter(fn: (r) => r["_measurement"] == "hm-rpc.1.00181D89B4E7B4.1.ILLUMINATION")
|> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value")
|> group()
|> sort(columns: ["_time"], desc: false)
|> limit(n: 1)
2023-12-02 17:08:27.575 - debug: influxdb.0 (1500) Send: 38 of: 42 in: 169ms
2023-12-02 17:08:27.583 - debug: influxdb.0 (1500) Query to execute: from(bucket: "iobroker") |> range(start: 2023-11-30T16:08:27.407Z, stop: 2023-12-02T16:08:27.407Z) |> filter(fn: (r) => r["_measurement"] == "hm-rpc.1.00181D89B4E7B4.1.ACTUAL_TEMPERATURE") |> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value") |> sort(columns:["_time"], desc: false)
2023-12-02 17:08:27.599 - debug: influxdb.0 (1500) Query to execute: from(bucket: "iobroker") |> range(start: 2023-11-30T16:08:27.407Z, stop: 2023-12-02T16:08:27.407Z) |> filter(fn: (r) => r["_measurement"] == "hm-rpc.1.00181D89B4E7B4.1.WIND_SPEED") |> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value") |> sort(columns:["_time"], desc: false)
2023-12-02 17:08:27.614 - debug: influxdb.0 (1500) Send: 82 of: 127 in: 195ms
2023-12-02 17:08:27.630 - debug: influxdb.0 (1500) Query to execute: from(bucket: "iobroker")
|> range(start: 2023-12-02T16:08:27.408Z)
|> filter(fn: (r) => r["_measurement"] == "0_userdata.0.NodeRedVar.Regenmenge_Heute")
|> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value")
|> group()
|> sort(columns: ["_time"], desc: false)
|> limit(n: 1)
2023-12-02 17:08:27.647 - debug: influxdb.0 (1500) Query to execute: from(bucket: "iobroker")
|> range(start: 2023-12-02T16:08:27.408Z)
|> filter(fn: (r) => r["_measurement"] == "hm-rpc.1.00181D89B4E7B4.1.ACTUAL_TEMPERATURE")
|> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value")
|> group()
|> sort(columns: ["_time"], desc: false)
|> limit(n: 1)
2023-12-02 17:08:27.659 - error: influxdb.0 (1500) HttpError: runtime error @4:12-4:144: filter: type conflict: bool != string
2023-12-02 17:08:27.673 - debug: influxdb.0 (1500) Send: 50 of: 54 in: 243ms
2023-12-02 17:08:27.682 - debug: influxdb.0 (1500) Query to execute: from(bucket: "iobroker")
|> range(start: 2023-12-02T16:08:27.408Z)
|> filter(fn: (r) => r["_measurement"] == "hm-rpc.1.00181D89B4E7B4.1.WIND_SPEED")
|> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value")
|> group()
|> sort(columns: ["_time"], desc: false)
|> limit(n: 1)
2023-12-02 17:08:27.709 - debug: influxdb.0 (1500) Send: 87 of: 127 in: 288ms
2023-12-02 17:08:29.220 - debug: influxdb.0 (1500) Write Point: mqtt.0.Heizung_1.WWSp_Oben.WWSp_Oben values:{"value":48.69,"time":"2023-12-02T16:08:29.218Z","from":"system.adapter.mqtt.0","q":0,"ack":true} options: null
2023-12-02 17:08:29.228 - debug: influxdb.0 (1500) Point written to iobroker
2023-12-02 17:08:30.222 - debug: influxdb.0 (1500) Write Point: mqtt.0.Heizung_1.WWSp_Out.WWSp_Out values:{"value":44.56,"time":"2023-12-02T16:08:30.220Z","from":"system.adapter.mqtt.0","q":0,"ack":true} options: null
2023-12-02 17:08:30.230 - debug: influxdb.0 (1500) Point written to iobroker
2023-12-02 17:08:34.131 - debug: influxdb.0 (1500) PING OK

[Marc Berg]

@stealthangel sagte in InfluxDB 2 und Umzug auf neuen PI:

Werde aber nicht schlau daraus

Ich auch nicht, ich denke mal durch die Asynchronität lässt es sich schwer zuordnen. Kannst du versuchen, die Anzahl der Requests zu reduzieren? Also z.B. Flot/echarts abschalten und teils deaktivieren.

[StealthAngel]

Ich habe scheinbar ein Problem beim scheiben von String in die Influxdb. Wenn ich diese Objekte schreibe

kann ich die Daten anschießend nicht auslesen, wenn ich auf das Zahnrad drücke.

Zuerst habe ich gedacht, es könnte was in der Datenbank stehen, so dass die Typen evtl. nicht passen.
Also die Einträge in der Datenbank gelöscht, aber das Verhalten bleibt gleich.
Im nächsten Schritt einen neuen Eintrag definiert, der vorher nicht existierte:

Auch hier gleiches Verhalten. Aber jetzt kommt es. Lege ich einen Alias davon an und schreibe den Alias in die Datenbank klappt es

Habt Ihr eine Ahnung, was da los sein könnte?

[Marc Berg]

@stealthangel sagte in InfluxDB 2 und Umzug auf neuen PI:

Habt Ihr eine Ahnung, was da los sein könnte?

Versuche mal, den Datentyp auf "automatisch" zu setzen, ob sich dann was ändert.

[StealthAngel]

@marc-berg said in InfluxDB 2 und Umzug auf neuen PI:

Versuche mal, den Datentyp auf "automatisch" zu setzen, ob sich dann was ändert.

Du bist mein persönlicher Held des Tages

Ich hätte schwören können, dass ich das bereits probiert hatte.
Aber egal, es funktioniert

[Marc Berg]

@stealthangel sagte in InfluxDB 2 und Umzug auf neuen PI:

Aber egal, es funktioniert

Ja, das ist ein seltsamer Bug, der auftritt, auch wenn die Datentypen passen. Ich hatte aber noch nicht die Muße, das reproduzierbar zu gestalten und ein Issue draus zu machen.