ViCare Die Anwendung hat die Anfrage zur Auswahl eines Gerätes abgebrochen. VITODENS 200-W B2HF-24

[adevw]

Hallo,

ich habe ein ViCare Verbindungsproblem.

ViCare verbindet sich zwar mit der Anlage aber bricht dann mit einer Fehlermeldung ab.

Die angehängten Bilder zeigen das Problem.

App neu installieren und anderes Handy verwenden sind erfolglose Lösungsversuche.

Die Anlage ist bei www.viessmann.de/registrierung angemeldet.

    

Was ist zu tun?

Danke für hilfreiche Vorschläge.

[CustomerCareChris]

Hallo adevw,

bitte entschuldige, dass ich dich nicht weiter auf dem Laufenden gehalten hatte.

In der Tat scheint der Fix nicht zu funktionieren, unsere Entwicklung hat das Ticket TVC-1333 wieder aufgenommen und sucht nach der richtigen Lösung.

Besten Gruß

[adevw]

Hallo Chris,

tickt das Ticket TVC-1333 noch oder hat die Entwicklung aufgegeben?

Viele Grüße

adevw

[adevw]

Hallo Chris,

Problem gelöst, aber  wie und mit welcher APP ?

Eine Antwort wäre nett.

Mit freundlichen Grüßen

adevw

[philippraffael]

Hallo,

da ich selbst von Beruf Programmierer bin und das Problem auch bei meiner Vitodens 200W seit Anfang an auftritt, hab ich die letzten Tage mal intensiv die Kommunikation der Vicare-App mit der Heizanlage durchforstet.

Daraufhin habe ich eine Android-App gebastelt, welche sich per DoIP mit der Vitodens verbindet. Das sollte soweit auch klappen.... tut es aber nicht. Auf die "Routing Activation Request" - also die erste Begrüßungsnachricht - reagiert die Heizanlage nicht.

Für mich sieht es ganz danach aus, dass die Vitodens (zumindest bei mir) eine inkorrekte Firmware hat, welche nicht richtig mit dem DoIP Protokoll umgehen kann. Das würde aber bedeuten: Ein reines ViCare App-Update kann das Problem gar nicht fixen, so wie es hier im Thread andauernd dargestellt wird. Es handelt sich wohl eher um ein serienmäßiges Problem der Anlagen..

Grüße,

Philipp

[gnarf]

Hi @philippraffael

ich sitze gerade auch dran mir die Kommunikation genauer anzuschauen und dachte ich teile einfach mal meine Erkenntnisse. Bei meiner Anlage kann ich ebenfalls mit dem Web-Browser auf die 192.168.0.1 zugreifen und bekomme die Lizenztexte von der Anlage übertragen. Grundlegend funktioniert also schonmal ein TCP/IP Stack. Dann habe ich mal die WLAN Kommunikation mitgeschnitten und unbeantwortete DoIP Vehicle identification requests von der App gesehen. So weit warst du wohl auch schon.

Daraufhin habe ich mit Python ein simples Skript geschrieben, um selber ein Vehicle Identification Request abzusetzen:

from doipclient import DoIPClient

address, announcement = DoIPClient.get_entity()
logical_address = announcement.logical_address
ip, port = address
print(ip, port, logical_address)

Antwort:
> /bin/python /tmp/doip-test2.py
192.168.0.1 13400 291

Die Kiste antwortet also auf meine Anfrage mit der logischen Adresse 291 (in Hex 0x0123). VIN ist 7956241202006127, EID und GID sind in der Antwort beide auf 0x0. Wenn ich das Gerät nach einem "Entity Status" frage bekomme ich allerdings ein NACK mit unknown payload type 0x01. Ich kenne mich leider zu wenig mit DoIP aus, um hier weiter zu machen.

Ich habe aus Interesse auch mal die ViGuide App installiert (das Kommissionierungstool für den Installateur). Wenn man in den Service-Modus geht (Menü + OK für 4 Sekunden drücken) und dort die Kommissionierung neu startet kann sich diese App tatsächlich mit dem Gerät verbinden! Ich kann darüber auch verschiedene Heizparameter einstellen, nur das Verbinden mit meinem WLAN ist dort keine Option. Ist aber auch wenig überraschend, das ist macht ja der Anlagenbetreiber, nicht der Installateur. Aber vielleicht gibt es andere Wege, um durch den Kommissionierungsprozess das Problem zu beheben.

