SOLVED - Verbrauch von heute (seit Mitternacht) anzeigen

[zinnik]

Allerdings kann das nicht stimmen um 15:01:28 muss die Ausgabe 54088 lauten. Also die ersten beiden Stellen wären momentan 54, aber da müssten noch drei weitere Stellen mit ausgegeben werden.

EDIT: Du darfst da nicht durch 1000 teilen, die Division durch 1000 kommt von der vorherigen Berechnung, da handelte es sich aber um Millisekunden.

Achso stimmt

Jetzt sieht es besser aus aber was mich wundert im Log sieht jetzt wo die Leistung am Solarpanel =0 ist wird der Ertrag herunter gezählt. Also immer weniger?
Laut meiner App habe ich heute mit dem Panel 0,89kwh erzeugt
Laut Berechnung aber 1.07kwh

Code: Alles auswählen

2022-10-27 17:46:36.551 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Solarpanel_Ertrag_Tag' changed from 1.07352542 to 1.07348105
2022-10-27 17:46:46.586 [INFO ] [openhab.core.model.script.Solarpanel] - Sekunde: 64006 
2022-10-27 17:46:46.587 [INFO ] [openhab.core.model.script.Solarpanel] - Tagesertrag: 1.07343648 Ws
2022-10-27 17:46:46.588 [INFO ] [openhab.core.model.script.Solarpanel] - Tagesertrag: 3.0E-7 kWh
2022-10-27 17:46:46.590 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Solarpanel_Ertrag_Tag' changed from 1.07348105 to 1.07343648

[peter-pan]

Könnte es sein, dass der Ertrag, der ja auf Basis eine Durchschnitts ermittelt wird, sich gegen Tages-Ende dann deinem Ist-Wert annähert, da die Anzahl der Sekunden(Divisor) ja immer mehr werden. Aber der Ertrag (Dividend) immer gleich bleibt?
Ich hoffe ich hab mich mit meinen mathematischen Fähigkeiten nicht komplett "zum Affen" gemacht !!

[zinnik]

Könnte es sein, dass der Ertrag, der ja auf Basis eine Durchschnitts ermittelt wird, sich gegen Tages-Ende dann deinem Ist-Wert annähert, da die Anzahl der Sekunden(Divisor) ja immer mehr werden. Aber der Ertrag (Dividend) immer gleich bleibt?
Ich hoffe ich hab mich mit meinen mathematischen Fähigkeiten nicht komplett "zum Affen" gemacht !!

Ja das ist momentan auch meine Vermutung

Nein dein mathematischen Fähigkeiten sind Spitze.

PS: Ich staune eh... wie toll ihr solche Rules erstellt... mir schweben noch viele Automatisierung Regeln im Kopf leider weiß ich nicht wie ich alles umsetzen soll. Weil ich von den Rule kein Verständnis habe.
Ich weiss zwar wie man Maschinen repariert aber leider nix mit ...Informatik am Hut


Eine frage fällt mir noch ein. Ich möchte zur Sicherheit alle derzeit 1600 Items persistieren. Default ist bei mir influxdb 1.8.2 und auch rrd4j läuft mit in OH3.

für rrd4j gibt es keine .persist Datei und für influx habe ich momentan diese ------>

Code: Alles auswählen

Strategies {
}
 
Items {
   *						: strategy = everyChange, restoreOnStartup

}

Hatte aber die letzten 4 Tage Probleme beim persistieren mit der Datenbank.... es wurden nur vereinzelt items geschrieben obwohl ich nichts gemacht habe.

Lg zinnik

[udo1toni]

Also eigentlich sollte der Durchschnitt umgekehrt proportional zur Zeitspanne sinken. Mit anderen Worten: von einer kleinen Ungenauigkeit abgesehen sollte ab dem Zeitpunkt, wo kein Strom mehr erzeugt wird die angezeigte Energie gleich bleiben, weil auf der einen Seite der betrachtete Zeitraum wächst, auf der anderen Seite aber der Durchschnitt auch sinkt, und diese beiden Größen sollten sich dann egalisieren.

Wie gesagt, es ist wichtig, dass die Zeitabstände bei der Messung möglichst gleich sind. Die Doku spricht zwar von einer zeitlichen Gewichtung beim errechnen des Durchschnitts, aber ob das tatsächlich so funktioniert, wie gedacht, ist schwer zu überprüfen. Die zahlenakrobatik im Hintergrund müsste man im Quelltext nachlessen, und all diese Berechnungen setzen zwingend voraus, dass die Messwerte sauber persistiert wurden.

