Beta-Test für Tageszusammenfassungen

[ledermann]

Hat jemand Interesse an einem Beta-Test der jüngsten Entwicklungen? Ich habe einige Zeit an Pull-Request #3533 gearbeitet und denke, dass das Ergebnis stabil genug ist, um getestet zu werden. Das ist übrigens unabhängig vom Sponsoring-Status.

Es geht hier nicht um ein neues Feature, sondern um eine interne Verbesserung. Bessere Performance und Genauigkeit der dargestellten Messwerte ist das Ziel.

Nützlich ist diese Neuerung vor allem für folgende Anwendungsfälle:

• Instanzen mit umfangreichen historischen Daten (mehrere Jahre)
• Instanzen, bei denen (einzelne) Messwerte lückenhaft hereinkommen (z.B. Wallbox per MQTT, die nur im Betrieb Daten sendet, nicht aber im Ruhezustand)

Außerdem wird die neue Herangehensweise Ungenauigkeiten beseitigen, die z.B. in #2654, #1894 und #2032 berichtet wurden. Ich markiere mal einige Leute, die involviert waren: @jbaesner, @pietnie, @q2doc, @gereons, @halmich

Die Details erkläre ich genauer im PR, grob umrissen stellt sich die Verbesserung so dar:

• SOLECTRUS legt nun für jeden einzelnen Tag eine "Tageszusammenfassung" in PostgreSQL an, in der für jeden Sensor die Energie (in Wh), Mittelwerte (in W), Minima und Maxima (in W) des Tages gespeichert sind. Bei der Energie-Berechnung wird die Integral-Funktion von InfluxDB benutzt, die zwar relativ langsam ist, aber sehr genau arbeitet - auch bei lückenhaften Messwerten.
• Für die Darstellung eines Zeitraums (Woche/Monat/Jahr/Gesamt) sowie die Top10 und Kacheldarstellung wird ausschließlich auf die Tageszusammenfassungen zurückgegriffen. Das ist sehr viel schneller als mit InfluxDB-Aggregationsfunktionen zu arbeiten. Und es gibt keine Abweichungen mehr.
• Die Tageszusammenfassungen werden während der normalen Benutzung von SOLECTRUS erstellt bzw. aktualisiert.

Beim ersten Start fehlen natürlich die Tageszusammenfassungen für die Vergangenheit. Diese werden nach und nach erstellt - nicht im Hintergrund, sondern wenn man einzelne Zeiträume aufruft. Klickt man beispielsweise auf eine Woche, die noch nicht zusammengefasst ist, erfolgt die Berechnung für diese 7 Tage. Bei einem Monat oder Jahr muss entsprechend mehr berechnet werden. Jeder Tag der Vergangenheit muss nur genau einmal berechnet werden. Die Wartezeit wird mit einem Fortschrittsbalken versüßt ;-) Die Berechnung kann jederzeit unterbrochen werden, indem man woanders hin navigiert.

In der Live-Demo mit Datenmaterial aus vier Jahren dauerte die Gesamtberechnung etwa 10 Minuten. Wohlgemerkt: Einmalig.

Um die Beta-Version auszuprobieren, ist Folgendes zu tun:

1. Bearbeiten der compose.yaml: Dort ist die Zeile image: ghcr.io/solectrus/solectrus:latest durch image: ghcr.io/solectrus/solectrus:pr-3533 zu ersetzen.
2. docker-compose up -d ausführen
3. Nach dem ersten Start auf "Gesamt" oder "Top10" klicken und die Berechnung nach Möglichkeit vollständig durchlaufen lassen.
4. Prüfen, ob Watchtower installiert ist und ggfs. nachholen. Die Beta-Version wird häufig aktualisiert werden, das möchte man nicht manuell machen.

Falls unüberwindbare Probleme auftauchen sollten, kann man wieder zurück auf latest wechseln.

Ich freue mich über Feedback. Bei konkreten Problemen oder Fehlern wäre ein separates Issue vermutlich am besten.

[gereons]

Wow. Ich bin schwer beeindruckt, der Performancegewinn ist ja wirklich massiv. Tolle Arbeit!

Die Berechnung hat auf dem kleinsten Hetzner-Server knapp eine Minute für ungefähr 16 Monate an Daten gebraucht, also seeeehr überschaubar.

[Zeppelin-PV]

... das ist beeindruckend !!!
meine Daten von 25 Monaten waren in zwei Minuten durchgerechnet.
Das Klicken durch die Zeiten, alles in Echtzeit, kein Kringel
... hab mich einfach getraut da mitzumachen

[StevieC121176]

der Performancegewinn ist enorm. Sehr gute Arbeit.
hat bei mir ca. 4min gedauert.

[halmich]

verrückt wie viel schneller die Berechnungen bei euch gehen. Sind die Raspis so viel schneller als ein synology ds220+? Oder habt ihr alle cloud Server 😅

[gereons]

CPU ist hier nicht der limitierende Faktor, eher I/O. Und der ist auf SSDs oder auch SD-Karten halt extrem viel schneller als auf rotierenden rostigen Tellern... 🤷‍♂️

[GalOR7]

Danke @ledermann - ich finde vor allem bei den "Essentials" ist das richtig schnell geworden. Auf dem raspi 4 waren es etwa 3 Minuten zu rechnen - allerdings auch nur 1 Jahr Daten. Echt klasse 👍

