Leistungsprognose für Wechselrichter

[TheTrumpeter]

Danke & schönen Urlaub!

Momentan gehe ich aber nicht von einem codeproblem aus.

Ich habe gestern Abend noch auf die letzte Version aktualisiert und werde es erstmal beobachten.
Seither ist es noch nicht wieder aufgetreten, aber ob das an der neuen Version oder dem FHEM-Neustart liegt (ggf. hatte sich davor was "verschluckt"), kann ich nicht sagen.
(Andernorts sind mir davor keine fehlenden Events aufgefallen, auch nicht solche, die nur selten kommen und auch kein "min-interval" gesetzt haben.)

Das ist jetzt auch kein gravierendes Problem, wenn's tatsächlich nur Auswirkung im Log-File hat. Aber wer weiß, woher es wirklich kommt und welche Auswirkungen es noch hat.

[DS_Starter]

Bin wieder aktiv und habe heute mal die Events LastHourPVforecast und LastHourPVreal mitgeloggt.
Ich konnte bei mir keinerlei Unregelmäßigkeiten feststellen.

[TheTrumpeter]

Ich konnte bei mir keinerlei Unregelmäßigkeiten feststellen.

Wie kann ich denn bei der Fehlersuche helfen?
Im Logfile fehlen die Einträge immer noch sporadisch, z.B. gestern beide um 09:00, vorgestern z.B. "LastHourPVforecast" um 08:00 (wobei, ev. war das 0 Wh und wurde daher nicht geloggt?). Am Neujahrstag fehlte "real" ebenfalls um 08:00 (könnte ebenfalls 0 Wh gewesen sein), aber von 10 bis inkl. 12 fehlten beide sowie auch um 14 und 15 Uhr.

"event-on-change-reading" ist auf ".*" gesetzt, sonst bisher kein weiteres relevantes Attribut. Ich habe nun zusätzlich "event-on-update-reading" auf "LastHourPV.*" gesetzt, um ggf. aufeinanderfolgende "0 Wh" nicht zu verlieren. (Relevant kann das nur in der 1. sowie ggf. letzten Sonnenstunde sein. Tagsüber glaube ich kaum, dass sich zwei aufeinanderfolgende Stunden exakt decken würden.)

[DS_Starter]

Ich schlage vor dass du das Attr event-on-update-reading löschst und dafür dies setzt:

Code Auswählen Erweitern

attr ... event-min-interval LastHourPV.*:900

Das würde den Sinn erfüllen so in etwa alle 15 Minuten einen Event zu erhalten, was ausreichen sollte.

Dann lege dir bitte dieses Filelog an:

Code Auswählen Erweitern

define SolCastFL FileLog ./log/LastHourFile  <SolCast-Device>:.*LastHourPV.*

Darüber hinaus habe ich mich im Code versichert, dass diese Readings nur eine Wiedergabe der Readings Today_HourXX_PVforecast bzw. Today_HourXX_PVreal der vorangegangenen Stunde darstellen. D.h. mit jedem Zyklus werden die entsprechenden Readings ausgelesen und als LastHourPV.*-Readings manifestiert. Also absolut keine besondere Sache.

[TheTrumpeter]

Danke, ist getan. Mal sehen wie's in den nächsten Tagen ausschaut.

[DS_Starter]

@all,
morgen früh kommt ein kleines Update.
Das Modul erkennt jetzt, wenn Consumer von extern, also nicht über die Consumerplanung im Modul, geschaltet wurden. Das gilt auch für die Schalter im Grafikpaneel da sie auch einen externen Vorgang abbilden wenn sie manuell bedient werden. Der Status der Consumer ist um einen Info-Eintrag ergänzt wie im Screenshot zu sehen.

[DS_Starter]

Guten Morgen,

heute früh ist die V 1.6.2 im Update in der ich einen kleinen Patzer im Batteriemanagement ausgeglichen habe.
Macht bitte dieses Update.

[TheTrumpeter]

Mir fällt immer wieder eine Unschärfe der "LastHourPVreal" zumindest am Tagesbeginn auf.

Beispielsweise war die Erzeugung heute in der "letzten Stunde" zum aktuellen Ablesezeitpunkt (08:50) lt. Wechselrichter 0,04 kWh:
statAccumulated_energy_yieldLast Hour: 0.04
SolarForecast behauptet im Reading LastHourPVreal (bzw. Today_Hour08_PVreal) es wären 30 Wh gewesen.
An der Auswertefrequenz kann es eher nicht liegen, weil ich einige Minuten vor 8 Uhr schon die 0.04 am WR gesehen habe.
Im "currentInverterDev" ist "etotal=Accumulated_energy_yield:kWh" definiert.

Für die aktuelle Stunde stimmt es derzeit.


Nachtrag: Für die letzte Stunde passt es wieder nicht, 1220 Wh vom solarForecast vs. 1,26 kWh vom Wechselrichter. Möglicherweise hängt es doch am Auswerteintervall? Ich werd' das mal verkürzen und weiter beobachten.
Oder wäre es sinnvoll zu jeder Stunde eine "Sonderauswertung" zu implementieren, damit die Werte "richtig" sind?

[DS_Starter]

Moin,

die Datensammlung kannst du sehr detailliiert nachvollziehen wenn du dir ctrlDebug = collectData setzt.

Code Auswählen Erweitern

