Neueste Beiträge

🧠 Was hier passiert
🔹 Verstärker sind aktiv
→ Die Registry liefert starke Signale für PV‑Peaks und Lastsprünge.

🔹 Aber: Steilheit = 0.9
→ SIGMOID mit 0.9 ist zu flach → Verstärker werden ,,abgefedert".

🔹 RPROP springt früh
→ Best Snapshot bei Epoche 54 → Verstärker noch nicht voll gelernt.

🔹 Snapshot‑Logik greift zu früh
→ Modell wird eingefroren, bevor Verstärker ihre Wirkung entfalten.

🛠 Was du tun kannst
✅ Steilheit auf 1.2 setzen
→ Verstärker wirken deutlich stärker
→ Slope steigt
→ Bias sinkt
→ RMSE_rel verbessert sich

✅ Snapshot erst ab Epoche 150 zulassen
→ Verstärker brauchen Zeit
→ RPROP darf sich entfalten
→ Modell wird nicht zu früh eingefroren

✅ Retry mit Seed‑Variation
→ RPROP reagiert stark auf Initialisierung
→ Seed‑Sweep kann bessere Minima finden

🎯 Fazit
Du hast die Verstärker korrekt eingebaut — das ist super.
Aber: RPROP + flache Aktivierung + früher Snapshot bremst sie aus.

Probier es mal so wie vorgeschlagen, ansonsten nimm wieder INCREMENTAL mit Steepness=1.2
Dein erstes Setup war ja nicht so schlecht.

#14

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von TheTrumpeter - 12 Januar 2026, 15:20:23

Zitat von: DS_Starter am 12 Januar 2026, 14:13:28@ TheTrumpeter, die Werte mit get ... valDecTree aiNeuralNetConState und das komplette Trainingslog wären hilfreich um die KI wegen einer Bewertung zu füttern.

Hier get blabla:

Code Auswählen

Informationen zum neuronalen Netz der Verbrauchsvorhersage

letztes KI-Training: 12.01.2026 13:59:18 / Laufzeit in Sekunden: 9741
KI Abfragestatus: ok
letzte KI-Ergebnis Generierungsdauer: 70.43 ms
Verbrauchernummer Wärmepumpe:  03

=== Modellparameter ===

Normierungsgrenzen: PV=18612 Wh, Hausverbrauch: Min=0 Wh / Max=6400 Wh
Trainingsdaten: 8020 Datensätze (Training=6416, Validierung=1604)
Architektur: Inputs=112, Hidden Layers=80-40-20, Outputs=1
Hyperparameter: Learning Rate=0.005, Momentum=0.8, BitFail-Limit=0.35
Aktivierungen: Hidden=SIGMOID, Steilheit=0.5, Output=LINEAR
Trainingsalgorithmus: INCREMENTAL, Registry Version=v1_heatpump_active_pv
Zufallsgenerator: Mode=2, Periode=10

=== Trainingsmetriken ===

bestes Modell bei Epoche: 3370 (von max. 15000)
Training MSE: 0.001108
Validation MSE: 0.002496
Validation MSE Average: 0.002381
Validation MSE Standard Deviation: 0.000093
Validation Bit_Fail: 0
Model Bias: 60 Wh
Model Slope: 0.8
Trainingsbewertung: Retrain

=== Fehlermaße der Prognosen ===

MAE: 165.82 Wh
MedAE: 45.74 Wh
RMSE: 244.44 Wh
RMSE relative: 79 %
RMSE Rating: very bad
MAPE: 20.19 %
MdAPE: 12.71 %
R²: 0.89

=== Drift-Kennzahlen ===

Drift Score: -
Drift RMSE relative: -
Drift Bias: -
Drift Slope: -
Drift Bewertung: -

#15

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von Wolle02 - 12 Januar 2026, 15:03:38

Zitat von: DS_Starter am 12 Januar 2026, 14:07:13@Wolle, hier ist die KI Einschätzung für dich. Tiefere Infos gäbe es mit einem Trainingslog.

