76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[denis.robel]

Weglassen geht nicht weil Pflichtangabe.
Bei dir ist diese Richtung immer 0 weil die nichts vom Hausnetz in die Batterie speist. ac2dc=0:W wird vermutlich funktionieren, ist aber unschön weil der Wert daraus undef ist.
Ich würde dir vorschlagen in zendure_bridge_b0b21c980b18 ein Reading 'SF_ac2dc' mit dem festen Wert '0' anzulegen und dieses Reading in der Definition anzugeben. Dann liest das Modul immer definiert 0 W.
Anzugeben dann so:

Code Auswählen Erweitern

attr SolarForecast_dach setupInverterDev02 zendure_bridge_b0b21c980b18\
  strings=none\
  dc2ac=output_home_power:W\
  ac2dc=SF_ac2dc:W\
  capacity=1200\
  asynchron=0

Edit: Ein kleiner Hinweis zum userReadings. Du hast keinen definierten Trigger angegeben. D.h. das userReading berechnet bei jedem Event des Device MQTT2_shellypro3em_34987a465e38 neu. Wenn du das öfter in deinem System machst, geht das ganz schön auf die Rechnerleistung/Performance. Besser ist es ein bestimmtes Reading des Device als Trigger zu benutzen. Und dann im Attr angeben z.B. so:

Code Auswählen Erweitern

attr MQTT2_shellypro3em_34987a465e38 userReadings gcon:TriggerReading.* { ReadingsVal($name,"total_act_power",0) > 0 ? ReadingsVal($name,"total_act_power",0) : 0 },\
gfeedin:TriggerReading.* { ReadingsVal($name,"total_act_power",0) < 0 ? abs(ReadingsVal($name,"total_act_power",0)) : 0 }

LG,
Heiko

ok hab ich alles angepasst, auch das triggerreading beim Shelly.

Danke für die hilfreichen Hinweise.

Hallo Heiko,

ich habe jetzt das Ganze ein paar Tage laufen lassen und festgestellt, dass

1. die KI nicht fertig wird mit trainieren. Ich habe immmer nur 2 gelbe Punkte bei dem KI Status.
2. die Grafik für den Energiefluss den eigentlichen PV Input nicht so richtig darstellt. Der PV-Input setzt sich zusammen aus der Summe der Leistung bei dem Sonnen Symbol und der Leistung beim Solar Charger.


Wenn alles in die Batterie geladen wird, steht bei PV-In 0W und beim Solar Charger die Leistung, die von den PV-Modulen direkt in die Akkus geladen wird.
Hat das Auswirkungen auf die Trainingsdaten der KI?

[DS_Starter]

@grappa24,

Bitte im Wiki den Abschnitt PV-Vorhersage an evcc übertragen (PV-Überschussladen von E-Autos über steuerbare Wallboxen) ergänzen.

Ich habe den Abschnitt ergänzt.
Bitte gegenchecken da ich nicht der Autor des Beitrages bin.
Du/ihr könnt euch auch einen Wiki-User besorgen und mit dokumentieren. Das hilft ungemein.

[DS_Starter]

@300P,

Block=bias_implausible kommt, wenn der Bias über einen definierten Grenzwert steigt. Das kann durchaus mit der Zeitumstellung zu tun haben (machen wir das erste Mal mit FANN durch).
Andererseits könnte die Einstellung aiConShuffleMode=1 aktuell ungünstig sein.
Warum?
Bei deinen 8341 Datensätzen werden für Training=6672 genutzt und zur Validation=1669, wobei das Splitting chronologisch ist. D.h. die letzten ca. 2,5 Monate werden zur Validierung genutzt und die ca. 9,5 Monate davor sind Trainingsdaten, wobei die meiste Zeit davon auf nicht Wintermonate fällt. Jetzt kommen wir wieder in die Frühlings- und Sommermonate. Im Prinzip wird für die Validierung eine Zeit genutzt, die weder für die Trainingsdaten noch für die akzuellen Live Daten typisch ist.
Wenn dein System trotz allem gute Ergebnisse erzeugt, muß man ja nichts ändern. Wobei ein Test mit aiConShuffleMode=2 m.M.nach nicht schaden kann.

[DS_Starter]

@Denis,

1. die KI nicht fertig wird mit trainieren. Ich habe immmer nur 2 gelbe Punkte bei dem KI Status.

Das sind 2 verschiedene KI, PV und CON. Gelb kann mehrere Ursachen haben. Einen ersten Hinweis gibt ein Mouse-Over Popup über den gelben Punkten.

2. die Grafik für den Energiefluss den eigentlichen PV Input nicht so richtig darstellt. Der PV-Input setzt sich zusammen aus der Summe der Leistung bei dem Sonnen Symbol und der Leistung beim Solar Charger.

Zeig mal deine aktuelle setup* Konfiguration.
Für das Wording ist wichtig ... der Inverter bei dir mit dem Sonnensymbol ist der Solar-Charger, d.h. der Inverter der die PV Energie liefert die entweder nur in die Batterie geht und/oder in das Hausnetz. In der Mitte befindet sich der Batterie-WR der nur die Energie (664W) von der Batterie bzw. dem Solar-Charger (wenn Bat voll ist) umgewandelt in das Hausnetz leifert.

