@sborg
Oh Mann, da hätte ich doch auch selbst drauf kommen können. Ich war in einem anderen Zusammenhang schon über Mehrfachwerte bei Flux-Abfragen gestolpert...
Aber OK, der Reihe nach.
Ich habe beim Umstieg auf Influx 2.7 eine neue IOBroker DB "iobroker2/global" angelegt. Die alten "iobroker/global" und "iobroker/autogen wurden ja automatisch beim Influx-Umstieg migriert.
Im IOBroker habe ich dann im Influx-Adapter das Häkchen für "Verwende Tags, anstelle von Feldern,..." gesetzt, da es mir immer spanisch vorkam, dass die als Felder geschrieben wurden (passte nicht zu der Erklärung in der Influx-Doku).
Ich hatte auch die Hoffnung, dass das den Arbeitsspeicherhunger der Influx etwas bändigen könnte, an der Stelle hat es aber nicht geholfen, die gönnt sich immer noch 50% mehr als vor dem Umstieg die 1.8.x.
Dafür ist, nach umkopieren der alten "iobroker/global" in die neue "iobroker2/global" die Datenbank auf der SSD keine 1,6GB mehr groß sondern nur noch 600MB.
Allerdings zum eigendlichen Problem:
Eine Abfrage in Flux liefert die Ergebnisse dann immer sortiert in "tables". Die Tables haben immer die identischen Werte der Tags gruppiert.
D.h. alles was an Tags q=0, ack=true, from=system.adapter.influxdb.0 hat landet in einem Table. Alles was q=0, ack=true, from=system.adapter.simple-api.0 im nächsten. Wenn q nicht gleich 0 oder ack=false gibt es weitere tables.
Heißt, man muß diese Tables vor dem min/max/mean, bzw. generell vor dem Weiterverarbeiten, erstmal zusammenführen.
Das habe ich bei dem oben genannten "anderen Zusammenhang" durch ein zwischengeschaltetes:
|> drop(columns: ["ack", "from", "q"]) |> sort(columns: ["_time"])
gemacht.
Was natürlich die Gefahr birgt, dass der Influx-Adapter in Zukunft mal weitere Tags einführt...
Es ginge auch mit einem:
|> keep(columns: ["_value"]) |> sort(columns: ["_time"])
dann ist die Ausgabe aber anders formatiert.
Beispiele:
Die Ursprungs-query aus der wetterstation.sub "influx_query()" Funktion liefert dieses Ergebnis:
influx query 'from(bucket: "iobroker2/global") |> range(start: -1d, stop: now()) |> filter(fn: (r) => r._measurement == "javascript.0.Wetterstation.Aussentemperatur" and r._field == "value") |> max()'
Result: _result
Table: keys: [_start, _stop, _field, _measurement, ack, from, q]
_start:time _stop:time _field:string _measurement:string ack:string from:string q:string _time:time _value:float
------------------------------ ------------------------------ ---------------------- ------------------------------------------- ---------------------- ------------------------- ---------------------- ------------------------------ ----------------------------
2023-08-19T11:50:41.246763433Z 2023-08-20T11:50:41.246763433Z value javascript.0.Wetterstation.Aussentemperatur true system.adapter.influxdb.0 0 2023-08-19T12:16:26.633000000Z 31.22
Table: keys: [_start, _stop, _field, _measurement, ack, from, q]
_start:time _stop:time _field:string _measurement:string ack:string from:string q:string _time:time _value:float
------------------------------ ------------------------------ ---------------------- ------------------------------------------- ---------------------- --------------------------- ---------------------- ------------------------------ ----------------------------
2023-08-19T11:50:41.246763433Z 2023-08-20T11:50:41.246763433Z value javascript.0.Wetterstation.Aussentemperatur true system.adapter.simple-api.0 0 2023-08-19T12:15:26.615000000Z 31.22
Ergänzt mit dem "drop" und "sort" nur noch ein Table:
influx query 'from(bucket: "iobroker2/global") |> range(start: -1d, stop: now()) |> filter(fn: (r) => r._measurement == "javascript.0.Wetterstation.Aussentemperatur" and r._field == "value") |> drop(columns: ["ack", "from", "q"]) |> sort(columns: ["_time"]) |> max()'
Result: _result
Table: keys: [_start, _stop, _field, _measurement]
_start:time _stop:time _field:string _measurement:string _time:time _value:float
------------------------------ ------------------------------ ---------------------- ------------------------------------------- ------------------------------ ----------------------------
2023-08-19T11:57:11.324077570Z 2023-08-20T11:57:11.324077570Z value javascript.0.Wetterstation.Aussentemperatur 2023-08-19T12:15:26.615000000Z 31.22
Das sieht dann meiner Meinung nach so aus, wie dass, was Deine Abfrage liefert (hier an einer anderen meiner DBs, die keine Tags hat, probiert):
influx query 'from(bucket: "vito2/autogen") |> range(start: -1d, stop: now()) |> filter(fn: (r) => r._measurement == "vito" and r._field == "TempAtp") |> max()' Result: _result
Table: keys: [_start, _stop, _field, _measurement]
_start:time _stop:time _field:string _measurement:string _time:time _value:float
------------------------------ ------------------------------ ---------------------- ---------------------- ------------------------------ ----------------------------
2023-08-19T12:03:41.255250302Z 2023-08-20T12:03:41.255250302Z TempAtp vito 2023-08-19T12:35:00.000000000Z 28.6
Nur zur Ergänzung: die Ausgabe mit dem "keep" sieht völlig anders (und viel übersichtlicher) aus:
influx query 'from(bucket: "iobroker2/global") |> range(start: -1d, stop: now()) |> filter(fn: (r) => r._measurement == "javascript.0.Wetterstation.Aussentemperatur" and r._field == "value") |> keep(columns: ["_value"]) |> sort(columns: ["_time"]) |> max()'
Result: _result
Table: keys: []
_value:float
----------------------------
31.22
Was ich jetzt noch nicht ausprobiert habe ist, ob das Resultat identisch aussieht, wenn man anstatt der influx-cli zum Abfragen curl nimmt (wie in Deinem Script)?!
Und was ich so ad hoc auch nicht absehen kann: Ob ein Ergänzen der Query in der Funktion influx_query() um das "drop" und "sort" an anderer Stelle eine negative Auswirkung hat?!
NaJa, Versuch macht kluch... ich baue es mal in die .sub ein und teste mit --influx_test und --metsommer
Gruß
Hefo
Das konnte ich dann aber ganz am Ende noch auf Dateisystem-Ebene hin- und herschieben...