Schreib gerne wenn du Weiteres herausfindest. Das Thema juckt mich schon ein wenig.

Grüße
Jan

[gnarf]

Ah, ich bin gerade über das open3e Projekt auf github gestoßen. Damit kann man über DoIP verschiedene Systemparameter auslesen und schreiben. Hier als Beispiel 0x284 (MixerOneCircuitFlowTemperatureSensor) und 0x604 (GatewayApDataSet):

> open3e -d 192.168.0.1 --ecuaddr 0x123 -r 284
Configuration file devices.json not found, continuing with generic DID list, ECU 0x123
{"Actual": 76.8, "Minimum": 35.5, "Maximum": 81.7, "Average": 49.0, "Unknown": 0}

❯ open3e -d 192.168.0.1 --ecuaddr 0x123 -r 604
Configuration file devices.json not found, continuing with generic DID list, ECU 0x123
{"SSID_AccessPoint": "Viessmann-7221", "Password_AccessPoint": "--MEIN-AP-PASSWORT--", "IP-Address_AccessPoint": "192.168.000.001"}

Offensichtlich lässt sich die Kiste also korrekt ansprechen. Ich kann auch Register beschreiben, wie zB die Zieltemperatur für Warmwasser. Es gibt auch ein Register 0x617: GatewayRemoteSsid, in das habe ich mal versucht den Namen meines WLANs reinzuschreiben, aber erhalte hier einen Error "ConditionsNotCorrect". Ich vermute für das Konfigurieren des WLANs muss man anders vorgehen, vielleicht ist der Modus falsch oder Register müssen in einer anderen Reihenfolge beschrieben werden etc.

Ich habe also weiterhin die Hoffnung, dass das Problem auf der Seite der App sitzt. @CustomerCareChris es wäre schön, wenn man hier mehr Infos von offizieller Seite bekommt. Ich kann bei Interesse auch gerne direkt mit den Entwicklern reden und gemeinsam das Problem debuggen. So wie es aussieht besteht das Problem ja bereits seit geraumer Zeit und die Kommunikation ist leider eher dürftig. Und falls ihr Unterstützung benötigt: Ich mache beruflich embedded Entwicklung für Industriekunden, meine Kollegen und ich kennen uns bei Home Automation auch recht gut aus 😉

[philippraffael]

Hi @gnarf ,

mit open3e direkt hatte ichs aufgrund der Entfernung von PC <-> Anlage noch nicht probiert.

Hab mal meinen Laptop rausgewühlt und es ausprobiert. Du hast Recht! Die Anlage lässt sich ansprechen.

Es ist sinnvoll erstmal ein "open3e_depictSystem -d 192.168.0.1" auszuführen, damit alle Datenendpunkte geladen werden.

Anschließend kann man über "open3e -d 192.168.0.1 -r 619" die Anlage zu einem WLAN-Scan zwingen.

Die gefundenen SSIDs kann man dann über die Endpunkte 1233 bis 1237 im Hexformat abgreifen (z.B. "open3e -d 192.168.0.1 -r 1233").

Der Name meines WLANs ist "Hahn", was in HEX 4861686E entspricht.

Um der Anlage die Verbindungs-SSID mitzuteilen, wird auf den Endpunkt 617 geschrieben. Der Wert muss genau 72 Stellen haben. Heißt: Man nimmt die SSID und füllt die restlichen Stellen mit Null-Bytes. In meinem Fall kommt dann der Befehl "open3e -d 192.168.0.1 -raw -w 617=4861686E0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000" raus.
Wenige Sekunden nach Ausführung zeigt das Display der Anlage an, dass eine Verbindung hergestellt wird. Die Verbindung wird dann aber wegen fehlendem WLAN-Passwort abgebrochen.

Vielleicht kann man ja noch rausfinden, wie man der Anlage das Passwort mitteilt.

LG

