Rule zur Berechnung von Tagesverbrauch

[B0LT]

Hallo,

Kurz zur Erklärung:
Grundsätzlich habe ich eine Rule mit der ich den Netzbezug von meinen Smartmeter (Netzbetreiber) auslese und den Tages, Monat & Jahres Verbrauch berechne.

Nun will ich das aber bei meiner PV auch machen, dazu lese ich mittels Fronius Binding den Wert aus (in mWh). Den gleichen Wert hole ich dann auch noch über die API direkt (in Wh).

Allerdings funktioniert die Berechnung nicht, das OpenHAB einfach ins unendliche rechnet. Ich vermute das die Zahl einfach zu lange ist.

Die Rule sieht nun folgendermaßen aus:

Code: Alles auswählen

when
  
    Item gen24_yield_all1 received update 
   
then
    
	val  ZonedDateTime 	zdt = ZonedDateTime.now()

    var  ZonedDateTime 	start_of_day = zdt.toLocalDate().atStartOfDay(zdt.getZone())
    var  ZonedDateTime 	start_of_month = zdt.withDayOfMonth(17).toLocalDate().atStartOfDay(zdt.getZone())
    var  ZonedDateTime 	start_of_year = zdt.withDayOfYear(351).toLocalDate().atStartOfDay(zdt.getZone())

        var gen24_yield_day = gen24_yield_all1.deltaSince((start_of_day),"influxdb") as Number
        var gen24_yield_month = gen24_yield_all1.deltaSince((start_of_month),"influxdb") as Number
        var gen24_yield_year = gen24_yield_all1.deltaSince((start_of_year),"influxdb") as Number

        gen24_yield_all1.postUpdate(gen24_yield_day)
        gen24_yield_all1.postUpdate(gen24_yield_month)
        gen24_yield_all1.postUpdate(gen24_yield_year)
        
end

die Items dazu:
gen24_yield_all1 (in Wh)

Code: Alles auswählen

8085416.2594444444

gen24_yield_all (in mWh)

Code: Alles auswählen

8.0854162594444444

gibt es dazu irgend eine Lösung das die Berechnung funktioniert ohne das sich OpenHAB tot rechnet?

vielen dank im vorraus!

[udo1toni]

Herzlich willkommen im openHAB Forum!

Ich nehme mal an, Du meinst MWh, nicht mWh (Megawattstunden vs. Milliwattstunden)
Die erste Frage ist: welche Version von openHAB nutzt Du?
Wenn Du openHAB3 oder openHAB4 nutzt, sollte das Fronius Binding direkt QuantityType liefern. Wenn Du über http mit openHAB3.4 oder openHAB4 weitere Daten einsammelst, kannst Du auch dort QuantityType verwenden.
Wenn Du openHAB4 verwendest, ist es sehr wichtig, bei QuantityType Items auch noch den unit Parameter korrekt zu setzen, sinnvollerweise setzt Du unit für alle Items gleich, die miteinander zu tun haben werden. unit bestimmt, wie der Wert von der Persistence gespeichert wird, denn die Persistence hat mit QuantityType nichts am Hut, sie speichert nur nackte Zahlen. Mein Tipp wäre, hier für beide Items kWh zu verwenden (Kilowattstunden). Achte auch darauf, was in den Variablen tatsächlich landet (also das Delta). Evtl. steht hier auch die Unit mit dabei, das kann beim Schreiben in ein Item ebenfalls zu Problemen führen.

Ganz allgemein sollte eine Abfrage des Wertes zum Jahresbeginn allerdings weder bei InfluxDB noch bei rrd4j sonderlich lange dauern, es geht ja nur um einen Einzelwert, nicht um alle Werte seitdem...
Stehen die Werte auch für die Zeitpunkte zur Verfügung? Das könnte sonst zum Problem werden.

Die Zeitpunkte erscheinen mir im Übrigen etwas seltsam. So sollte das für openHAB ab Version 3 aussehen:

Code: Alles auswählen

val startOfDay = now.with(LocalTime.MIDNIGHT)
val startOfMonth = startOfDay.withDayOfMonth(1)
val startOfYear = startOfDay.withDayOfYear(1)

[B0LT]

Erstmal danke für deine Antwort

Ich nehme mal an, Du meinst MWh, nicht mWh (Megawattstunden vs. Milliwattstunden)

natürlich mein ich Megawattsunden, entschuldige da hab ich mich vertan.

