76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

Shadow3561 · 13 Mai 2026, 19:45:18

Ich habe mal eine Frage. Ich messe den Verbrauch mit einem Shelly Pro 3EM.
Folgend ist es als Meter definiert

ShellyPro_3EM gcon=Active_Power_S:W gfeedin=-gcon contotal=Purchased_Energy_S:Wh feedtotal=Returned_Energy_S:Wh asynchron=1

Leider zeigt mir pv-forecast den ganzen Tag über Verbrauch an, aber nur im Balkendiagramm. In der Flussgrafik stimmen die Werte wenn ich kontrolliere. Bilder sind angehängt. Was läuft hier falsch? Hat evtl. jemand einen Shelly 3EM eingebunden und kann mir die genaue definition in pv-forecast geben?

Edit:
Wird bei mir der Eigenverbrauch von der PV mitgezählt?
Bild vom Solaredge-Zähler anbei.
Gruss,
Daniel

DS_Starter · 13 Mai 2026, 20:24:07

Ich habe die Aussage:

ZitatLeider zeigt mir pv-forecast den ganzen Tag über Verbrauch an, aber nur im Balkendiagramm. In der Flussgrafik stimmen die Werte wenn ich kontrolliere.

nicht verstanden. Kannst du es nochmal anders beschreiben was du meinst?
Welche Daten zeigen die grauen und blauen Balken im Diagramm?

DS_Starter · 13 Mai 2026, 22:15:51

@all,

ich habe an der Drift/Retrain-Empfehlung weitergearbeitet.
Das System signalisiert über eine Retrain-Empfehlung mit der Abstufung 'keine', 'empfohlen', 'dringend' an den User.
Zu sehen aktuell über das Pupup.

Update Version 2.6.9 liegt im contrib.

LG,
Heiko

Shadow3561 · 14 Mai 2026, 06:05:53

Zitat von: DS_Starter am 13 Mai 2026, 20:24:07Ich habe die Aussage:

ZitatLeider zeigt mir pv-forecast den ganzen Tag über Verbrauch an, aber nur im Balkendiagramm. In der Flussgrafik stimmen die Werte wenn ich kontrolliere.

nicht verstanden. Kannst du es nochmal anders beschreiben was du meinst?
Welche Daten zeigen die grauen und blauen Balken im Diagramm?

Moin, die grauen Balken sind consumptionForecast und die blauen gridconsumption. Jedoch wird bei gridconsumption der Eigenverbrauch von der PV mitgerechnet, ebenso der Teil der in den Akku geht. Jedoch zeigt das Flussbild die richtigen Werte an.
Gruß

300P · 14 Mai 2026, 08:53:25

Zitat von: DS_Starter am 13 Mai 2026, 22:15:51ich habe an der Drift/Retrain-Empfehlung weitergearbeitet.
Update Version 2.6.9 liegt im contrib.

Guten Morgen!

auf dem Vatertag werden heute sicherlich mehr Flaschen geleert werden als bei warmen wetter....

, denn draußen wandern ist nicht "drin".

Forecscast daher :
Viel Regen - Wenig Sonne - Viele Flaschen werden leer - viele "Flaschen" total besoffen.....

(siehe Grafik zum Vatertag)

Allen Vätern trotzdem einen Schönen Vatertag

Rückmeldung V2.6.9:
~~Ergebnis mit der V2.6.9 ist so wie ich (mit jetzigem Wissen) es erwartet hatte:~~
Ich war zu früh - nach dem nächsten Stundenwechsel wurde ein neues Training dringend empfohlen - das läuft jetzt

Code Auswählen

Informationen zum neuronalen Netz der Verbrauchsvorhersage

letztes KI-Training: 09.05.2026 21:38:52 / Laufzeit in Sekunden: 5168
KI Abfragestatus: ok
letzte KI-Ergebnis Generierungsdauer: 78.12 ms
Alpha: 0.8
Verbrauchernummer Wärmepumpe: 08