[denis.robel]

Hallo Heiko,

hier die Infos:

@Denis,

Das sind 2 verschiedene KI, PV und CON. Gelb kann mehrere Ursachen haben. Einen ersten Hinweis gibt ein Mouse-Over Popup über den gelben Punkten.

Der linke gelbe Punkt liefert bei Mouse over:
Die KI-Unterstützung arbeitet einwandfrei, liefert jedoch keinen Wert für die aktuelle Stunde. Letztes KI-Training: 20.02.2026 02:15:26

Der rechte gelbe Punkt liefert:
das neuronale Netz zur Verbrauchsprognose wird gerade trainiert, die Prognose erfolgt ohne KI.
letztes Training des neuronalen Netzes Verbrauchsprognose: -

Zeig mal deine aktuelle setup* Konfiguration.
Für das Wording ist wichtig ... der Inverter bei dir mit dem Sonnensymbol ist der Solar-Charger, d.h. der Inverter der die PV Energie liefert die entweder nur in die Batterie geht und/oder in das Hausnetz. In der Mitte befindet sich der Batterie-WR der nur die Energie (664W) von der Batterie bzw. dem Solar-Charger (wenn Bat voll ist) umgewandelt in das Hausnetz leifert.

Code Auswählen Erweitern

defmod SolarForecast_dach SolarForecast
attr SolarForecast_dach aiControl aiConActivate=1 aiConProfile=v1_common_active
attr SolarForecast_dach ctrlLanguage DE
attr SolarForecast_dach event-on-change-reading .*
attr SolarForecast_dach graphicBeam1Content pvReal
attr SolarForecast_dach graphicBeam2Content pvForecast
attr SolarForecast_dach graphicBeam3Color FFC875
attr SolarForecast_dach graphicBeam3Content batsocRealSum
attr SolarForecast_dach graphicBeam4Content batsocForecastSum
attr SolarForecast_dach graphicBeam5Content energycosts
attr SolarForecast_dach graphicShowNight 01
attr SolarForecast_dach plantControl cycleInterval=60
attr SolarForecast_dach room Solar
attr SolarForecast_dach setupBatteryDev01 zendure_bridge_b0b21c980b18 \
  pin=output_pack_power:W \
  pout=pack_input_power:W \
  cap=3840 \
  charge=electricity_level show=1\
  icon=@dyn:@dyn:@dyn:@dyn
attr SolarForecast_dach setupInverterDev01 zendure_bridge_b0b21c980b18\
  feed=bat \
  pvIn=solar_input_power:W \
  pvOut=output_pack_power:W\
  strings=Dach1\
  etotal=solar_input_energy:Wh\
  capacity=1400\

attr SolarForecast_dach setupInverterDev02 zendure_bridge_b0b21c980b18\
  strings=none\
  dc2ac=output_home_power:W\
  ac2dc=sf_ac2dc:W\
  capacity=1200\
  asynchron=0
attr SolarForecast_dach setupInverterStrings Dach1
attr SolarForecast_dach setupMeterDev MQTT2_shellypro3em_34987a465e38 \
  gcon=gcon:W \
  contotal=total_act:Wh \
  gfeedin=gfeedin:W \
  feedtotal=total_act_ret:Wh \
  conprice=0.30:€ \
  feedprice=0.00:€
attr SolarForecast_dach setupRadiationAPI OpenMeteoDWD-API
attr SolarForecast_dach setupStringAzimuth Dach1=15
attr SolarForecast_dach setupStringDeclination Dach1=35
attr SolarForecast_dach setupStringPeak Dach1=1.780
attr SolarForecast_dach setupWeatherDev1 OpenMeteoDWD-API


[DS_Starter]

Der linke gelbe Punkt liefert bei Mouse over:
Die KI-Unterstützung arbeitet einwandfrei, liefert jedoch keinen Wert für die aktuelle Stunde. Letztes KI-Training: 20.02.2026 02:15:26

Das ist ok.

Der rechte gelbe Punkt liefert:
das neuronale Netz zur Verbrauchsprognose wird gerade trainiert, die Prognose erfolgt ohne KI.
letztes Training des neuronalen Netzes Verbrauchsprognose: -

Hier ist das Traningslog wesentlich -> ctrlDebug=aiProcess -> dann Training (neu) starten.

attr SolarForecast_dach setupBatteryDev01 zendure_bridge_b0b21c980b18 \
  pin=output_pack_power:W \
  pout=pack_input_power:W \
....
attr SolarForecast_dach setupInverterDev01 zendure_bridge_b0b21c980b18\
..
  pvIn=solar_input_power:W \
  pvOut=output_pack_power:W\
...