Die erste Frage ist: welche Version von openHAB nutzt Du?

4.0.4

Wenn Du openHAB3 oder openHAB4 nutzt, sollte das Fronius Binding direkt QuantityType liefern. Wenn Du über http mit openHAB3.4 oder openHAB4 weitere Daten einsammelst, kannst Du auch dort QuantityType verwenden.

Ich nutze das Fronius Binding, nutze aber kein QuantityType. Generell nutze ich das nicht, ich lasse mir nur nackte zahlen in meine InfluxDB schreiben.

Wenn Du openHAB4 verwendest, ist es sehr wichtig, bei QuantityType Items auch noch den unit Parameter korrekt zu setzen, sinnvollerweise setzt Du unit für alle Items gleich, die miteinander zu tun haben werden. unit bestimmt, wie der Wert von der Persistence gespeichert wird, denn die Persistence hat mit QuantityType nichts am Hut, sie speichert nur nackte Zahlen. Mein Tipp wäre, hier für beide Items kWh zu verwenden (Kilowattstunden). Achte auch darauf, was in den Variablen tatsächlich landet (also das Delta). Evtl. steht hier auch die Unit mit dabei, das kann beim Schreiben in ein Item ebenfalls zu Problemen führen.

Ganz allgemein sollte eine Abfrage des Wertes zum Jahresbeginn allerdings weder bei InfluxDB noch bei rrd4j sonderlich lange dauern, es geht ja nur um einen Einzelwert, nicht um alle Werte seitdem...
Stehen die Werte auch für die Zeitpunkte zur Verfügung? Das könnte sonst zum Problem werden.

Das problem ist schlicht ergreifend das openHAB es nichtschafft bekommt die werte richtig auszurechnen. Er probiert was zu berechnen, landet im minus was ständig hochgezählt wird. Dann geht ihn anscheinen der Speicher aus und er beginnt von vorne.

Zum thema Zeitpunkte:

Die Zeitpunkte erscheinen mir im Übrigen etwas seltsam. So sollte das für openHAB ab Version 3 aussehen:

Code: Alles auswählen

val startOfDay = now.with(LocalTime.MIDNIGHT)
val startOfMonth = startOfDay.withDayOfMonth(1)
val startOfYear = startOfDay.withDayOfYear(1)

Genau deswegen stehen die Zahlen auf den gewissen Tagen, weil ich ab dort daten hatte. Sonst funktioniert die Berechnung nicht. Darf man nur nicht vergessen am 1. die Berechnung umzustellen. Das funktioniert im übrigen mit der gleichen Rule in vielen Berechnungen seit teilweise weit über 1 Jahr absolut problemlos. Ich lese unter anderem auch den Smartmeter von meinen Netzbetreiber aus, dort geht das ebenfalls talldelos!


Hier mal die Ausgabe der Rule, wenn sie versucht den Tagesverbrauch zu berechnen, Das item gen24_yield_all liefert den Wert von Fronius Binding

Code: Alles auswählen