=== Modellparameter ===

Normierungsgrenzen: PV=10450 Wh, Hausverbrauch: Min=0 Wh / Max=6770 Wh
Trainingsdaten: 12069 Datensätze (Training=9655, Validation=2414)
Architektur: Inputs=98, Hidden Layers=80-40, Outputs=1
Hyperparameter: Learning Rate=0.002, Momentum=0.8, BitFail-Limit=0.28
Aktivierungen: Hidden=ELLIOT_SYMMETRIC, Steepness=1.0, Output=LINEAR
Trainingsalgorithmus: INCREMENTAL, Registry Version=v1_heatpump_active_pv
Zufallsgenerator: Mode=2, Period=20
Modellalter: 105 h

=== Trainingsmetriken ===

bestes Modell bei Epoche: 5706 (max. 15000)
Training MSE: 0.000634
Validation MSE: 0.000073
Validation MSE Average: 0.000094
Validation MSE Standard Deviation: 0.000011
Validation Bit_Fail: 0
Model Bias: -7 Wh
Model Slope: 1.0
Trainingsbewertung: ok

=== Fehlermaße der Prognosen ===

MAE: 44.38 Wh
MedAE: 33.76 Wh
RMSE: 48.59 Wh
RMSE relative: 4 %
RMSE Rating: excellent
MAPE: 3.88 %
MdAPE: 2.41 %
R²: 1.00

=== Rauschen ===

Rauschen Bewertung: low
Empfehlung für Bit_Fail: 0.28 (Einstellung von aiControl->aiConBitFailLimit)

=== Drift-Kennzahlen ===

Drift Score: 16.91
Drift RMSE ratio: 20.03
Drift Slope: 0.437
Drift Bias: 975.89
Drift Bias Live: 969.27
Drift Index: 2.73
Drift Bewertung: recalibration blocked: rmse_anomaly
Empfehlung für Retrain: keine (Grund: -)
Slope Reference: 1.0
Bias Reference: -7
letzte Rekalibrierung: -

Code Auswählen

2026.05.14 08:00:16 1: Forecast DEBUG> start add AI raw data for hour: 8
2026.05.14 08:00:16 1: Forecast DEBUG> AI raw add - 1 entities added to raw data pool (set verbose 4 for output more detail)
2026.05.14 08:00:16 1: Forecast DEBUG> AI raw data saved into file: ./FHEM/FhemUtils/AIraw_SolarForecast_Forecast
2026.05.14 08:00:17 1: Forecast DEBUG> DRIFT [con]: Flag=moderate | Block=rmse_anomaly | SlopeLive=0.437 | DriftSlope=0.437 | BiasLive=969.27 | DriftBias=975.89 | RMSErelLive=80.1 | RMSErelRatio=20.03 | BiasVarNorm=1.29 | DriftIndex=2.73 | DriftScore=16.91 | Zone3Hours=82 | Zone3Reset=0 | Hist=[moderate,moderate,moderate,moderate,moderate,moderate,moderate,moderate,moderate,moderate,moderate,moderate,moderate,moderate,moderate,moderate,moderate,moderate,moderate,moderate]
2026.05.14 08:00:17 1: Forecast DEBUG> AI FANN drift data type 'con' successfully written to file: ./FHEM/FhemUtils/NeuralNet_SolarForecast_Forecast

CON-Abweichung aktuell -12.2 % (mehr verbraucht als Forecast

) gesamter Vortag +15 % (weniger verbraucht als Forecast

)
PV-Abweichung aktuell +3.0 % (weniger erzeugt als Forecast

) gesamter Vortag -21 % (mehr produziert als Forecast

)

DS_Starter · 14 Mai 2026, 09:52:13

Guten Morgen,

ich wünsche allen ebenfalls einen schönen Feiertag.

@Shadow3561,

