76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[300P]

@

......
In meinem contrib liegt eine gefixte Version die auch morgen früh im Update sein wird.
......

Kleine -sehr unwichtige- Anmerkung am Rande für die ToDo-Liste auf d(ein)er Bereinigungsliste.
Ich hab es bislang noch nicht so gesehen / wahrgenommen ?!

Es erfolgt evtl. eine doppelte Prüfung / Anzeige der "Informationen zur Anlagenprüfung" der Ergebnisse der Perlmodule.

Anzeige bei "Common Settings"
checked Perl modules:
AI::DecisionTree

Anzeige bei "Perl Modules"
checked installed Perl Modules:
AI::DecisionTree

Gruß
300P

[DS_Starter]

Guten Morgen,

danke für den Hinweis 300P. 
Ich bereinige das.

LG,
Heiko

[Dirk070]

Ich würde auch ein Userreading mit monotonic bevorzugen.
Und wenn du Tageswerte oder sowas benötigst, dann eventuel diese mit statistic zusätzlich erstellen.
Dann bist du frei von irgendwelchen Timing Problemen von irgendeiner Hardware und irgendwelchen ominösen Systemzeiten.

Du hast auch ein E3DC, richtig?
Die Erzeugungs-, Einspesiungs, Batterieladungs- und Batterientladungswerte kommen ja nur 1/4 stündlich.
Bei mir war das immer so ca. 1-2 Minuten nach der vollen Stunde.

Vielleicht liegt das bei Dir da dran.

Ich habe mich dann mit meiner eigenen Rechnung beholfen.
Leider weiche ich da etwas von der E3DC Berechnung ab.

Code Auswählen Erweitern

fromgrid integral {ReadingsVal("$name","gridpower","")>0?ReadingsVal("$name","gridpower","")/3600:0},
togrid integral {ReadingsVal("$name","gridpower","")<0?ReadingsVal("$name","gridpower","")/-3600:0},
batin integral {ReadingsVal("$name","batterypower","")>0?ReadingsVal("$name","batterypower","")/3600:0},
batout integral {ReadingsVal("$name","batterypower","")<0?ReadingsVal("$name","batterypower","")/-3600:0},
fromroof integral {ReadingsVal("$name","solarpower",0)/3600}

Meine Erzeugungsleistung laut Eigenberechnung liegt bei 19,61kWh. Laut E3DC-Portal bei 20,85kWh.
Aber bis ich eine bessere Lösung habe, bleibt das so.

Gruß,
Heiko

Danke Euch beiden für die Hinweise. 

Ja, ich habe ein E3/DC und habe ab Mitternacht mal mitgeloggt.
Die Werte werden verzögert initialisiert, stimmt.

Ich teste jetzt mal einen einfachen Ansatz und setze um 00:00 per setreading auf Null.
Ich logge dann mal 10 Minuten lang minütlich mit um zu prüfen, ob der Wert wieder zurück springt.

[grappa24]

ich nehme mal an, dieser "Fehler" verschwindet mit der Zeit ...

[peterboeckmann]

Hallo Heiko,

ich habe mal wieder eine neue Idee. Vielleicht ist sie aber auch unnötig.
Wäre es evtl. für die Ertragsprognose hilfreich, die Momentanleistungen der einzelnen Strings zu kennen?

Zum Hintergrund:
Meine Solarpanelflächen (= Strings) sind untypisch ausgerichtet:
Du darfst diesen Dateianhang nicht ansehen.
Mein Wechselrichter liefert Spannung und Strom der einzelnen Strings. Daraus könnte immerhin die Scheinleistung ermittelt werden und so evtl. die Prognose verbessert werden?

Weiter verbessern ließe sich die Prognose evtl. mit der genauen Angabe der Dachneigung.
Meine Paneele liegen auf dem Dach, das eine Neigung von 38 Grad hat. Ich muss hier aber näherungsweise 40 Grad angeben.
Ich habe aktuell, da die Sonne jeden Tag etwas höher steigt, den Eindruck, dass 2 Grad einen recht deutlichen Unterschied in der potentiellen maximalen Leistung machen?

Kannst ja die Gedanken mal ein bisschen gären lassen.

Vielen Dank und viele Grüße,
Peter

[300P]

ich nehme mal an, dieser "Fehler" verschwindet mit der Zeit ...

@grappa24

Das kommt darauf an wie lange dort du deine Daten speichern läßt und warten möchtest.
Eine Vorgabe für die Historie ist bis zu 180 Tage da möglich.
- persönliche individuelle Einrichtung möglich - 
Default / Standart ist augenblicklich, soweit ich es kenne, 60 Tage.

Schau mal hier https://forum.fhem.de/index.php?topic=137058.msg1333936#msg1333936

Gruß
300P

Nachsatz:

Bei Wochentagen weiß ich nicht so richtig wie es sich dann wirklich verhält.... 
Die dann anfallenden 180 Wochen wäre schon etwas sehr lange und sind bei 180 Speicherwerten auch nicht alle da 

Code Auswählen Erweitern

affectConsForecastLastDays
Es wird die angegebene Anzahl historischer Tageswerte bei der Berechnung der Verbrauchsprognose einbezogen.
So wird z.B. mit dem Attributwert "1" nur der vorangegangene Tag berücksichtigt, mit dem Wert "14" die vergangenen 14 Tage.
Die tatsächlich berücksichtigten Tage können geringer als angegeben sein wenn noch nicht genügend Werte im internen Speicher vorhanden sind.
(default: 60)

Hinweis: Bei einem zusätzlich gesetzten Attribut affectConsForecastIdentWeekdays wird die angegebene Anzahl vergangener gleicher Wochentage (Mo .. So) berücksichtigt.
In diesem Fall werden bei einem gesetzten Wert von "8" die gleichen Wochentage der vergangenen 8 Wochen berücksichtigt.

[DS_Starter]

@grappa24 und @300P

ich nehme mal an, dieser "Fehler" verschwindet mit der Zeit ...

Ja und Nein.
Ja, die Daten in der pvHistory bleiben max. 31 Tage enthalten. Sie würde verschwinden wenn nicht neue Datensätze mit negativer Consumption geschrieben werden. Ständig neue Datensätze mit neg. Verbrauch deuten auf ein Problem im Setup bzw. den Quellen hin.

Deswegen würde ich die vorhandenen neg. Werte löschen und beobachten ob neue entstehen.
Wie das geht steht im Log, z.B.:

2025.02.18 14:11:32.335 1: SolCast6 - WARNING - The stored Energy consumption of day/hour 04/15 is negative. This appears to be an error. The incorrect value can be deleted with 'set SolCast6 reset consumptionHistory 04 15'.
2025.02.18 14:11:32.338 1: SolCast6 - WARNING - The stored Energy consumption of day/hour 18/13 is negative. This appears to be an error. The incorrect value can be deleted with 'set SolCast6 reset consumptionHistory 18 13'.
2025.02.18 14:11:32.341 1: SolCast6 - WARNING - The stored Energy consumption of day/hour 31/15 is negative. This appears to be an error. The incorrect value can be deleted with 'set SolCast6 reset consumptionHistory 31 15'.

Die Stundenwerte der Wochentage stehen in der pvCircular und sie werden bis zu 210 Tage (bis 180 auswertbar) in die Vergangenheit reichen. Im Wiki habe ich etwas zu den neuen Zusammenhängen geschrieben.

Ob sich in der pvCircular ebenfalls negative Verbrauchswerte finden, kann mit "get ... pvCircular" geprüft werden. Wichtig hier der Schlüssel con_all. Sauber sieht er etwa so aus:

      con_all => Mo  @ 634 708 483
                Mi  @ 648 665
                Fr  @ 567 522
                Do  @ 528 727
                Sa  @ 682 616
                So  @ 1059 578
                Di  @ 570 665 575

Sollten dort auch negative Werte zu finden sein, sagt Bescheid. In der aktuellen Version werden keine negativen con-Werte in diesen Schüssel eingetragen.

[DS_Starter]

Hallo Peter,

Wäre es evtl. für die Ertragsprognose hilfreich, die Momentanleistungen der einzelnen Strings zu kennen?

Naja, das wäre maximal für die aktuelle Stunde hilfreich um daraus über ein Integral auf die Stundenleistung zu schließen.
Für die Prognose der kommenden Stunden kann man den Wert nicht verwenden. Diese Prognosen bzw. der Tageswerte liefern die API's der gewählten Wetterdienste.

Weiter verbessern ließe sich die Prognose evtl. mit der genauen Angabe der Dachneigung.
Meine Paneele liegen auf dem Dach, das eine Neigung von 38 Grad hat. Ich muss hier aber näherungsweise 40 Grad angeben.
Ich habe aktuell, da die Sonne jeden Tag etwas höher steigt, den Eindruck, dass 2 Grad einen recht deutlichen Unterschied in der potentiellen maximalen Leistung machen?

Die Angabe des Neigungswinkels (set .. setupStringDeclination) kann ich freigeben.
Durch die Weiterentwicklungen der letzten Monate können wir jetzt den Winkel zw. 0 und 90 Grad in 1-Grad Schritten frei angeben.
Ich baue das kurzfristig ein.

LG,
Heiko

[peterboeckmann]

Hallo Heiko,

Naja, das wäre maximal für die aktuelle Stunde hilfreich um daraus über ein Integral auf die Stundenleistung zu schließen.
Für die Prognose der kommenden Stunden kann man den Wert nicht verwenden. Diese Prognosen bzw. der Tageswerte liefern die API's der gewählten Wetterdienste.