2023-12-21 22:08:45.761 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'gen24_yield_all' changed from -257.1177232694444005 to -257.0674895708332895
2023-12-21 22:08:45.788 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'gen24_yield_all' changed from -257.0674895708332895 to -265.1529058302777325
2023-12-21 22:08:45.788 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'gen24_yield_all' changed from -265.1529058302777325 to -265.1026721316666215
2023-12-21 22:08:45.813 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'gen24_yield_all' changed from -265.1026721316666215 to -273.1880883911110645
2023-12-21 22:08:45.813 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'gen24_yield_all' changed from -273.1880883911110645 to -273.1378546924999535
2023-12-21 22:08:45.838 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'gen24_yield_all' changed from -273.1378546924999535 to -281.2232709519443965
2023-12-21 22:08:45.839 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'gen24_yield_all' changed from -281.2232709519443965 to -281.1730372533332855
2023-12-21 22:08:45.863 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'gen24_yield_all' changed from -281.1730372533332855 to -289.2584535127777285
2023-12-21 22:08:45.864 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'gen24_yield_all' changed from -289.2584535127777285 to -289.2082198141666175
2023-12-21 22:08:45.892 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'gen24_yield_all' changed from -289.2082198141666175 to -297.2936360736110605
2023-12-21 22:08:45.892 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'gen24_yield_all' changed from -297.2936360736110605 to -297.2434023749999495
2023-12-21 22:08:45.920 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'gen24_yield_all' changed from -297.2434023749999495 to -305.3288186344443925
2023-12-21 22:08:45.921 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'gen24_yield_all' changed from -305.3288186344443925 to -305.2785849358332815
2023-12-21 22:08:45.946 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'gen24_yield_all' changed from -305.2785849358332815 to -313.3640011952777245
2023-12-21 22:08:45.946 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'gen24_yield_all' changed from -313.3640011952777245 to -313.3137674966666135
2023-12-21 22:08:45.971 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'gen24_yield_all' changed from -313.3137674966666135 to -321.3991837561110565
2023-12-21 22:08:45.971 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'gen24_yield_all' changed from -321.3991837561110565 to -321.3489500574999455
2023-12-21 22:08:45.996 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'gen24_yield_all' changed from -321.3489500574999455 to -329.4343663169443885
2023-12-21 22:08:45.996 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'gen24_yield_all' changed from -329.4343663169443885 to -329.3841326183332775
2023-12-21 22:08:46.027 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'gen24_yield_all' changed from -329.3841326183332775 to -337.4695488777777205
2023-12-21 22:08:46.027 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'gen24_yield_all' changed from -337.4695488777777205 to -337.4193151791666095
2023-12-21 22:08:46.053 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'gen24_yield_all' changed from -337.4193151791666095 to -345.5047314386110525
2023-12-21 22:08:46.053 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'gen24_yield_all' changed from -345.5047314386110525 to -345.4544977399999415
2023-12-21 22:08:46.078 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'gen24_yield_all' changed from -345.4544977399999415 to -353.5399139994443845
2023-12-21 22:08:46.078 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'gen24_yield_all' changed from -353.5399139994443845 to -353.4896803008332735
2023-12-21 22:08:46.104 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'gen24_yield_all' changed from -353.4896803008332735 to -361.5750965602777165
2023-12-21 22:08:46.105 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'gen24_yield_all' changed from -361.5750965602777165 to -361.5248628616666055
2023-12-21 22:08:46.130 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'gen24_yield_all' changed from -361.5248628616666055 to -369.6102791211110485
2023-12-21 22:08:46.130 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'gen24_yield_all' changed from -369.6102791211110485 to -369.5600454224999375

So rechnet er das ins unendliche, dann fängt er irgendwann wieder von vorne an.


deaktiviere ich die rule, dann springt der wert sofort wieder auf das richtige um

Code: Alles auswählen

2023-12-21 22:10:26.484 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'gen24_yield_all' changed from -2547.0945194083329095 to 8.0935349366666665

und hier von einen anderen Wert, wo die berechnung funktioniert. Rule ist dort wie gesagt die gleiche zur berechnung:

Code: Alles auswählen

2023-12-21 22:15:56.087 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'PowerIN_Today' changed from 35.30100000 to 35.30800000

[udo1toni]

Ich nutze das Fronius Binding, nutze aber kein QuantityType. Generell nutze ich das nicht, ich lasse mir nur nackte zahlen in meine InfluxDB schreiben.

In der InfluxDB landen ohnehin immer nur nackte Zahlen. Was QuantityType betrifft, so ist die Benutzung jetzt noch optional, das wird sich aber mit hoher Wahrscheinlichkeit ändern. Ich kann also nur raten, dass Du Dich damit auseinandersetzt und die Items entsprechend "aufrüstest"

Das problem ist schlicht ergreifend das openHAB es nicht schafft bekommt die werte richtig auszurechnen

openHAB rechnet da nicht viel aus, es fragt bei der Datenbank nach der Differenz der beiden Werte, die auch aus der Datenbank stammen. Wenn überhaupt, dann liefert also InfluxDB keine Daten.

So rechnet er das ins unendliche, dann fängt er irgendwann wieder von vorne an.

Ja, kein Wunder (auf den zweiten Blick...) denn Du schreibst das Ergebnis der Berechnung in das Item, welches die Rule auslöst, das muss ja zu einer Endlosschleife führen. Du musst die postUpdates am Ende der Rule in die korrekten Items vornehmen lassen (nicht in Sack und Asche gehen, ist mir auch bei der ersten Antwort durchgerutscht...)

[B0LT]

In der InfluxDB landen ohnehin immer nur nackte Zahlen. Was QuantityType betrifft, so ist die Benutzung jetzt noch optional, das wird sich aber mit hoher Wahrscheinlichkeit ändern. Ich kann also nur raten, dass Du Dich damit auseinandersetzt und die Items entsprechend "aufrüstest"