Zitatdie grauen Balken sind consumptionForecast und die blauen gridconsumption. Jedoch wird bei gridconsumption der Eigenverbrauch von der PV mitgerechnet, ebenso der Teil der in den Akku geht

gridconsumption ist ein Wert der direkt aus dem gemessenen bzw. gelieferten Wert von setupMeterDev->contotal abgeleitet wird. Er ist ebenfalls in den Readings Today_HourXX_GridConsumption ersichtlich.

D.h. sind dort andere Bestandteile als nur der Netzbezug enthalten, muß man das angegebene Reading in setupMeterDev->contotal überprüfen. Dort ist anzugeben:

contotal
Reading welches die Summe der aus dem Netz bezogenen Energie liefert (ein sich stetig erhöhender Zähler)
   Wird der Zähler zu Beginn des Tages auf '0' zurückgesetzt (Tageszähler), behandelt das Modul diese Situation entsprechend.
   In diesem Fall erfolgt eine Meldung im Log mit verbose 3.

Zur Kontrolle kan man ctrlDebug=collectData aktivieren. Man sieht dann etwa:

Code Auswählen

2026.05.14 09:47:49.718 1: SolCast DEBUG> collect Energy Meter data - device: SMA_Energymeter =>
2026.05.14 09:47:49.718 1: SolCast DEBUG> gcon: 19.7 W, gfeedin: 0 W, contotal: 3497.6 Wh, feedtotal: 37117.3 Wh

Relevant ist gcon für den aktuellen Bezug, dargestellt in der Flußgrafik. Der Wert in contotal ist der totale Energiebezug aus dem der Stundenwert abgeleitet wird. Dieser Wert wäre in deinem beschriebenen Kontext relevant.

LG,
Heiko

300P · 14 Mai 2026, 09:53:36

Glaube ich habe den Auslöser für meine super tollen Drifter- bzw. CON-WOW-Ergebnisse bei mir gefunden:

aiConAbsOversample=0.25
->> das ist wohl zu hoch von mir gewählt.

Code Auswählen

026.05.09 20:12:50 1: Forecast DEBUG> AI FANN - Absence oversampling: original=286 absent, target_ratio=25%, needed=3017, added=2731. New total=12069 records (absent share=25.0%)

Beim Trainigstart heute / vorhin kam wieder nach 1 Wert schon BitFail= 0
...trotzdem Tausende weitere Logzeilen mit Berechnungsergebnissen.....

so was macht mich mißtrauisch

Code Auswählen

2026.05.14 09:19:21 1: Forecast DEBUG> AI FANN - Absence oversampling: original=294 absent, target_ratio=25%, needed=3051, added=2757. New total=12204 records (absent share=25.0%)
2026.05.14 09:19:21 1: Forecast DEBUG> First attempt 0 with Seed=638160
2026.05.14 09:19:21 1: Forecast DEBUG> AI FANN Training started with Params:
input datasets=12204, 
Registry version=v1_heatpump_active_pv, 
training algo=FANN_TRAIN_INCREMENTAL, 
output AF=LINEAR, 
hidden AF=ELLIOT_SYMMETRIC, 
hidden Neurons=80-40, 
hidden steepness=1.0, 
max. Epoches=15000, 
mse_error=0.001, 
learning rate=0.00200, 
learning momentum=0.8, 
BitFail limit: 0.28, 
Data sharing=split after shuffle of training data and use AI internal shuffle (Train=9763, Test=2440), 
Data shuffle=2 (period=20)
2026.05.14 09:19:22 1: Forecast DEBUG> Epoche 1: Train MSE=0.009878, Val MSE=0.008495, Val MAE=0.070334, Val MedAE=0.057356, Bit_Fail=24 -> Snap metric improved
2026.05.14 09:19:23 1: Forecast DEBUG> Epoche 2: Train MSE=0.006709, Val MSE=0.006639, Val MAE=0.066407, Val MedAE=0.054215, Bit_Fail=0 -> Snap metric improved
2026.05.14 09:19:24 1: Forecast DEBUG> Epoche 3: Train MSE=0.004458, Val MSE=0.005276, Val MAE=0.059123, Val MedAE=0.053290, Bit_Fail=0 -> Snap metric improved
2026.05.14 09:19:25 1: Forecast DEBUG> Epoche 4: Train MSE=0.003945, Val MSE=0.004404, Val MAE=0.053285, Val MedAE=0.045342, Bit_Fail=0 -> Snap metric improved

