Climate Solutions Community

@cmenschel: war der Techniker eigentlich direkt von Viessmann oder von einer Heizungsfirma? 430 € für 1,5 Stunden ist schon ein heftiger Stundensatz, das muss man sagen 😧. Ehrlich gesagt ist es jetzt sogar blöd für dich, dass das Problem behoben wurde. Damit lässt sich kaum noch nachweisen, ob die neue Firmware meinen analysierten Fehler tatsächlich behebt oder einfach nur weniger große Pakete sendet. Der Thread hier bleibt aber Beleg genug, dass am Viessmann-Backend Änderungen vorgenommen wurden. Das Kunden für Herstellerfehler zahlen sollen, ist natürlich unsinnig, dass muss selbst Viessmann einsehen. @Erich3: bei dir muss es sich aufgrund der vorhandenen Daten, auf diese der Heizungsbetrieb zugreifden kann, um ein anderes Problem handeln. Die von mir dokumentierten Abbrüche zeigen ein sehr spezifisches Muster, dieses zum Verbindungsabbruch des Connect Modules führt. Die ViCare-App wurde nochmals aktualisiert, vielleicht hilft ein Update (falls das noch nicht automatisch passiert ist). ... Mehr anzeigen

Danke, die Analyse hat mich trotz KI-Unterstützung auch nicht unerheblich Zeit gekostet. Diese Arbeit ist eigentlich etwas, das bei Viessmann hätte erledigt werden sollen und wofür die Leute dort auch bezahlt werden. Deine Rückmeldung ist Gold wert, denn Viessmann hat jetzt zwei fundierte Ergebnisse, und ich hoffe, sie machen etwas daraus. ... Mehr anzeigen

Ergänzung zu meinem letzten Beitrag Ich habe die Mitschnitte der letzten Tage weiter analysiert und den Fehler nun eindeutig eingegrenzt. Die Backend-Verbindung bricht nicht zufällig ab, sondern systematisch, sobald das Modul größere Datenmengen sendet. Ich denke Viessmann (z.B. @CustomerCareChris, @Flo_Schneider, @CustomerCareLeo) sollte diese Information an die Entwicklung weiter geben.    Ursache: MTU/MSS-Problem auf der Ausgaberichtung Das Connect-Modul sendet TCP-Pakete mit 1460 Byte Payload (IP-Gesamtlänge 1500 Byte). Auf PPPoE-Verbindungen (DSL, viele Glasfaser-Anschlüsse) beträgt die effektive MTU jedoch nur 1492 Byte. Mein Router fragmentiert diese Pakete zwar, aber die Fragmente kommen beim Azure-Backend nicht durch oder werden nicht korrekt reassembliert. Der Server wartet auf Bestätigungen, bekommt keine, und beendet die Verbindung nach ca. 24 Sekunden sauber per FIN. Wobei ich in der Azure-Cloud eventuell ein Problem sehe, denn Microsoft dokumentiert für den Azure Load Balancer explizit: „IP fragmentation of UDP and TCP packets isn't supported on load-balancing rules"   Interessanterweise funktioniert die Eingangsrichtung einwandfrei: Der Server sendet maximal 1452 Byte Payload, was exakt in die 1492er MTU passt. Das Problem liegt also ausschließlich im Sende-Verhalten des Moduls.   Was am Router eingestellt sein muss Damit die Verbindung stabil bleibt, muss sichergestellt werden, dass das Modul keine Pakete größer als 1452 Byte Payload sendet. Das erreicht man durch MSS-Clamping auf dem Router: Für DSL/Glasfaser mit PPPoE: Setze das maximale TCP-Segment (MSS) für ausgehende Verbindungen auf 1452 (oder konservativ 1440). Für reine Ethernet-Anschlüsse (Kabel, FTTH ohne PPPoE): MSS auf 1460 belassen oder auf 1420 setzen, falls Probleme auftreten. Die genaue Einstellung hängt vom Router-Modell ab (bei vielen Geräten unter „Firewall“, „MSS Clamping“ oder „MTU-Optimierung“ zu finden). Wichtig ist, dass die Regel ausgehende TCP-SYN-Pakete auf dem WAN-Interface betrifft.   Warum die Verbindung manchmal „zufällig“ steht Wenn das Backend nach dem Verbindungsaufbau nur kleine Keepalive-Pakete sendet und das Modul selbst wenig publiziert, bleiben alle Pakete unter der kritischen Größe. Sobald jedoch größere Datenmengen fließen (z. B. bei Updates, Konfigurationsänderungen oder höheren Publish-Intervallen), tritt der Fehler sofort auf. Das erklärt die scheinbar willkürlichen Phasen ohne Probleme.   07:20:32.181202 Out ... 79.xxx.xx.xxx.54543 > 52.138.229.0.8883: Flags [.], seq 1651:3103, ack 61406, win 12288, length 1452 ← IP 1492, flags "," (kein DF!) 07:20:32.181226 Out ... id 56, offset 1472, flags none, proto TCP 6, length 28 79.xxx.xx.xxx 52.138.229.0 ip-proto-6 ← 2. Fragment, 8 Byte Payload Die Paketanalyse zeigt einen Defekt im TCP-Stack des Connect-Moduls: Es sendet 1460 Byte Payload über einen 1492er Pfad, setzt kein DF-Flag und reagiert nicht korrekt auf die im SYN-ACK angezeigte Server-MSS als Sende-Obergrenze. Das ist ein bekanntes PMTUD-Versagen, das durch Firmware behoben werden muss. ... Mehr anzeigen