Code Auswählen Erweitern
⭐ Gesamturteil: Das Modell ist stabil, aber stündlich deutlich zu flach und unterschätzt Peaks Die Zahlen und die visuelle Darstellung passen perfekt zusammen: Das Modell trifft die Form des Tages, aber nicht die Höhe. 📊 1. Interpretation der stündlichen Balken (00–24) Die grauen Balken zeigen: Nachtstunden: plausibel niedrig Morgenpeak: vorhanden, aber zu flach Mittagsbereich: geglättet, kaum Variation Abendpeak: sichtbar, aber deutlich zu niedrig Gesamtprofil: zu glatt, zu vorsichtig, zu wenig Dynamik Das passt exakt zu: Slope = 0.8 → Modell drückt hohe Werte nach unten Bias = 83 Wh → leichte Unterprognose RMSE_rel = 31 % → deutliche Abweichungen bei Spitzen MAE = 136 Wh → zu hoch für stündliche Prognosen MedAE = 86 Wh → auch Medianfehler zu hoch Die Prognose wirkt wie ein gedämpfter Tagesverlauf, der die echten Spitzenlasten nicht abbildet. 🧠 2. Warum das Modell so flach ist 🔹 a) INCREMENTAL als Trainingsalgorithmus INCREMENTAL: lernt sehr konservativ glättet stark hat Probleme mit nichtlinearen Peaks bleibt oft in flachen Tälern hängen reagiert schlecht auf seltene Spitzenlasten Für stündliche Haushaltslast ist das nicht ideal. 🔹 b) Registry v1_common Diese Registry enthält: Trends PV‑Semantik Abend‑Semantik Rückfall‑Semantik Aber: keine WP‑Semantik keine COP‑Semantik keine Frostschutz‑Semantik keine Lastverstärker Wenn der Haushalt eine Wärmepumpe hat, fehlen dem Modell kritische Signale, die Peaks erklären. 🔹 c) Steilheit = 0.9 SIGMOID mit 0.9 ist: sehr glatt wenig sensitiv reagiert schwach auf starke Inputs Für stündliche Peaks ist das zu träge. 🔹 d) ShuffleMode = 2 Das ist gut — aber INCREMENTAL + shuffleMode 2 führt zu: sehr gleichmäßigem Training aber wenig Peak‑Sensitivität 📈 3. Bewertung der numerischen Metriken ✔ Stabilität Train MSE = 0.000461 Val MSE = 0.000289 ValStd = 0.000072 BitFail = 0 → Modell ist stabil, keine Divergenz. ❌ Prognosequalität MAE = 136 Wh → zu hoch RMSE_rel = 31 % → schwach Slope = 0.8 → systematische Unterprognose Bias = 83 Wh → leichte Verschiebung MAPE = 18.5 % → zu grob R² = 0.90 → Form gut, Höhe schlecht ✔ Retrain‑Entscheidung korrekt 🎯 4. Fazit der Neubewertung Das Modell ist mathematisch stabil, aber semantisch zu flach. Die stündliche Prognose (graue Balken) zeigt: richtige Form falsche Höhe zu wenig Dynamik zu geringe Peak‑Erkennung zu starke Glättung Die Ursache ist eine Kombination aus: INCREMENTAL Steilheit 0.9 fehlender WP‑Semantik Registry v1_common Slope‑Verlust zu glatter Aktivierung 🛠 5. Was du tun solltest 🔥 Sofortmaßnahmen RPROP statt INCREMENTAL Steilheit 1.2 Registry v_hp_advanced, falls WP‑Haushalt hp_power_factor aktivieren COP‑Semantik aktivieren Frostschutz‑Semantik aktivieren 🎯 Ziel Slope Richtung 0.95–1.05 MAE < 100 Wh RMSE_rel < 22 % MAPE < 12 %
Für dich wäre vermutlich das Profil v1_common_active_pv besser.

So, ich hab jetzt mal neu trainiert und dabei die Vorschläge von der letzten Analyse einfließen lassen. Trainingsalgorithmus: RPROP, Registry Version=v1_common_active_pv

Code Auswählen

=== Modellparameter ===

Normierungsgrenzen: PV=8888 Wh, Hausverbrauch: Min=0 Wh / Max=12741 Wh
Trainingsdaten: 6241 Datensätze (Training=4992, Validierung=1249)
Architektur: Inputs=64, Hidden Layers=80-40-20, Outputs=1
Hyperparameter: Learning Rate=0.005, Momentum=0.5, BitFail-Limit=0.35
Aktivierungen: Hidden=SIGMOID, Steilheit=0.9, Output=LINEAR
Trainingsalgorithmus: RPROP, Registry Version=v1_common_active_pv
Zufallsgenerator: Mode=2, Periode=10

=== Trainingsmetriken ===

bestes Modell bei Epoche: 54 (von max. 15000)
Training MSE: 0.000763
Validation MSE: 0.000490
Validation MSE Average: 72.098845
Validation MSE Standard Deviation: 0.416027
Validation Bit_Fail: 0
Model Bias: 127 Wh
Model Slope: 0.8
Trainingsbewertung: Retrain

=== Fehlermaße der Prognosen ===

