Da sich inzwischen die Berichte über plötzlich nicht mehr funktionierende Kommunikationsmodule häufen und Viessmann das Problem scheinbar nicht zentral aufgreift, müssen wir wohl selbst versuchen, die Gemeinsamkeiten zu finden. Eigentlich schon ziemlich unfassbar. Bei mir besteht das Problem seit dem 18.08. Die Anlage selbst funktioniert, WLAN und Internetzugang ebenfalls. Ich habe inzwischen WLAN zurückgesetzt, Router und Anlage neu gestartet, die Anlage längere Zeit ausgeschaltet und sogar testweise über einen iPhone-Hotspot verbunden. Das Ergebnis ist immer identisch. Mit Wireshark ist zu sehen, dass das Kommunikationsmodul Verbindungen zu Viessmann aufbaut. Der TCP-Verbindungsaufbau funktioniert, TLS-Kommunikation findet ebenfalls statt, anschließend wird die Verbindung jedoch wieder abgebrochen bzw. zurückgesetzt. Aktuell sehe ich vor allem zwei mögliche Ursachen: 1. TLS-/Zertifikatsproblem Ich habe mir das Zertifikat von api.viessmann-climatesolutions.com angeschaut. Das aktuell verwendete Server-Zertifikat ist erst seit dem 08.08.2026 gültig: NotBefore: Aug 8 00:00:00 2026 GMT Die Zertifikatskette ist: api.viessmann-climatesolutions.com RapidSSL TLS RSA CA G1 DigiCert Global Root G2 Auf einem aktuellen Rechner ist die Zertifikatskette völlig in Ordnung. Die Frage ist aber, ob bestimmte Firmwarestände der Viessmann-Kommunikationsmodule mit einem neu ausgestellten Zertifikat, einer bestimmten CA-Kette oder einer geänderten TLS-Konfiguration Probleme haben. Das wäre kein ungewöhnlicher Fehler bei Embedded-Geräten: Server wird aktualisiert, moderne Clients funktionieren weiterhin, während ältere oder bestimmte Firmwarestände das Zertifikat oder Teile der TLS-Konfiguration nicht mehr akzeptieren. Wichtig: Das muss nicht zwingend genau dieser API-Endpunkt sein. Die Anlage wird vermutlich weitere Viessmann-Server für Gerätekommunikation, Authentifizierung, Updates usw. verwenden. Interessant wäre deshalb, welche Server die betroffenen Kommunikationsmodule tatsächlich kontaktieren. 2. Serverseitige Sperre / Rate-Limit Eine weitere Möglichkeit wäre eine serverseitige Sperre bestimmter Geräte, Installationen oder Accounts. Ich nutze beispielsweise Home Assistant über die offizielle Viessmann-API. Grundsätzlich sollte ein API-Limit eigentlich nicht dazu führen, dass das Kommunikationsmodul selbst seine Verbindung zum Backend verliert. Ganz ausschließen würde ich einen Zusammenhang mit serverseitigen Limits oder einer fehlerhaften Sperrlogik momentan aber nicht. Daher wäre interessant zu wissen, ob andere Betroffene ebenfalls Home Assistant, ioBroker, FHEM oder andere Anwendungen über die Viessmann-API verwenden. Vielleicht können wir hier einmal systematisch Daten zusammentragen: Seit welchem Datum besteht der Ausfall? Wird im Display noch eine Verbindung zum Viessmann-Backend angezeigt? Funktioniert ein anderes WLAN bzw. ein Handy-Hotspot ebenfalls nicht? Werden Home Assistant oder andere externe API-Anwendungen verwendet? Besonders auffällig wäre es natürlich, wenn mehrere Anlagen mit bestimmten Firmwareständen ungefähr seit demselben Zeitpunkt Probleme bekommen haben. Falls jemand Wireshark verwenden kann: Interessant wären insbesondere die DNS-Anfragen bzw. TLS-SNI-Hostnamen des Kommunikationsmoduls. Dann könnte man sehen, welche Viessmann-Server tatsächlich angesprochen werden und ob bei diesen Servern ebenfalls kürzlich Zertifikate ausgetauscht wurden. Vielleicht bekommen wir so gemeinsam heraus, ob wir es wirklich mit einzelnen defekten Kommunikationsmodulen zu tun haben – oder doch mit einer serverseitigen Änderung bei Viessmann.
... Mehr anzeigen