Das sieht nach der Störung aus, diese bereits diskutiert wird. ... Mehr anzeigen

Das ist fast das Verhalten, das ich über die ganze Woche hatte. Bei mir wird dann vermutlich zur Fehlerbereinigung vom Connect-Modul auch die WLAN-Verbindung neu aufgebaut.   Seit meiner letzten Nachricht, irgendwann am Freitagnachmittag (28.08.), gab es keine Updates der Werte mehr, und die Backend-Verbindung war gestört. Am Sonntagmorgen (30.08.) habe ich die Heizung neu gestartet. Danach wurden die Werte langsam wieder aktualisiert, und ich schneide seitdem die gesamte verschlüsselte Datenübertragung vom Kommunikationsmodul mit. Bis jetzt scheinen keine Probleme aufzutreten. Da das Fehlerbild bei anderen weiterhin auftritt, denke ich, dass es wirklich daran liegt, mit welchem Server sich das Kommunikationsmodul verbindet.   Heute am Montagmorgen 31.08. um 06:18:11 Uhr konnte ich in meinen Mitschnitten erkennen, dass bis dahin eine normale, dauerhafte TCP/TLS-Verbindung auf Port 8883 bestand; danach erzeugt das Connect-Modul wiederholt neue Verbindungen, die der Server jeweils nach kurzer Zeit mit FIN beendet.   Der TCP-Dreiwege-Handshake gelingt also. Dasselbe wiederholt sich unter den ausgehenden lokalen Ports 56168, 56169, 56170, 56171 usw. Die Verbindung scheitert somit nicht beim Aufbau auf IP-, Routing-, NAT- oder TCP-Ebene.   Auffälliges Abbruchmuster 06:18:11 Modul öffnet .56167 06:18:34 Backend sendet FIN für .56167 06:18:28 Modul öffnet .56168 06:18:54 Backend sendet FIN für .56168 06:18:48 Modul öffnet .56169 06:19:18 Backend sendet FIN für .56169 06:19:12 Modul öffnet .56170 06:19:44 Backend sendet FIN für .56170   Damit ist nun sehr stark das Viessmann-Backend als Ursache bestätigt, da dieses plötzlich eine stabile Verbindung mit FIN beendet. Ich gehe mal davon aus, dass Viessmann sich trotz Beweis weiterhin nicht dazu äußern wird.   Ich habe heute, Dienstagmorgen (01.09.), den bisherigen Stream weiterhin mit Hilfe von KI untersucht. Leider habe ich vor dem 18.08.26 keinen Mitschnitt der damals noch störungsfreien Verbindung. Dennoch habe ich eine Optimierung meiner Firewall-Regel in meinem Router vorgenommen. Das Verhalten hat sich sofort gebessert, und die KI konnte mir einen Grund nennen, was sich vermutlich an der Backend-Infrastruktur verändert hat. Wenn ich mehr Nachweise und Tests durchgeführt habe, werde ich die Gründe veröffentlichen und auch eine mögliche Lösung für die Betroffenen liefern. ... Mehr anzeigen

