76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

Und die V 1.37.3 ist nun auch eingecheckt. 

Danke für euren Mut zu testen und das Feedback ... macht Freude mit euch zusammen am Modul zu arbeiten!

LG

[kask]

HAHA! Macht freude das Modul zu testen wenn es adhoc und offen angepasst wird. Und das Lob geht an dich, das Du so mutig bist schnell abzuändern.
Das zeigt mir das deine Debugging und Test&Trial-techniken schon was auf dem Nacken haben, bei so wenig vermarmelten Versionen bis jetzt.
Erst 2 dicke Eier gab es bei fast täglichen Änderungen zeitweise.

[Parallix]

Danke für das schöne Update.

Ein Problem beschäftigt mich derzeit noch: Obgleich ich bei "setupMeterDev"
"gfeedin=-gcon" gesetzt habe, erhalte ich regelmäßig Warnungen wie folgt:

Code Auswählen Erweitern

2024.10.11 19:13:22 3: SF - WARNING - The stored Energy consumption of day/hour 10/02 is negative. This appears to be an error. The incorrect value can be deleted with 'set SF reset consumption 10 02'.
Anhand der Doku hätte ich erwartet, dass derartige Warnungen wegen "gfeedin=-gcon" nicht auftauchen.
Oder sehe ich da etwas falsch?

[DS_Starter]

Hallo Parallix,
die Angabe "gfeedin=-gcon" bedeutet zunächst nur dass das Modul den Wert im Reading gcon=<Readingname> als Grideinspeisung (gfeedin) nutzt, sofern dieser Wert negativ ist.
Das verwendet man wenn der Meter nur ein Reading anbietet, welches sowohl Bezug (als positiven Wert) als auch Einspeisung (als negativen Wert) liefert.

In den Readings Today_HourXX_GridConsumption und Today_HourXX_GridFeedIn solltest du aber nur positve Werte sehen.
Die Consumtion für die Stunde wird dann berechnet aus:

Code Auswählen Erweitern

Hausverbrauch = PV-Ertrag + (Erzeugung OtherProducer) - Netzeinspeisung + Netzbezug - BatterieIn + BatterieOut
Die jeweiligen Werte in der Gleichung sind immer positiv, also ohne negativen Vorzeichen.

Mit ctrlDebug=saveData2Cache kannst du verfolgen was mit jedem Zyklus gespeichert wird:

...
2024.10.27 19:35:28.354 1: SolCast DEBUG> setPVhistory -> stored simple  - Day: 27, Hour: 20, Key: con, Value: 303
2024.10.27 19:35:28.355 1: SolCast DEBUG> setPVhistory -> stored compute - Day: 27, Hour: 99, Key: con, Value: 13882
...
2024.10.27 19:36:08.333 1: SolCast DEBUG> setPVhistory -> stored simple  - Day: 27, Hour: 20, Key: con, Value: 308
2024.10.27 19:36:08.333 1: SolCast DEBUG> setPVhistory -> stored compute - Day: 27, Hour: 99, Key: con, Value: 13887
...
2024.10.27 19:37:28.247 1: SolCast DEBUG> setPVhistory -> stored simple  - Day: 27, Hour: 20, Key: con, Value: 318
2024.10.27 19:37:28.247 1: SolCast DEBUG> setPVhistory -> stored compute - Day: 27, Hour: 99, Key: con, Value: 13897
...

Du siehst, wie sich die Summen mit jeder Messung erhöhen. "stored simple" ist der Stundenwert in Wh und "stored compute" der aufsummierte Tageswert. Der Key "con" beschreibt die Consumption des Hauses, d.h. die Summe aller Verbräuche.
Wenn sich irgendwann mal eine negative Differenz ergibt (evtl. immer zur selben Zeit) wäre das ein Ansatz zur Suche.

Wenn sich die besagte Meldung immer auf eine bestimmte Stunde des Tages bezieht, kannst du das Attr ja mal gezielt mit einem at entsprechen aktivieren/ deaktivieren um die Ergebnisse zu sehen.

LG,
Heiko

[Parallix]

Hallo Parallix,
die Angabe "gfeedin=-gcon" bedeutet zunächst nur dass das Modul den Wert im Reading gcon=<Readingname> als Grideinspeisung (gfeedin) nutzt, sofern dieser Wert negativ ist.
Das verwendet man wenn der Meter nur ein Reading anbietet, welches sowohl Bezug (als positiven Wert) als auch Einspeisung (als negativen Wert) liefert.

In den Readings Today_HourXX_GridConsumption und Today_HourXX_GridFeedIn solltest du aber nur positve Werte sehen.
...

Danke für das Feedback! Werde mir das die Woche mal genauer ansehen.