Womit wir bei Deiner zweiten Frage sind.

Ich vermute, die "Sicherheit" ist hier nur "falls ich irgendwann mal auf die Idee komme, mir diese Daten ansehen zu wollen". rrd4j läuft automatisch mit, weil man den Leuten ein "Oh, ich muss nichts machen und bekomme trotzdem Verlaufsdaten seit Bismark" Erlebnis bieten will.
In meinen Augen eine ganz schlechte Idee, aber ich bin kein Entwickler.
InfluxDB ist darauf spezialisiert, Messreihen zu verarbeiten und kann dies bemerkenswert gut. Aber je nach Datenaufkommen sind 1600 Messpunkte schon ein Happen, das Ding läuft ja parallel zu openHAB auf einer Zigarettenschachtel...

Keinesfalls solltest Du einfach alle Items automatisch beim Neustart wiederherstellen lassen, das schreit nach Problemen. restoreOnStartup sollte nie mit dem * angegeben werden. Ich weiß, dass das mal in irgendeiner Doku drin stand, aber es ist eine miserable Idee.
Es ist besser, keinen Messwert zu haben als einen falschen, bei dem man nicht erkennen kann, dass er nicht aktuell ist. (Frag mal Kraftwerksfahrer... )

Aber auch die Anzahl der persistierten Items sollte besser auf das Nötige reduziert werden, das braucht auch alles Speicher, und auf dem Raspberry (mindestens wenn eine Micro-SD-Karte zum Einsatz kommt) sind viele Schreibzugriffe der sichere Tod des Systems.

[zinnik]

Hallo Udo, danke für dein Bedenken

Also mein System läuft auf einer Qnap mit 16GB Arbeitsspeicher als Docker. Also OH3, influx, solaranzeige, deconz, grafana und mosquitto jeweils einzelne Docker.

der Docker der Influx ist bei 1% Ram Auslastung

Die Qnap wird ungefähr einmal im halben Jahr neu gestartet. Der Docker ca. alle 2 Wochen.

Wie ist denn das mit der Influx Datenbank registriert sie auch werte wenn die Werte=0 sind so ist es jetzt ja zb.

In den Screenshots sieht man das bei Solarpanel_Ertrag ab 16:09 nichts mehr geschrieben wurde und bei Solar PowerConsumption bis 18:52

Wie kann ich ich das beeinflussen wie oft in die Datenbank geschrieben wird zb: 10sec Abstand?

Screenshot (211).png

Screenshot (212).png

Screenshot (213).png

[zinnik]

Screenshot (214).png

[udo1toni]

Na, Du hast als Trigger für die Persistence everyChange angegeben, also wird auch nur gespeichert, wenn es eine Änderung gibt. Solange Du einen konstanten Wert hast, wird nicht gespeichert, und eigentlich ist dieses Verhalten durchaus wünschenswert.
Wenn Du Geräte hast, die über viele Stunden vorhersehbar keine Werte liefern, kannst Du (um z.B. in Grafana keine leere Anzeige zu haben, weil kein Messwert im Zeitfenster liegt) einfach eine Cron Strategy definieren, z.B.

Code: Alles auswählen

Strategies {
    every10Seconds : "0/10 * * * * ?"
    everyMinute : "3 * * * * ?"
    every15Minutes : "7 3/15 * * * ?"
    
}
Items {
    * : strategy = everyChange, everyMinute
}

Achte darauf, wenn Du mehrere Strategies erstellst, diese sinnvoll zu staffeln, um die Schreibzugriffe möglichst zu verteilen. Das gilt im Übrigen auch für die Rules, wenn man Time cron Trigger verwendet oder den Scheduler.

Es ist eigentlich nicht erstrebenswert, alle 10 Sekunden 1600 Messwerte zu schreiben, die man zu 99% nicht braucht. Detenbankingenieure stecken viel Energie in die Vermeidung von unnötigen Daten

[zinnik]

Hallo,

leider funktioniert die Berechnung noch nicht der Wert bei Solarpanel_Ertrag_Tag bleibt immer nur bei 1,07 stehen und verändert sich nicht mehr
Solarpanel_PowerConsumption wird aber alle 10s persistiert.