Jetzt neuer Versuch mit :
aiConAbsOversample=0.10

Code Auswählen

2026.05.14 09:34:15 1: Forecast DEBUG> AI FANN - Absence oversampling: original=294 absent, target_ratio=10%, needed=1017, added=723. New total=10170 records (absent share=10.0%)
2026.05.14 09:34:16 1: Forecast DEBUG> First attempt 0 with Seed=956776
2026.05.14 09:34:16 1: Forecast DEBUG> AI FANN Training started with Params:
input datasets=10170, 
Registry version=v1_heatpump_active_pv, 
training algo=FANN_TRAIN_INCREMENTAL, 
output AF=LINEAR, 
hidden AF=ELLIOT_SYMMETRIC, 
hidden Neurons=80-40, 
hidden steepness=1.0, 
max. Epoches=15000, 
mse_error=0.001, 
learning rate=0.00200, 
learning momentum=0.8, 
BitFail limit: 0.28, 
Data sharing=split after shuffle of training data and use AI internal shuffle (Train=8136, Test=2033), 
Data shuffle=2 (period=20)
2026.05.14 09:34:17 1: Forecast DEBUG> Epoche 1: Train MSE=0.010520, Val MSE=0.010959, Val MAE=0.087255, Val MedAE=0.083240, Bit_Fail=18 -> Snap metric improved
2026.05.14 09:34:17 1: Forecast DEBUG> Epoche 2: Train MSE=0.007831, Val MSE=0.009136, Val MAE=0.077880, Val MedAE=0.070504, Bit_Fail=5 -> Snap metric improved
2026.05.14 09:34:18 1: Forecast DEBUG> Epoche 3: Train MSE=0.005414, Val MSE=0.007079, Val MAE=0.067047, Val MedAE=0.058759, Bit_Fail=3 -> Snap metric improved
2026.05.14 09:34:19 1: Forecast DEBUG> Epoche 4: Train MSE=0.004304, Val MSE=0.005714, Val MAE=0.060038, Val MedAE=0.051889, Bit_Fail=2 -> Snap metric improved
2026.05.14 09:34:19 1: Forecast DEBUG> Epoche 5: Train MSE=0.004044, Val MSE=0.005043, Val MAE=0.056088, Val MedAE=0.047296, Bit_Fail=2 -> Snap metric improved
2026.05.14 09:34:20 1: Forecast DEBUG> Epoche 6: Train MSE=0.003946, Val MSE=0.004730, Val MAE=0.053946, Val MedAE=0.044954, Bit_Fail=1 -> Snap metric improved
2026.05.14 09:34:21 1: Forecast DEBUG> Epoche 7: Train MSE=0.003890, Val MSE=0.004557, Val MAE=0.052602, Val MedAE=0.043257, Bit_Fail=1 -> Snap metric improved
2026.05.14 09:34:21 1: Forecast DEBUG> Epoche 8: Train MSE=0.003849, Val MSE=0.004444, Val MAE=0.051639, Val MedAE=0.042007, Bit_Fail=1 -> Snap metric improved
2026.05.14 09:34:22 1: Forecast DEBUG> Epoche 9: Train MSE=0.003816, Val MSE=0.004363, Val MAE=0.050882, Val MedAE=0.041097, Bit_Fail=1 -> Snap metric improved
2026.05.14 09:34:22 1: Forecast DEBUG> Epoche 10: Train MSE=0.003789, Val MSE=0.004301, Val MAE=0.050253, Val MedAE=0.039772, Bit_Fail=1 -> Snap metric improved
2026.05.14 09:34:23 1: Forecast DEBUG> Epoche 11: Train MSE=0.003766, Val MSE=0.004250, Val MAE=0.049714, Val MedAE=0.038807, Bit_Fail=1 -> Snap metric improved
2026.05.14 09:34:24 1: Forecast DEBUG> Epoche 12: Train MSE=0.003745, Val MSE=0.004208, Val MAE=0.049244, Val MedAE=0.038120, Bit_Fail=1 -> Snap metric improved
2026.05.14 09:34:24 1: Forecast DEBUG> Epoche 13: Train MSE=0.003727, Val MSE=0.004174, Val MAE=0.048835, Val MedAE=0.037742, Bit_Fail=1 -> Snap metric improved
2026.05.14 09:34:25 1: Forecast DEBUG> Epoche 14: Train MSE=0.003710, Val MSE=0.004146, Val MAE=0.048476, Val MedAE=0.037400, Bit_Fail=1 -> Snap metric improved
2026.05.14 09:34:26 1: Forecast DEBUG> Epoche 15: Train MSE=0.003694, Val MSE=0.004122, Val MAE=0.048161, Val MedAE=0.036715, Bit_Fail=1 -> Snap metric improved
2026.05.14 09:34:26 1: Forecast DEBUG> Epoche 16: Train MSE=0.003680, Val MSE=0.004103, Val MAE=0.047885, Val MedAE=0.036138, Bit_Fail=1 -> Snap metric improved
2026.05.14 09:34:27 1: Forecast DEBUG> Epoche 17: Train MSE=0.003666, Val MSE=0.004087, Val MAE=0.047641, Val MedAE=0.035685, Bit_Fail=1 -> Snap metric improved
2026.05.14 09:34:28 1: Forecast DEBUG> Epoche 18: Train MSE=0.003653, Val MSE=0.004074, Val MAE=0.047428, Val MedAE=0.035457, Bit_Fail=1 -> Snap metric improved
2026.05.14 09:34:28 1: Forecast DEBUG> Epoche 19: Train MSE=0.003641, Val MSE=0.004064, Val MAE=0.047242, Val MedAE=0.035230, Bit_Fail=1 -> Snap metric improved
2026.05.14 09:34:30 1: Forecast DEBUG> Epoche 21: Train MSE=0.005799, Val MSE=0.004635, Val MAE=0.048877, Val MedAE=0.034547, Bit_Fail=1 -> Snap weighted rmse improved
2026.05.14 09:34:30 1: Forecast DEBUG> Epoche 22: Train MSE=0.005641, Val MSE=0.004596, Val MAE=0.048539, Val MedAE=0.034717, Bit_Fail=1 -> Snap weighted rmse improved
2026.05.14 09:34:31 1: Forecast DEBUG> Epoche 23: Train MSE=0.005519, Val MSE=0.004600, Val MAE=0.048449, Val MedAE=0.033969, Bit_Fail=1 -> Snap weighted rmse improved
2026.05.14 09:34:32 1: Forecast DEBUG> Epoche 24: Train MSE=0.005410, Val MSE=0.004629, Val MAE=0.048512, Val MedAE=0.033811, Bit_Fail=1 -> Snap weighted rmse improved
2026.05.14 09:34:33 1: Forecast DEBUG> Epoche 26: Train MSE=0.005211, Val MSE=0.004744, Val MAE=0.048981, Val MedAE=0.033613, Bit_Fail=1 -> Snap weighted rmse improved
2026.05.14 09:35:22 1: Forecast DEBUG> Epoche 100: Train MSE=0.003605, Val MSE=0.009403, Val MAE=0.071706, Val MedAE=0.049997, Bit_Fail=32
2026.05.14 09:36:29 1: Forecast DEBUG> Epoche 200: Train MSE=0.003056, Val MSE=0.008448, Val MAE=0.063368, Val MedAE=0.039779, Bit_Fail=27
2026.05.14 09:37:01 1: PERL WARNING: Argument "" isn't numeric in sprintf at (eval 259912) line 1.
2026.05.14 09:37:35 1: Forecast DEBUG> Epoche 300: Train MSE=0.002764, Val MSE=0.010413, Val MAE=0.075234, Val MedAE=0.054856, Bit_Fail=34
2026.05.14 09:38:39 1: Forecast DEBUG> Epoche 400: Train MSE=0.002583, Val MSE=0.007742, Val MAE=0.060097, Val MedAE=0.037552, Bit_Fail=25
2026.05.14 09:39:44 1: Forecast DEBUG> Epoche 500: Train MSE=0.002410, Val MSE=0.008633, Val MAE=0.064715, Val MedAE=0.042794, Bit_Fail=35
2026.05.14 09:40:49 1: Forecast DEBUG> Epoche 600: Train MSE=0.002265, Val MSE=0.009091, Val MAE=0.064608, Val MedAE=0.040543, Bit_Fail=40
2026.05.14 09:41:54 1: Forecast DEBUG> Epoche 700: Train MSE=0.002152, Val MSE=0.008678, Val MAE=0.063506, Val MedAE=0.039698, Bit_Fail=38
2026.05.14 09:42:01 1: PERL WARNING: Argument "" isn't numeric in sprintf at (eval 274625) line 1.
2026.05.14 09:42:59 1: Forecast DEBUG> Epoche 800: Train MSE=0.002042, Val MSE=0.009026, Val MAE=0.064545, Val MedAE=0.040666, Bit_Fail=46
2026.05.14 09:44:04 1: Forecast DEBUG> Epoche 900: Train MSE=0.001937, Val MSE=0.008428, Val MAE=0.062749, Val MedAE=0.040911, Bit_Fail=39
2026.05.14 09:45:10 1: Forecast DEBUG> Epoche 1000: Train MSE=0.001850, Val MSE=0.008596, Val MAE=0.063272, Val MedAE=0.040617, Bit_Fail=42
2026.05.14 09:45:27 1: Forecast DEBUG> Early stopping bei Epoche 1026 (no improvement since 1000 epochs)
2026.05.14 09:45:27 1: === Snapshot-Statistik ===
2026.05.14 09:45:27 1: Metric-Improvement Snapshots:              19 (letzte Epoche: 19)
2026.05.14 09:45:27 1: Weighted-RMSE-Proxy-Improvement Snapshots: 5 (letzte Epoche: 26)
2026.05.14 09:45:27 1: Bit-Improvement Snapshots:                 0 (letzte Epoche: 0)
2026.05.14 09:45:27 1: Bit-Tradeoff Snapshots:                    0 (letzte Epoche: 0)
2026.05.14 09:45:27 1: Forecast DEBUG> Best Snapshot reloaded from Epoche 26: Train MSE=0.005211, Val MSE=0.004744, Val MAE=0.048981, Val MedAE=0.033613, Bit_Fail=1,
2026.05.14 09:45:27 1: Forecast DEBUG> Run Validation Test with 20% of Input data ...
2026.05.14 09:45:27 1: Forecast DEBUG> Validation finished - Best Training MSE=0.005211, Validation MSE=0.004744, Validation Bit_Fail=1
2026.05.14 09:45:27 1: Forecast DEBUG> Retrain check ->

