76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[Prof. Dr. Peter Henning]

Kommando zurück: nach ein paar Minuten hat der Resetbefehl gewirkt, danke für den Tipp. Ein get valCurrent zeigt jetzt als Prognose "warte auf weitere Tage mit einer Verbrauchszahl". Womit sich die Frage stellt, woher der absurd hohe Wert kam.

LG

pah

[300P]

...manchmal mus man es einfach hinnehmen, dass da irgendwo ein Haken 🪝 an irgendeiner Sache ist den man nicht ergründen will - weil es ,,ab jetzt" einfach funktioniert 😎😉🥳🥂🍾

[Prof. Dr. Peter Henning]

Etwas OT jetzt...

Äh - nein, das ist das Gegenteil von meiner Arbeitsweise. Und bei meinen Studenten würde ich das auch nicht akzeptieren.

LG

pah

[300P]

Nochmals OT:

...ist doch ,,nur" Hobby und für Zuhause - keine Arbeit und kein Studium. 🤓 (bin in Rente)

OT Ende


Aber es gab in der Vergangenheit schon das ein oder andere Mal Probleme mit den vorhersagewerten bei Usern die neu aufgesetzt haben.

Meist war es ein n.i.O - Wert in den Vergangenheitswerten der für solche überzogenen Forecast-Werte (Solar- oder Verbrauchswert) der Auslöser war.

Da es bei deinen ,,tollen" Werten um die Verbrauchswerte ging lag die Ursache eindeutig dort und es musste daher mit dem ,,reset" der Verbrauchswerte zu 99,9 %-iger Sicherheit klappen...😉

[Prof. Dr. Peter Henning]

So ganz ist das mit dem "Reset" gestern abend doch nicht erfolgreich gewesen.

Das hat zwar gestern den Vorhersagewert genullt. Aber heute früh (nach der Debatte Harris-Trump...) ist der Vorhersagewert für den nächsten Tag 2,4 kWh (das ist ungefähr der Betrag, der heute zwischen 0:00 und 5:00 aus dem Netz gezogen wurde). Finde ich etwas seltsam, weil eine lineare Extrapolation zu 11,52 kWh führen sollte).

Zweitens zeigt mir das Modul _heute_ einen

RestOfDayConsumptionForecast 96925 Wh

Das bedeutet, der "genullte" Vorhersagewert von gestern abend wurde nicht um Mitternacht auf den heutigen Tag übertragen, sondern die alte (falsche) Vorhersage wird für heute weiter verwendet.

Wenn ich mir die weiteren Daten ansehe, sind auch noch ein paar Fragezeichen vorhanden.
Beispiel: Ich habe zwei Strings in meiner zweiten PV-Anlage, die sind mit dem Attributwert

setupStringPeak PV2.south=2.64 PV2.north=3.52

(in kWp) eingetragen. Warum und wie macht das Modul daraus ein

allstringspeak => 5460

LG

pah

Und OT:
Na, in meinem (ehemaligen) Job ist das schwer zu trennen. Wenn ich jetzt noch ein weiteres Buch über Hausautomatisierung schreibe: Ist das nun Hobby, oder Arbeit?
Ende OT

[TheTrumpeter]

Mir fallen die eigenen Fehler bei Konfigurationen auf, weil ich erst alle Möglichkeiten überprüfe, bevor ich etwas ins Forum schreibe.

Ich prüfe es auch selbst 3x, bevor ich was ins Forum schreibe.
Trotzdem rutscht MIR manchmal ein Fehler durch, weil ich die Anleitung vielleicht nicht richtig verstanden/interpretiert habe oder möglicherweise gerade den Wald vor lauter Bäumen nicht mehr gesehen habe.

Das hat zwar gestern den Vorhersagewert genullt. Aber heute früh (nach der Debatte Harris-Trump...) ist der Vorhersagewert für den nächsten Tag 2,4 kWh (das ist ungefähr der Betrag, der heute zwischen 0:00 und 5:00 aus dem Netz gezogen wurde). Finde ich etwas seltsam, weil eine lineare Extrapolation zu 11,52 kWh führen sollte).

Wer sagt, dass die Vorhersage linear verläuft?
Soweit ich die Idee hinter dem Modul bisher verstanden habe, sind die Stundenwerte Basis für Hochrechnungen. Wenn Du gestern Abend "genullt" hast, dann hat das Modul zwar Vorhersagedaten für die Stunden nach dem Reset, nicht aber für die vor dem Reset. Daher könnte es ein, dass die Stunden vor dem Reset einfach mit "0" in die Vorhersage eingehen.