Ich hatte heute trotz Neustart weiterhin keine Daten, dann bin ich auf mobilen Hotspot vom Smartphone gewechselt und es wurden relativ schnell Werte aktualisiert. Mit KI-Unterstützung habe ich aber auch den Datenstrom analysiert, viele Dinge durchdacht (DNS, MTU/MSS, Hardware-Defekte). Dann wieder nach 2h zurück zu meinen Heim-WLAN zurück gewechselt und dort funktionierte es weiterhin ohne Probleme.  Die KI hat mir beide Datenströme verglichen, der nicht funktionierende hatte auffällige ARP-Requests und TCP-Retransmission, wobei immer wieder die selben Datenpakte wiederholt wurden (selbe Sequenznummer). Als würde das Backend nicht so antworten, wie es das Connect Modul erwartet. Dieses Fehlerbild ist bei mir aktuell nicht mehr erkennbar. Entweder ich bin auf einen anderen Backend-Server gelandet oder Viessmann hat den Fehler behoben. Ich bin echt gespannt ob es das nun war, oder ob der Fehler wieder auftritt.  ... Mehr anzeigen

Update 1: Ich habe die ganze Nacht keine stabile Backend-Verbindung gehabt, und die Werte wurden ebenfalls nicht aktualisiert. Gerade eben habe ich die Heizung ausgeschaltet und neu gestartet – seitdem bleibt die Backend-Verbindung bestehen. Das ähnelt dem Muster von gestern. Off-Topic: Hat jemand eine Ahnung, um welche Uhrzeit Firmware-Updates erfolgen und ob auch alte Softwarestände (2 Jahre alt) problemlos per Remote-Update aktualisiert werden? Update 2:  Ich glaube außer der Außentemperatur wurde nichts weiter nach dem Neustart aktualisiert und die Backend-Verbindung toggelt weiterhin (wechsel zwischen "Nicht aktiv" und "Verbunden").  ... Mehr anzeigen

Das passt leider ins Bild. Ich musste gerade nach deiner Nachricht feststellen, dass bei mir ebenfalls wieder keine Verbindung mehr zum Backend besteht. In meinen API-Logs sehe ich, dass ab 16:19 Uhr ständig die Verbindung neu aufgebaut wird – davor lief es seit 9:10 Uhr ohne Probleme. Da kann man nur hoffen, dass bei Viessmann um 16:19 Uhr jemand in den Feierabend gegangen ist und das Problem morgen weiterverfolgt wird. Von Viessmann gibt es gibt es natürlich keine Informationen dazu und laut Viessmann Monitoring laufen alle Dienste ohne Störung.  Nachtrag: Ich habe mal das Kommunikationsmodul (TCU) neu gestartet, aber die Backend-Verbindung wird weiterhin ständig neu aufgebaut (also gleiches Fehlerbild wie seit Tagen). Jedoch scheinen einzelne Werte aktualisiert zu werden, dass kann aber auch reiner Zufall sein oder bei Viessmann wird aktuell weiterhin am Problem gearbeitet.  ... Mehr anzeigen

@Ummanzer: Danke, das wusste ich noch gar nicht. Ich habe mir den Link direkt als Bookmark gespeichert. Das wird künftig zumindest helfen einzuschätzen, ob das Problem bei Viessmann oder auf meiner Seite liegt. ... Mehr anzeigen