Das sieht "besser" aus - warten wir mal was an Ergebnis kommt....

DS_Starter · 14 Mai 2026, 10:03:59

ZitataiConAbsOversample=0.25
->> das ist wohl zu hoch von mir gewählt.

Ja, sehr wahrscheinlich, siehe:

* 0.25 – 0.40 (25–40%) - starkes Oversampling, für sehr unausgewogene Datensätze mit extrem wenigen Abwesenheiten, kann übertreiben!

Technisch werden aus den wenigen Datensätzen mit Abwesenheiten (presence=0) neue Datensätze erzeugt und eingesetzt. Die Gewichtung dieser Daten wird dadurch im Trainingsprozess verstärkt, negativ wie positiv.
Das muß man also mit Vorsicht einsetzen.

300P · 14 Mai 2026, 12:38:51

Zuerst mit 0.10 - schlechtes Ergebnis

Dann nochmals trainiert mit 0.05 - weiter schlechtes Ergebnis

Dann mit 0.02:

Code Auswählen

 026.05.14 11:22:42 1: Forecast DEBUG> AI FANN - Absence oversampling not needed: current share=3.1% >= target=2

Somit wäre eine minimale Abwesenheit hinterlegt die aber geringer als die Realität ist. Dann ist ab jetzt wenigstens ein ,,Sicherheitsgurt Abwesenheit" vorhanden.😉