Du kannst das aber überprüfen, indem Du Dir die Vorhersagedaten ausliest:
get mySolarForecast nextHours

Die Werte confc und confcEx sind dann die stündlichen Prognosewerte, die aber auch den Werten in der Vorhersagegrafik entsprechen. Dort würdest Du auch sehen welchen Verbrauch das Modul für die einzelnen Stunden annimmt.

[300P]

Guten Morgen,

Zeig einmal im Lauf des Tages mit get ... pvHistory den aktuellen Stand deiner Daten.

Dort erkennt man ebenfalls ob und wo etwas in/an den Daten hängt.

Und zusätzlich noch ein get ... pvCircular wäre hilfreich.

Es gibt im Modul die Moglichkeit solche evtl. fehlerhaften Werte in diesen historischen Werte-Tabellen zu löschen.

Gruß
300P

[Prof. Dr. Peter Henning]

Wer sagt, dass die Vorhersage linear verläuft?

Na, mal langsam.
Erstens habe den Reset gestern um 21:00 durchgeführt - für die Zeit bis Mitternacht sind also Daten vorhanden.
Zweitens muss selbstverständlich jede Vorhersage auf Basis der _jüngsten_ Vergangenheit geschehen, das ist einfach gute wissenschaftliche Praxis. Und bei einem einigermaßen konstanten Verbrauch (wie bei mir) läuft das auf eine lineare Fortschreibung hinaus, das ist elementare nummerische Mathematik.

Schlussfolgerung: Ich verstehe die hier angewandten Algorithmen nicht. Bevor ich dieses Verständnis nicht habe, werde ich das nicht weiter kritisieren. Aber trauen werde ich dem auch nicht...

LG

pah

[kask]

Soweit ich weiß basiert die Vorhersage auf die Vergagenheit.
Wieso sollte man da eine Hochrechnung einbringen wenn nicht einmal eine ganze Datenbasis vorhanden ist (21.00 - 09:40).
Klar könnte man das machen wenn man sofort Daten haben will/muß.

Aber es ist jetzt nun erstmal egal ob bei einem die Daten 24/7 konstant sind. Nicht mal ein Datensatz ist komplett (24h) um irgend etwas an Vorhersage zu geben.
Und ob ob es da Sinn macht dahingehend was einzupflegen um <24h Zeitvorteil zu erhalten ist fragwürdig.
Am darauf folgenden Tag sollte erstmals brauchbares an Daten kommen bei 24/7 ziemlich konstanten Verbrauch. Die Zeit sollte man da schon mitbringen können.

Die Frage ist aber wirklich warum da ein 10facher Wert ausgegeben wurde.
Das gilt es schon zu hinterfragen was da ursächlich für verantwortlich war. Schliesslich geht der 10fache Wert dann so auch in Zukunft auf die Wertbildung. Und das würde eine normalisierung stark verzögern bzw. die nächsten Tage und die Tage auf dem darauf folgenden Monat ziemlich verfälschen.
Das ist sehr unschön.
So wie ich das verstanden habe wurde ja ein neues Device eingefplegt. Das kann doch eigentlich keine "alt Lasten" aufnehmen.
Was hat das jetzt hervorgerufen. Ich finde es auch komisch.

[Prof. Dr. Peter Henning]

Wie geschrieben: Ich werde nur kritisieren, was ich verstanden habe.
Es dauert eine Weile, sich durch 20.000 Zeilen Code zu graben.

Generell aber gilt: Wenn keine Vorhersage möglich ist, sollte auch keine ausgegeben werden. Das kann man schon erwarten - und nicht etwa einen Wert, dessen Fehlerhaftigkeit im Nachhinein ausführlich begründet wird.

Konkret also: Im dargestellten Fall könnte entweder statt eines Vorhersagewertes eine Warnung auftauchen ("nicht genug Daten"). Oder ein vereinfachter Wert (von mir aus per Extrapolation) mit zusätzlicher Warnung ("verringerte Genauigkeit").

LG

pah

[DS_Starter]

Die Verbrauchsprognose wird aus den aufgezeichneten Stundenwerten der pvHistory Key "con" jedes Tages und jeder Stunde über Durchschnittskalkulation die Ableitung für die kommenden Stunden erstellt. Dabei werden nur die gleichen Stunden der Tage betrachtet. Mit dem Attr affectConsForecastIdentWeekdays kann darüber hinaus bestimmt werden ob ebenfalls nur identische Wochentage (Mo - So) zueinander betrachtet werden sollen um "Gewohnheiten" an bestimmten Tagen nicht über alle anderen Tage zu verteilen.

