data organization: redundant values?

[pohly]

I am looking at your code because I want to adapt it to the values that I get out of a Sonnenbatterie.

In that context I am wondering why the data organization contains energy stats, like importedWh. Isn't that redundant because it can be derived by integrating over the corresponding power stats, in this example meterInW? Is it because the accuracy would be lower?

In that case I should check whether Sonnenbatterie can also report energy stats and record those.

[pohly]

We can also discuss over in https://www.photovoltaikforum.com/thread/150542-umfangreiches-logging-mit-grafana-anleitung/?pageNo=38 (in German ;-), if that is preferred.

[airborneastro]

Hallo Patrick,

der SMA-Wechselrichter bzw. der SMA Sunny Home Manager liefert diese Wh-Werte "frei Haus", deswegen ist eine Integration in diesem Fall also nicht nötig. Redundant ja, aber bequem, da ohne Rechenaufwand. Insbesondere ist auch consumptW in hohem Mass redundant, das hätte man auch in einer query berechnen können. Wie gesagt, work in progress, und Speicherplatz ist billig.

[pohly]

Speicherplatz ist billig

Das ja, aber wie lange dauert es, bis die Verbeitungsgeschwindigkeit dann doch einbricht, weil immer mehr Daten pro Query zu verarbeiten sind? Dazu fehlt mir die Erfahrung. Woanders habe ich gesehen, dass Daten für die Langzeitspeicherung nochmal runterskaliert werden. Keine Ahnung, ob das relevant wird. :shrug:

[pohly]

Mal abgesehen von dem pragmatischen "es ist halt da" (:smile: ), was wäre denn wünschenswerter: aktuelle Leistung oder Gesamtenergie?

Vermutlich Gesamtenergie, weil dann die Genauigkeit des Samplings weniger ins Gewicht fällt. Allerdings frage ich mich dabei was passiert, wenn früher oder später der Zähler in der Hardware zurückgesetzt wird (sei es wegen Softwareupdate oder schlicht Austausch der Hardware). Dann hat man einen Messwert mit "1000kWh" und den nächsten mit "0kWh". Gibt es bei Queries die Möglichkeit, so einen Rückwärtssprung auszugleichen?

[airborneastro]

So ein Rücksprung läßt sich in der influxdb2 mit einem entsprechenden |> map in flux und zurückschreiben in die Datenbank lösen. Meine Lösung arbeitet mit Differenzen des Wh-Zählers, es wäre also nur ein Wert betroffen. In meinem SMA kann man wohl auch einen Offset auf den "total kWh"-Wert setzen und damit nach dem Hardwaretausch den alten Zählerstand wieder herstellen.

Ich habe zur Langzeitspeicherung ein paar Tasks in der influxdb eingerichtet (nicht in diesem repository gezeigt), mit denen aggregates über die measurements in einem gröberen Zeitraster in ein "history-bucket" abgespeichert werden. Dann kann man für queries über lange Zeiträume die query-Laufzeit in Grenzen halten. Bei queries über 7 Tage für Daten im 5s-sampling wird es für den raspberry schon etwas eng, aber noch praktikabel.

Speicher: ein 256GB-Speicherstick am raspberry kostet zwar um die 55 Euro, hält aber lange...

Was das sampling der Leistungsdaten angeht, müsste man erst mal das sampling des Energiemessgeräts (hier : Sunny Home Manager) kennen. Ein "normaler" kWh-Zähler macht das wohl mit 2 kHz. So schnell schafft das die Software nicht. Es käme dann auf den "schnellsten Verbraucher" an.

[pohly]

Ich hab nachgeschaut, die Sonnenbatterie liefert keine Energie, nur Leistung. Damit fällt für mich das Problem mit dem Rücksprung weg, stattdessen muss ich halt mal schauen, wie genau das Integrieren der gesampelten Leistung am Ende ist.

Irgendeinen Tipp, wie ich in Queries wie z.B. https://github.com/airborneastro/photovoltaics/blob/3c1066ce2959cebdb796612941603b47e1110c6a/SMA%20Smart%20Energy%2010.0-1697030388119.json#L916 importedWh durch meterInW ersetzen könnte? Ich bin bei Flux absoluter Anfänger - das muß sich noch ändern, aber "Starthilfe" wäre willkommen.

[airborneastro]

Ich verstehe nicht ganz, wozu genau Du einen Tip brauchst. Zum Integrieren hat flux eine Funktion. Wh sollte dann mit |> integral(unit: 1h) gehen.

edit: Ich habe es eben ausprobiert: mit z.B. from(bucket: "PV-Anlage") |> range(start: v.timeRangeStart, stop: v.timeRangeStop) |> filter(fn: (r) => r["_measurement"] == "power-stats") |> filter(fn: (r) => r["_field"] == "consumptW") |>integral(unit:1h) und meinem sampling der Leistungswerte alle 5sec erhalte ich die gleichen Werte wie aus den Wh-Zählern des Wechselrichters/Energymeters, auch wenn ich über 7 Tage rechne.

Wenn es darum geht, Daten aus verschiedenen measurements (hier: energy-stats und power-stats) in einer query zu verarbeiten, geht das mit den normalen Filtern in Flux: |> filter(fn: (r) => r["_measurement"] == "energy-stats" or r["_measurement"] == "power-stats") |> filter(fn: (r) => r["_field"] == "importedWh" or r["_field"] == "meterInW") Ich bin kein flux-Experte, habe vorher auch noch nicht damit gearbeitet. Es hilft anfangs schon mal, wenn man sich im Data Explorer von InfluxDB2 im "Query Builder" eine query zusammenklickt und sich die flux query dazu dann im "Script Editor" anschaut.