Jetzt kommt wenigsten ein akzeptables Ergebnis heraus🧐

DS_Starter · 14 Mai 2026, 14:55:06

Ich habe den Drift-Block im Dashboard neu strukturiert, Übersetzungen für technische Sachverhalte eingefügt und den Erläuterungsblock für Driftwerte erweitert.

Update liegt im contrib.

Edit: zur Erinnerung ... die Auswertung kann man sich auch mit "get ... valDecTree aiNeuralNetConState" ausgeben lassen.

lorisurfen · 14 Mai 2026, 16:57:52

Zitat von: DS_Starter am 13 Mai 2026, 19:39:37@Markus, @300P,

Zitatconsumer01 Heizstab 3kW (swprio=100).
consumer02-05 heater je 1000W (swprio=50).
Im Winter wenn morgens die Sonne aufgeht erwartetes Verhalten:
surplus 1000W -> consumer02 schaltet ein.
Anschließend zusätzlich surplus 1000W -> consumer 03 schaltet ein (Gesamtüberschuss (surplus + eingeschaltetete consumer) 2000W).
Weitere 1000W surplus-> consumer 04 schaltet ein (Gesamtüberschuss 3000W). usw.
Dann würde den ganzen Tag consumer02-05 mit niedriger prio an sein, und consumer01 mit höchster prio gar nicht zum Zug kommen ?
Erwartung wäre dass bei einem Gesamtüberschuss von 3000W, dann auf consumer01 mit höchster Prio umgeschaltet wird und die consumer mit niedriger prio dafür ausgeschaltet werden.
Wie 300P schon gefolgert hat, müßte man diese Logik über ctrlUserExitFn unterstützen. Für eine Logik wäre das Setup etwa so.