[philippraffael]

Ok habs raus.

Um das WLAN einzurichten muss man folgendes tun:

1. SSID in HEX umwandeln und mit Nullen auffüllen, bis 64 Zeichen erreicht sind

2. WLAN-Passwort in HEX umwandeln und mit Nullen auffüllen, bis 80 Zeichen erreicht sind.

3. Die beiden Zeichenketten aneinanderreihen

4. open3e -d 192.168.0.1 -raw -w 617=[Zeichenkette] ausführen

Die Zeichenkette sieht dann ungefähr so aus (Passwortteil unterstrichen):

574C414E2D4E616D650000000000000000000000000000000000000000000000574C414E2D50617373776F7274000000000000000000000000000000000000000000000000000000

Mit diesen Schritten taucht die Anlage bei mir als "0019-wifi" in der Fritzbox auf.

Ein Problem besteht aber weiterhin: Die Anlage will sich mit Viessmann-Servern verbinden, schafft das nicht und kappt die WLAN-Verbindung nach wenigen Sekunden wieder.

[gnarf]

Hey @philippraffael , danke für den Input! Das hilft mir sehr weiter.

Ich bin noch eine Stückchen weiter gekommen: In dem String für den Gateway-Namen muss ebenfall das Passwort stehen. Die ersten 36 Zeichen sind für die SSID, die letzten 20 sind für das Passwort. Darauf bin ich gekommen nachdem ich in anderen Posts laß, dass das Passwörter länger als 20 Zeichen nicht funktionieren 😄

Hier als Python Einzeiler, um den korrekten String zu erhalten:
print("MeinWLAN".encode('utf-8').hex().ljust(36*2, '0') + "MainPasswort".encode('utf-8').hex().ljust(20*2, '0'))

Damit taucht die Heizung in meinem Router auf, zwar ohne leserlichen Hostname und eine IP-Adresse holt sie sich auch nicht, aber die MAC ist von Viessmann. Vielleicht muss man vorher den Endpunkt 607 "GatewayRemoteIP" mit einer korrekten Config füllen oder DHCP aktivieren? Jedenfalls fehlt noch das letzte Stücken. Mir zeigt der Schirm auch den Fehler E12: "Verbindung zum Server konnte nicht hergestellt werden", was für fehlende Netzwerk-Config spricht.

[gnarf]

Ah Verzeihung, da hab ich mich vertan: Die ersten 52 Zeichen sind die SSID, danach kommen 20 Zeichen Passwort. Der Code ist entsprechend:
print("MeinWLAN".encode('utf-8').hex().ljust(52*2, '0') + "MainPasswort".encode('utf-8').hex().ljust(20*2, '0'))

[gnarf]

Oh, ich hätte mal neu laden müssen. Dann hätte ich gesehen, dass du auch drauf gekommen bist, dass SSID und Passwort im gleichen Feld sind. Wobei bei dir der Offset des Passworts anders ist.

Ich musste bei mir noch das Feld 618: "RemoteGatewayStaticIP" von 1 auf 0 setzen, damit das System sich eine dynamische IP holt und mit dem Router verbunden bleibt. Womöglich hab ich das auch zuvor beim Ausprobieren verstellt. Jetzt ist allerdings der Port für DoIP nicht mehr offen wie zuvor über den access point 😞

[philippraffael]

DoIP funktioniert wohl wirklich nur im AP-Modus.

Ich hab mit Wireshark mal den Netzwerktraffic der Anlage ins/vom Internet mitgelesen. Es werden Anfragen nach mgmt.viessmann-platform.io gemacht. 

(192.168.178.45 ist die Anlage)

Bin jetzt kein Wireshark Profi, aber die Meldung TLSv1.2 "Alert (Level: Fatal, Description: Unknown CA)" klingt für mich nach nem Zertifikatsproblem.

Mehr kann ich dem ganzen Traffic auch nicht entnehmen 😞

[gnarf]