In der Tat liegt bei mir der (beschriebene) Fall vor, dass das genutzte Reading (Netz-Einspeisung bzw. Bezug) positiv oder negativ sein kann. Den gleichen Fall (positives oder negatives Reading) habe ich allerdings auch bei meinen (zwei einzeln am GW25K-ET angeschlossenen) Speichern, die ich ohne Umwege aktuell ja noch nicht einzeln in die Grafik einbauen kann und daher zusammengeführt habe.

Heute hatte ich auch noch ein seltsamen Prognosewert: 20,2kWh im 6:00 Uhr Bin (siehe Grafik) halte ich selbst bei bestem Solarwetter für nicht realisierbar. Diese Anzeige hatte ich übrigens auch schon vor dem heutigen Update!

Eine Frage noch am Rande: Das zyklisch eigentlich gewünschte Update für das SolarCast-Fenster erfolgt bei mir auch in allen anderen Brower-Fenstern in denen ich (andere) FHEM-Seiten anzeige, Liegt da möglicherweise ein Fehler vor?

Du darfst diesen Dateianhang nicht ansehen.

[DS_Starter]

Heute hatte ich auch noch ein seltsamen Prognosewert: 20,2kWh im 6:00 Uhr Bin (siehe Grafik) halte ich selbst bei bestem Solarwetter für nicht realisierbar.

Würde ich auch bezweifeln.
Du verwendest die OpenMeteo-API ohne Korrektur.
D.h. die Prognose von OpenMeteoDWD wird 1:1 durchgereicht/dargestellt.

Ein "get ... solApiData" listet dir die Inputdaten auf. Die Rad1h Werte kommen direkt von der API.
Wenn du dort bereits den Ausreißer siehst, ist die Ursache klar.

Eine Frage noch am Rande: Das zyklisch eigentlich gewünschte Update für das SolarCast-Fenster erfolgt bei mir auch in allen anderen Brower-Fenstern in denen ich (andere) FHEM-Seiten anzeige, Liegt da möglicherweise ein Fehler vor?

Nein, das ist technisch bedingt. Man kann alternativ noch mit ctrlAutoRefreshFW arbeiten.
Andererseits wundere ich mich, dass überhaupt jemand diese Möglichkeit verwendet. Ich hatte mir bereits überlegt diese Attribute zu entfernen, da die Grafik sich ohnehin in der Raumansicht selbständig aktualisiert und die Readings ebenfalls über die FHEM internen Mechanismen.
Diese Atribute sind eigentlich Relikte aus der Anfangszeit von denen ich der Meinung war sie seinen inzwischen überflüssig.

Zu dieser Kategorie zählen für mich auch die Attr graphicStartHtml /graphicEndHtml die ich auch entfernen würde, es sei denn jemand möchte sie gern aus welchen Gründen auch immer behalten.

[Thomas Vandahl]

Hallo Forum,

ich habe das Modul zusammen mit einem Fronius-WR und dem SolarAPI-Modul 98_fronius.pm in Betrieb genommen. Die angezeigten Werte sind soweit plausibel. in den Current_*_Readings steht alles so drin, wie erwartet. Ich kann z.B. Current_PowerBatIn und Current_PowerBatOut mit den Angaben von Fronius vergleichen - soweit ok.
Mir ist aber aufgefallen, dass die Stunden-Buckets Today_Hour??_BatIn und Today_Hour??_BatOut immer 0 sind. Ist das so gedacht?

Meine Batteriekonfiguration sieht so aus:

Code Auswählen Erweitern

attr Solar setupBatteryDev PVInverter pin=-pout pout=PowerFlow_Site_P_Akku:W cap=Storage_1_Controller_DesignedCapacity:Wh charge=PowerFlow_Inverters_1_SOC

[DS_Starter]

Hallo Thomas,
nein das ist so nicht gedacht.

In deiner Battriedefinition fehlen die Schlüssel:

 intotal    Reading welches die totale Batterieladung als fortlaufenden Zähler liefert (optional)
outtotal    Reading welches die totale Batterieentladung als fortlaufenden Zähler liefert (optional)

Sie sind optional, allerdings werden die Stundenwerte nicht generiert wenn diese Angaben fehlen.
Wenn die Batterieanlage diese Werte nicht von Haus aus liefert, könnte userReadings mit Intergralfunktion helfen diese Werte als Input für SF zu erstellen.

LG,
Heiko

[Thomas Vandahl]

Hallo Heiko,

danke für die schnelle Antwort. Habe ich Nachteile, wenn die Werte nicht gefüllt werden? Die Schlüssel sind ja sicher nicht ohne Grund optional.

Gruß, Thomas

[DS_Starter]