Dies ist die aktuelle Rule bei der er einmal bis auf die 1.07 hochgezählt hat. Seitdem verändert sich der Wert nicht.
Muss hier noch irgendwas gegen Mitternacht resettet werden?

Code: Alles auswählen

rule "Solarpanel Ertrag Tag"
when
    Item Solarpanel_PowerConsumption received update         // momentane Leistung in Watt

then
val Leistung = Solarpanel_PowerConsumption.averageSince(ZonedDateTime.now().with(LocalTime.MIDNIGHT)) as Number
val Sekunde = LocalDateTime.now().toLocalTime().toSecondOfDay()
    logInfo("Solarpanel", "Sekunde: {} ",Sekunde)
val Ertrag = ((Leistung * Sekunde)/3600000)
        logInfo("Solarpanel","Tagesertrag: {} Ws",Ertrag)
        logInfo(("Solarpanel","Tagesertrag: {} kWh",Ertrag)/3600000)
        Solarpanel_Ertrag_Tag.postUpdate(Ertrag)
end

[udo1toni]

Du kannst Doc hnicht einfach irgendwo Klammern setzen und durch eine Zahl teilen!?!
Die Rule sollte eher so aussehen:

Code: Alles auswählen

rule "Solarpanel Ertrag Tag"
when
    Item Solarpanel_PowerConsumption received update
then
    val Leistung = Solarpanel_PowerConsumption.averageSince(ZonedDateTime.now().with(LocalTime.MIDNIGHT)) as Number
    val Sekunde = LocalDateTime.now().toLocalTime().toSecondOfDay()
    val Ertrag = Leistung * Sekunde / 3600000

    logInfo("Solarpanel","Leistung: {} Sekunde: {} Tagesertrag: {} kWh",Leistung,Sekunde,Ertrag)
    Solarpanel_Ertrag_Tag.postUpdate(Ertrag)
end

Wobei ich den logInfo Befehl noch mal geändert habe, so dass man alle Zahlen im Blick hat, die in die Berechnung einfließen.
Die Rule Engine kennt die mathematischen Grundregeln, z.B. Punkt vor Strich (wobei Minus und Plus Strich sind, und Mal und geteilt Punkt entsprechen.
Es spielt z.B. oben keine Rolle, ob man zuerst Ertrag mit Sekunde multipliziert und anschließend durch 3600000 teilt, oder erst Ertrag oder Sekunde durch 3600000 teilt und anschließend mit dem übrigen Faktor multipliziert, Stichworte sind hier das Kommutativgesetz und Multiplikation mit dem Kehrwert statt einer Division.

[zinnik]

Du kannst Doc hnicht einfach irgendwo Klammern setzen und durch eine Zahl teilen!?!

Verdammt,ja leider wusste ich das nicht ich. Ich dachte ich gebe mit den Klammern die Priorität vor, was zuerst gerechnet werden sollte.
Ja ärgerlich wenn man sich mit sowas nicht auskennt.

Jetzt habe ich den gleichen Ertrag wie auch in der App.

Aber wie gesagt er verändert sich noch und zählt wahrscheinlich langsam runter bis Mitternacht

Code: Alles auswählen

2022-10-29 21:55:09.937 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Solarpanel_Ertrag_Tag' changed from 0.52823358 to 0.52823333
2022-10-29 21:55:19.956 [INFO ] [openhab.core.model.script.Solarpanel] - Sekunde: 78919 
2022-10-29 21:55:19.957 [INFO ] [openhab.core.model.script.Solarpanel] - Leistung: 24.09609197335614 Sekunde: 78919 Tagesertrag: 0.52823319 kWh
2022-10-29 21:55:19.958 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Solarpanel_Ertrag_Tag' changed from 0.52823333 to 0.52823319
2022-10-29 21:55:29.832 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Solarpanel_Temperature' changed from 15.369999885559082 °C to 15.430000305175781 °C
2022-10-29 21:55:30.001 [INFO ] [openhab.core.model.script.Solarpanel] - Sekunde: 78930 
2022-10-29 21:55:30.002 [INFO ] [openhab.core.model.script.Solarpanel] - Leistung: 24.09302535996079 Sekunde: 78930 Tagesertrag: 0.52823958 kWh