sinnvolle Persistence für Wechselrichter

[Yfkt5A]

Hallo zusammen,

was ist sinnvoll welche Werte wann zu speichern?

Es geht mir dabei vorallem um den Wert der Tagesleistung, also wieviel die PV an diesem Tag produziert hat...

hätte es jetzt mal so probiert:

Strategies {
        taeglichvorzwoelf  : "59 23 * * * ?"
}

Items {
        PV_*_Leistung_AC: strategy = everyChange, restoreOnStartup
        PV_*_Tagesleistung: strategy = taeglichvorzwoelf, restoreOnStartup
        PV_*_Strom_DC: strategy = everyChange, restoreOnStartup
        PV_*_Leistung_DC: strategy = everyChange, restoreOnStartup
        PV_*_Spannung_DC: strategy = everyChange, restoreOnStartup
        PV_*_Temperatur: strategy = everyChange, restoreOnStartup
        PV_*_Wirkungsgrad: strategy = everyChange, restoreOnStartup
}​

Meinungen, Verbesserungen?

[udo1toni]

Da hast Du etwas missverstanden. Der * ist kein Joker, er darf ausschließlich am Ende eines ausgeschriebenen Group Items stehen. Ist das Group Item so markiert, so wird nicht das Item selbst persistiert, sondern alle unmittelbaren Member. Beispiel:

Group eineGruppe "Ein Group Item"
Switch einSwitch "Ein Switch Item" (eineGruppe)
Number eineZahl "Ein Number Item" (eineGruppe)

Jetzt kannst Du im *.persist File mit

...
Items {
    eineGruppe* : strategy = everyChange
}

beide Items einSwitch und eineZahl persistieren. eineGruppe wird hingegen nicht persistiert.

Weiter. Um welche Persistence soll es sich denn handeln? Denn wenn Du rrd4j nutzt, musst Du zwingend everyMinute nutzen - für jedes Item.

Und dann der cron Ausdruck. openHAB nutzt Quartz cron, das unterscheidet sich vom üblichen crontab.unter anderem dergestalt, dass es sekundengenau funktioniert.
Mithin steht die erste Zahl für die laufende Sekunde in der Minute und die zweite Zahl für die Minute innerhalb der Stunde. Erst die dritte Zahl ist die Stunde, danach folgen Tag im Monat und Monat, als letztes noch der Wochentag. taeglichvorzwoelf triggert also stündlich, um xx:23:59

Mit restoreOnStartup ist das auch so eine Sache. Das Wiederherstellen des Status führt ja zwangsläufig zu einem inaktuellen Stand, je nach Wert kann es sinnvoller sein, keinen gültigen Wert zu haben, anstatt eines alten Wertes.

[Yfkt5A]

Themaverfehlung, setzen 6!

Da passt ja garnichts

Dir udo1toni natürlich vielen Dank für die Hinweise.

Also erstmal versuchen das geradezuziehen:

pv.items:

Group PV_persitent_eC "Photovoltaik persistent jede Änderung"
Group PV_persitent_tvz "Photovoltaik persistent täglich vor zwölf"
Number PV_WR1_Leistung_AC "Wechselrichter 1 aktuelle Leistung" (PV_persitent_eC)
Number PV_WR1_Tagesleistung "Wechselrichter 1 Tagesleistung" (PV_persitent_tvz)​

pv.persist:

Strategies {
        taeglichvorzwoelf  : "0 59 23 * * ?"
}

Items {
        PV_persitent_eC*: strategy = everyChange, restoreOnStartup
        PV_persitent_tvz*: strategy = taeglichvorzwoelf, restoreOnStartup
}​​

Ist das so jetzt besser? Wenn ja, könnten wir zur eigentlichen Frage kommen...

Weiter. Um welche Persistence soll es sich denn handeln?

Im Hintergrund werkelt mariaDB

Mit restoreOnStartup ist das auch so eine Sache. Das Wiederherstellen des Status führt ja zwangsläufig zu einem inaktuellen Stand, je nach Wert kann es sinnvoller sein, keinen gültigen Wert zu haben, anstatt eines alten Wertes.

Genau auf Sachen wie dies zielte die eigentliche Frage ab.
Wann ist restoreOnStartup sinnvoll?
Tagesleistung reicht 1mal am Ende des Tages zu speichern -> taeglichvorzwoelf?
Die anderen Werte die sich ständig ändern -> everyChange? so dass man auch schöne Kurven in der smartVISU erzeugen kann.

[udo1toni]

Ja, das sieht viel besser aus

Was das Persistieren der Tagesleistung betrifft, so finde ich es ebenso interessant, wie sich der Wert über den Tag entwickelt, aber das ist natürlich auch eine Geschmacksfrage
smartVISU kenne ich nicht, ich nutze für die Charts Grafana und dort als Datenquelle InfluxDB, aber das läuft auf das gleiche hinaus, hübsche Kurven InfluxDB ist auf Messwerterfassung spezialisiert und äußerst schlank, was die Systemanforderungen betrifft (ich lasse das hier in einem Container laufen, RAMbedarf im Idle weniger als 200MByte, wenn er Daten liefern muss geht es mal auf 300MByte hoch, aber das war's dann auch... die Prozessorkerne kann er natürlich auslasten, speziell, wenn große Mengen angefordert werden, z.B. die Temperaturverläufe aller Räume (11) der letzten 30 Tage, sowas dauert dann etwas) Aber MariaDB habe ich auch noch laufen für andere Daten

restoreOnStartup holt, wie gesagt, lediglich den letzten persistierten Wert und lädt ihn in ein noch nicht initialisiertes Item, und zwar ausschließlich, wenn openHAB gerade startet. Ich nutze hauptsächlich knx und kann deshalb beim Systemstart alle Zustände aller Aktoren und Sensoren aktiv vom Bus anfordern. Auch mein Wechselrichter liefert seine Daten auf Anforderung beim Start. Der Stromzähler aktualisiert wie Werte mehrfach pro Sekunde, also auch kein Bedarf... es bleiben nur eine Handvoll Items übrig (vor allem solche, die keine reale Hardware haben - z.B. ein Schalter, um einen Schlafgast im Wohnzimmer zu markieren, damit die Rollläden später aufgehen usw.), die sind dann tatsächlich per restoreOnStartup persistiert. Es kommt für restoreOnStartup also nur darauf an, wann die entsprechenden Daten nach einem Neustart automatisch zur Verfügung stehen. Ist die Antwort hier "sehr schnell", lässt Du definitiv restoreOnStartup sein. Ist die Antwort z.B. "um x Uhr", weil der Wert einmal täglich von einer Rule generiert wird, musst Du schauen, ob es sinnvoll möglich ist, die Rule zusätzlich beim Startup zu triggern, um den dann aktuellen Wert zu berechnen. Ist die Antwort "nie" oder "erst nach einer Aktion des Anwenders" ist restoreOnStartup quasi Pflicht. Und natürlich gibt es eine breite Grauzone, in der Du einfach abwägen musst.