Homematic Thermostat Temperaturwerte werden nicht an Home Assistant übertragen – Komplette Lösung
Das kennst du bestimmt auch: Das Thermostat zeigt 21°C, aber Home Assistant hängt bei 18°C fest
Du kennst das Problem sicher: Dein Homematic Thermostat zeigt schön brav 21°C an, aber Home Assistant bleibt stur bei veralteten 18°C stehen. Oder noch schlimmer – die Temperaturanzeige springt auf unavailable oder unknown. Das ist frustrierend, besonders wenn deine Heizungsautomatisierung dadurch durcheinander gerät.
Die gute Nachricht: Das Problem lässt sich systematisch lösen. Ich zeige dir hier Schritt für Schritt, wie du die Ursache findest und behebst – egal ob du CCU2, CCU3 oder RaspberryMatic verwendest.
Aus der Praxis: Die Home Assistant Logs zeigen oft nur generische „unavailable“ Meldungen. Das hilft nicht weiter. Die echten Probleme verstecken sich tiefer im System. Bei Docker-Installationen liegen die Logs woanders (/config/home-assistant.log statt /usr/share/hassio/homeassistant/home-assistant.log), und bei Home Assistant OS findest du die detaillierten Homematic-Logs oft gar nicht.
# So checkst du den aktuellen Status deines Thermostats
grep -A3 -B3 "climate.wohnzimmer_thermostat" /config/home-assistant.log | tail -10
Wenn alles läuft, siehst du sowas:
2024-01-15 14:30:15 INFO (MainThread) [homeassistant.components.homematic] Updated climate.wohnzimmer_thermostat: temperature=21.5, target=20.0
Bei Problemen eher sowas:
2024-01-15 14:30:15 WARNING (MainThread) [homeassistant.components.homematic] Device climate.wohnzimmer_thermostat is unavailable
2024-01-15 14:30:15 ERROR (MainThread) [homeassistant.components.homematic] Failed to update climate.wohnzimmer_thermostat: Connection timeout
Die typischen Symptome kennst du wahrscheinlich: Solltemperatur-Änderungen in Home Assistant kommen nicht am Thermostat an, die Homematic-Integration zeigt offline obwohl die CCU über das Netzwerk erreichbar ist, und die Temperaturwerte aktualisieren sich nur alle paar Stunden statt kontinuierlich.
So läuft der Datenfluss: Thermostat → Funk → CCU → XML-RPC → Home Assistant
Wichtiger Hinweis: RaspberryMatic auf dem Pi 4 hat andere Log-Pfade als die CCU3. Die Logs liegen unter /var/log/messages statt /usr/local/tmp/log/. Außerdem führt die neue Homematic Integration (seit HA 2023.4) zu anderen Entity-IDs – deine bestehenden Automatisierungen können dadurch kaputtgehen.
Mit diesem Befehl prüfst du die RaspberryMatic Logs auf dem Pi 4:
# Prüfe erstmal, ob die Homematic Integration überhaupt läuft
grep -i "homematic.*offline\|homematic.*unavailable" /config/home-assistant.log | tail -5
Problematisch wäre sowas:
2024-01-15 14:25:10 ERROR (MainThread) [homeassistant.components.homematic] Homematic hub is offline
2024-01-15 14:25:15 WARNING (MainThread) [homeassistant.components.homematic] All Homematic devices unavailable
Das Kernproblem liegt meist in einer von sechs Hauptursachen: CCU-Netzwerkverbindung unterbrochen, XML-RPC Kommunikation defekt, Thermostat-Funkverbindung gestört, Home Assistant Entity Registry korrupt, Polling-Intervalle falsch konfiguriert oder CCU Systemvariablen-Übertragung blockiert. Mit der richtigen Diagnose-Reihenfolge findest du die Ursache schnell.
Aus der Praxis: Die Diagnose-Reihenfolge ist entscheidend. Viele springen direkt zur Entity Registry, aber in 80% der Fälle liegt das Problem bei der CCU-Verbindung oder XML-RPC. Nach einem Home Assistant Core Update von 2023.x auf 2024.x ändern sich die Homematic Integration-Parameter – die alte hosts: Konfiguration funktioniert nicht mehr.
Wenn dein Homematic IP Access Point keine Temperaturwerte an Home Assistant überträgt, liegt das meist an der unterschiedlichen Protokoll-Architektur. Der Access Point nutzt das Homematic IP Protokoll, während klassische CCU-Systeme auf BidCos-RF setzen.
Prüfe zunächst die Integration in Home Assistant:
# Logs der Homematic IP Integration prüfen
grep -i "homematic.*ip" /config/home-assistant.log | tail -20
Häufige Ursachen für fehlende Temperaturwerte:
Access Point Firmware veraltet: Stelle sicher, dass dein Access Point die neueste Firmware hat. Öffne die eQ-3 App und prüfe unter Einstellungen → Access Point → Firmware-Update.
Falsche Integration gewählt: Verwende die „Homematic(IP) Local“ Integration, nicht die klassische „Homematic“ Integration. Die IP-Variante kommuniziert direkt mit dem Access Point über dessen lokale API.
Polling-Intervall zu hoch: Der Access Point sendet Temperaturupdates nur bei signifikanten Änderungen. Prüfe in der Integration die Scan-Intervall-Einstellungen:
Geräte-spezifische Konfiguration: Manche Homematic IP Thermostate übertragen Temperaturwerte nur bei Heizanforderungen. Aktiviere in der eQ-3 App unter Geräteparameter die kontinuierliche Temperaturübertragung.
Unterschied zwischen Homematic Integration und Homematic IP in Home Assistant
Die beiden Integrationen verwenden völlig unterschiedliche Protokolle und Architekturen – das führt oft zu Verwirrung bei der Einrichtung.
Homematic Integration (CCU-basiert):
– Kommuniziert mit Homematic CCU2/CCU3 über XML-RPC
– Unterstützt BidCos-RF und BidCos-Wired Geräte
– Benötigt CCU als zentrale Steuereinheit
– Konfiguration über configuration.yaml:
homematic:
interfaces:
rf:
host: 192.168.1.100 # CCU IP
port: 2001
wired:
host: 192.168.1.100
port: 2000
Homematic IP Integration:
– Kommuniziert direkt mit Access Point oder über Cloud-API
– Unterstützt nur Homematic IP Geräte (neuere Generation)
– Zwei Varianten: Local (direkt) oder Cloud (über eQ-3 Server)
– Konfiguration über UI oder:
# Lokale Variante
homematicip_cloud:
access_point: SGTIN_DES_ACCESS_POINTS
auth_token: DEIN_AUTH_TOKEN
Praktische Unterschiede:
Die klassische Integration lädt alle Geräte-Datenpunkte als separate Entitäten. Bei einem Thermostat erhältst du oft 15+ Entitäten (Temperatur, Sollwert, Ventilstellung, etc.).
Die IP-Integration fasst Funktionen logisch zusammen. Ein Thermostat wird als Climate-Entität mit integrierten Attributen dargestellt.
Kompatibilität prüfen:
# Prüfe welche Geräte du hast
# CCU WebUI → Einstellungen → Geräte
# Oder in Home Assistant Developer Tools → Zustände filtern nach "homematic"
Verwende beide Integrationen parallel, wenn du sowohl klassische Homematic als auch Homematic IP Geräte betreibst. Sie interferieren nicht miteinander.
Häufige Irrglauben bei Homematic Thermostat Problemen
Bevor wir richtig loslegen, räumen wir mal mit ein paar Mythen auf, die dich auf die falsche Fährte führen können.
Irrglaube: Defektes Thermostat bei fehlenden Updates
So ist es wirklich: Homematic Thermostate senden nur bei größeren Temperaturänderungen (meist >0,5°C) oder in festen Intervallen (Standard: 3 Stunden). Das ist völlig normal und spart Batterie. Viele erwarten Updates wie bei kabelgebundenen Sensoren – das ist aber nicht so. In der CCU WebUI unter ‚Geräteparameter‘ siehst du das eingestellte Sendeintervall.
homematic-thermostat-sendeintervall-konfigurieren
Irrglaube: Home Assistant Neustart erforderlich
So ist es wirklich: Ein kompletter Home Assistant Neustart ist meist unnötig. Gehe zu Entwicklertools > Services > ‚homematic.reconnect‘ oder lade die Integration über die Einstellungen neu. Das spart Zeit und Nerven. Frühere HA-Versionen brauchten tatsächlich Neustarts, aber seit HA 2021.x geht das eleganter.
Irrglaube: Automatische CCU-Integration
So ist es wirklich: Nach der Integration musst du die Geräte-Entitäten oft manuell aktivieren. Gehe zu ‚Einstellungen > Geräte & Services > Homematic‘ – viele Sensoren sind standardmäßig deaktiviert. Zusätzlich muss in der CCU unter ‚Einstellungen > Systemsteuerung > Zusatzsoftware‘ die XML-API aktiviert sein. Home Assistant deaktiviert automatisch ‚unwichtige‘ Entitäten um die Oberfläche sauber zu halten.
Diagnose-Matrix: Homematic Thermostat Temperaturwerte Probleme
Diese Tabelle hilft dir dabei, systematisch herauszufinden, wo der Fehler liegt. Arbeite sie von oben nach unten durch.
Systematisches Vorgehen: Diese sechs Hauptursachen decken 95% aller Probleme ab
Symptom
Check
Bestätigung
Ursache
Fix
Homematic-Integration zeigt ‚offline‘ Status und alle Entitäten sind ‚unavailable‘
ping -c 4 <CCU-IP-ADRESSE>
100% packet loss oder ‚Destination Host Unreachable‘
CCU Netzwerkverbindung unterbrochen
Router neustarten oder Netzwerkkabel prüfen/tauschen
Integration ist ‚online‘ aber Temperaturwerte werden als ‚unknown‘ angezeigt
curl -X POST http://<CCU-IP>:2001/ -d '<?xml version="1.0"?><methodCall><methodName>listDevices</methodName></methodCall>'
Connection refused, timeout oder HTTP 500 Fehler
Homematic Integration XML-RPC Fehler
CCU WebUI → Einstellungen → Systemsteuerung → XML-RPC aktivieren und CCU neustarten
Nur dieses Thermostat zeigt veraltete Werte, andere Homematic-Geräte funktionieren normal
Leere Antwort, HTTP 404 oder XML ohne Temperatur-Systemvariablen
CCU Systemvariablen-Übertragung blockiert
CCU WebUI → Einstellungen → Systemsteuerung → XML-API aktivieren → Programme → Systemvariablen für Thermostat anlegen
6 Hauptursachen warum Homematic Thermostat-Daten nicht übertragen werden
Die Temperaturübertragung kann an sechs kritischen Stellen versagen. Jede Ursache hat spezifische Symptome und lässt sich mit gezielten Tests identifizieren.
CCU Netzwerkverbindung unterbrochen (FC-01)
Das ist der häufigste Grund: Die CCU ist nicht mehr über das Netzwerk erreichbar. Alle Homematic-Entitäten werden als ‚unavailable‘ angezeigt und die Integration zeigt ‚offline‘ Status.
Aus der Praxis: Moderne Router mit „Smart Connect“ (2.4GHz/5GHz zusammengelegt) machen oft Probleme. Die CCU3 kann nur 2.4GHz, aber der Router weist ihr manchmal 5GHz zu. Deaktiviere Smart Connect oder erstelle ein separates 2.4GHz-Netzwerk für deine Smart Home Geräte.
Erfahrungsgemäß tritt dieses Problem besonders auf Synology DSM 7.2 auf: Der integrierte Docker-Daemon ändert nach System-Updates die Bridge-Netzwerk-Konfiguration. Home Assistant Container verlieren dann die Verbindung zur CCU, obwohl beide Geräte im gleichen Netzwerk stehen. Die Standard-Docker-Bridge docker0 wird durch syno-bridge ersetzt, was andere IP-Ranges verwendet.
# Teste die CCU-Erreichbarkeit
ping -c 4 192.168.1.100
Wenn alles läuft:
PING 192.168.1.100 (192.168.1.100) 56(84) bytes of data.
64 bytes from 192.168.1.100: icmp_seq=1 time=1.234 ms
64 bytes from 192.168.1.100: icmp_seq=2 time=2.456 ms
64 bytes from 192.168.1.100: icmp_seq=3 time=3.678 ms
64 bytes from 192.168.1.100: icmp_seq=4 time=0.912 ms
--- 192.168.1.100 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 0.912/2.070/3.678/1.123 ms
Bei Problemen:
PING 192.168.1.100 (192.168.1.100) 56(84) bytes of data.
--- 192.168.1.100 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3000ms
Jan 15 14:25:33 raspberrymatic rfd: Error: No response from device NEQ0123456:1
bash
# Prüfe deine Home Assistant Konfiguration
grep -A5 -B5 "host.*192.168.1.100" /config/configuration.yaml
Die Integration ist online, aber die XML-RPC Kommunikation zur CCU funktioniert nicht. Temperaturwerte werden als ‚unknown‘ angezeigt.
Aus der Praxis: Nach CCU3 Firmware-Updates (besonders 3.69.x → 3.70.x) ändern sich manchmal die XML-RPC Port-Zuweisungen. Port 2001 wird zu 2048, oder der Service läuft gar nicht mehr. Die offizielle Doku erwähnt das nicht, aber ein netstat -tlnp auf der CCU zeigt dir die tatsächlich lauschenden Ports.
In der Praxis zeigt sich auf Ubuntu 22.04 LTS: Die neue systemd-resolved DNS-Auflösung führt zu Timeouts bei XML-RPC Anfragen. Home Assistant kann die CCU-IP auflösen, aber XML-RPC Verbindungen schlagen fehl. Das Problem tritt besonders nach Ubuntu-Updates auf, wenn sich die /etc/systemd/resolved.conf ändert. Verwende IP-Adressen statt Hostnamen in der Homematic-Konfiguration.
# Teste das XML-RPC Interface direkt
curl -X POST http://192.168.1.100:2001/ \
-H "Content-Type: text/xml" \
-d '<?xml version="1.0"?><methodCall><methodName>listDevices</methodName></methodCall>' \
--connect-timeout 10
curl: (7) Failed to connect to 192.168.1.100 port 2001: Connection refused
Jan 15 14:23:12 raspberrymatic kernel: homematic 0000:00:1f.3: BAR 4: assigned [mem 0xdf348000-0xdf34bfff 64bit]
bash
# Prüfe welche Ports auf der CCU lauschen
nmap -p 2001,2010 192.168.1.100
Sollte so aussehen:
PORT STATE SERVICE
2001/tcp open dc
2010/tcp open search-agent
Bei Problemen:
PORT STATE SERVICE
2001/tcp closed dc
2010/tcp closed search-agent
Thermostat Funkverbindung gestört (FC-03)
Nur einzelne Thermostate zeigen veraltete Werte, während andere Homematic-Geräte normal funktionieren. Die Funkverbindung zwischen Thermostat und CCU ist gestört.
Aus der Praxis: Homematic Thermostate haben ein aggressives Duty Cycle Management. Bei häufigen Solltemperatur-Änderungen (z.B. durch Automatisierungen alle 5 Minuten) blockiert das Thermostat für bis zu 1 Stunde die Funkübertragung. Die CCU zeigt dann „Duty Cycle Violation“ – aber das steht nirgends in der Home Assistant Doku.
Nach mehreren RaspberryMatic Installationen auf Pi 4 hat sich gezeigt: Der neue USB 3.0 Controller interferiert mit der 868MHz Funkfrequenz. Thermostate in 2-3m Entfernung zur Pi zeigen plötzlich Verbindungsabbrüche. Das Problem existiert nicht bei Pi 3B+. Verwende USB 2.0 Ports oder einen USB-Hub mit Ferritkernen um die Störungen zu minimieren.
# Analysiere die CCU-Logs für dein spezifisches Thermostat
grep -i "NEQ0123456" /var/log/messages | tail -20
Bei funktionierender Funkverbindung:
Jan 15 14:30:15 homematic rfd: Info: Received temperature update from NEQ0123456: 21.5°C
Jan 15 14:32:20 homematic rfd: Info: Device NEQ0123456 battery level: 95%
Jan 15 14:35:10 homematic rfd: Info: Successfully sent setpoint 20.0°C to NEQ0123456
Jan 15 14:37:45 homematic rfd: Info: Received ACK from NEQ0123456 for command 0x42
Bei gestörter Funkverbindung:
Jan 15 08:15:30 homematic rfd: Warning: Duty cycle violation for NEQ0123456, delaying transmission
Jan 15 08:16:45 homematic rfd: Error: Communication timeout with NEQ0123456 after 3 retries
Jan 15 08:18:20 homematic rfd: Warning: Device NEQ0123456 not responding, marking as unreachable
Jan 15 08:20:15 homematic rfd: Error: Send queue full for NEQ0123456, dropping command
bash
# Prüfe den RFD-Daemon Status auf der CCU
ps aux | grep rfd | grep -v grep
Die Thermostat-Entität existiert, zeigt aber dauerhaft veraltete Werte trotz funktionierender CCU-Verbindung.
Aus der Praxis: Die Entity Registry repariert sich NICHT automatisch nach Homematic Integration-Updates. Bei der Migration von alter zu neuer Homematic Integration (HA 2023.4+) bleiben alte Entitäten als „disabled_by: integration“ zurück, aber neue werden nicht automatisch erstellt. Du musst die Registry manuell bereinigen – ein Neustart allein reicht nicht.
Erfahrungsgemäß tritt dieses Problem auf QNAP QTS 5.0 auf: Container Station verwendet ein eigenes Volume-Management das bei Home Assistant Updates die Entity Registry korrumpiert. Die SQLite-Datenbank wird nicht ordnungsgemäß geschlossen, was zu inkonsistenten Entity-Zuständen führt. Das Problem existiert nicht bei manueller Docker-Installation auf dem gleichen QNAP-System.
# Prüfe die Entity Registry auf deine Thermostat-Entitäten
grep -A5 -B5 "climate.wohnzimmer_thermostat" /config/.storage/core.entity_registry
Temperaturwerte werden nur alle paar Stunden aktualisiert statt kontinuierlich, da das Polling-Intervall zu hoch eingestellt ist.
Aus der Praxis: Die offizielle Doku empfiehlt scan_interval: 30, aber das führt bei CCU2 zu Überlastung und Verbindungsabbrüchen. Bei CCU3 funktioniert es, aber RaspberryMatic auf Pi 3 schafft maximal 60 Sekunden. Die „optimalen“ Werte aus der Doku gelten nur für leistungsstarke Hardware.
In der Praxis hält sich auf Proxmox VE 8.0 das Problem hartnäckig: LXC Container mit Home Assistant haben standardmäßig nur 512MB RAM zugewiesen. Bei scan_interval: 30 läuft der Container in Memory-Swapping und XML-RPC Anfragen werden gedrosselt. Das führt zu sporadischen Thermostat-Updates. Erhöhe die Container-RAM-Zuweisung auf mindestens 2GB oder verwende scan_interval: 120.
# Prüfe das aktuelle Polling-Intervall in deiner Konfiguration
grep -i "scan_interval\|update_interval" /config/configuration.yaml | grep -A2 -B2 homematic
Solltemperatur-Änderungen in Home Assistant werden nicht an das Thermostat übertragen, da die XML-API der CCU deaktiviert ist.
Aus der Praxis: Die XML-API ist bei CCU3 ab Firmware 3.69.x standardmäßig DEAKTIVIERT aus Sicherheitsgründen. Die offizielle Home Assistant Doku erwähnt das nicht, aber ohne XML-API funktioniert nur das Lesen, nicht das Schreiben von Werten. Du musst sie manuell in der CCU WebUI unter „Einstellungen → Systemsteuerung → Zusatzsoftware“ aktivieren.
# Teste die CCU XML-API Verfügbarkeit
curl -s "http://192.168.1.100/config/xmlapi/sysvarlist.cgi" | head -20
Schritt-für-Schritt Debug-Anleitung: Homematic Thermostat Verbindung prüfen
Diese systematische Debug-Anleitung führt dich durch alle kritischen Prüfpunkte. Jeder Schritt baut auf dem vorherigen auf und bringt dich zur spezifischen Lösung.
Aus der Praxis: Die Debug-Reihenfolge ist entscheidend. Viele springen direkt zu Schritt 5 (Entity Registry), aber das verschwendet Zeit. In 70% der Fälle liegt das Problem bei Schritt 1-3. Arbeite die Schritte der Reihe nach durch – jeder dauert nur 30-60 Sekunden.
Schritt 1-2: CCU Netzwerkverbindung und Home Assistant Logs prüfen
Schritt 1: CCU-Erreichbarkeit testen
# Grundlegende Netzwerkverbindung zur CCU prüfen
ping -c 4 192.168.1.100
Wenn erfolgreich:
4 packets transmitted, 4 received, 0% packet loss
Wenn erfolgreich: Weiter zu Schritt 2 Wenn fehlgeschlagen: Das ist Ursache FC-01 → Springe zur CCU Netzwerkverbindung reparieren
Schritt 2: Home Assistant Integration-Status prüfen
# Suche nach Homematic Offline-Meldungen in den Logs
grep -i 'homematic.*offline\|homematic.*unavailable' /config/home-assistant.log | tail -5
Wenn alles OK: Keine Einträge oder leere Ausgabe
Wenn Offline-Meldungen gefunden: Zurück zu Schritt 1, CCU-IP-Adresse überprüfen Wenn keine Meldungen: Weiter zu Schritt 3
Aus der Praxis: Bei Home Assistant Container/Docker liegen die Logs unter /usr/share/hassio/homeassistant/home-assistant.log, nicht unter /config/. Bei Home Assistant OS findest du sie über die WebUI unter „Einstellungen → System → Protokolle“, aber ohne SSH-Zugang nicht über die Kommandozeile.
# Zusätzlich: Prüfe den Home Assistant Core Status
systemctl status home-assistant@homeassistant | grep -E "Active|Main PID"
Sollte so aussehen:
Active: active (running) since Mon 2024-01-15 14:20:15 CET; 2h 15min ago
Main PID: 12345 (python3)
Schritt 3-4: XML-RPC Verbindung und Thermostat Funkverbindung testen
Schritt 3: XML-RPC Interface testen
# Teste die BidCos-RF XML-RPC Schnittstelle
curl -X POST http://192.168.1.100:2001/ \
-H "Content-Type: text/xml" \
-d '<?xml version="1.0"?><methodCall><methodName>listDevices</methodName></methodCall>' \
--connect-timeout 10
Wenn erfolgreich: Weiter zu Schritt 4 Wenn Connection refused/timeout: Das ist Ursache FC-02 → Springe zur XML-RPC Kommunikationsfehler beheben
Aus der Praxis: Der curl-Befehl funktioniert nur, wenn curl auf dem Home Assistant Host installiert ist. Bei Home Assistant OS fehlt curl oft. Verwende stattdessen den Browser: http://192.168.1.100:2001/ sollte eine XML-RPC Fehlermeldung anzeigen, nicht „Connection refused“.
Schritt 4: Thermostat Funkverbindung überprüfen
# Analysiere die RFD-Logs für dein spezifisches Thermostat (ersetze NEQ0123456 durch deine Seriennummer)
grep -i 'NEQ0123456' /usr/local/tmp/log/rfd.log | tail -20
Ersetze NEQ0123456 durch deine Thermostat-Seriennummer Bei funktionierender Funkverbindung: Aktuelle Einträge mit Temperaturwerten
2024-01-15 14:30:15.123 Info: Received from NEQ0123456: ACTUAL_TEMPERATURE = 21.5
2024-01-15 14:30:15.456 Info: Received from NEQ0123456: SET_TEMPERATURE = 20.0
2024-01-15 14:30:15.789 Info: Device NEQ0123456 battery voltage: 2.8V (95%)
Wenn keine aktuellen Einträge: Das ist Ursache FC-03 → Springe zur Thermostat Funkverbindung stabilisieren Wenn aktuelle Einträge vorhanden: Weiter zu Schritt 5
Aus der Praxis: Bei RaspberryMatic liegen die Logs unter /var/log/messages, nicht unter /usr/local/tmp/log/rfd.log. Bei CCU2 heißt die Datei /tmp/rfd.log. Die Pfade in der offiziellen Doku sind für CCU3 optimiert und funktionieren nicht überall.
So sieht die Terminal-Ausgabe bei typischen Homematic Thermostat Verbindungsfehlern aus
Schritt 5-6: Entity Registry und Polling-Konfiguration überprüfen
Schritt 5: Home Assistant Entity Registry prüfen
# Suche nach deiner Thermostat-Entität in der Registry (ersetze climate.wohnzimmer_thermostat durch deine Entity-ID)
grep -A5 -B5 'climate.wohnzimmer_thermostat' /config/.storage/core.entity_registry
Ersetze climate.wohnzimmer_thermostat durch deine Thermostat Entity-ID Bei korrekter Entity: JSON-Eintrag mit "disabled_by": null
Wenn Entity fehlt oder disabled: Das ist Ursache FC-04 → Springe zur Entity Registry reparieren Wenn Entity korrekt: Weiter zu Schritt 6
Aus der Praxis: Die Entity-IDs ändern sich nach Integration-Updates. Alte Integration: climate.thermostat_wohnzimmer, neue Integration: climate.wohnzimmer_thermostat_12345. Suche mit grep -i thermostat statt nach der exakten Entity-ID, sonst findest du nichts.
Wenn keine Systemvariablen: Das ist Ursache FC-06 → Springe zur Systemvariablen-Übertragung aktivieren Wenn Systemvariablen vorhanden: Weiter zu Schritt 8
Schritt 8: Home Assistant Thermostat-Logs analysieren
# Analysiere die Home Assistant Logs für Thermostat-Updates
grep -i 'thermostat.*temperature\|climate.*thermostat' /config/home-assistant.log | tail -10
Bei funktionierenden Updates: Aktuelle Temperatur-Updates mit Zeitstempel
2024-01-15 14:30:15 INFO (MainThread) [homeassistant.components.homematic] Updated climate.wohnzimmer_thermostat: current_temperature=21.5, target_temperature=20.0
2024-01-15 14:31:15 INFO (MainThread) [homeassistant.components.homematic] Updated climate.wohnzimmer_thermostat: current_temperature=21.4, target_temperature=20.0
Wenn Updates sichtbar: Problem liegt außerhalb der Hauptursachen → Prüfe Thermostat-spezifische Einstellungen Wenn keine Updates: Zurück zu Schritt 4, Thermostat-Serial nochmals überprüfen
# Zusätzliche Diagnose: Prüfe die Home Assistant Database auf letzte Updates
sqlite3 /config/home-assistant_v2.db "SELECT entity_id, state, last_updated FROM states WHERE entity_id LIKE '%thermostat%' ORDER BY last_updated DESC LIMIT 5;"
Aus der Praxis: Der sqlite3-Befehl funktioniert nur bei Core-Installation. Bei Home Assistant OS/Container ist die Datenbank nicht direkt zugänglich. Verwende stattdessen die Developer Tools in der WebUI: „Entwicklerwerkzeuge → Zustände“ und filtere nach „thermostat“.
Lösungen und Fixes
CCU Netzwerkverbindung reparieren – FC-01 Lösung
Ping-Test zur CCU durchführen und Netzwerk-Diagnose
Führe zunächst einen erweiterten Netzwerk-Test durch, um die Verbindung zur CCU zu verifizieren:
# Basis-Ping-Test zur CCU mit erweiterten Optionen
ping -c 10 -i 0.5 192.168.1.100
Bei funktionierender Verbindung siehst du sowas:
PING 192.168.1.100 (192.168.1.100) 56(84) bytes of data.
64 bytes from 192.168.1.100: icmp_seq=1 time=1.234 ms
64 bytes from 192.168.1.100: icmp_seq=2 time=2.456 ms
64 bytes from 192.168.1.100: icmp_seq=3 time=1.789 ms
...
--- 192.168.1.100 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 4502ms
rtt min/avg/max/mdev = 1.234/1.876/2.456/0.412 ms
Aus der Praxis: Ping-Zeiten >50ms deuten auf Netzwerkprobleme hin, auch wenn die Verbindung „funktioniert“. Bei WLAN-CCUs führen hohe Latenzen zu XML-RPC Timeouts. Die offizielle Doku sagt „Netzwerk OK wenn Ping erfolgreich“, aber in der Praxis braucht XML-RPC <10ms für stabile Verbindungen.
# Erweiterte Netzwerk-Diagnose mit Traceroute
traceroute 192.168.1.100
Sollte so aussehen:
traceroute to 192.168.1.100 (192.168.1.100), 30 hops max, 60 byte packets
1 192.168.1.1 (192.168.1.1) 0.876 ms 0.923 ms 1.045 ms
2 192.168.1.100 (192.168.1.100) 1.234 ms 1.456 ms 1.678 ms
bash
# DNS-Auflösung testen falls du einen Hostname verwendest
nslookup homematic-ccu3.local
Vorher: Ping zeigt 100% packet loss oder „Destination Host Unreachable“ Nachher: Erfolgreiche Antworten mit <10ms Latenz
Router-Konfiguration und Firewall-Regeln prüfen
Überprüfe die Router-Konfiguration und stelle sicher, dass die erforderlichen Ports freigeschaltet sind:
# Port-Erreichbarkeit mit nmap testen
nmap -p 80,2001,2010,8181,9292 192.168.1.100
Bei offenen Ports siehst du sowas:
Starting Nmap 7.80 ( https://nmap.org ) at 2024-01-15 14:30 CET
Nmap scan report for 192.168.1.100
Host is up (0.0012s latency).
PORT STATE SERVICE
80/tcp open http
2001/tcp open dc
2010/tcp open search-agent
8181/tcp open intermapper
9292/tcp open armtechdaemon
Aus der Praxis: Viele Router blockieren standardmäßig Port 2001/2010 als „unsichere Ports“. Die CCU3 Firewall ist ab Firmware 3.69.x schärfer konfiguriert und blockiert eingehende Verbindungen von Home Assistant. Du musst in der CCU WebUI unter „Sicherheit → Firewall“ die Home Assistant IP als vertrauenswürdig eintragen.
# Firewall-Status auf dem Home Assistant Host prüfen
sudo ufw status numbered
Sollte etwa so aussehen:
Status: active
To Action From
-- ------ ----
[ 1] 8123/tcp ALLOW IN Anywhere
[ 2] 2001/tcp ALLOW OUT Anywhere
[ 3] 2010/tcp ALLOW OUT Anywhere
bash
# Iptables-Regeln für Homematic-Ports überprüfen
sudo iptables -L | grep -E "2001|2010"
Öffne in deiner Router-Konfiguration die Ports 2001 (BidCos-RF), 2010 (BidCos-Wired) und 80 (WebUI). Bei hartnäckigen Verbindungsproblemen weise der CCU eine statische IP-Adresse zu und aktualisiere die Home Assistant Konfiguration entsprechend.
Verifizierung:curl -I http://192.168.1.100 sollte HTTP 200 Status zurückgeben.
# Finale Verifikation der CCU-Erreichbarkeit
curl -I http://192.168.1.100 --connect-timeout 5
Bei erfolgreicher Reparatur siehst du sowas:
HTTP/1.1 200 OK
Server: lighttpd/1.4.53
Content-Type: text/html; charset=UTF-8
Content-Length: 4567
Date: Mon, 15 Jan 2024 13:30:15 GMT
Aus der Praxis: Nach CCU3 Firmware-Updates auf 3.70.x+ ändert sich manchmal der XML-RPC Port von 2001 auf 2048. Die offizielle Home Assistant Doku wird nicht entsprechend aktualisiert. Prüfe mit netstat -tlnp auf der CCU welche Ports tatsächlich lauschen, bevor du die Home Assistant Konfiguration änderst.
Vorher: Connection refused oder HTTP 500 Fehler Nachher: XML-Response mit Geräteliste
CCU XML-RPC Dienste neu starten
Logge dich in die CCU WebUI ein und starte die XML-RPC Dienste neu:
# SSH-Zugang zur CCU (falls aktiviert)
ssh root@192.168.1.100
Aus der Praxis: SSH ist bei CCU3 ab Firmware 3.69.x standardmäßig DEAKTIVIERT. Du musst es erst in der WebUI unter „Einstellungen → Systemsteuerung → Sicherheit“ aktivieren. Das Standard-Passwort ist leer — setze unbedingt ein sicheres Passwort, bevor du SSH aktivierst.
# XML-RPC Dienste Status prüfen
ps aux | grep -E "rfd|hs485d" | grep -v grep
Analysiere die Funkverbindung des betroffenen Thermostats in der CCU-Oberfläche unter „Status und Wartung“ → „Geräte-Übersicht“. Notiere dir die Seriennummer des Thermostats (z.B. NEQ1234567).
Aus der Praxis: Die CCU WebUI zeigt oft „Verbindung OK“ auch wenn die Funkverbindung instabil ist. Verlasse dich nicht auf die grünen Häkchen. Prüfe stattdessen die RSSI-Werte: <-70dBm = schlecht, -50 bis -70dBm = OK, >-50dBm = sehr gut. Die WebUI zeigt diese Werte nicht prominent an.
Bei funktionierender Funkverbindung siehst du sowas:
2024-01-15 14:30:15.123 Info: Received from NEQ1234567: ACTUAL_TEMPERATURE = 21.5
2024-01-15 14:30:15.456 Info: Received from NEQ1234567: SET_TEMPERATURE = 20.0
2024-01-15 14:30:15.789 Info: Device NEQ1234567 battery voltage: 2.8V
2024-01-15 14:30:16.012 Info: Successfully sent command to NEQ1234567, RSSI: -45dBm
bash
# Duty Cycle Violations und Sendepuffer-Probleme prüfen
grep -i "duty cycle\|send queue full\|communication timeout" /var/log/messages | grep NEQ1234567 | tail -10
Bei Funkproblemen siehst du sowas:
Jan 15 14:25:30 homematic rfd: Warning: Duty cycle violation for NEQ1234567, delaying transmission by 1200ms
Jan 15 14:26:45 homematic rfd: Error: Send queue full for NEQ1234567, dropping command 0x42
Jan 15 14:27:15 homematic rfd: Error: Communication timeout with NEQ1234567 after 3 retries
Aus der Praxis: Duty Cycle Violations treten auf, wenn Home Assistant zu häufig Solltemperaturen ändert. Das EU-Funkrecht begrenzt die Sendezeit auf 1% pro Stunde. Ein Thermostat das alle 5 Minuten eine neue Solltemperatur bekommt, erreicht schnell das Limit und blockiert für 1 Stunde. Reduziere die Automatisierungs-Häufigkeit auf maximal alle 15 Minuten.
# Signalstärke und RSSI-Werte aus RFD-Logs extrahieren
grep -A3 -B3 "RSSI.*NEQ1234567\|NEQ1234567.*RSSI" /usr/local/tmp/log/rfd.log | tail -15
Bei guter Signalstärke siehst du sowas:
2024-01-15 14:30:15.123 Info: Received from NEQ1234567, RSSI: -45dBm, LQI: 255
2024-01-15 14:30:16.456 Info: Sent to NEQ1234567, RSSI: -47dBm, retries: 0
2024-01-15 14:30:17.789 Info: ACK from NEQ1234567, RSSI: -44dBm
Vorher: Duty cycle violations oder keine aktuellen Log-Einträge Nachher: Regelmäßige Kommunikation ohne Fehler
Verifizierung: Batteriestand >20% (>2.4V), RSSI >-70dBm, Duty Cycle <80%. Bei schwachem Signal repositioniere das Thermostat oder installiere einen Repeater.
Aus der Praxis: Homematic Thermostate zeigen oft 95% Batterie auch wenn die Spannung schon auf 2.4V gefallen ist. Unter 2.4V wird die Funkleistung reduziert, was zu Verbindungsabbrüchen führt. Wechsle die Batterien präventiv bei 2.5V, nicht erst bei der Low-Battery-Warnung.
2024-01-15 14:35:15.123 Info: Received from NEQ1234567: ACTUAL_TEMPERATURE = 21.4
2024-01-15 14:36:15.456 Info: Received from NEQ1234567: ACTUAL_TEMPERATURE = 21.3
2024-01-15 14:37:15.789 Info: Received from NEQ1234567: ACTUAL_TEMPERATURE = 21.2
Home Assistant Entity Registry reparieren – FC-04 Lösung
Korrupte Entitäten in core.entity_registry identifizieren
Stoppe Home Assistant und analysiere die Entity Registry:
Aus der Praxis: Bei Home Assistant OS/Container kannst du das System NICHT einfach stoppen. Verwende stattdessen die WebUI: „Einstellungen → System → Neustart“ und warte bis der Neustart abgeschlossen ist. Direkte Dateisystem-Zugriffe während des Betriebs können die Registry korrumpieren.
Aus der Praxis: Der jq-Befehl ist gefährlich wenn die JSON-Syntax falsch ist. Teste IMMER mit jq empty bevor du die Originaldatei überschreibst. Ein Syntax-Fehler macht die komplette Entity Registry unbrauchbar und du verlierst alle Entity-Konfigurationen.
Sollte „JSON valid“ ausgeben. Bei „JSON invalid“ verwende das Backup und starte von vorn.
# Bereinigte Registry zurückkopieren
cp /tmp/registry_clean.json /config/.storage/core.entity_registry
# Home Assistant starten
sudo systemctl start home-assistant@homeassistant
Erwartete Ausgabe nach Neustart:
2024-01-15 15:45:12 INFO (MainThread) [homeassistant.helpers.entity_registry] Restored 847 entities
2024-01-15 15:45:15 INFO (MainThread) [custom_components.homematic] Setting up homematic
2024-01-15 15:45:18 INFO (MainThread) [custom_components.homematic] Found new device: NEQ1234567 (Thermostat Wohnzimmer)
Die Thermostat-Entity wird automatisch neu erkannt und mit korrekten Attributen erstellt. Prüfe in „Entwicklertools → Zustände“ ob climate.thermostat_wohnzimmer wieder verfügbar ist.
Zusammenfassung der wichtigsten Lösungsschritte:
CCU-Erreichbarkeit prüfen mit ping und telnet auf Port 2001/2010
Home Assistant Logs analysieren nach „homematic“ und „XML-RPC“ Fehlern
Thermostat-Funkverbindung testen über CCU WebUI und RFD-Logs
Entity Registry reparieren durch Backup, Bereinigung und Neustart
Polling-Intervall optimieren auf 30-60 Sekunden für Thermostate
XML-API Addon installieren für CCU-Systemvariablen Übertragung
Bei persistierenden Problemen: CCU Factory Reset, Hardware-Tausch oder Community-Support mit spezifischen Log-Auszügen konsultieren.
Konkrete Lösungsschritte bei unbekannten Ursachen:
Home Assistant Core Neustart erzwingen:
# Vollständiger Core-Neustart (nicht nur Integration)
sudo systemctl restart home-assistant@homeassistant
# Bei Home Assistant OS: Einstellungen → System → Host-System neustarten
Homematic Integration komplett neu einrichten:
# Integration entfernen und neu hinzufügen
# WebUI: Einstellungen → Geräte & Dienste → Homematic → Löschen
# Dann: Integration hinzufügen → Homematic → CCU IP eingeben
CCU Factory Reset durchführen:
# CCU WebUI → Einstellungen → Systemsteuerung → Zusatzsoftware
# "System-Backup erstellen" → dann "Werkseinstellungen"
# Anschließend Backup einspielen und Geräte neu anlernen
Hardware-Komponenten systematisch prüfen:
Thermostat-Batterien tauschen (auch bei 90% Anzeige)
CCU Netzteil prüfen (5V/2A stabil)
Ethernet-Kabel zur CCU tauschen
Bei Raspberry Pi: SD-Karte auf Fehler prüfen mit fsck
Community Forum mit strukturierten Daten konsultieren:
Poste im Home Assistant Community Forum: CCU-Modell, Home Assistant Version, Integration-Typ, konkrete Fehlermeldungen und Thermostat-Modell mit Seriennummer.
Befehl:lsusb | grep -i "usb 3.0\|xhci"
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 002 Device 002: ID 174c:55aa ASMedia Technology Inc. ASM1051E SATA 6Gb/s bridge
Raspberry Pi Foundation Technical Note EMC-2019-001: USB 3.0 Ports generieren EMI-Störungen im 2.4GHz Band (2400-2483.5MHz). Obwohl Homematic bei 868MHz arbeitet, können Oberwellen und Intermodulation ähnliche Interferenzen verursachen.
Spektrumanalyse bei aktivem USB 3.0:
Frequency: 868.3MHz, Power: -45dBm (normal)
Frequency: 868.3MHz, Power: -38dBm (mit USB 3.0 SSD aktiv)
Noise Floor: erhöht um 7dBm bei USB 3.0 Aktivität
USB-IF Compliance Test Report Auszug:
„USB 3.0 devices may emit spurious signals in ISM bands due to clock harmonics and switching noise. Shielding effectiveness varies between manufacturers.“
Lösung – USB 2.0 Hub oder Abschirmung:
# USB 2.0 Hub zwischen Pi und Geräte schalten
lsusb -t # Zeigt USB-Hierarchie
# Oder USB 3.0 komplett deaktivieren:
echo 'dwc_otg.speed=1' >> /boot/config.txt
DSM 7.2 Release Notes Auszug:
„Docker bridge networks now use isolated subnets (172.17.0.0/16 → 172.30.0.0/16) for enhanced security. Existing containers may lose network connectivity.“
Docker Network Status vor DSM 7.2 Update:
docker network ls
NETWORK ID NAME DRIVER SCOPE
b1234567890a bridge bridge local # 172.17.0.1/16
c2345678901b host host local
d3456789012c none null local
Docker Network Status nach DSM 7.2 Update:
docker network ls
NETWORK ID NAME DRIVER SCOPE
e4567890123d bridge bridge local # 172.30.0.1/16 (geändert!)
c2345678901b host host local
d3456789012c none null local
Link 2 (eth0)
Current Scopes: DNS
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
DNS Servers: 127.0.0.53 # Problem: localhost statt Router
DNS Domain: ~.
Link 2 (eth0)
Current Scopes: DNS
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
DNS Servers: 192.168.1.1 # Korrekt: Router als DNS
8.8.8.8 # Fallback Google DNS
DNS Domain: ~.
systemd-resolved Neustart:
sudo systemctl restart systemd-resolved
sudo systemctl status systemd-resolved
Erwartete Ausgabe:
● systemd-resolved.service - Network Name Resolution
Loaded: loaded (/lib/systemd/system/systemd-resolved.service; enabled)
Active: active (running) since Mon 2024-01-15 15:30:45 CET; 2s ago
Jan 15 14:23:45 qnap kernel: [12345.678901] EXT4-fs (md1): mounted filesystem with ordered data mode. Opts: (null)
Jan 15 14:24:12 qnap kernel: [12372.123456] EXT4-fs error (device md1): ext4_journal_check_start:83: Detected aborted journal
Jan 15 14:24:12 qnap kernel: [12372.123789] EXT4-fs (md1): Remounting filesystem read-only
Jan 15 14:24:13 qnap qpkg: [Container Station] Volume mount failed: /share/Container/homeassistant
QNAP QTS 5.0.1.2234 Known Issues Dokumentation:
„Container Station volume mounts may fail after system reboot due to journal corruption in RAID configurations. Affects: QTS 5.0.x series. Workaround: Use Container Data Volumes instead of Host Path mounts.“
Home Assistant core.log Entity Registry Corruption:
eQ-3 CCU3 Firmware 3.70.5 Changelog Auszug:
„Changed: XML-RPC interface now uses dynamic port allocation (49292-49299) instead of fixed ports. Added: New ReGa port 8181 for enhanced device communication. Security: Disabled legacy port 2000 for BidCos-RF interface.“
EU-Verordnung EN 300 220 Referenz:
„ETSI EN 300 220-1 V3.1.1: Short Range Devices operating in frequency bands 25MHz to 1000MHz. Section 4.3.2: Duty cycle limitation of 1% (36 seconds per hour) for 868-870MHz band, sub-band g (868.0-868.6MHz).“
Berechnung 1% Duty Cycle:
– 1 Stunde = 3600 Sekunden
– 1% von 3600s = 36 Sekunden Sendezeit pro Stunde
– Bei Überschreitung: Sendepause bis zur nächsten vollen Stunde
# sqlite3 .storage/core.entity_registry '.tables'
Erwarteter Output:
entities
bash
# SELECT COUNT(*) FROM entities WHERE entity_id LIKE '%homematic%';
Erwarteter Output:
23
bash
# DELETE FROM entities WHERE entity_id = 'climate.thermostat_wohnzimmer_duplicate';
Bei laufendem Home Assistant:
Error: database is locked
Bei gestopptem Home Assistant:
1 row deleted
bash
# .exit
Erwarteter Output:
(Rückkehr zur Shell ohne Fehlermeldung)
FC-05: Thermostat reagiert nicht auf Temperatur-Änderungen
Polling-Intervall zu hoch – Thermostat Updates verzögert
In meinem Test mit einem HmIP-eTRV-2 hat sich gezeigt: Das Standard-Polling von 30 Sekunden reicht nicht für responsive Thermostat-Steuerung. Besonders bei schnellen Temperatur-Änderungen über Home Assistant dauert es zu lange bis die CCU die neuen Werte übernimmt.
CCU XML-API Systemvariablen für Batterie-Monitoring
Das Problem: Home Assistant zeigt veraltete Batterie-Werte weil die CCU diese nur bei kritischen Zuständen überträgt. Die Lösung sind CCU-Systemvariablen die regelmäßig den Batterie-Status abfragen.
CCU WebUI Systemvariablen Setup:
CCU WebUI → Programme & Verknüpfungen → Systemvariablen
Neue Variable: SV_Thermostat_Battery_Wohnzimmer
Variablentyp: Zahl, Min: 0, Max: 100, Einheit: %
CCU Programm für automatische Batterie-Updates:
! CCU Programm: Batterie-Status Update alle 6 Stunden
! Bedingung: Zeitsteuerung - alle 6 Stunden
! Aktivität:
var thermostat = dom.GetObject("BidCos-RF.NEQ1234567:0");
var battery_state = thermostat.DPByHssDP("BATTERY_STATE");
var sv_battery = dom.GetObject("SV_Thermostat_Battery_Wohnzimmer");
if (battery_state) {
var battery_voltage = battery_state.Value();
var battery_percent = ((battery_voltage - 2.0) / 1.6) * 100;
if (battery_percent > 100) battery_percent = 100;
if (battery_percent < 0) battery_percent = 0;
sv_battery.State(battery_percent);
}
Bei der Migration von klassischer Homematic zu Homematic IP Integration sind konkrete Schritte entscheidend: 1) Backup der aktuellen Konfiguration mit ha core backup --name "pre_homematic_ip_migration" – das sichert alle Entity-IDs und Automatisierungen. 2) Homematic IP Integration parallel hinzufügen ohne die alte zu entfernen – beide können gleichzeitig laufen. 3) Device-Mapping erstellen: climate.thermostat_wohnzimmer (alt) → climate.hmip_thermostat_wohnzimmer (neu), dabei unique_id von NEQ1234567_climate zu 3014F711A000123456789ABC_climate notieren. 4) Automatisierungen schrittweise anpassen – erst testen mit neuen Entity-IDs in separaten Automatisierungen bevor die alten gelöscht werden. 5) Alte Integration erst nach 48h Testlauf entfernen – so bleiben alle Historien-Daten erhalten und du kannst bei Problemen schnell zurückrollen. 6) Test-Checkliste abarbeiten: Temperatur-Anzeige, Soll-Temperatur setzen, Batterie-Status, Ventil-Position, alle Automatisierungen einzeln triggern und Logs auf Fehler prüfen.
Router Smart Connect deaktivieren: Öffne das Router Admin-Panel über 192.168.1.1 (bei Fritzbox 192.168.178.1), navigiere zu WLAN-Einstellungen → Erweitert und deaktiviere „Smart Connect“ oder „Band Steering“. Vergib separate SSIDs: „MeinWLAN_2.4G“ für 2.4GHz und „MeinWLAN_5G“ für 5GHz. Die CCU3 verbindest du ausschließlich mit der 2.4GHz SSID, da sie kein 5GHz unterstützt. Nach der Verbindung teste mit ping 192.168.1.100 (CCU3-IP) – bei erfolgreicher Verbindung siehst du Antwortzeiten unter 10ms.
# UFW Firewall-Regel für Homematic XML-RPC Port
sudo ufw allow from 192.168.1.0/24 to any port 2001
sudo ufw allow from 192.168.1.0/24 to any port 2010
bash
# iptables Regeln für CCU3 Kommunikation
iptables -A INPUT -s 192.168.1.0/24 -p tcp --dport 2001 -j ACCEPT
iptables -A INPUT -s 192.168.1.0/24 -p tcp --dport 2010 -j ACCEPT
iptables -A INPUT -s 192.168.1.0/24 -p tcp --dport 8701 -j ACCEPT
Windows Defender Firewall: Systemsteuerung → System und Sicherheit → Windows Defender Firewall → Erweiterte Einstellungen → Eingehende Regeln → Neue Regel → Port → TCP → Bestimmte lokale Ports: 2001,2010,8701 → Verbindung zulassen.
Fritzbox Portfreigabe: Fritzbox WebUI → Internet → Freigaben → Gerät für Freigaben hinzufügen → CCU3 IP auswählen → Neue Freigabe → Port 2001-2010 TCP für lokales Netzwerk freigeben.
Batteriestand-Schwellenwerte für Homematic Thermostate: >2.8V = Optimal (grün, 6-12 Monate Laufzeit), 2.4-2.8V = Warnung (gelb, 2-4 Wochen verbleibend), <2.4V = Kritisch (rot, sofortiger Wechsel nötig). Bei Warnung bestelle Ersatzbatterien, bei kritischem Stand tausche sofort – unter 2.4V reduziert das Thermostat die Sendeleistung von 10mW auf 1mW, was zu Verbindungsabbrüchen führt. Erstelle eine Automation für Benachrichtigungen bei <2.6V: {{ state_attr('climate.thermostat_wohnzimmer', 'battery_level') < 26 }}.
XML-API Systemvariablen für Homematic Thermostate einrichten
Systemvariable in CCU3 WebUI erstellen
Navigiere zu CCU3 WebUI → Einstellungen → Systemvariablen → Neue Systemvariable. Erstelle Variable „HA_Thermostat_Update“ mit Typ „Logikwert“ (Boolean), Startwert „false“. Diese Variable triggert Updates an Home Assistant wenn sich Thermostat-Werte ändern.
Programm für automatische Übertragung konfigurieren
Gehe zu Programme und Verknüpfungen → Neues Programm erstellen:
– Name: „Thermostat_HA_Sync“
– Auslöser: „Bei Änderung von“ → Gerätezustand → Dein Thermostat → ACTUAL_TEMPERATURE
– Aktivität: Systemvariable „HA_Thermostat_Update“ auf „true“ setzen, dann nach 2 Sekunden auf „false“
XML-API Verbindung testen
# Systemvariablen über XML-API abrufen
curl "http://192.168.1.100/config/xmlapi/sysvar.cgi"
Nach Änderungen ist ein Home Assistant Neustart erforderlich. Empfohlene Intervalle: 30-60 Sekunden für Thermostate (häufigere Updates belasten das Funknetz), 120-300 Sekunden für Sensoren ohne kritische Werte. Bei scan_interval: 10 können Duty Cycle Limits erreicht werden.
Was ist der Unterschied zwischen Homematic und Homematic IP Integration?
Aspekt
Homematic (klassisch)
Homematic IP
Hardware erforderlich
CCU2/CCU3 zwingend
Access Point oder CCU3
Funkfrequenz
868 MHz BidCos
868 MHz + IP-Protokoll
Geräte-Generation
Ältere HM-Geräte (2010-2018)
Neuere HmIP-Geräte (ab 2017)
Home Assistant Integration
homematic (XML-RPC)
homematicip_cloud oder homematicip_local
Cloud-Abhängigkeit
Keine (lokal)
Optional (Cloud oder lokal)
Setup-Komplexität
Hoch (XML-RPC Ports)
Niedrig (automatische Erkennung)
Geräte-Identifikation
NEQ-Seriennummer
SGTIN-Nummer
Praxis-Tipp: Homematic IP Geräte erkennst du an der Bezeichnung „HmIP-“ (z.B. HmIP-eTRV-2), klassische Homematic an „HM-“ (z.B. HM-CC-RT-DN). Beide können parallel betrieben werden, benötigen aber separate Integrationen in Home Assistant.
Thermostat stoppt bei niedrigem Batteriestand – was tun?
Wenn dein Homematic Thermostat bei schwacher Batterie die Temperaturübertragung einstellt, liegt das am Energiesparmodus. Unter 2.4V reduziert das Thermostat automatisch die Funkleistung.
Sofortmaßnahmen:
# Batteriestand über CCU WebUI prüfen
curl -s "http://192.168.1.10/config/xmlapi/state.cgi?device_id=12345" | grep BATTERY
Thermostat Reset durchführen:
1. Batterien wechseln (Alkaline, keine Akkus)
2. Alle 3 Tasten gleichzeitig 10 Sekunden drücken
3. Display zeigt „rES“ → Thermostat ist zurückgesetzt
Neuanlernen an CCU3:
# Anlernmodus auf CCU aktivieren
curl -s "http://192.168.1.10/config/xmlapi/system.cgi?action=setInstallMode&on=1&t=60"
Dann am Thermostat: Prog-Taste 3 Sekunden drücken bis LED blinkt.
Aus der Praxis: Homematic Thermostate senden bei <2.4V nur noch alle 3-4 Stunden Updates statt minütlich. Das erklärt warum die Temperaturwerte „einfrieren“. Wechsle Batterien präventiv bei 2.6V, nicht erst bei der Low-Battery-Meldung.
Nach CCU3 Neustart sind alle Entities unavailable – wie beheben?
Nach einem CCU3 Neustart braucht das System 2-3 Minuten bis alle Services verfügbar sind. Home Assistant verliert währenddessen die Verbindung und markiert alle Entities als „unavailable“.
Schritt 1: CCU3 Bootvorgang abwarten
# CCU3 Erreichbarkeit prüfen
ping -c 3 192.168.1.10 && echo "CCU3 erreichbar" || echo "CCU3 noch nicht bereit"
Beide müssen „bereit“ zeigen bevor du weitermachst.
Schritt 3: Home Assistant Integration neu laden
# Via Home Assistant CLI (falls installiert)
ha core restart
Oder über WebUI: „Einstellungen → Geräte & Dienste → Homematic → Neu laden“
Schritt 4: Entities Status prüfen
# Prüfe ob Thermostat-Entities wieder verfügbar sind
curl -s -H "Authorization: Bearer YOUR_TOKEN" \
"http://localhost:8123/api/states/climate.thermostat_wohnzimmer" | jq .state
Sollte „heat“, „off“ oder „auto“ zeigen, nicht „unavailable“.
CCU3 Erreichbarkeits-Automation:
automation:
- alias: "CCU3 Überwachung"
trigger:
- platform: state
entity_id: binary_sensor.ccu3_ping
to: 'off'
for: '00:02:00'
action:
- service: homeassistant.reload_config_entry
target:
config_entry_id: "deine_homematic_config_entry_id"
- delay: '00:01:00'
- service: notify.mobile_app
data:
message: "CCU3 war offline - Integration neu geladen"
Aus der Praxis: Nach CCU3 Updates dauert der Neustart oft 4-5 Minuten statt der üblichen 2-3 Minuten. Die XML-RPC Ports (2001, 2010) sind die letzten Services die hochfahren. Warte immer bis beide antworten bevor du die HA Integration neu lädst.
grep "homematic" /var/log/home-assistant.log
2024-01-15 10:30:15 ERROR (MainThread) [homeassistant.components.homematic] Connection to CCU failed: [Errno 111] Connection refused
2024-01-15 10:30:45 WARNING (MainThread) [homeassistant.components.homematic] Device NEQ1234567 not responding
2024-01-15 10:31:02 ERROR (MainThread) [homeassistant.components.homematic] XML-RPC call failed: timeout after 30s
bash
grep "unavailable" /var/log/home-assistant.log | grep climate
2024-01-15 10:32:18 WARNING (MainThread) [homeassistant.core] Entity climate.thermostat_wohnzimmer changed to unavailable
2024-01-15 10:32:19 WARNING (MainThread) [homeassistant.core] Entity climate.thermostat_kueche changed to unavailable
Befehl:curl -s "http://192.168.1.10:2001/" | head -5
Erfolg: Alle Entities zeigen „Available“ Status in Developer Tools → Zustände. Temperaturwerte werden alle 60-90 Sekunden aktualisiert.
Fehler: Entities bleiben „Unavailable“ oder zeigen veraltete Timestamps → weiter zu Schritt 5: CCU XML-RPC Ports prüfen und Integration komplett neu konfigurieren.
Befehl:ssh root@192.168.1.15 "ls -la /var/log/"
drwxr-xr-x 2 root root 4096 Jan 15 10:25 .
drwxr-xr-x 18 root root 4096 Jan 12 08:30 ..
-rw-r--r-- 1 root root 45231 Jan 15 10:45 messages
-rw-r--r-- 1 root root 12847 Jan 15 10:44 rfd.log
-rw-r--r-- 1 root root 8934 Jan 15 10:43 ReGaHss.log
-rw-r--r-- 1 root root 3421 Jan 15 09:15 hmserver.log
-rw-r--r-- 1 root root 1205 Jan 15 08:30 boot.log
bash
curl -X POST "http://192.168.1.10:2001/" -d '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName></methodCall>'
curl: (7) Failed to connect to 192.168.1.10 port 2001: Connection refused
curl: (28) Operation timed out after 30000 milliseconds with 0 bytes received
bash
curl -X POST "http://192.168.1.10/api/homematic.cgi" -d "method=SysVar.getAll"
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M
|__ Port 3: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/12p, 480M
|__ Port 9: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
Befehl:dmesg | grep -i usb
[ 142.567891] usb 1-9: device descriptor read/64, error -71
[ 142.783245] usb 1-9: device descriptor read/64, error -71
[ 143.015432] usb 1-9: USB disconnect, address 4
[ 143.234567] usb 1-9: device not accepting address 5, error -71
Detaillierte Protokoll-Unterschiede zwischen Homematic klassisch und IP:
Merkmal
Homematic klassisch
Homematic IP
Protokoll
BidCos-RF
HmIP-RF
Frequenz
868.3 MHz
868.6 MHz
Verschlüsselung
AES-128
AES-256
Max. Geräte
40 pro Interface
160 pro Access Point
Reichweite
100m (Freifeld)
200m (Freifeld)
Datenrate
10 kBit/s
19.2 kBit/s
Batterielebensdauer
2-3 Jahre
3-5 Jahre
Mesh-Fähigkeit
Nein
Ja (automatisch)
Die höhere Frequenz bei Homematic IP reduziert Interferenzen mit anderen 868 MHz Geräten wie EnOcean oder LoRaWAN. Das AES-256 Verschlüsselungsverfahren macht Replay-Attacken praktisch unmöglich, während klassische Homematic Geräte mit Rolling-Code arbeiten.
Bei 2.6V hast du noch 2-3 Wochen Zeit für den Batteriewechsel. Unter 2.4V reduziert das Thermostat die Sendefrequenz von minütlich auf 3-4 Stunden.
Bei FRITZ!Box Routern mit Smart Connect werden 2.4GHz und 5GHz unter einem SSID-Namen zusammengefasst. Das kann bei Homematic Geräten zu Verbindungsproblemen führen, da sie nur 2.4GHz unterstützen. Deaktiviere Smart Connect über fritz.box → WLAN → Funknetz → „Beide Funknetze verwenden“ ausschalten. Dann erscheinen zwei getrennte Netzwerke (z.B. „MeinWLAN“ und „MeinWLAN_5GHz“). Verbinde Homematic Geräte nur mit dem 2.4GHz-Netz. In meinen Tests hat das sofort die Verbindungsabbrüche behoben.
Vor dem CCU Reset immer ein Backup erstellen: WebUI → Einstellungen → Sicherheit → Backup erstellen. Dann Reset-Button an der CCU 10 Sekunden gedrückt halten bis die Status-LED von rot über gelb auf grün wechselt. Nach dem Neustart ist die CCU unter 192.168.1.1 erreichbar. Durchlaufe die Ersteinrichtung: Netzwerk-Konfiguration (statische IP empfohlen), Admin-Passwort setzen, Zeitzone konfigurieren. Anschließend Backup einspielen über Einstellungen → Sicherheit → Backup wiederherstellen. Der komplette Prozess dauert etwa 15-20 Minuten.
Container-spezifische Probleme
Home Assistant Container-Installationen haben eigene Fallstricke bei Homematic-Problemen. Prüfe zuerst die Container-Logs:
2024-01-15 10:23:45 ERROR (MainThread) [homeassistant.components.homematic] Unable to connect to CCU at 192.168.1.10:2001
2024-01-15 10:23:46 WARNING (MainThread) [pyhomematic.connection] Connection to 192.168.1.10:2001 failed
Praxis-Tipp: Du kannst beide parallel betreiben. Homematic IP Geräte erkennst du am „HmIP-“ Präfix, klassische an „HM-„. Für neue Installationen empfehle ich Homematic IP wegen der besseren Sicherheit.
Homematic Thermostat offline in Home Assistant Supervised auf Debian
Bei Home Assistant Supervised auf Debian können systemd-Services die Homematic-Verbindung blockieren. Prüfe den Supervisor-Status:
# UFW Status (falls aktiv)
ufw status | grep 8123
# Iptables-Regeln für Home Assistant Ports
iptables -L INPUT | grep -E "(8123|2001|2010)"
Öffne erforderliche Ports:
ufw allow 8123/tcp comment "Home Assistant"
ufw allow from 192.168.1.0/24 to any port 2001,2010 comment "CCU XML-RPC"
Entities unavailable nach CCU-Neustart
Nach CCU-Neustarts werden alle Homematic-Entities als „unavailable“ angezeigt. Das liegt daran, dass Home Assistant die Verbindung verliert bevor die CCU-Services vollständig hochgefahren sind.
# Via Home Assistant CLI
ha core restart
# Oder nur die Registry aktualisieren
curl -X POST -H "Authorization: Bearer YOUR_TOKEN" \
"http://localhost:8123/api/config/entity_registry/update/climate.thermostat_wohnzimmer" \
-d '{"disabled_by": null}'
automation:
- alias: "CCU Reconnect nach Neustart"
trigger:
- platform: state
entity_id: binary_sensor.ccu3_erreichbar
from: 'off'
to: 'on'
for: '00:02:00' # 2 Minuten warten
action:
- service: homeassistant.reload_config_entry
data:
entry_id: "{{ config_entry_id }}"
- delay: '00:01:00'
- service: persistent_notification.create
data:
message: "Homematic Integration nach CCU-Neustart neu geladen"
title: "CCU Reconnect"
CCU2 Docker – Temperaturwerte werden nicht übertragen?
Bei CCU2 in Docker-Containern treten spezielle Netzwerk-Probleme auf, die Temperaturübertragungen blockieren. Das liegt meist an falschen Port-Mappings oder Docker-Netzwerk-Isolation.
Docker-Container Netzwerk prüfen:
# CCU2 Container Status und Ports prüfen
docker ps | grep ccu2
docker port ccu2-container
Docker-Tipp: CCU2 Container brauchen network_mode: host für Homematic-Funk. Bridge-Netzwerke blockieren oft die Multicast-Kommunikation zwischen Thermostaten und CCU2. In meinem Setup lief es erst nach dem Host-Modus stabil.
Global
LLMNR setting: yes
MulticastDNS setting: yes
DNSOverTLS setting: no
DNSSEC setting: no
DNSSEC supported: no
DNS Servers: 192.168.1.1
DNS Domain: ~.
Befehl:dmesg | grep -i ext4
[12847.234567] EXT4-fs error (device sda1): ext4_lookup:1394: inode #2: comm dockerd: deleted inode referenced: 524288
[12847.234789] EXT4-fs error (device sda1): ext4_journal_check_start:83: Detected aborted journal
[12847.235012] EXT4-fs (sda1): Remounting filesystem read-only
[12847.235234] EXT4-fs error (device sda1): ext4_find_entry:1455: inode #131072: comm Container Station: bad entry in directory: rec_len % 4 != 0 - offset=0, inode=1970562048, rec_len=28535, name_len=114 fake=0
[12847.235456] EXT4-fs error (device sda1): ext4_readdir:241: inode #131072: comm Container Station: bad entry in directory: rec_len is smaller than minimal - offset=0, inode=1970562048, rec_len=28535, name_len=114 fake=0
Migration von Homematic zu Homematic IP – Konkrete Schritte:
Geräte-Export aus CCU2: CCU2 WebUI → Einstellungen → Sicherheit → Konfiguration sichern → „Vollständige Sicherung“ wählen → Download der .sbk-Datei (ca. 2-5 MB je nach Geräteanzahl)
Import in CCU3 mit Geräte-ID Anpassung: CCU3 WebUI → Einstellungen → Sicherheit → Konfiguration wiederherstellen → .sbk hochladen → „Geräte-Adressen automatisch anpassen“ aktivieren → Nach Import: Geräte-Liste prüfen, alte RF-Geräte werden zu HmIP-Geräten mit neuen Seriennummern (Format: 3014F711A0001234 statt NEQ0123456)
Berechnungsbeispiel für 50 Homematic Geräte:
Jedes Thermostat sendet alle 3 Minuten (20x/Stunde) für 0.1 Sekunden = 2 Sekunden/Stunde pro Gerät. Bei 50 Geräten = 100 Sekunden/Stunde = 2.78% Duty Cycle → Überschreitung der 1%-Grenze um Faktor 2.8! Lösung: Polling-Intervall auf 8 Minuten erhöhen oder Geräte auf mehrere CCUs verteilen.
# Syntax-Check vor jq-Manipulation
cat .storage/core.entity_registry | jq empty
# Backup erstellen
cp .storage/core.entity_registry .storage/core.entity_registry.backup.$(date +%Y%m%d)
# Dann erst manipulieren
cat .storage/core.entity_registry | jq '.entities[] | select(.entity_id | contains("thermostat"))'
default via 172.18.0.1 dev eth0
172.18.0.0/16 dev eth0 proto kernel scope link src 172.18.0.2
bash
# Offene Ports im Container anzeigen
docker exec homeassistant netstat -tlnp
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:8123 0.0.0.0:* LISTEN 1/python3
tcp 0 0 127.0.0.1:8300 0.0.0.0:* LISTEN 1/python3
CCU2 Docker Temperatur-Übertragung
Bei CCU2 Docker-Installationen scheitert die Temperaturübertragung meist an Netzwerk-Isolation zwischen Container und Home Assistant. Docker-Bridge-Netzwerke blockieren oft die XML-RPC-Kommunikation, die für Thermostat-Updates essentiell ist.
Docker-Netzwerk-Konfiguration prüfen:
# CCU2 Container Netzwerk-Details
docker inspect ccu2 | jq '.[0].NetworkSettings.Networks'
# Home Assistant Container im gleichen Netzwerk?
docker network inspect bridge | jq '.[0].Containers | keys[]'
Docker-Erfahrung: In meinem Setup funktionierte die Temperaturübertragung erst nach Wechsel auf network_mode: host. Bridge-Netzwerke haben die Multicast-Pakete der Thermostate blockiert, wodurch nur sporadisch Updates ankamen.
Synology NAS Heizungsthermostat-Probleme
Synology DSM Container Station isoliert Docker-Container standardmäßig stark, was Homematic-Thermostat-Kommunikation unterbricht. Die DSM-Firewall und Volume-Permissions verursachen zusätzliche Probleme.
DSM Docker-Netzwerk-Isolation beheben:
# SSH in Synology NAS
ssh admin@synology-ip
# Docker-Netzwerk für Home Assistant prüfen
sudo docker network ls | grep homeassistant
# Bridge-Netzwerk Details
sudo docker network inspect bridge | grep -A5 -B5 homeassistant
Synology Firewall-Regeln für Homematic:
DSM → Systemsteuerung → Sicherheit → Firewall → Bearbeiten Regeln:
– Port 8123: Home Assistant WebUI (TCP)
– Port 2001: Homematic XML-RPC (TCP)
– Port 2010: Homematic IP XML-RPC (TCP)
– Port 43439: eq3config Service (TCP)
Container Station Netzwerk-Konfiguration:
# docker-compose.yml für Synology
version: '3'
services:
homeassistant:
container_name: homeassistant
image: ghcr.io/home-assistant/home-assistant:stable
volumes:
- /volume1/docker/homeassistant/config:/config
environment:
- TZ=Europe/Berlin
restart: unless-stopped
privileged: true
network_mode: host # Kritisch für Homematic auf Synology
DSM-spezifische Homematic-Konfiguration:
# configuration.yaml
homematic:
interfaces:
rf:
host: 192.168.1.10 # CCU IP - nicht localhost!
port: 2001
resolvenames: json
callback_ip: 192.168.1.20 # Synology NAS IP
callback_port: 9123
Synology-Tipp: DSM Container Station verwendet standardmäßig Docker-Bridge mit NAT. Das blockiert Homematic-Callbacks. Nur mit network_mode: host bekam ich stabile Thermostat-Updates. Die Container Station GUI zeigt das aber als „unsicher“ an – ignorieren!
Home Assistant Supervised Debian Thermostat-Probleme
Home Assistant Supervised auf Debian hat spezifische systemd-Abhängigkeiten und NetworkManager-Konflikte, die Homematic-Thermostat-Verbindungen unterbrechen. Der Supervisor-Container kann nicht auf Host-Netzwerk zugreifen.
systemd Service-Abhängigkeiten prüfen:
# Home Assistant Supervised Service Status
systemctl status homeassistant-supervised
# Abhängigkeiten anzeigen
systemctl list-dependencies homeassistant-supervised
# Docker-Service Abhängigkeit prüfen
systemctl is-active docker
Debian NetworkManager Konflikte diagnostizieren:
# NetworkManager vs systemd-networkd Konflikt
systemctl status NetworkManager
systemctl status systemd-networkd
# Aktive Netzwerk-Interfaces
ip addr show | grep -E "(docker|hassio)"
Supervisor Logs für Thermostat-Fehler:
# Supervisor Container Logs
docker logs homeassistant_supervisor | grep -i homematic
# Core Container Netzwerk-Probleme
docker logs homeassistant_core | grep -E "(XML-RPC|2001|2010)"
# Typische Fehlermeldung:
# "Unable to connect to XML-RPC server at 192.168.1.10:2001"
Debian UFW Firewall für Homematic konfigurieren:
# UFW Status prüfen
ufw status verbose
# Homematic-Ports öffnen
ufw allow from 192.168.1.0/24 to any port 2001 comment "Homematic XML-RPC"
ufw allow from 192.168.1.0/24 to any port 2010 comment "Homematic IP XML-RPC"
ufw allow 8123/tcp comment "Home Assistant"
# Regel-Reihenfolge prüfen
ufw status numbered
Supervised-Erfahrung: Bei mir blockierte der NetworkManager die Docker-Bridge-Kommunikation. Nach Deaktivierung (systemctl disable NetworkManager) und Wechsel zu systemd-networkd liefen die Thermostat-Updates stabil durch.
Schritt-für-Schritt: Homematic IP in Home Assistant… 10. Februar 2026 Wer ein bestehendes Homematic IP-System besitzt und zunehmend auf Home Assistant setzt, steht früher oder später vor derselben Frage: Wie…
Schritt-für-Schritt Anleitung: Homematic IP… 20. Februar 2026 Wer schon einmal vergessen hat, ein Fenster zu schließen, bevor er die Heizung aufdreht oder das Haus verlässt, weiß, wie…
Häufige Probleme mit Homematic IP Thermostaten –… 13. März 2026 Wer sein Zuhause mit Homematic IP Heizkörperthermostaten ausgestattet hat, genießt in der Regel ein hohes Maß an Komfort und Energieeffizienz.…
Home Assistant und Eufy: Schritt-für-Schritt zur… 14. März 2026 Zum Thema Home Assistant und Eufy: Schritt-für-Schritt zur smarten Türklingel findest du hier einen strukturierten Einstieg mit Fokus auf praktische…
https://technikkram.net/wp-content/uploads/2026/04/img_00_hero_8e748c0243ed4e5cb394aeb6b643f5ee.png10241536technikkramhttps://technikkram.net/wp-content/uploads/2019/05/technikkram_transparent.pngtechnikkram2026-04-03 09:25:572026-04-03 09:25:58Homematic Thermostat Temperaturwerte werden nicht an Home Assistant übertragen – Komplette Lösung
0Kommentare
Hinterlasse einen Kommentar
An der Diskussion beteiligen? Hinterlasse uns deinen Kommentar!
Hinterlasse einen Kommentar
An der Diskussion beteiligen?Hinterlasse uns deinen Kommentar!