Diese Schlüssel müsstest du nochmal prüfen. Das pvOut von setupInverterDev01 sollte die aktuell erzeugte PV Leistung sein und gleichzeitig pin für setupBatteryDev01. Ich weiß jetzt nicht welche Bedeutung output_pack_power und pack_input_power haben. Wenn ich annehme, dass "pack" ein Batterie in/out ist und du eventuell nur einen impliziten Wert solar_input_power für die gelieferte PV hast, könnte es so richtig sein:

attr SolarForecast_dach setupBatteryDev01 zendure_bridge_b0b21c980b18 \
  pin=solar_input_power:W \
  pout=output_pack_power:W \
....
attr SolarForecast_dach setupInverterDev01 zendure_bridge_b0b21c980b18\
..
  pvIn=solar_input_power:W \
  pvOut=solar_input_power:W\
...

Zur besseren Ansicht schalte dir flowGraphicControl->showGenerators=1 ein.

[denis.robel]

Hallo Heiko,

hier eine Übersicht über die Energie Readings vom Zendure SolarHub 2000:

Code Auswählen Erweitern

solar_input_power         aktuelle Solar‑Eingangsleistung (Summe, in W, hier ca. 148 W).
solar_power_1 / solar_power_2         Leistung von Solarkette/String 1/2 (z.B. 73 W + 77 W).
pack_input_power                 aktuelle Ladeleistung in die Batteriepacks (z.B. 501 W = wird geladen).
output_pack_power                 aktuelle Ausgangsleistung aus den Batteriepacks (hier 0, offenbar im Standby).
output_home_power                 aktuelle Ausgangsleistung für den Haus‑Verbraucher (in W, hier ca. 626 W).
output_limit / inverse_max_power maximale Ausgangsleistung (z.B. 1200 W = Inverterleistungsgrenze).
pack_num                         Anzahl der angebundenen Batterie‑Packs (z.B. 2).
master_switch                         Zustand des Hauptschalters (z.B. ON = Hub aktiv).
auto_recover                         ON/OFF = ob nach Ausfall/Shutdown automatisch wieder gestartet wird.

Wobei von der aktuellen Situation pack_input_power und output_pack_power von der Bezeichnung her vertauscht sein müssen, weil der Akku gerade entlädt...

Ich habe daher meine devices so angepasst:

setupBatteryDev01:

Code Auswählen Erweitern

zendure_bridge_b0b21c980b18
  pin=solar_input_power:W
  pout=pack_input_power:W
  cap=3840
  charge=electricity_level show=1
  icon=@dyn:@dyn:@dyn:@dyn

setupInverterDev01:

Code Auswählen Erweitern

zendure_bridge_b0b21c980b18
  feed=bat
  pvIn=solar_input_power:W
  pvOut=solar_input_power:W
  strings=Dach1
  etotal=solar_input_energy:Wh
  capacity=1400

Das werde ich jetzt mal beobachten und dann wieder berichten.

Zur besseren Ansicht schalte dir flowGraphicControl->showGenerators=1 ein.

Danke für den Hinweis, damit wird die PV-Leistung nochmal separat angezeigt. Das habe ich vermisst.

[DS_Starter]

Wobei von der aktuellen Situation pack_input_power und output_pack_power von der Bezeichnung her vertauscht sein müssen, weil der Akku gerade entlädt...

Hätte ich jetzt nicht gedacht, sondern eher dass es bei output_pack_power bleibt weil:

Code Auswählen Erweitern

output_pack_power                 aktuelle Ausgangsleistung aus den Batteriepacks (hier 0, offenbar im Standby).
Das heißt doch die Bat ist voll, liefert aber nichts weil der Bedarf alleine noch durch die PV Erzeugung gedeckt wird. Aber kann mich irren, du kennst deine Anlage besser.

[DS_Starter]

@all,

folgende Problematik habe ich festgestellt.
Wie viele von euch auch habe ich ein gutes Modell (eigentlich mehrere) für die Verbrauchsvorhersage trainiert. In diesem Modell (ca. 1 Jahr Daten) ist die Anwesenheit (Digit 0|1) enthalten, wobei nur wenige Tage  Anwesenheit=0 (ca. 10-15) in den Trainingsdaten vorhanden sind, sonst Anwesenheit=1.

Nun war ich 2 Tage weg und somit die aktuelle Anwesenheit=0. Die Verbrauchsprognose ist während dieser Zeit sehr deutlich! zu hoch ausgefallen. Sobald ich wieder zu Hause war und somit Anwesenheit=1 wurde die Prognose wieder sehr gut.

Ich bin die Thematik mit meiner LLM durchgegangen und das Kernproblem ist fast sicher ein Klassenungleichgewicht – das Modell hat schlicht nicht genug ,,gelernt, was Abwesenheit bedeutet", was wohl ein klassisches Problem mit unbalancierten Klassen ist. Das ändert sich natürlich sobald mehr Daten für Abwesenheit gesammelt sind.
Aber ich wollte euch das mitteilen falls ihr bei euch änliches Verhalten feststellt.

Ich werde mir Gedanken machen ob/wie ich dieser Problematik im Code begegnen kann, z.B. durch Presence-gewichtete Lag-Features.