Die so ermittelten Prognosen kann man sich mit "get ... nextHours" im Key "confc" ansehen. Der Schlüssel "confcEx" enthält die Verbrauchsprognose ohne den aufgezeichneten Energieanteil registrierter Verbraucher. Damit kann z.B. die verwendete Ladeenergie eines E-Autos von der Prognose ausgeblendet werden. Soll ein Verbraucher in diesem Kontext in den Key "confEx" eingehen, kann der Key "exconfc=1" im Consumerattribut gesetzt werden.

Im Nachhinein eine Ursachenanalyse vornehmen zu wollen ist müßig. Wenn etwas nicht einleuchtet hilft in diesem Kontext das Attr ctrlDebug=consumption um Anhaltspunkte zu erhalten solange der Zusatnd vorhanden ist.

LG

[DS_Starter]

@300P

Zur Info wg. neuer Version:
Meine BHKW-Logik hat sich entschieden heute ab 21:06 Uhr das BHKW mal zu starten und entsprechend zeitverzögert nach ca. 1h dann mit der Stromproduktion zu beginnen.
=> sieht alles bislang prima (65 W  ->ab 22:00Uhr)

(Den o.g. Wert "pprl01" sehe ich bislang noch nicht)

"pprl01" ist ein Key in der pvHistory, kein Reading. Es gibt pprl01 - pprl03.

Die Grafik sieht "natürlich" jetzt bei der Produktion "seltsam" aus 

Ja das müssen wir noch anpassen. Hatte ich nicht auf dem Schirm.
Weiß nicht ob kask schon was gemacht hat. Ich habe gerade etwas wenig Zeit, aber jetzt wird es ja wieder etwas herbstlicher. 

LG,
Heiko

[Bozan]

Hallo Zusammen,

nach geraumer Zeit hatte ich bei mir mal wieder dieses Modul aktualisiert und augenscheinlich läuft es auch soweit korrekt.
Dennoch habe ich an einer Stelle ein Verständnisproblem.
Diese Readings bekomme ich korrekt anzeigt, weshlab ich davon ausgehe, dass das Batterie-Setup stimmt.

Current_PowerBatIn    709 W    2024-09-12 10:27:34
Current_PowerBatOut    0 W    2024-09-12 10:24:47

Aber die dokumentierten Stundenwerte stimmen meines Erachtens überhaupt nicht, hier einmal exemplarisch:

Today_Hour11_BatIn    100 Wh    2024-09-12 10:24:47
Today_Hour11_BatOut    0 Wh    2024-09-12 10:24:47

Die Werte sind hier IMMER Vielfache von 100 Wh und weit weg von der Realität.

Dies hier ist mein Setup:

setupBatteryDev
   
BYD_Batterie pin=BatteryChargeWatt:W pout=BatteryDischargeWatt:W intotal=Summe_Ladung:kWh outtotal=Summe_Entladung:kWh cap=5120 charge=BatteryChargePercent

Welche zusätzlichen Infos benötigt Ihr ggf. noch?

VG,
Bozan

[Gisbert]

Hallo Heiko,

ich weiß, dass man die fhem.cfg nicht editieren soll. Da ich vor vielen Jahren mal damit angefangen habe, Definitionen in eigene Module (Own modules and helper files) per include in der fhem.cfg auszulagern, hatte ich auch das mit SolarForecast getan. Bisher gab es aus der Erinnerung heraus keine Probleme damit, Devices in "Own modules and helper files" auszulagern. Diesmal hat es bei SolarForecast dazu geführt, dass 2 Informationen verlorengegangen sind:

• setupStringAzimuth
• setStringDeclination

Diese Infos waren dank deiner geführten Installation schnell nachgeholt. Auch scheinen log-Dateien noch vorhandenen zu sein, ebenso historische Daten. Alle anderen setup-Definitionen sind als Attribute ausgeführt, so dass sie nach einem Fhem-Neustart noch vorhanden waren.

Um Kommentaren vorzubeugen - ja, es ist nicht sonderlich schlau die fhem.cfg zu editieren, man sollte es besser sein lassen und dem Drang nach Ordnung in der fhem.cfg nicht nachgeben.

Viele Grüße Gisbert

[DS_Starter]

@Bozan,

für die Stundenwerte Today_HourXX_BatIn/BatOut ist das Quellenreading im Schlüssel intotal / outtotal zuständig. Es ist zu vermuten, dass der Dateninput an dieser Stelle nicht ok ist.
Du kannst dir die Startwerte jeder Stunde in der pvHistory im Schlüssel batouttotal bzw. batintotal anschauen und verifizieren ob sie deiner Erwartung entsprechen. Die Differenzen zum Startwert der nächsten Stunde entsprechen dem jeweiligen In / Out.