TL;DR: Die TCU verliert im Betrieb ihre Uhrzeit und synchronisiert sie nicht nach. Mit einer Uhr auf 2024 sind alle Backend-Zertifikate „noch nicht gültig“, TLS scheitert, das Modul bleibt offline. Prüfen: curl -sI http://<IP-der-Heizung>/ | grep -i date. Workaround: Anlage komplett stromlos (WLAN-Modul-Neustart reicht nicht). Dauerhafte Lösung muss von Viessmann kommen: NTP-Handling in der Firmware. Hallo zusammen, ich hatte heute (11.09.2026) an einer Vitocal mit TCU301_Vitocal, Firmware 516.2537.4.0 dasselbe Bild wie in mehreren aktuellen Threads (Vitodens 200-W / TCU301, Vitodens 333-F / TCU200, ViCare-Integration seit 11.09.2026 offline, Verbindungsfehler Kommunikationsmodul😞 WLAN verbunden, IP per DHCP, Modul lokal erreichbar – aber „Backend: nicht aktiv“, ViCare-App ohne Verbindung, IoT-API meldet 400 DEVICE_COMMUNICATION_ERROR / GATEWAY_OFFLINE. Anlage lief normal. Ich habe die Ursache gemessen und beheben können. Ursache Der Webserver des Moduls (liefert die Open-Source-Lizenzliste) schickt bei jeder Antwort die Systemzeit mit: $ curl -sI http://<IP-der-Heizung>/ | grep -i date Date: Wed, 09 Oct 2024 22:53:35 GMT ← gemessen am 11.09.2026, 16:30 Uhr Die Uhr lief, stand aber auf dem Firmware-Datum von 2024 und wurde über Stunden nicht per NTP korrigiert. Alle Zertifikate des Backends sind aber erst ab 2026 gültig (api.viessmann-climatesolutions.com ab 08.08.2026, iam ab 24.02.2026, Azure Device Provisioning ab 31.07.2026). Aus Sicht einer Uhr auf 2024 ist jedes davon „not yet valid“ – jeder TLS-Handshake scheitert, das Modul kommt nie bis zum Backend. Das erklärt auch die Beobachtung von @n0y im TCU301-Thread, dass die MQTT-Verbindungen zur Azure-Cloud sofort wieder zugehen. Am Netz lag es nicht: NTP (UDP 123) und DNS waren aus demselben Netz nachweislich erreichbar. Lösung Anlage 30 Sekunden komplett stromlos (Hauptschalter, nicht nur das WLAN-Modul aus/ein – das hatte keine Wirkung). Direkt nach dem Booten: Date: Fri, 11 Sep 2026 15:44:20 GMT ← sekundengenau Backend-Verbindung innerhalb einer Minute wieder da, API und App funktionieren. Bitte an Viessmann Beim Booten holt sich das Modul die Zeit problemlos. Im laufenden Betrieb hat es seine Uhr aber verloren (bei mir um ca. 13:50 Uhr, ohne Eingriff – vermutlich ein interner Neustart) und danach nicht wieder synchronisiert. Damit steckt es in einem Zustand fest, aus dem es allein nicht herauskommt: falsche Uhr → TLS scheitert → kein Backend → keine Zeit vom Backend. Das ist ein Firmware-Problem, kein Netzwerkproblem. Bitte das NTP-Handling der TCU so anpassen, dass die Zeit nach jedem Verbindungsaufbau und zusätzlich periodisch synchronisiert wird, nicht nur beim Booten, und bei einem TLS-Fehler wegen ungültiger Zertifikatsdaten eine erneute Zeitsynchronisation ausgelöst wird, statt den Verbindungsversuch endlos zu wiederholen. Die Häufung identischer Meldungen seit dem 25./26.08.2026 (TCU200 und TCU301) spricht dafür, dass mehr Anlagen betroffen sind, als es hier im Forum aussieht. Wer das Bild hat: den curl-Befehl oben ausführen – steht dort 2024, ist es dieselbe Ursache. Viele Grüße Till
... Mehr anzeigen