Definiert sind die Consumer ohne exclgroup, aber mit swprio (02-05 könnte gleich sein, aber ich würde die Reihenfolge mal vorsehen):

consumer01 Heizstab 3000W -> swprio=100, locktime=300
consumer02 heater 1000W -> swprio=50, locktime=300
consumer03 heater 1000W -> swprio=40, locktime=300
consumer04 heater 1000W -> swprio=30, locktime=300
consumer05 heater 1000W -> swprio=20, locktime=300

Wenn zum Start des Tages der Überschuß ansteigt, schalten die consumer 02 bis 05 nacheinander an, da der Überschuß langsam steigt. Sollte er schnell auf über 3000W steigen und noch nicht alle 02-05 an sein, schaltet consumer01 an wegen der höheren prio! Muß man sehen ob das realistisch ist.

Wenn also insgesamt 4000W Überschuß vorhanden ist, sind die consumer 02-05 on und verbrauchen den Überschuß obwohl der Überschuß jetzt reichen würde um consumer01 und ggf. noch einen anderen consumer zu betreiben.

Eine Lösung wäre in ctrlUserExitFn eine kleine Logik zu bauen:

1. prüfe ob alle consumer 02-05 (evtl. 02-04) "on" sind
2. wenn ja, ist eigentlich genügend Überschuß vorhanden um consumer01 zu bereiben -> dann
3. schalte über die entsprechenden Befehle die consumer 02-05 (02-04) aus!