@Nie-Haus66: Dein regelmäßiges Muster (freitags gegen 20 Uhr offline, sonntags wieder da) ist ungewöhnlich. Um deine Netzwerk-/Internet-Infrastruktur als Ursache auszuschließen, eine Frage: Hast du schon einmal dein Smartphone als mobilen WLAN-Hotspot verwendet und die Heizung darüber verbunden – idealerweise über ein Wochenende, also genau in dem Zeitraum, in dem es sonst ausfällt? Dein aktueller Ausfall seit gestern 13:42 Uhr könnte allerdings auch zu der Backend-Störung gehören, über die wir hier im Thread gerade diskutieren. @Ummanzer: Ob der Neustart ausschlaggebend war, lässt sich wohl nie sicher sagen. Auch wenn die App nicht so toll ist, es gibt immer noch die Möglichkeit auf die API zuzugreifen. Daraus lässt sich eine eigene Webseite bauen oder HomeAssistent nutzen. @cmenschel: Da stimme ich dir voll zu. Eine Status-Seite für Störungen und Wartungsarbeiten, wie sie bei Tech-Firmen selbstverständlich ist, fehlt bei Viessmann schlicht. Ein transparenter Umgang – im Idealfall ein echtes Monitoring mit öffentlichem Status, wäre mir deutlich lieber als diese tagelange Ungewissheit.   Viessmann schuldet uns eine Erklärung, was hier eigentlich los war. Das Vertrauen muss Viessmann erst wieder zurückgewinnen.   ... Mehr anzeigen

@Frank_Ho: Danke für deine Rückmeldung! Kurzes Update von mir: Rund 2 Stunden nach dem Neustart des Kommunikationsmoduls (TCU) läuft bei mir scheinbar wieder alles normal. Die Werte werden in App und API aktualisiert, und beide Verbindungen (Internet und Backend) sind stabil – ohne die bisherigen Unterbrechungen. Ob der Neustart geholfen hat oder Viessmann zeitgleich etwas im Backend repariert hat, kann ich nicht sicher sagen. ... Mehr anzeigen

Danke @cmenschel und @Ummanzer für die Rückmeldungen! Mein aktueller Stand: Ich habe heute kurz nach 9 Uhr das Kommunikationsmodul (TCU) neu gestartet. Seitdem ist die Backend-Verbindung wieder stabil ("Verbunden", kein Toggeln mehr) – aber es werden weiterhin keine Werte aktualisiert, weder in der App noch über die API.   @cmenschel: Deine TCU (10.516.2537.4) trägt den Softwarestand 516 aus KW 37/2025. Deine HPMU (20.517.2629.320) ist sogar von KW 29/2026, vermutlich das Update vom Techniker. Das untermauert die Vermutung, dass das Backend mit älteren Softwareständen nicht mehr sauber zusammenspielt. Damit stehen hier jetzt drei Zustände nebeneinander: Bei Ummanzer läuft alles wieder, bei mir ist die Verbindung stabil, aber ohne Daten, und bei anderen (Frank_Ho, TobiasFriedrich) gibt es gar keine Verbindung. Das sieht nach einem Backend-Umbau in Etappen aus. Eine kurze offizielle Stellungnahme von Viessmann wäre wirklich angebracht. ... Mehr anzeigen