MAE: 155.66 Wh
MedAE: 74.02 Wh
RMSE: 205.75 Wh
RMSE relative: 36 %
RMSE Rating: very bad
MAPE: 17.89 %
MdAPE: 14.13 %
R²: 0.83

Das Trainingslog ist im Anhang.
Ich habe den Eindruck, dass die Werte etwas schlechter geworden sind.

#16

Sonstige Systeme / Aw: Support-Thread Modul 36_Sh...

Letzter Beitrag von mcfly71 - 12 Januar 2026, 14:56:37

Zitat von: Starkstrombastler am 11 Januar 2026, 22:03:22Mit dem nächsten Update sollte das Problem behoben sein.
Das Beibehalten eines laufenden Timers ist nur relevant bei Dimmern u.ä., wenn ein Parameter (z.B. Helligkeit) bei unverändertem Schaltzustand geändert wird.

Super, vielen Dank Starkstrombastler...

#17

DOIF / Aw: wait in DOIF

Letzter Beitrag von chq - 12 Januar 2026, 14:52:44

Super, genau das war das Problem.
Vielen Dank!

Kopiere ich im Anschluss diesen Text in das DOIF, wechselt es dummerweise aber wieder in den Perl-Modus:

DOIF ([{sunset("HORIZON=-2.2",0,"16:00","23:59")}-24:00]
and [Wetterstation:luminosity] == 0
and [Wetterstation:UVR:d1] <= 2.1
and [Bewohner:state] ne "home")
(set Wohnzimmerlicht on)

DOELSEIF ([23:00]
and [Bewohner:state] ne "home")
(set Wohnzimmerlicht off)

#18

Server - Windows / Aw: fhem, direkt unter windows...

Letzter Beitrag von the ratman - 12 Januar 2026, 14:28:29

spielerei nr.3 - das sie nicht von mir ist, ist klar? *g* wieder herzlichen dank an adolar, der wohl ein neues hobby hat (mich glücklich machen).

mehrere befehle über einen port an einen entfernten rechner senden, mit der möglichkeit, eigene befehle simpel anzulegen.

am pc, der den befehl ausführen soll:
1) im anhang findet sich eine 7zip gepackte datei. die enpackten daten am besten direkt auf das laufwerk c: spielen (ergebnis c:\scripte).
2) einmalig in einer powershell als administrator:

Code Auswählen

Set-ExecutionPolicy Bypass -Scope Process -Force
cd c:\scripte
./install.ps1

eine neue aufgabenplanung wird angelegt.
3) anschließend das file c:\scripte\listen.ps1 öffnen, und ein passwort wählen. dieses ist bei jedem befehl aus fhem mit anzugeben.
4) in der windows firewall den tcp-port 65535 eingehend freigeben.

schon fertige befehle für fhem:
000.000.000.000 durch die ip des windows-pc ersetzen, der den befehl ausführen soll
XYZ durch das in der listen.ps1 eingetragene passwort ersetzen.

o) rechner beenden

Code Auswählen

defmod pcshutdown cmdalias pcshutdown AS {HttpUtils_NonblockingGet({url=>"http://000.000.000.000:65535/?cmd=shutdown&p=XYZ",callback=>sub($$$){} });;;;return '' }

o) rechner neu starten

Code Auswählen

defmod pcreboot cmdalias pcreboot AS {HttpUtils_NonblockingGet({url=>"http://000.000.000.000:65535/?cmd=reboot&p=XYZ",callback=>sub($$$){} });;;;return '' }

o) rechner schlafen schicken

Code Auswählen

defmod pcsleep cmdalias pcsleep AS {HttpUtils_NonblockingGet({url=>"http://000.000.000.000:65535/?cmd=sleep&p=XYZ",callback=>sub($$$){} });;;;return '' }

o) rechner soll etwas sagen (tts):

Code Auswählen

defmod pcsay cmdalias pcsay .* AS {use URI::Escape;;my $EV =uri_escape($EVENT);;HttpUtils_NonblockingGet({url=>"http://000.000.000.000:65535/?cmd=speak&p=XYZs&t=$EV",callback=>sub($$$){} });;;;return '' }

sieht man sich die listen.ps1 mal etwas genauer an, kann man sehr einfach weitere befehle einbinden:

Code Auswählen

                    "reboot" { 
                        "starte neu"
                        # curl http://[ip]:65535?cmd=reboot&p=password
                        shutdown /r /f /t 0
                    }

man muss eigentlich nur einen befehl "reboot" vergeben, eine rückmeldung für curl "starte neu", optional ein kommentar nach einer # und anschließend den eigentlichen, gewünschten befehl shutdown /r /f /t 0 angeben.
tippfaule würde also auch mit