Danke für den Hinweis, ich werde mich damit näher auseinander setzen und mein meine Items "upgraden" - so wie ich das beim schnellen drüberlesen gesehn habe kann man dann die Werte gut von Wh in kWh konvertieren bzw openhab macht das dann selbst.

Ja, kein Wunder (auf den zweiten Blick...) denn Du schreibst das Ergebnis der Berechnung in das Item, welches die Rule auslöst, das muss ja zu einer Endlosschleife führen. Du musst die postUpdates am Ende der Rule in die korrekten Items vornehmen lassen (nicht in Sack und Asche gehen, ist mir auch bei der ersten Antwort durchgerutscht...)

Oh mein Gott, wie blöd kann ich nur sein. Ist ja logisch das es dann nicht funktioniert Asche auf mein Haupt, jetzt gehts natürlich sang und klaglos. Das einzige was ich noch schauen muss ist, das der Ertrag mit der Fronius Web Ansicht nicht zusammen passt - aber das ist ein eine andere Geschichte.

Vielen Dank für das Aufklären meines eigenes Fehlers

[B0LT]

Ich muss das Thema nun nochmal hervorbringen, weil die Berechnung von dem Fronius Total Wert hinten und vorne nicht passt mit dem Solar.web

Ich habe ja die aktuelle Ausgangsleistung von der PV in Watt. Eigentlich müsste es ja möglich sein die Summe von der Produktion in Tag zusammen zu zählen und dann den Wert in kWh ausgeben. Dies muss dann aber jeden Tag passieren, als Berechnungszeitraum von 0-24 Uhr. Die Daten sind ja vorhanden, da ich den Wert persistieren lasse in meine InfluxDB.

Ich hab mich schon etwas gespielt, und auch probiert irgend eine Rule zu finden welche mir zumindest einen Hinweis gibt wie ich das lösen kann. Allerdings steh ich nun etwas auf dem Schlauch wie ich das Realisieren soll.

Gleiches Gilt für die Batterie. Da bekomme ich ja ebenfalls die Leistung ZUR und VON der Batterie geliefert in Watt. Leistung zur Batterie wird in Minus (-) Werten angezeigt, Leistung von der Batterie in Plus (+) Werten.

Damit könnte ich mir dann auch den Eigenverbrauch, Direktverbrauch und was in den bzw aus der Batterie bezogen ist berechnen.
Netzeinspeisung und Verbrauch hol ich mir vom direkt vom Smartmeter vom Netzbetreiber.

Somit könnte man dann das Solar.web selbst nachstellen, nur das die daten viel aktueller sind und bei mir zuhause am Server berechnet werden.

[oh73]

ich hab da ein ähnliches Problem,
mein SMA Wechselrichter liefert mir über den Modbus den Gesamt Tagesertrag, von 2 Inverter.
habe aber die West-, und Ostseite getrennte Erträge, InverterA und InverterB, die mir aber nur als momentan Ertrag angezeigt werden.
deshalb hab ich mir eine Rule dafür geschrieben, die dem momentan Ertrag zu einem Tages Ertrag zusammen rechnet.

ist noch in der Versuchs Phase, scheint aber zu funktionieren,
nur morgens beim ersten Start , gefällt mir das Ergebnis noch nicht ganz!
da hab ich immer so ca. 400 Watt drin und weiß nicht woher

hab allerdings heute noch mal die Abfrage von dem Stand vorher geändert, hoffe das das Morgen richtig ist.

Code: Alles auswählen

rule "Inverter A auswerten"
when 
    Item inverter1PowerA changed 