Update: Ich habe gestern Abend meine gesamte Netzwerk-/Internet-Infrastruktur und die Heizung neu gestartet. Während des Toggelns der Backend-Verbindung (wechsel zwischen "Nicht aktiv" und "Verbunden") konnte ich im Verbunden-Zustand erfolgreich die Warmwassertemperatur verändern. Zusätzlich scheinen die aktuellen Werte auch wieder an das Viessmann-Backend gesendet zu werde, jedenfalls wurden sie in der App aktualisiert.   Es könnte sein, dass Viessmann gerade etwas am Backend ändert und in der Cloud-Infrastruktur unterschiedliche Software-Stände vorliegen. Möglicherweise verbinde ich mich jetzt rein zufällig mit einem anderen Viessmann-Server, dessen Backend noch etwas weniger "kaputt" ist.   @Frank_Ho: Interessant ist, dass das Problem bei dir erst gestern Morgen aufgetreten ist und heute schon wieder behoben ist. Hast du eine Internet-Zwangstrennung bzw. lässt du den Router in der Nacht eine neue Internet-Verbindung aufbauen? Das kann aus meiner Sicht dafür sprechen, dass Viessmann mehrere Server betreibt und die Backend-Updates gestaffelt ausrollt.   @FamilieFriedrich: Wenn du am Router schon geprüft hast, dass dieser noch eine Internetverbindung hat, ist die Wahrscheinlichkeit sehr hoch, dass die Störung im Backend von Viessmann liegt. Vielleicht ist es bei dir auch so wie bei mir, dass sich das Kommunikationsmodul in kurzen Abständen (3–5 Minuten) immer wieder vom WLAN ab- und wieder anmeldet. Wenn du das auf dem Router siehst, kannst du dir die Fahrt über die 300 km wahrscheinlich ersparen. Wie Hein_1 weiter oben schon geschrieben hat, wirst du von Viessmann mehr oder weniger im Stich gelassen.   An alle hier: Ich denke, nur ein reger Austausch und eine Diskussion in diesem Thread erregt genug Aufmerksamkeit (z.B. bei @CustomerCareChris, @Flo_Schneider, @CustomerCareLeo ) und führt irgendwann zu einer Reaktion von Viessmann. Im Vergleich zu früheren Störungen ist hier bisher zu wenig Aktivität. Ich z.B. weiß gar nicht, ob es bei @Hein_1, @Ummanzer oder @G-A-N nicht schon wieder läuft. In der Heizperiode gäbe es hier sicher mehr Aktivität, umgekehrt ist die Heizpause für Viessmann natürlich ein idealer Zeitraum, um die Backend-Infrastruktur umzubauen. Ich denke, wir als Kunden sollten ein klares Signal senden: Wir sehen, was hier passiert, und wir nehmen das so nicht hin. ... Mehr anzeigen

Vielleicht liegt es an der Störung jedenfalls wäre Interessant, ob beim WLAN-Access-Point die Verbindung auftaucht, aber nur zum Viessmann Backend keine Verbindung hergestellt werden kann. Wenn du sicher gehen willst, dann richte bei dein Smartphone als Hotspot ein und verbinde auf dieses WLAN deine Anlage. Damit hast du schon einmal dein WLAN-Access-Point/Router als Fehlerquelle ausgeschlossen, wenn es dort ebenfalls nicht funktioniert und du siehst, ob sich deine Anlage darauf verbunden hat. ... Mehr anzeigen

Mich würde interessieren, ob das Problem bei den anderen (außer cmenschel) weiterhin besteht.   Ich habe gestern aus Verzweiflung bei meiner Heizung (Vitodens 300-W B3HG-19) die Freigabe für automatische Updates erteilt, bisher ist noch nichts passiert. Die Updates sollen aber schrittweise erfolgen, und ob das ohne stabile Backend-Verbindung überhaupt funktioniert, ist fraglich. @ReneF: Das Service-Passwort schaltet nur das Servicemenü frei, dort kannst du unter "Erkannte Geräte" die Softwarestände der Module (TCU, HMU/HPMU, HMI ...) einsehen und Diagnose/Parameter machen. Das Kommunikationsmodul (TCU) nennt sich bei mir "Backend-Gateway" und hat die SW-Version 19.506.2307.7, HW-Version 19.1.0.0. Aufspielen kannst du damit nichts. Interessant wäre, welche SW-Version bei @cmenschel dort nun nach dem Update steht.   Updates gehen nur auf zwei Wegen: Remote-Update / automatisches Update durch Viessmann, mit der Voraussetzung, dass die Freigabe in der ViCare-App erteilt wurde und die Anlage vermutlich auch eine funktionierende Verbindung zum Viessmann-Backend benötigt. Das Update wird normalerweise schrittweise ausgerollt. Vor Ort durch den Fachbetrieb per ViGuide-App.   Das Henne-Ei-Problem: Ohne Backend-Verbindung dürfte auch kein Firmware-Update ankommen. Das könnte erklären, warum es bei @cmenschel den Techniker brauchte.   Zur Versionsfrage: Eine offizielle Versionsübersicht für Endkunden gibt es leider nicht (von Viessmann so bestätigt). Es gibt aber Release Notes in den "Serviceanleitungen für die Fachkraft". Welche Version bei @cmenschel nach dem Technikerbesuch installiert ist, kann nur er selbst sagen (siehe Servicemenü → "Erkannte Geräte" → TCU / Backend-Gateway). ... Mehr anzeigen