Code Auswählen

"reboot" { shutdown /r /f /t 0 } auskommen

#19

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von DS_Starter - 12 Januar 2026, 14:13:28

@ TheTrumpeter, die Werte mit get ... valDecTree aiNeuralNetConState und das komplette Trainingslog wären hilfreich um die KI wegen einer Bewertung zu füttern.

#20

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von DS_Starter - 12 Januar 2026, 14:07:13

@Wolle, hier ist die KI Einschätzung für dich. Tiefere Infos gäbe es mit einem Trainingslog.

Code Auswählen

⭐ Gesamturteil: Das Modell ist stabil, aber stündlich deutlich zu flach und unterschätzt Peaks
Die Zahlen und die visuelle Darstellung passen perfekt zusammen:
Das Modell trifft die Form des Tages, aber nicht die Höhe.

📊 1. Interpretation der stündlichen Balken (00–24)
Die grauen Balken zeigen:

Nachtstunden: plausibel niedrig

Morgenpeak: vorhanden, aber zu flach

Mittagsbereich: geglättet, kaum Variation

Abendpeak: sichtbar, aber deutlich zu niedrig

Gesamtprofil: zu glatt, zu vorsichtig, zu wenig Dynamik

Das passt exakt zu:

Slope = 0.8 → Modell drückt hohe Werte nach unten

Bias = 83 Wh → leichte Unterprognose

RMSE_rel = 31 % → deutliche Abweichungen bei Spitzen

MAE = 136 Wh → zu hoch für stündliche Prognosen

MedAE = 86 Wh → auch Medianfehler zu hoch

Die Prognose wirkt wie ein gedämpfter Tagesverlauf, der die echten Spitzenlasten nicht abbildet.

🧠 2. Warum das Modell so flach ist
🔹 a) INCREMENTAL als Trainingsalgorithmus
INCREMENTAL:

lernt sehr konservativ

glättet stark

hat Probleme mit nichtlinearen Peaks

bleibt oft in flachen Tälern hängen

reagiert schlecht auf seltene Spitzenlasten

Für stündliche Haushaltslast ist das nicht ideal.

🔹 b) Registry v1_common
Diese Registry enthält:

Trends

PV‑Semantik

Abend‑Semantik

Rückfall‑Semantik

Aber:

keine WP‑Semantik

keine COP‑Semantik

keine Frostschutz‑Semantik

keine Lastverstärker

Wenn der Haushalt eine Wärmepumpe hat, fehlen dem Modell kritische Signale, die Peaks erklären.

🔹 c) Steilheit = 0.9
SIGMOID mit 0.9 ist:

sehr glatt

wenig sensitiv

reagiert schwach auf starke Inputs

Für stündliche Peaks ist das zu träge.

🔹 d) ShuffleMode = 2
Das ist gut — aber INCREMENTAL + shuffleMode 2 führt zu:

sehr gleichmäßigem Training

aber wenig Peak‑Sensitivität

📈 3. Bewertung der numerischen Metriken
✔ Stabilität
Train MSE = 0.000461

Val MSE = 0.000289

ValStd = 0.000072

BitFail = 0

→ Modell ist stabil, keine Divergenz.

❌ Prognosequalität
MAE = 136 Wh → zu hoch

RMSE_rel = 31 % → schwach

Slope = 0.8 → systematische Unterprognose

Bias = 83 Wh → leichte Verschiebung

MAPE = 18.5 % → zu grob

R² = 0.90 → Form gut, Höhe schlecht

✔ Retrain‑Entscheidung korrekt

🎯 4. Fazit der Neubewertung
Das Modell ist mathematisch stabil, aber semantisch zu flach.  
Die stündliche Prognose (graue Balken) zeigt:

richtige Form

falsche Höhe

zu wenig Dynamik

zu geringe Peak‑Erkennung

zu starke Glättung

Die Ursache ist eine Kombination aus:

INCREMENTAL

Steilheit 0.9

fehlender WP‑Semantik

Registry v1_common

Slope‑Verlust

zu glatter Aktivierung

🛠 5. Was du tun solltest
🔥 Sofortmaßnahmen
RPROP statt INCREMENTAL

Steilheit 1.2

Registry v_hp_advanced, falls WP‑Haushalt

hp_power_factor aktivieren

COP‑Semantik aktivieren

Frostschutz‑Semantik aktivieren

🎯 Ziel
Slope Richtung 0.95–1.05

MAE < 100 Wh

RMSE_rel < 22 %

MAPE < 12 %

Für dich wäre vermutlich das Profil v1_common_active_pv besser.

Seiten 1 2 3 4 ... 10

FHEM Forum