Optional sind sie nur weil manche Anlagen sie nicht per default liefern und niemand deswegen an dieser Stelle scheitern soll.
Nachteile ergeben sich, z.B. kann der Hausverbrauch auf Stundenbasis nicht richtig berechnet werden da die Batteriewerte fehlen.
Dadurch werden die Verbrauchsprognosen via ctrlStatisticReadings auch nicht richtig sein. Es können sich noch mehr Abhängigkeiten ergeben die ich momentan nicht alle übersehen kann, dafür ist das Modul zu komplex. 
Also wenn es geht, würde ich dir raten diese Werte liefern zu lassen.

[Parallix]

Eine Frage noch am Rande: Das zyklisch eigentlich gewünschte Update für das SolarCast-Fenster erfolgt bei mir auch in allen anderen Brower-Fenstern in denen ich (andere) FHEM-Seiten anzeige, Liegt da möglicherweise ein Fehler vor?

Nein, das ist technisch bedingt. Man kann alternativ noch mit ctrlAutoRefreshFW arbeiten.
Andererseits wundere ich mich, dass überhaupt jemand diese Möglichkeit verwendet. Ich hatte mir bereits überlegt diese Attribute zu entfernen, da die Grafik sich ohnehin in der Raumansicht selbständig aktualisiert und die Readings ebenfalls über die FHEM internen Mechanismen.

Wenn ich ctrlAutoRefresh entferne, werden, während sich die Grafik nicht aktualisiert, auf der Browserseite nur die Readings erneuert.

[DS_Starter]

Wenn ich ctrlAutoRefresh entferne, werden, während sich die Grafik nicht aktualisiert, auf der Browserseite nur die Readings erneuert.

Wenn du die Readings siehst, befindest du dich auf der sogenannten Detailseite.

Wenn du einen Raum auswählst, befindest du dich in der Raumansicht. Hier wird auch die Grafik automatisch aktualisiert.
Wichtig ist dass das Reading "state" einen Event generiert, was aber der Fall ist wenn man es nicht explizit unterbindet.

[Parallix]

Wenn du einen Raum auswählst, befindest du dich in der Raumansicht. Hier wird auch die Grafik automatisch aktualisiert.
Wichtig ist dass das Reading "state" einen Event generiert, was aber der Fall ist wenn man es nicht explizit unterbindet.

Zu blöd von mir. Hätte ich eigentlich wissen müssen.

Die Gelegenheit möchte ich aber nutzen, um hier noch eine Anregung zu geben: Die in der Grafik dargestellten Werte sind - wenn ich das richtig sehe - ja Augenblickswerte der jeweiligen Readings. Vor dem Hintergrund, dass sich diese häufiger ändern, als die Grafik aktualisiert wird, sind die angezeigten Werte bei hoher Fluktuation der Ursprungswerte wenig aussagekräftig. Dem könnte man wunderbar entgegentreten, wenn in der Grafik gleitenden Mittelwerte (zeitliche Breite entsprechend der Zeit zwischen zwei Updates) angezeigt werden würden.

[DS_Starter]

Alternativ sehe ich noch zwei weitere (und für mich bessere) Varianten.

1. Die Aktualisierungsfrequenz der Grafik ist abhängig vom Zyklus eingestellt im Attr ctrlInterval. Je nach Leistungsfähigkeit eurer Server kann man die Zeit durchaus sehr kurz wählen. Habe es bei mir schon mal auf 1 Sekunde gesetzt und läuft damit einwandfrei, CPU geht halt entsprechend hoch.

2. Die zweite Variante ist die Möglichkeit der Asynchronität und mein persönlicher Favorit. Ihr kennt das bereits wenn dieses Merkmal bei einem Consumer angegeben ist. Dann wertet das Modul die Schalt-Events des Consumers aus und startet nach Empfang eines solchen sofort den Updatevorgang. Dieses Verfahren kann man ggf. auch auf die angegebenen Devices in setupInverterDevXX, setupBatteryDev, setupMeterDev, setupOtherProducerXX erweitern. Das führt dann bei Empfang relevanter Events zu einem unmittelbaren Update und entsprechend aktueller Werte in der Grafik und den Modulreadings.

Aber das muß natürlich erstmal alles gebaut werden.
Aktuell lasse ich zunächst etwas Ruhe einkehren und werde größere Aktivitäten erst wieder Angang Dezember beginnen. Bis dahin hat etwas Anderes meine Aufmerksamkeit.    

[DS_Starter]

@all,
wie bereits in #1280 erwähnt, habe ich die Attr graphicStartHtml und graphicEndHtml entfernt und die V eingecheckt.
Sie waren noch Relikte aus der Anfangszeit des Moduls.
Falls es jemanden geben sollte der diese Dinge aus welchen Gründen auch immer aktiv nutzt, dann bitte nicht updaten und hier melden.

LG,
Heiko