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! 👍🏼