Das Problem könnte sich aber mit etwas Glück von alleine lösen. Für TLS braucht es auf beiden Seiten Root Zertifikate, die für ein paar Jahre gültig sind. Ich hatte es schon ein paar Mal, dass ein Gerät welches lange Zeit nicht im Internet hing veraltete Root Zertifikate hatte und sich überhaupt nicht mehr verbinden ließ. Hier im Forum laß man auch öfter, dass man bei Server-Fehler E12 zwei bis drei Stunden das Gerät im Netz hängen lassen soll und es dann geht. Vielleicht holt sich die Anlage also nach einer gewissen Zeit die neuen Zertifikate, so kenne ich es zumindest von embedded Linux Geräten.

[gnarf]

Bei mir läuft's jetzt! Ich habe nach circa zwei Stunden gemerkt, dass die Anlage nicht mehr im lokalen Netzwerk hing. Also habe ich wieder die Kopplung gestartet, um über den Access Point Zugriff zu bekommen. Zuerst war ich verwirrt, denn nun konnte ich nicht mehr wie zuvor mittels open3e Endpunkte lesen oder schreiben. Dann habe ich aber die App geöffnet und sie konnte meine Heizung sofort erkennen und in's Netzwerk einhängen!
Mir scheint also, dass der Fehler behebbar ist und man den Prozess zum Reparieren bestimmt auch in der App automatisieren könnte. Für diejenigen, die den umständlichen manuellen Weg ausprobieren wollen:
1. Kopplung an der Anlage starten (3 Sekunden die "OK"-Taste drücken) und einen PC mit dem Viessmann Access Point verbinden
2. Mittels open3e manuell im Endpunkt 0x618 die Zugangsdaten für das WLAN eintragen

3. Anlage für einige Zeit im heimischen WLAN verweilen lassen

4. Kopplung erneut durchführen und die ViCare App verwenden

[philippraffael]

Tatsächlich! Ich hab die Anlage über Nacht im WLAN gelassen und konnte heute früh die Einrichtung mit ViCare durchführen.

Nach langem Warten kann die Anlage endlich in mein HomeAssistant integriert werden 🥳

[ollie307]

Mega! 🙂 Danke für's reingraben und die anschließende Beschreibung. Hat einwandfrei funktioniert und meine Anlage ist nun erreichbar! 👍🏼

[extirpate]

Toller Job. Muss ich für open3e phyton können und muss das installiert werden (firmen laptop) oder reicht irgendwie auch n Smartphone/Tablet?

Edit: Hab mir github durchgelesen. Mit Windows komm ich da wohl nicht weit.

[philippraffael]

Hi @extirpate ,

per Tablet oder Smartphone geht es momentan noch nicht.

Mit Windows gehts so:
- Aus dem Microsoft Store oder von woanders Python installieren (evtl. PC-Neustart erforderlich)

- pip install git+https://github.com/open3e/open3e.git ausführen, um open3e zu installieren

Danach solltest du die open3e Befehle ausführen können 😄

Viel Erfolg!

[brueggz]

Hi zusammen,

ich hab das alles so gemacht und die Vitodens 200-W versucht sich mit dem WLAN zu verbinden, scheitert aber nach kurzer Zeit mit einem E10 Fehler. Im Fritz Box Portal steht auch die korrekte Mac-Adresse bei gescheiterten Verbindungsversuchen. Ich habe sie dann manuell als Gerät zugefügt um die Portfreigaben zu erzeugen:

Die nötigen Portfreigaben in Fritz Box angelegt:

Habe das Ganze auch mit deaktiviertem 5Ghz Funkkanal probiert (also nur 2,4Ghz aktiv).

Und ich habe open3e -d 192.168.0.1 -w 618=0  genauso wie open3e -d 192.168.0.1 -w 618=1 probiert.

Trotz mehrfach geprüften korrekten WLAN Namens und PW for Hexa-Konvertierung per Python funzt es leider nicht:

Habt ihr noch Ideen?

Woanders habe ich gelesen, dass jemand sein WLAN Modul hat austauschen lassen und es danach ohne Probleme funktionierte - wäre nach Ablauf der Garantie aber vermutlich auf eigene Kosten?!...

Vielen Dank schon mal und bereits für die mega Lösungsanalyse!!

[dozi84]

@brueggz 