...
2024.01.09 08:57:57.812 1: SolCast DEBUG> wid: fc1_21_ww, val: 100, txt: Bewölkungsentwicklung nicht beobachtet, cc: 16, rp: 0.00, temp: -6.5
2024.01.09 08:57:57.813 1: SolCast DEBUG> wid: fc1_22_ww, val: 100, txt: Bewölkungsentwicklung nicht beobachtet, cc: 14, rp: 1.00, temp: -6.90
2024.01.09 08:57:57.814 1: SolCast DEBUG> wid: fc1_23_ww, val: 100, txt: Bewölkungsentwicklung nicht beobachtet, cc: 16, rp: 1.00, temp: -6.80
2024.01.09 08:57:57.815 1: SolCast DEBUG> wid: fc1_24_ww, val: 100, txt: Bewölkungsentwicklung nicht beobachtet, cc: 16, rp: 1.00, temp: -6.80
2024.01.09 08:57:57.826 1: SolCast DEBUG> collect Inverter data - device: MySTP_5000 =>
2024.01.09 08:57:57.827 1: SolCast DEBUG> pv: 812 W, etotal: 56642903 Wh
2024.01.09 08:57:57.828 1: SolCast DEBUG> collect Meter data - device: SMA_Energymeter =>
2024.01.09 08:57:57.829 1: SolCast DEBUG> gcon: 0 W, gfeedin: 30.7 W, contotal: 529071.8 Wh, feedtotal: 7338 Wh
2024.01.09 08:57:57.830 1: SolCast DEBUG> collect Battery data: device=SolCastDummy =>
2024.01.09 08:57:57.831 1: SolCast DEBUG> pin=0 W, pout=0 W, totalin: 150 Wh, totalout: 210 Wh, soc: 86.67

etotal ist der Lesewert in jedem Zyklus. Damit kannst du dir die Stundenwerte ermitteln.

Technisch bedingt gibt es kleine Abweichungen in den Stundenwerten, da zu Beginn jeder Stunde zunächst der Startwert des Inverters festgehalten wird um den Stundenwert am Ende zu ermitteln. Je nach Zyklus kann es passieren, das der Übertrag aus z.B. 08:58 bis 09:02 verloren geht. Idealerweise müsste ein Zyklus jeweils hh:mm:58 und noch einer hh+1:mm:00 laufen und den eingestellten Zyklus temporär übersteuern. Das ist aber steuerungstechnisch nicht trivial zumal FHEM kein Echtzeitsystem ist.

[DS_Starter]

Oder wäre es sinnvoll zu jeder Stunde eine "Sonderauswertung" zu implementieren, damit die Werte "richtig" sind?

Ja, siehe die Begründung zuvor.
Ich denke auch nochmal darüber nach ob/wie ich zum Stundenwechsel ggf. etwas hilfreiches einbauen kann.

[TheTrumpeter]

zu Beginn jeder Stunde zunächst der Startwert des Inverters festgehalten wird um den Stundenwert am Ende zu ermitteln

Warum wird nicht einfach der "letzte bekannte" Wert verwendet? Dann wären zwar die einzelnen Stundenwerte je nach Datenabgreifzeitpunkt nicht unbedingt konsistent zum WR, aber die Tagessumme würde passen.
Dann würde es auch ausreichen mit einer "Sonderauswertung" um x:59:58 auszukommen und nicht noch eine zusätzliche um x+1:00:02 zu benötigen.

Oder, ganz andere Idee, die möglicherweise einiges an Umbauaufwand verursachen würde, dafür aber die redundante Berechnung entfernen würde:
Vmtl. hat ohnehin fast jeder eine Statistik auf dem WR-Ertrag hängen. Dann könntest Du statt dem "etotal=Accumulated_energy_yield:kWh" auf den zugehörigen Statistik-Wert setzen und die Daten einfach von dort abgreifen, d.h. für die laufende Stunde den "statxxx"-Hour-Wert abgreifen und im 1. Zyklus der neuen Stunde setzt Du die "last"-Stunde auf den "statxxxLast"-Hour-Wert.

[DS_Starter]

Warum wird nicht einfach der "letzte bekannte" Wert verwendet?

Weil der "letzte bekannte" Wert zu unspezifisch ist. Der kann vom Vortag oder vor einer Woche gewesen sein.
Es gibt auch Situationen in denen FHEM ausfällt, umgezogen wird usw.
Oder man möge an den Austausch des Wechselrichters bzw. der Umkonfiguration / Zusammenfassung von mehreren WR in einen Dummy denken.
Es muß definierte Aufsetzpunkte geben. Ich mache mir ein paar Gedanken zu dem Stundenwechsel. Mal sehen.
 

[Wscheff]

Servus,

danke für das tolle Modul, das ich kürzlich entdeckt habe.

Ich habe eine Verständnisfrage zur grafischen Ansicht:

Bei meiner Konfiguration wird die Messung der gesamten Energie über ein Meter gemessen, dass alle Energie summiert (2) und auch den Bezug im Haus anzeigt (3).
Nun habe ich ein neues Device hinzugefügt (1) das bestimmte Verbraucher zusätzlich messen und schalten kann als consumer Device.
Wie erreiche ich, dass die Gesamtenergie 3 die Summe aus 2+1 ergibt und nicht der Betrag von 1 hinzugerechnet wird? 1 ist in 2 schon enthalten

Danke & Gruss

[DS_Starter]

Wie erreiche ich, dass die Gesamtenergie 3 die Summe aus 2+1 ergibt

Die Gesamtsumme (3) 582 = 546 (2) + 36 (1). Passt doch oder was meinst du?

[Wscheff]

Wie erreiche ich, dass die Gesamtenergie 3 die Summe aus 2+1 ergibt

Die Gesamtsumme (3) 582 = 546 (2) + 36 (1). Passt doch oder was meinst du?

ich verbrauche nur 546  INKLUSIVE 36 und nicht 582. (1) ist hinter (2) installiert