Das Modell ist technisch solide, aber semantisch zu flach für stündliche Haushaltsprognosen ohne Wärmepumpe. Ich zeige dir jetzt, warum die Retrain‑Entscheidung korrekt ist, obwohl die Form gut getroffen wird.
📊 Numerische Bewertung
Metrik Wert Bewertung
Train MSE 0.000355 sehr gut
Val MSE 0.000277 stabil
ValStd 0.000008 extrem niedrig → Modell ist konsistent
BitFail 0 perfekt
Bias −10 Wh neutral
Slope 0.90 leicht zu flach
MAE 135 Wh zu hoch für Standardhaushalt
RMSE 174 Wh schwach
RMSE_rel 31 % nicht akzeptabel
R² 0.91 sehr gut
MAPE 18.4 % zu hoch
MdAPE 13.9 % grenzwertig
Bewertung Retrain korrekt
🧠 Interpretation
✅ Was gut ist:
Formtreue: R² = 0.91 → Tagesverlauf wird gut getroffen
Stabilität: ValStd = 0.000008 → keine Schwankungen
Bias = −10 Wh → keine systematische Verschiebung
BitFail = 0 → keine neuronalen Sättigungen
Slope = 0.9 → Modell reagiert, aber nicht voll dynamisch
❌ Was kritisch ist:
MAE = 135 Wh → zu hoch für stündliche Steuerung
RMSE_rel = 31 % → deutliche Abweichungen bei Spitzen
MAPE > 18 % → zu grob für PV‑Optimierung
Retrain‑Entscheidung korrekt, da RMSE‑Rating = weak
📈 Was das Modell visuell zeigt (graue Balken)
Form stimmt: Tagesverlauf ist plausibel
Spitzenlasten werden unterschätzt → Slope = 0.9
Morgen- und Abendlasten sind geglättet
PV‑Mittagspeak wird nicht voll durchgelassen
Keine WP‑Artefakte sichtbar → korrekt für WP‑frei
🛠 Empfehlungen zur Verbesserung
🔧 Architektur
Steilheit 1.2 ist gut → beibehalten
Hidden Layers ggf. auf 60‑30‑15 reduzieren → weniger Glättung
RPROP als Alternative testen → kann Peaks besser lernen
🔧 Registry
v1_common_active_pv ist korrekt
ggf. pv_peak_booster aktivieren
semantic_peak_push verstärken
🔧 Training
Retry mit Seed‑Sweep
Snapshot ab Epoche 300 zulassen
Verstärkerwirkung visuell prüfen (z. B. Stunde 10–13)
🎯 Fazit
Das Modell ist technisch sauber, aber semantisch zu flach für präzise Haushaltsprognosen ohne WP.
Hidden Layers ggf. auf 60‑30‑15 reduzieren → weniger Glättung
RPROP als Alternative testen → kann Peaks besser lernen
gerne mal testen und wenn es nicht besser wird -> wieder zurück auf aktuelle Einstellung.Zitat von: Prof. Dr. Peter Henning am 12 Januar 2026, 19:33:54Wir benutzen LLM in verschiedenen Forschungsprojekten. Vor dem Hintergrund habe ich erhebliche Bedenken über die hier geübte Vorgehensweise, denn das ist eine irrsinnige Ressourcenverschwendung.Hallo pah,
Was man sinnvoll machen kann, ist ein Sprachmodell einzusetzen, um einen Text zu normieren, also generell einen Intent zu erkennen. Die Umsetzung in einen finalen FHEM-Befehl sollte man aber auf andere Weise machen, dafür gibt es schon verschiedene Module.
MQTT2_FHEM_Server
MQTT2_FHEM_Server_172.18.0.2_45856
MQTT2_FHEM_Server_172.18.0.3_55824
MQTT2_FHEM_Server_172.18.0.6_53184
MQTT2_FHEM_Server_172.18.0.9_39772
MQTT2_FHEM_Server_192.168.178.50_57589
MQTT2_FHEM_Server_192.168.178.51_52860
MQTT2_FHEM_Server_192.168.178.53_51770
MQTT2_FHEM_Server_192.168.178.54_50525
MQTT2_FHEM_Server_192.168.178.56_6908
MQTT2_FHEM_Server_192.168.178.67_58866
# MQTT_PUBLISH_OPTIONS: "-h broker -i signal-receiver"
# MQTT_SUBSCRIBE_OPTIONS: "-h broker -i signal-sender"
Dann kommt eine andere Meldung 
signal-mqtt - Start
/usr/local/bin/signal-mqtt: line 114: MQTT_SUBSCRIBE_OPTIONS: parameter not set
Error: Connection refused
DOELSEIF
(([00:01]-[23:59]|0123456) and [$SELF:P_button] eq "Turbo-Mode")
(set DimplexWPManager dimhp_temperature_dhwset 60)
(set DimplexWPManager dimhp_input_sgready_green on,set DimplexSmartGrid_green on,set Turbo_MODE on)
(Sleep [$SELF:P_Timer1]; set SmartGrid_doif P_button Auto; set Turbo_MODE off)
zigbee2mqtt:
image: koenkk/zigbee2mqtt:latest
volumes:
- ./zigbee2mqtt/data:/app/data
- /run/udev:/run/udev:ro
devices:
# - /dev/ttyACM0:/dev/ttyACM0
- /dev/serial/by-id/usb-Texas_Instruments_TI_CC2531_USB_CDC___0X00124B001CD4A620-if00:/dev/ttyACM0
restart: always
ports:
- '8084:8080'
privileged: true
environment:
- TZ=Europe/Berlin
sonos:
image: ghcr.io/svrooij/sonos2mqtt
# or the dockerhub svrooij/sonos2mqtt
restart: unless-stopped
ports:
- "6329:6329"
environment:
- SONOS2MQTT_DEVICE=192.168.178.36 # Service discovery doesn't work very well inside docker, so start with one device.
- SONOS2MQTT_MQTT=mqtt://192.168.178.60:1883 # mqtt2_server FHEM
# - SONOS2MQTT_DISTINCT=true # if your want distinct topics
- SONOS_LISTENER_HOST=192.168.178.60 # Docker host IP
# - SONOS_TTS_ENDPOINT=http://sonos-tts:5601/api/generate # If you deployed the TTS with the same docker-compose
depends_on:
- "fhem"
Zitat von: ch.eick am 12 Januar 2026, 19:10:43services:
fhem:
network_mode: host
services:
fhem:
network_mode: host
privileged: true <<<<< Das ist wegen eines alten SMA SmartMeter
< snip>
signal-mqtt:
image: ckware/signal-mqtt
# network_mode: host
# container_name: signal-mqtt
restart: unless-stopped
init: true
user: "nobody:nogroup"
environment:
MQTT_PUBLISH_OPTIONS: "-h broker -i signal-receiver"
MQTT_SUBSCRIBE_OPTIONS: "-h broker -i signal-sender"
MQTT_BROKER: "tcp://192.168.178.60:1883"
volumes:
- "./signal-mqtt:/home/.local/share/signal-cli"
ce@raspberrypi:/docker/fhem_2025 $ sudo docker run -it --rm -v /docker/fhem_2025/signal-mqtt:/home/.local/share/signal-cli ckware/signal-mqtt /bin/sh
/ # ping 192.168.178.60
PING 192.168.178.60 (192.168.178.60): 56 data bytes
64 bytes from 192.168.178.60: seq=0 ttl=64 time=0.087 ms
64 bytes from 192.168.178.60: seq=1 ttl=64 time=0.057 ms
64 bytes from 192.168.178.60: seq=2 ttl=64 time=0.056 ms
^C
--- 192.168.178.60 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.056/0.066/0.087 ms