Das bestärkt meinen Verdacht. Bei mir sind automatische Updates NICHT aktiviert, die Firmware dürfte ca. 2 Jahre alt sein. Ich schließe mich deiner Meinung an: Ein Backend-Update, das ältere Firmware-Versionen einfach abkoppelt, ohne die betroffenen Kunden vorher zu informieren, geht gar nicht. Viessmann weiß serverseitig genau, welche Anlagen mit welchem Softwarestand unterwegs sind – eine Warnung an die Betroffenen wäre technisch trivial gewesen. Offene Frage an @Viessmann: Kann bei betroffenen Anlagen ein automatisches Update erfolgen, oder ist dafür zwingend ein Techniker nötig? Automatische-Updates setzen laut Viessmann eine dauerhafte Internetverbindung voraus – genau die ist bei uns ja gestört. Das wäre dann ein Henne-Ei-Problem, das nur der Einsatz vor Ort löst. ... Mehr anzeigen

Kurzes Update von mir: Die Resonanz in diesem Thread ist bisher erstaunlich gering. Bei früheren Störungen war das anders. Entweder bemerken es wegen der Jahreszeit noch viele nicht (keine Heizsaison), oder es sind tatsächlich nur wenige Anlagen betroffen. Gestern (22.08.) gegen Mittag bekam ich für kurze Zeit wieder aktuelle Werte von der Anlage, danach wieder Stillstand. Das spricht dafür, dass an der Störung gearbeitet wird, oder es hat einen anderen technischen Grund. Rückfrage an die anderen Betroffenen: Wechselt bei euch im Servicemenü die Backend-Verbindung auch ständig zwischen "Verbunden" und "Nicht aktiv"? Und wird 2–5 Minuten danach die WLAN-Verbindung getrennt und neu aufgebaut? Dieses Muster läuft hier seit Tagen durchgehend. Wenn das bei euch genauso ist, wäre das ein weiterer Hinweis auf ein serverseitiges Problem. Off-Topic: Mich stört ebenfalls, wie schlecht Viessmann kommuniziert. Mit dem heutigen Wissen würde ich mich für einen anderen Hersteller entscheiden. Allein dass es nur die Cloud-API gibt und keinen lokalen Direktzugriff (z. B. für Home Assistant), ist ein Ärgernis – bei lokalem Zugriff wären einem Störungen bei Viessmann schlicht egal. Aber das ist nun mal deren Geschäftsmodell, das ich bei der nächsten Kaufentscheidung so nicht mehr unterstützen werde. ... Mehr anzeigen

