sudo docker run -it --rm -v ./signal-mqtt:/home/.local/share/signal-cli ckware/signal-mqtt /bin/sh
/ # signal-cli link
sgnl://linkdevice?uuid=NmTlWhDNBAeR0LJRMnQvVA%3D%3D&pub_key=BfrXc5BXh8zXIm86ufMamLNehODDBH8rSUO1ADLvrktw
INFO ProvisioningManagerImpl - Received link information from +49<Deine Nummer>, linking in progress ...
Associated with: +49<Deine Nummer>
/ #

ce@raspberrypi:/docker/fhem_2025/signal-mqtt/data $ ls -l
-rwx------ 1 nobody nogroup 1457 12. Jan 20:22 624839
drwx------ 2 nobody nogroup 4096 12. Jan 21:10 624839.d
-rw------- 1 nobody nogroup 180 12. Jan 17:15 accounts.json
signal-mqtt:
image: ckware/signal-mqtt
restart: unless-stopped
init: true
user: "nobody:nogroup"
environment:
MQTT_PUBLISH_OPTIONS: "-h 192.168.178.60 -p 1883 -i signal-receiver"
MQTT_SUBSCRIBE_OPTIONS: "-h 192.168.178.60 -p 1883 -i signal-sender"
volumes:
- "./signal-mqtt:/home/.local/share/signal-cli"
Internals:
BUF
FD 64
NAME MQTT2_FHEM_Server_172.18.0.5_47280
NR 10016606
PEER 172.18.0.5
PORT 47280
SNAME MQTT2_FHEM_Server
SSL
STATE Connected
TEMPORARY 1
TYPE MQTT2_SERVER
WBCallback
cflags 2
cid signal-sender
keepalive 60
lastMsgTime 1768244524.82839
protoNum 4
protoTxt MQTT
READINGS:
2026-01-12 20:00:04 state Connected
subscriptions:
signal/out/# 1768244404.73159
Attributes:
room hidden
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"