danke für die coole Idee . Gern würde ich es mal testen, es klemmt bei meiner Installation aber an 2 Punkten:
Meine seit mehreren Jahren geloggte Leistungsvariable ist in kW, nicht W. Jetzt könnte ich natürlich alles kopieren und umrechnen… Wäre es möglich, die Eingangsgröße in Deinem Modul-Konfigurator einstellbar (W/kW) zu machen?
Ähnliches Problem: Meine Anwesenheitsvariable ist eine Abwesenheitsvariable, also umgekehrte Logik. Auch lösbar, aber eleganter wäre auch hier ein Umschalter (normal/invers) zu haben.
alles ist umgestrickt und bei der Gelegenheit habe ich es auch noch um eine Lernkomponente erweitert und Hilfe habe ich in das Modul auch noch reingepackt. Deine 2 Probleme sind so gelöst, dass das Modul die Einheit in Deiner geloggten Leistungsvariablen entweder selbst erkennen kann oder Du es einstellen kannst. Für Deine Anwesenheitsvariablen ist “Automatik” keine Option. Für die Anwesenheit musst Du hart zugreifen und den Schalter einstellen ob invertiert sein soll.
Ich wünsche Dir mit dem Modul viel Spass beim ausprobieren und würde mich sehr über eine ehrliche Rückmeldung freuen. Zum einen natürlich über den Aufbau und der Konzeption des Moduls zum Anderen zu der Leistung- und Aussagefähigkeit.
Insgesamt musst man dabei natürlich sehen, dass dies ein Modul eines größeren Ganzen (EMS) werden soll, was alles abbildet.
ich teste gerade dein PVPrognose-Modul mit drei Generatoren: Süd als AC-PV (liefert frei) sowie Ost und West über DC-MPPT.
Bei Ost/West entspricht die gemessene Leistung nicht immer dem möglichen Wetterertrag: Mein eigenes Energiemanagement begrenzt die beiden MPPTs prognoseabhängig teilweise schon morgens, z. B. auf 10 A je Regler. Zusätzlich regeln die MPPTs bei etwa 55,2 V Batteriespannung selbstständig herunter.
Wäre eine Selbstkalibrierung pro PV-Generator möglich? Für Ost/West wäre außerdem ideal, wenn Messwerte bei aktivem Stromlimit bzw. bei Spannungsregelung von der Kalibrierung ausgeschlossen werden können. Sonst lernt die Prognose aus absichtlich abgeregelter Leistung eine dauerhaft zu kleine PV-Erzeugung.
Süd könnte dagegen normal kalibriert werden.
Aktuell lese ich bereits die PV-Prognosewerte aus dem Victron VRM Portal aus und nutze sie für mein Energiemanagement.
Ich möchte das Modul zunächst parallel laufen lassen und beide Prognosen über längere Zeit mit dem realen Ertrag vergleichen. Ziel wäre, bei ausreichend guter Genauigkeit langfristig unabhängig vom Victron-Portal zu werden und die Prognose direkt lokal über das Modul zu beziehen, bzw. als Backup zu benutzen.
Durch die besondere DC-Regelung von Ost/West ist mir dabei wichtig, dass die Selbstkalibrierung nicht die absichtlich reduzierte MPPT-Leistung als schlechteren Wetterertrag lernt.
das sind Spezialaufgaben, die so mit dem Modul nicht abgebildet werden sollten. Aber, ich werde mir Gedanken dazu machen. Vielleicht wird es in dem Modul dann 2 Prognosen geben, einmal das was ungehindert möglich sein hätte können und zum anderen wo der Ertrag mit angezogenen Zügeln hätte liegen müssen.
Das mit der MPPT Spannung bei etwa 55,2 V, das musst Du mir etwas genauer erklären was Du da machst oder meinst. Ich bin zwar genau in der Branche tätig, und mache hier auch sehr viel, aber das habe ich leider nicht geschnallt.
Ja, das ist wieder speziell ich weiß aber ohne das kommen, zumindest bei mir, keine brauchbaren Werte raus.
Zu den 55,2V Batteriespannung:
Grundlegend lade zu mit den DC-MPPT die Batterien (2x 16S) diese sind bei 55,2V bei 100% SoC
Wenn diese Spannung erreicht ist, dann gehen die MPPT auf 0W herunter, laden also nicht weiter und speisen auch nicht ein.
Mein AC-Wechselrichter versorgt am Tag das Haus und speist ein.
Nachts kommt dann die Batterie ins Spiel und am nächsten Tag laden die DC-MPPT diese wieder voll.
wenn also 14kWh in der Batterie fehlen, dann kann OST WEST nur 14kWh Tagesertrag schaffen obwohl es bei einem sonnigen Tag auch 60 oder 70kWh sein könnten, wenn sie dürften…
und zusätzlich drossel ich die Dinger noch je nach Prognose, um die Batterien so langsam wie möglich den ganzen Tag über zu laden, dass sie am Tagesende gerade so 100% SoC erreichen.
das alles verfälscht nat. die Prognosen, das Victronportal kommt damit erstaunlich gut zurecht, bei deinem Modul bin ich jetzt mal gespannt.
P.S.: ich kann die mein Script gern mal zukommen lassen, das ist recht komplex, hat aber nichts mit der Prognose zu tun eher mit der intelligenten Ladung der Batterie (wofür die Prognose absolut wichitg ist)
Ok, jetzt weiß ich was Du mit den MPPT meinst, das sind die Laderegler oder auch DC/DC Spannungswandler die die Batterien direkt befeuern. Hmmm, das wäre spannend und müsste ich mir mal so richtig überlegen wie man in der Konstellation am besten vor geht.
Dein Ziel wäre mir auch sehr wichtig. Im Moment gehe ich davon aus, dass Du für die Ost-West Anlage bereits Morgens wissen möchtest, ob Du die Batterien mit max 10A voll bekommst. Stimmt diese Annahme?
Die Prognose für die Süd-Anlage sollte wiederum kein Problem darstellen. Allerdings muss man in sich trotzdem sagen, dass Prognostizieren zwar genauer wie in die Glaskugel schauen ist, aber wir wissen ja alle wie es sich mit dem Wetter und dem Schmetterlingseffekt verhält.
Dein Skript kannst Du mir aber trotzdem schon mal in einer PN zukommen lassen.
genau.. das kann ich jetzt auch schon Problemlos mit meinem Script, aber eben mit der Victron Prognose, wenn deine zusätzlich noch etwa gleiche Werte liefert, wäre es perfekt und redundant.
Leider nur für 3 Tage, da war ich verwöhnt, aber das passt auch. Hat ja nichts mit dem Modul zu tun. Eines würde ich gerne anregen. Der Text oben rechts “PV …” müsste für mich nicht sein. Dass die strichlierte Linie der aktuelle Wert ist, weiß ich. Eventuell könnte man das einstellbar machen. Dann wäre mehr Platz in der Höhe. Ansonsten, vielen Dank.
Ich glaube, dass Du das Update downloaden sollst, warum auch immer hast Du nicht die Aktuelle Version am Start.
3 Tage sollten genügen, bei 4 oder mehr Tagen hast Du soviel Unsicherheit dass es eh nur optisch etwas bringt. Dafür habe ich nun links „Gestern“ dazugebaut um auch Morgen ein Resümee ziehen zu können.
Der Text oben rechts ist die Legende und hat daneben noch die Funktion wenn Du da drauf klickst, dann wird eben zum einen die PV oder der Verbrauch ausgeblendet wenn Du Dich nicht zuvor schon entschieden hast das eine oder andere auszublenden.
Den Rest schaue ich mir nochmals an und mache mir meine Gedanken dazu wie ich es vielleicht noch verbessern könnte.
Vielen Dank auch für die sehr wichtige und hilfreiche Mitteilung, dass es soweit passt. Rückmeldungen - auch kurze - sind immens Wichtig!
Hallo @Bricoleur , danke für die Umsetzung meiner Wünsche. Grundsätzlich funktioniert es jetzt, auch wenn die Streuung des 10/90-Bandes hoch ist. Da muss ich noch mal in Ruhe nachsehen.
Eine Frage habe ich noch bezüglich der OpenWeather-Instanz: Ich verwende 2 davon - welcher wird da gewählt bzw. kann ich die für die Prognose relevante explizit benennen?
Zur OpenWeather-Frage: Bisher hat das Modul im Auto-Modus einfach die erste gefundene OpenWeatherData-Instanz genommen — bei zweien also nicht steuerbar. Ab Build 43 kannst du im Panel „Temperaturvorhersage" die gewünschte Instanz explizit auswählen („OpenWeatherData-Instanz (Auto)"). Leer gelassen = wie bisher automatisch die erste. Voraussetzung bleibt, dass in der gewählten Instanz die Stundenvorhersage aktiv ist (hourly_forecast_count > 0 ).
Zum breiten 10/90-Band: Guter Punkt, den schau ich mir an. Aktuell kommt das Band aus der Streuung der „ähnlichen Tage" (k-NN-Nachbarn) — bei heterogenem Verbrauch wird das schnell breit. Auf der Roadmap steht, das Band stattdessen aus den tatsächlichen Prognose-Residuen zu bilden (also „in 90 % der Fälle lag der reale Wert drunter"), dann wird P10/P90 realistischer und meist enger. Die dafür nötige Trefferstatistik sammelt das Modul über die Snapshots bereits.
danke für den ausführlichen Bericht mit den Screenshots — das hat direkt aufs richtige Problem gezeigt.
Ursache (beides hängt zusammen): Eine deiner konfigurierten Variablen ist nicht archiviert. Das Modul hat trotzdem versucht, ihre Historie zu lesen — daher die vielen Warnungen im Meldungsprotokoll („Logging nicht verfügbar" bzw. „Aggregation aus der Zukunft"). Und genau das ist auch der Grund, warum die Wallbox nicht abgezogen wurde: Der Abzug funktioniert nur mit archivierten Werten, weil das Modul aus der Vergangenheit lernt.
Was ich geändert habe (aktuelle Beta):
Vor jedem Archivzugriff wird jetzt der Logging-Status geprüft → keine Warnungen mehr für nicht geloggte Variablen.
Die Auswertung läuft nicht mehr in die Zukunft (das war die zweite Warnung).
Der Status listet jetzt klar auf, welche Variablen nicht archiviert sind: „ nicht archiviert (ignoriert): …" — so siehst du sofort, wo das Logging fehlt.
Was du tun musst: Für die Wallbox-Variable (und ggf. weitere, die im Status auftauchen) die Archivierung aktivieren (Variable → Archivieren). Danach wird sie sauber abgezogen. Bis genügend Historie vorliegt, greift die Prognose auf die vorhandenen Tage zurück.
Ein Hinweis zur Kachel: Selbst wenn die Wallbox korrekt abgezogen wird, taucht sie weiterhin im Ist-Verlauf auf — dort steht ja der reale Hausverbrauch inklusive Auto. Nur das Soll ist die bereinigte Grundlast. An einem Ladetag ist das Ist also zwangsläufig höher als das Soll; das ist so gewollt (das Laden plant dein EMS, nicht die Prognose).
danke — gut zu wissen, dass die Wallbox archiviert ist. Dann ist sie nicht die Ursache, und ich hatte dich da auf die falsche Fährte geschickt, sorry.
Die Meldung „Logging nicht verfügbar" betrifft dann eine andere deiner konfigurierten Variablen. Die aktuelle Beta zeigt das jetzt direkt an: Nach dem Neuberechnen steht in der Status-Variable der Lastprognose-Instanz ⚠ nicht archiviert (ignoriert): … mit dem Namen. Magst du kurz updaten und mir diese Statuszeile schicken? Mein Verdacht: die Außentemperatur , die Anwesenheit oder der Zähler „Kumulierte System Wirkleistung (Heizung)" .
Zur Wallbox selbst: Ihr Abzug wirkt nur auf das Soll (die bereinigte Grundlast), nicht auf das Ist in der Kachel — dort steht immer der reale Verbrauch inkl. Auto. An einem Ladetag ist Ist daher höher als Soll, das ist normal. Ob der Abzug greift, siehst du eher daran, ob das Soll an Nicht-Ladetagen zu deiner Grundlast passt.
Noch ein Hinweis zu deinem Screenshot: Die Verdichtung löscht Werte nach 2 Monaten . Die Prognose lernt idealerweise aus bis zu einem Jahr — und für den Abzug sollten Hauptverbrauch und Wallbox gleich lang archiviert sein, sonst wird an älteren Tagen die Wallbox nicht mit abgezogen. Da lohnt evtl. eine längere Aufbewahrung für die Prognose-Variablen.
Schick mir gern die Statuszeile und die Liste deiner Abzugs-Variablen, dann pinnen wir es genau fest.
perfekt — genau dafür ist die neue Statuszeile da: Es war deine Anwesenheits-Variable („Status"), die nicht archiviert war.
Was du tun solltest: Für diese Variable die Archivierung aktivieren. Zwei Effekte:
Die Warnungen im Meldungsprotokoll verschwinden.
Die Prognose wird spürbar besser — Anwesenheit ist eines der stärksten Merkmale. Ohne sie kann das Verfahren „zu Hause"- und „unterwegs"-Tage nicht unterscheiden und mischt sie → die Vorhersage landet dazwischen und wird tendenziell zu niedrig.
Und das passt exakt zu deiner Prognosegüte: Bias −27 % — die Vorhersage liegt im Schnitt ~27 % zu tief, ein großer Teil davon kommt sehr wahrscheinlich von der fehlenden Anwesenheit. Wichtig: Die Anwesenheits-Historie baut sich erst ab jetzt auf (Archivierung wirkt nicht rückwirkend) — der volle Nutzen kommt also über die nächsten Tage/Wochen. Auch die MAPE (28,7 %) beruht bisher nur auf 7 Tagen; das stabilisiert sich mit mehr Datenbasis.
Noch relevant vom letzten Mal: Achte darauf, dass Hauptverbrauch, Wallbox und Anwesenheit ähnlich lange archiviert werden (deine Verdichtung löscht nach 2 Monaten) — je mehr Historie, desto besser die Treffer.
Schau in ein paar Tagen nochmal auf den Bias, der sollte Richtung 0 wandern. Sag gern Bescheid, wie es sich entwickelt!
Irgendwie kommt bei mir noch immer diese Fehlermeldung:
26.07.2026, 06:35:59 | TimerPool | LoadForecast (LFC_RebuildTimer):
Warning: Aggregation von Datensatz aus der Zukunft fehlgeschlagen in /mnt/data/symcon/modules/.store/eu.dg.prognose/Lastprognose/module.php on line 728
Warning: Aggregation von Datensatz aus der Zukunft fehlgeschlagen in /mnt/data/symcon/modules/.store/eu.dg.prognose/Lastprognose/module.php on line 728
nicht archiviert (ignoriert): …" — so siehst du sofort, wo das Logging fehlt.