then
    var inverterA_Watt = (inverter1PowerA.state as Number)
    if (inverterA_Watt > 0 ) {
        var Ertrag_A_vorher = inverter1PowerA.previousState(true,"jdbc").state as Number // Ertrag vor dem Update
        var inverterA = smertragA32.lastUpdate("jdbc")                              // Zeitpunt letztes Update
        var A_Zeit = Duration.between (inverterA, ZonedDateTime.now()).toSeconds()  // Differenz in Sekunden

        //logInfo("InverterA","Watt_X {}", inverterA_Watt ) 
        //logInfo("InverterA","InverterA {}", inverterA ) 
        //logInfo("Inverter_Zeit","TIME {}", A_Zeit ) 
        
        var ertragA_alt = 0
        if((smertragA32.state instanceof Number))                                   // Tagesertrag alten Stand lesen
            ertragA_alt = smertragA32.state as Number
        
        if (Ertrag_A_vorher > 0 ) {
            var ertragA = ertragA_alt + (Ertrag_A_vorher * A_Zeit / 3600 / 1000)    // Ertrag umrechnen, Stunden, Minuten, Watt, kWh 
            //logInfo("ErtragA","Ertrag A  {}", ertragA) 
            //ErtragA.postUpdate(inverterA_Watt)
            smertragA32.postUpdate(ertragA)                                         // Summe Tagesertrag speichern
        }
    }
    if (inverterA_Watt == 0 ) {                                 // hier nur um Zeitstempel zu erhalten
        var ertragA_alt = 0
        if((smertragA32.state instanceof Number))
            ertragA_alt = smertragA32.state as Number
        
        smertragA32.postUpdate(ertragA_alt)                     // Ertrag noch mal gespeichert! ob es gebraucht wird ??
    }
end

das ist jetzt nur für InverterA, das gleiche hab ich dann noch mal für InverterB.

wenn ich meine 2 Tages Erträge zusammenrechne komme ich in etwa auf den Tagesertrag den ich vom Modbus abrufe.
ich wollte aber wissen wieviel Ertrag kommt von der Westseite und wieviel von der Ostseite?

ps. für die Zeit Berechnung habe ich von hier viewtopic.php?t=8662
bisschen geklaut!

[udo1toni]

Um es kurz zu fassen: Nein.

Die längere Antwort: Leistung und Energiemenge sind zwei unterschiedliche Größen. Du kannst nicht einfach aus der Leistung die Energiemenge berechnen, ebenso wenig funktioniert das in der anderen Richtung. Man kann über den Tagesertrag (Energiemenge) eine Durchschnittsleistung errechnen (kWh / h), umgekehrt aus der über den Tag gelieferten Leistung wird das schwieriger, letztlich müsstest Du ein Integral bestimmen. Wenn die Messwerte gleichmäßig vorliegen (z.B. alle 30 Sekunden) und jeweils den Mittelwert(!) der letzten 30 Sekunden darstellen, dann kannst Du den Mittelwert über die letzten 24 Stunden errechnen und dann mit 24 multiplizieren, um eine hypothetische Energiemenge zu erhalten. Ob diese mit der Realität übereinstimmt, hängt von verschiedenen Faktoren ab, insbesondere, wie genau die Messungen im unteren und oberen Leistungsbereich sind, wie genau die Mittelung der Messwerte ist, wie hoch die zeitliche Auflösung ist usw.
Es reicht nicht, ein paar Zahlen zu addieren.

[B0LT]

Um es kurz zu fassen: Nein.

vielen dank für deine Ausführliche Antwort.

Dann ist es mir ein Rätsel wie andere es schaffen diese Werte korrekt zu errechnen mittels diversen Lösungen. Ich durchforste nun einige Zeit die Foren aber bin noch immer nicht dahinter gekommen.
Es gibt ja auch das "Fronius-Grafana-Dashbord" auf github, ich hab schon versucht das irgendwie zu "zerlegen" um an die Berechnungen zu kommen. Aber durchgeblickt habe ich bis jetzt noch nicht wie er was genau rechnet, denn er greif eigentlich auch nur auf die APIs vom Fronius Wechselrichter ab.

[udo1toni]

Ich lese die entsprechenden Daten aus meiner Fronius aus (d.h. ich berechne da gar nichts). Evtl. trifft das auf die Anderen ebenfalls zu

Es kommt leider auch bei Fronius auf das Modell an, welche Daten zur Verfügung stehen.
Vielleicht musst Du einen Teil der Daten auch am Fronius Binding vorbei per http-API-Call abholen.
Ich habe z.B. ein php-Script erstellt, welches in der Nacht täglich die 5-Minuten-Werte aus dem internen Speicher ausliest und in eine SQL-Datenbank schreibt. Ich kann so tatsächlich auf alle Spannungs- und Stromverläufe seit Errichtung meiner Anlage zugreifen, ohne einen Premium Account bei Fronius zahlen zu müssen.
Das sind aber auch Daten, die nicht über das Binding zur Verfügung stehen, da dort ausschließlich live Daten geliefert werden.
Bei meiner Fronius Symo kommen über das Binding z.B. Tagesertrag, Jahresertrag und Gesamtertrag rein, neben der aktuell abgegebenen Leistung.