wenn man die Werte direkt betrachtet, hast Du Recht. Ich dachte, es gibt evtl. eine Möglichkeit, die string-spezifischen Werte in die KI zum Lernen einfließen zu lassen?

Die Angabe des Neigungswinkels (set .. setupStringDeclination) kann ich freigeben.
Durch die Weiterentwicklungen der letzten Monate können wir jetzt den Winkel zw. 0 und 90 Grad in 1-Grad Schritten frei angeben.
Ich baue das kurzfristig ein.

Das ist super! Danke dafür schonmal vorab.

Viele Grüße,
Peter

[grappa24]

Deswegen würde ich die vorhandenen neg. Werte löschen und beobachten ob neue entstehen.
Wie das geht steht im Log, z.B.:

2025.02.18 14:11:32.335 1: SolCast6 - WARNING - The stored Energy consumption of day/hour 04/15 is negative. This appears to be an error. The incorrect value can be deleted with 'set SolCast6 reset consumption 04 15'.
2025.02.18 14:11:32.338 1: SolCast6 - WARNING - The stored Energy consumption of day/hour 18/13 is negative. This appears to be an error. The incorrect value can be deleted with 'set SolCast6 reset consumption 18 13'.
2025.02.18 14:11:32.341 1: SolCast6 - WARNING - The stored Energy consumption of day/hour 31/15 is negative. This appears to be an error. The incorrect value can be deleted with 'set SolCast6 reset consumption 31 15'.

Die "reset consumption dd hh" Befehle funktionieren bei mir nicht     Die aufgelisteten Werte sind in der Tat alle negativ

[DS_Starter]

Die "reset consumption dd hh" Befehle funktionieren bei mir nicht 

Was heißt das? Wie was funktioniert nicht? Gibt es einen Fehler oder beschreibe mal bitte was du machst.

[grappa24]

Ich nehme die Befehle aus dem Log, z.B. "set solErtrag reset consumption 01 07" und gebe sie in der FHEM Befehlszeile ein.
-> keine Rückmeldung und im Logfile bleibt der Fehler bestehen.

Ein "get soErtrag pvHistory 01" listet dann den negativen con-Wert immer noch auf, hier -87

Code Auswählen Erweitern

07 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
            etotali01: 9308650.02759221, etotali02: -, etotali03: -
            pvrl01: 0, pvrl02: -, pvrl03: -
            etotalp01: -, etotalp02: -, etotalp03: -
            pprl01: -, pprl02: -, pprl03: -
            confc: 1, con: -87, gcons: 1, conprice: 0.32
Was mir auffält: Im setter für SF gibts den reset-Befehl für "consumption dd hh" nicht?

[DS_Starter]

Ach .... ich werd alt 

In der aktuellen Version heißt es ja auch:

  reset consumptionHistory dd hh

Sorry

(Kommt auf die Korrekturliste. In der Hilfe steht es richtig, nur die Logausgabe habe ich vergessen nachzuziehen.  )

[DS_Starter]

Jetzt wird das Löschen klappen, ist aber nur die halbe Wahrheit.
Nun ist noch wichtig zu ergründen woher diese Werte kommen sofern sie immer wieder eingetragen werden.
Es kann "mal" passieren, zum Beispiel bei einer temporär falschen Einrichtung, sollte aber nicht permanent auftreten.

[Dirk070]

Guten Morgen,

so, das Nullen hat funktioniert, jetzt ist der initdaygcon: 0

Code Auswählen Erweitern

99 => tdayDvtn: -, ydayDvtn: -8.83
      todayConsumption: 8540, feedintotal: 0, initdayfeedin: 0
      gridcontotal: 8540, initdaygcon: 0
      initdaybatintot01: 0, initdaybatintot02: -, initdaybatintot03: -
      initdaybatouttot01: 0, initdaybatouttot02: -, initdaybatouttot03: -
      batintot01: 0, batintot02: -, batintot03: -
      batouttot01: 0, batouttot02: -, batouttot03: -
      lastTsMaxSocRchd01: 1739375885, lastTsMaxSocRchd02: -, lastTsMaxSocRchd03: -
      nextTsMaxSocChge01: 1741103885, nextTsMaxSocChge02: -, nextTsMaxSocChge03: -
      days2care01: -, days2care02: -, days2care03: -
      runTimeTrainAI: -, aitrainLastFinishTs: -, aiRulesNumber: -
      attrInvChangedTs: 1739282920
Die Balken in der Verbrauchsgraphik zeigen von 00:00-06:00 noch immer Null.
Ich habe jetzt noch einen RESET CONSUMPTION abgesetzt, hätte aber gedacht, dass nach Mitternacht mit dem korrekten Startwert nun die Verbrauchswerte ab diesem Zeitpunkt schon korrekt wären.