Hallo zusammen, ich kann das Problem bestätigen und ergänze ein paar Beobachtungen, die auf ein serverseitiges Problem hindeuten: Seit dem 20.08.2026 werden bei mir weder in der ViCare-App noch über die API Werte aktualisiert. Eine Störungsmeldung in der App habe ich NICHT.   Auffällig ist der Verbindungsstatus: Im Servicemenü der Heizung wechselt die Backend-Verbindung ständig zwischen "Verbunden" und "Nicht aktiv". Die WLAN-/Netzwerkverbindung selbst ist stabil.   Ich greife zusätzlich per Python auf die API zu. Dort sehe ich, dass die Zeitstempel der Datenpunkte exakt im Rhythmus des Backend-Toggels aktualisiert werden – die Werte selbst ändern sich aber nicht. Es sieht so aus, als würde die Verbindung kurz aufgebaut, ohne dass tatsächlich Daten übertragen werden. Einzige Ausnahme: Nach einem kompletten Neustart des Kessels (stromlos) wurde die Außentemperatur einmalig aktualisiert, danach wieder Stillstand.   Bereits erfolglos versucht: - WLAN-Access-Point gewechselt - Router neu gestartet - Kessel komplett neu gestartet   Da App und API gleichermaßen betroffen sind, die Anlage lokal einwandfrei läuft und die Zeitstempel ohne neue Werte aktualisiert werden, tippe ich auf ein Problem im Viessmann-Backend – passt auch zu den hier beschriebenen Fantasiewerten in der Analyse. @Viessmann-Team: Gibt es aktuell eine bekannte Störung oder Wartungsarbeiten? Eine kurze offizielle Info wäre hilfreich, bevor alle Betroffenen ihre eigene Hardware verdächtigen. ... Mehr anzeigen

Danke für die Info Shimmy979! Bei mir geht der schreibende Zugriff auch wieder 😀 ... Mehr anzeigen

Gleiches Problem bei mir. Ich nutze PyViCare mit einem selbst entwickelten Python-Tool zur Heizungssteuerung. Lesen funktioniert, Schreiben liefert 403. Ich hoffe sehr, dass es sich um einen technischen Fehler handelt und keine Absicht dahintersteckt – denn ich habe absichtlich den automatischen Updates nicht zugestimmt und damit auch keiner Änderung des Funktionsumfangs. Ich erwarte, die API so nutzen zu können wie zum Zeitpunkt meines Kaufs. Wer eine teure Anlage erwirbt, darf davon ausgehen, dass bestehende Funktionen nicht still und heimlich entzogen werden. ... Mehr anzeigen

Hallo Anne, bei mir läuft die ViCare-App ohne Probleme. Ich hatte sie heute Vormittag schon öfter im Einsatz, und auch jetzt kann ich alle Heizungswerte einsehen und Einstellungen direkt vornehmen. Ich gehe stark davon aus, dass Viessmann entweder schrittweise und unangekündigt Änderungen an den Servern vornimmt oder dass aktuell eine technische Störung an der Infrastruktur vorliegt.    Unkommentierte Ausfälle schaden dem Vertrauen mehr als ein offener Umgang mit Fehlern oder technischen Schwierigkeiten. Es ist besonders ärgerlich, da jeder von uns bereits einen beträchtlichen Zeitaufwand betrieben hat, um ein lokales Problem bei der eigenen Anlage auszuschließen. Viele Grüße Holger ... Mehr anzeigen

Hallo Hugo,   das habe ich heute Morgen auch bemerkt, dass es bei mir wieder läuft. Allerdings bin ich noch etwas skeptisch, da ich bereits vorgestern Probleme hatte und es dann nach kurzer Zeit plötzlich wieder ging. Ich werde das Ganze jetzt weiter beobachten und hoffe, dass die Störung nicht noch einmal auftritt. Viele Grüße Holger ... Mehr anzeigen

Hallo zusammen, ich schließe mich an, da ich exakt das gleiche Problem habe: Einstellungen über die ViCare-App sind unmöglich. Zudem findet keinerlei Synchronisation mehr statt; Änderungen direkt an der Heizung werden in der ViCare-App nicht übernommen – alles wirkt wie „eingefroren“. Nachdem ich erfolglos Kommunikationsmodul neu gestartet habe und mein WLAN überprüft habe, bin ich nun sicher, dass es an einer zentralen Störung liegen muss, da auch du diesen Fehler meldest. Hoffentlich wird das Problem seitens Viessmann schnell behoben! ... Mehr anzeigen