Dh. in diesem Fall werden durch die Logik ctrlUserExitFn alle consumer 02-05 (02-04) am Ende des SF-Zyklus ausgeschaltet sein, der PV-Überschuß wird frei.
Im nächsten Zyklus wird consumer01 aktiviert da genügend PV Überschuß vorhanden ist und er die höchste Prio hat. Damit nicht gleicht einer der consumer 02-05 dazu kommt, haben alle locktime von 5 Minuten nach dem Ausschalten gesetzt.

Sollte die PV nach unten gehen, wird consumer01 unterbrochen und die anderen 02-05 werden beim Hochlauf der PV wieder aktiviert bis die Logik in ctrlUserExitFn wieder greift, die C 02-05 abschaltet und dann consumer01 wieder fortsetzt da ja genug PV vorhanden.

Wenn das Verfahren gefällt, muß man es nur noch in Perl kodieren und testen.

LG,
Heiko

Habe es wie folgt codiert in ctrlUserExitFn:
Wenn es noch Anregungen/Verbesserungsvorschläge gibt gerne Rückmeldung.
Am Ende habe ich nach Ausschalten noch das consumerNewPlanning hinzugefügt, da vermutlich analog ausschalten extern die consumer02-05 sonst nicht wieder eingeschaltet werden.

Code Auswählen

{
  my $sumPower =
     ReadingsNum($name,"Current_Surplus",0)
    + ReadingsNum($name,"consumer02_currentPower",0)
    + ReadingsNum($name,"consumer03_currentPower",0)
    + ReadingsNum($name,"consumer04_currentPower",0)
    + ReadingsNum($name,"consumer05_currentPower",0);
    storeReading ('userFn_sumPower', $sumPower);
  ## consumer01=RutenbIP4_Out1 mit swprio=100 soll durch Ausschalten der Verbraucher mit niedriger Prio eingeschaltet werden:
  if ($sumPower > 3000 && ReadingsVal("RutenbIP4_Out1","state","off") eq "off") {
      fhem("set Shelly_UG_1 off; set Shelly_EG_1 off; set Shelly_EG_2 off; set Shelly_DG_1 off");
      fhem("sleep 60; set SF01 consumerNewPlanning 02, set SF01 consumerNewPlanning 03,set SF01 consumerNewPlanning 04, set SF01 consumerNewPlanning 05");
  Log 3, "Schalte consumer02-0x AUS: sumPower =$sumPower";
    }
}

300P · 14 Mai 2026, 18:41:14

Ich würde : (ohne Batteriebetrachtung dabei)

Wenn C01 nicht aktiv / nicht AN ist und wenn die Einspeisung >= 1.100 UND die C02-05 mehr als 3.000 Watt verbrauchen (dürften).
Nur wirklich dann:
schalte alle C02-C05 AUS (Logeintrag extern ausgeschaltet erfolgt)
dann sollte der C1 sich automatisch nach XX sek. "selber einschalten. (Locktime vernünftig einstellen !!! z.B. locktime=30:30) = schnell AN / kürzer noch AN bleiben als die anderen 1.000 W Consumer...
danach Newplaning C02-C05 ->> damit sie wieder einschalten könnten wenn es sein soll. ( wie oben ->> z.B. locktime=60:15) Langsamer AN / kürzer noch AN bleiben

Wenn dann am Morgenverlauf mehr/weniger erzeugt wird schalten sich die C02-C05 (auch der C01) automatisch wieder ab / an......

Eventuell kannst du ja noch interruptable=1 im attr der C02-C05 sinnvoll nutzen (auch im C01)