Hatte das gleiche Problem. Half alles nichts, musste ein Gäste-WLAN anlegen ohne Passwort und dieses per open3e konfigurieren. Danach tauchte auch die Anlage in der Fritzbox auf. Nach 90 Minuten hat sich auch der Hostname in der Fritzbox zu "Viessmannxx" geändert. Im Anschluss konnte ich über die App das richtige WLAN konfigurieren und die Heizung online nehmen.

Die Wartezeit ist wohl nötig, um die abgelaufenen Zertifikate usw. zu aktualisieren.

Viele Grüße,

dozi

[brueggz]

Yes, so hat es endlich geklappt (nach 3-4h erst und laut Fritz Box Upload im einstelligen kbit/s Bereich, der mich zumindest stutzig machte, ob es überhaupt laufen wird).

Vielen Dank allen Lösungsfindern!!! ❤️

[oej1991]

Ich möchte  mich hier auch einmal ganz herzlich bei gnarf und den anderen fleißigen Usern bedanken, die durch die ganze Tüftelei herausgefunden haben, wie man seinen Kessel doch noch ins Smart Home integrieren kann! Die Anleitung hat super geholfen, ich konnte die Netzwerk SSID und das dazugehörige Passwort mit den beschriebenen Befehlen an den Kessel übermitteln und nach 1-2 Stunden WLAN-Verweilzeit ließ sich der Kessel ganz normal über die ViCare-App koppeln. Starke Leistung, danke nochmal!

[JFalk]

Hallo zusammen, dank oej1991, der mich auf diesen Thread bzw. die Lösung gestoßen hat, habe ich meine Vitodens 222-F jetzt ebenfalls ins WLAN bekommen und mit der App registriert. 😁

Da hier ein paar widersprüchliche Angaben gemacht wurden (z.B. Endpunkt 617 vs. 618 und Passwort-Offset), hier mein Vorgehen:
0. Vorbereitung

Einen Laptop organisieren; Python und Git installieren; Danach open3e mittels pip in der Eingabeaufforderung/Terminal/Shell  installieren.
pip install git+https://github.com/open3e/open3e.git

1. Kopplung & Verbindung

Die Kopplung an der Anlage starten (5 Sekunden die "OK"-Taste drücken) und Laptop mit dem Viessmann Access Point verbinden (viessmann-####)

2. Mittels open3e manuell im Endpunkt 617 die Zugangsdaten für das WLAN eintragen
Bei den Zugangsdaten hat die Ausgabe folgender Zeile bei mir nicht funktioniert:
print("Mein-Gast-WLAN".encode('utf-8').hex().ljust(52*2, '0') + "Mein-WLAN-Passwort".encode('utf-8').hex().ljust(20*2, '0'))

Der Passwort-Offset scheint meiner Meinung nach nicht korrekt zu sein, ich konnte aber auch aus zeitlichen Gründen keine anderen Offsets und Kennwörter ausprobieren. 
Erst nachdem ich das Gast-WLAN ohne Passwort betrieben habe, hat der Zugriff funktioniert.
Ich habe also quasi nur das hier benutzt:
print("Mein-Gast-WLAN".encode('utf-8').hex().ljust(72*2, '0'))
open3e -d 192.168.0.1 -raw -w 617=[Zeichenkette]

3. Anlage für einige Zeit im heimischen WLAN verweilen lassen
Bei mir waren es ca. 90 Minuten. In dieser Zeit zeigt das Display unter WLAN "Verbinden Backend" an, darunter der Name des vorher übermittelten WLANs.

Ob man genug gewartet hat, ist daran erkennbar, dass die Anlage aus dem Gast-WLAN verschwindet und wieder den eigenen Access Point aufbaut.

4. Kopplung erneut durchführen und die ViCare App verwenden
Hier zeigte mir die App nach der Angabe des dauerhaften WLAN an, dass die Anlage bereits registriert sei.
Nach einem vollständigen App-Neustart wurde sie dann aber korrekt angezeigt.

Als Info: Beim Eintragen des richtigen WLANs in der App werden auch Passwörter >20 Zeichen akzeptiert.

Vielen Dank an alle, die hier zur Lösung beigetragen haben! 👏