[WolfImBusch]

Hi Georg,

bei Beta-Tests bin ich immer gerne dabei .. :-)

Vielleicht stelle ich mich ja zu dämlich an, wenn wenn ich von "latest" auf "pr-3533" in der "compose.yaml" umstelle, bekomme ich folgende Fehlermeldung ...

[+] Running 0/1
⠿ power-splitter Error 1.3s
Error response from daemon: manifest unknown

Hast Du da ne Idee?

Ich danke Dir und viele Grüße!

[ledermann]

Tippfehler wirklich ausgeschlossen? Die Änderung beim richtigen Service eingetragen? Das Tag pr-3533 gehört zum Dashboard, nicht zum Power-Splitter.

Es muss exakt so lauten:

services:
  # ...
  dashboard:
    image: ghcr.io/solectrus/solectrus:pr-3533

[WolfImBusch]

Herzlichen Dank Georg! Ich war natürlich bei Power-Splitter und nicht beim Dashboard "unterwegs" - war also wie befürchtet zu dämlich ... :-)

[ledermann]

Für die technisch Interessierten (also alle 😃) hier mal eine kleine Übersicht, wie der Performance-Gewinn zustande kommt:

Die Grundidee basiert darauf, dass die Tageszusammenfassungen sehr wenig Speicher benötigen. Es sind derzeitig etwa 30 Fließkommazahlen pro Tag. 8 Byte pro Zahl. Bei einer Lebenszeit der PV-Anlage von 20 Jahren entstehen 20 Jahre x 365 Tage/Jahr x 30 Zahlen/Tag x 8 Byte = 1,7 MB. Das ist quasi nichts, das hält PostgreSQL komplett im RAM. Zukünftig, wenn es mehr Sensoren gibt, wird das etwas ansteigen, aber das fällt nicht ins Gewicht.

In InfluxDB stehen hingegen Messwerte im 5s-Takt. Das ist VIEL mehr, grob überschlagen das 17.000-fache ;-)

Es gibt nun drei Szenarien:

1. Einmalige Berechnung der historischen Tageszusammenfassungen: Jeder einzelne Tag wird von InfluxDB berechnet. Insbesondere die Berechnung des Integrals (Energie in Wh) für Messwerte im 5s-Takt ist zeitaufwändig. Auf SSD oder SD-Karte ist das noch erträglich (etwa 500ms pro Tag), bei Festplatten (wie Synology NAS) dauert es länger. Man sieht einen Fortschrittsbalken.

2. Abrufen historischer Zeiträume, die vollständig abgeschlossen sind (z.B. gestern, letzte Woche, letzter Monat, letztes Jahr, ...). Hier gibt es eine Fallunterscheidung:

   a) Falls die Tageszusammenfassung alle vorhanden und vollständig sind: Sehr, sehr schnell, weil ausschließlich auf fertige Tageszusammenfassungen zugegriffen wird. Auch auf Festplatten, weil kaum I/O. InfluxDB ist überhaupt nicht involviert. Hier muss PostgreSQL nur die Tageszusammenfassungen addieren, das geht rasend schnell, auch bei 20 Jahren.

   b) Falls Tageszusammenfassungen fehlen oder unvollständig sind: Nachberechnen, genau wie bei 1). Für jeden fehlenden Tag fallen wieder die 500ms an. Der Fortschrittsbalken erscheint, wenn mehr als zwei Tage zu bearbeiten sind. Wer in seine SOLECTRUS-Instanz also nur alle paar Tage mal hineinschaut, wird immer zunächst einen kurzen Fortschrittsbalken sehen.

3. Abrufen von Zeiträumen, die noch nicht abgeschlossen sind (z.B. heute, aktuelle Woche, aktueller Monat, aktuelles Jahr, Gesamt, Top10, ...): Hier wird zunächst eine vorläufige Tageszusammenfassung für den laufenden Tag berechnet (also mit Integral, d.h. wieder 500ms). Diese hat eine Gültigkeit von 5 Minuten (von mir so festgelegt). Beim Navigieren ist also der erste Abruf etwas langsamer, in den folgenden 5 Minuten dann wieder alles so schnell wie bei 2a) und so weiter.

[Zeppelin-PV]

Frage -

• wird diese Tageszusammenfassung bei einem Backup berücksichtigt / gespeichert ?

[ledermann]

Ja, die Tageszusammenfassungen werden in der PostgreSQL-Datenbank abgelegt. Diese ist Teil der Sicherung, die mit den Backup-Restore-Scripten erstellt/wiederhergestellt werden.

[ledermann]

Danke für den Hinweis. Habe #3599 angelegt, alles Weitere dort.

[ledermann]

Nachdem ich noch einige Zeit an den Details geschraubt habe, funktionieren die Tageszusammenfassungen jetzt ganz ordentlich. Ich habe die Änderung daher nach develop übernommen.

Das Docker-Tag pr-3533 ist nun mit develop identisch. Als nächstes bereite ich das Update auf v0.18.0 vor.

[ledermann]

Die Tageszusammenfassungen sind jetzt Teil der soeben veröffentlichten Version 0.18 🎉

Wer noch develop oder pr-3533 nutzt, könnte/sollte wieder auf latest wechseln.