Lokaler Datenzugriff Vitodens 200-W B2HF

[Daniel0]

Hallo,

zunächst einmal möchte ich anmerken, dass ich die Bereitstellung einer API prinzipiell sehr begrüssenswert finde. Vielen Dank dafür.

Allerdings ist die cloud-basierte Lösung für meinen Anwendungsfall (und wie ich diversen Posts entnehme, auch für viele andere) - diplomatisch ausgedrückt - "suboptimal". Ich betreibe einen Raspberry Pi zur Hausautomation, der in einem 1sek-Zyklus ein Prozessabbild aktualisiert (hauptsächlich über Modbus/TCP / Modbus/RTU Slaves) und gewisse Steuerungsaufgaben übernimmt sowie eine Visualisierung bereitstellt. In diese Steuerung / Visualisierung würde ich sehr gerne auch die Vitodens einbinden.

Ich habe eine Steuerung, die 1m von der Vitodens entfernt ist, die problemlos physischen Zugriff auf die Anlage erhalten könnte, aber ich muss mich mit auslaufenden Tokens, mit der Abhängigkeit einer funktionierenden Internetverbindung, mit einer komplett indeterministischen Antwortzeit und einem Payload/Overhead-Verhältnis von (geschätzt) 1/1000 auseinandersetzen. Das wäre eine akzeptable Lösung für eine Smartphone-Anwendung in der man alle paar Tage mal die Temperatur um 1°C herunter und später wieder herauf setzen möchte, aber nicht für eine autonome Automatisierung.

Nun ist mir aber auch klar, dass das was ich möchte nicht umsonst zu haben ist. Gerne wäre ich bereit mir ein VitoGate 300 zu kaufen. Wenn ich es richtig verstehe, kann man das VitoGate allerdings nicht mit einer Vitodens 200-W B2HF verbinden, da das VitoGate nur ein LON-Bus Interface hat, die genannte Vitodens aber nicht (nur PlusBus und CAN).

Ich habe folgende Anforderungen:

- Auslesen sämtlicher Sensordaten + Status Aktoren (z.B. Pumpe an oder aus?) mind. 1/sec

- Ansteuerung WW Zirkulationspumpe

- Setzen von Sollwerten (HK Temp. / WW Temp.)

Für eine Protocol-Spec mit R/W Datenpunkten (z.B. CAN, oder Modbus/TCP) wäre ich bereit einen mittleren 3-stelligen Betrag zu zahlen + NDA, auch, wenn mir eine offene Lösung natürlich wesentlich lieber wäre.

VG Daniel

[MRM]

Hallo Daniel,

mich würde interessieren, ob Du zu deiner Frage/Kritik mal eine Antwort bekommen hast?

Die Ansicht, dass deine angedachte/geforderte Lösung nicht umsont zu haben sei, teile ich nicht: Beispielsweise schaffen es Allterco (Shelly), AVM (Fritz!) oder Philips (Hue) auch, performante cloudless-Schnittstellen bereitzustellen. Bei den hier vorliegenden Produkten tippe ich jedoch, dass ein "direktes" Anzapfen technisch gar nicht mehr möglich ist, weil der Hersteller womöglich eine fertige IoT-Middleware einsetzt (Vermutung!): Dabei verbaut der Gerätehersteller in seinen Endgeräten eine fertig eingekaufte Komponente, die die Kommunikation zu Backendservern des Geräteherstellers macht. Die "Viessmann-API" greift dann genau auf diese Backendserver zu, um die Steuerbefehle an die Geräte in den Netzwerken seiner Kunden zu senden. Wenn Du so willst, ist das eine Art "Plug and P[l|r]ay-Lösung" für Gerätehersteller, damit sie sich nicht allzusehr in die Niederungen der IT begeben müssen (Datenschutz, Kundendaten, Verschlüsselung und weitere "heiße Eisen").

Ich hatte im Jahr 2014 mal das OSRAM Lightify mit Wireshark auseinandergenommen und festgestellt, dass dort genau so ein Framework eingesetzt wurde. Konkret war das "ARRAYENT". Mittlerweile hat "ARRAYENT" das Zeitliche gesegnet. Und OSRAM Lightify folglich eben auch. So schnell wird aus "Plug and Play" eben "Plug and Pray" 😉. (Ich hatte glücklicherweise das Lightify-Zeug damals gleich wieder zurückgeschickt, weil eben die offenen und dokumentierten Schnittstellen zu den Endgeräten fehlten.)

Wie gesagt: Ob Viessmann eine solche Middleware einsetzt, kann ich nicht beurteilen. Ich bin nur gerade auf der Suche nach einer Gastherme und habe nach meinen Recherchen ein Déjà-vu.

[Daniel0]

Hallo MRM,

nein, ich habe leider keinerlei Antwort / Rückmeldung auf meine Anfrage bekommen.

Sehr bedauerlich.

Ein "direktes Anzapfen" muss möglich sein. Zwischenzeitlich habe ich dieses Gateway gefunden, das kann die Daten auch über die CAN Schnittstelle abgreifen bzw. Sollwerte vorgeben:

https://connectivity.viessmann.com/de-de/mp_rt/wago-automation-gateway.html

Mit ca. 1.300 bis 1.400€ für die es in einigen wenigen Online Shops zu finden ist, ist es zwar alles andere als günstig. U.u. wäre ich sogar trotzdem bereit, dieses Geld auszugeben, wenn mir das Gateway vollen Zugriff auf die Anlage geben würde, aber:

- Laut Datenpunktliste (die man mit viel Geduld in den hintersten Winkeln des Internets finden kann) sind die bereit gestellten Datenpunkte sehr mau. Weit weniger als das, was die Cloud-API zur Verfügung stellt. So viel Geld auszugeben und dann doch noch die Hälfte der Daten über die Claud-API abfragen zu müssen ist, naja... bescheiden...

- Ich habe es trotzdem mal angefragt, aber auch die Shops, die es vermeintlich auf Lager haben, können es aktuell nicht liefern. Ich vermute, es ist noch gar nicht verfügbar...

Die CAN Schnittstellenspezifikation freizugeben ist auf jeden Fall keine Frage des Könnens, sondern eine des Wollens.

[CaCicala]

Hallo,

für meine Anforderungen reicht mir die "Viessmann in the Middle" Cloud Lösung unseres Lieblingsheizungsherstellers. Trotzdem fände ich es auch interessant, direkt auf meine Vitodens 200W zuzugreifen um die Downtime meines cronisch unzuverlässigen WDSL-Internetproviders und die fast ebenso unzuverlässige Response der Viessmann Server zu umgehen.

Für geduldige Bastler und Programmierer gibt es Lösungen. Zum Beispiel hier: https://github.com/openv/openv/wiki

Hardwareseitig funktioniert das, indem die optische Schnittstelle im Viessmann V abgegriffen und auf USB umgesetzt wird. Allerdings würde ich das Original Optolink Kabel kaufen, anstatt hier selbst was zu löten.

Die Software setzt einiges an Linux etc. Wissen voraus ist aber beherrschbar.

Viel Spaß noch

Chris

[Daniel0]

Hallo Chris,

---

@CaCicala  schrieb:

Für geduldige Bastler und Programmierer gibt es Lösungen. Zum Beispiel hier: https://github.com/openv/openv/wiki

---

das funktioniert leider nicht (mehr), weil die neuen Steuerungen keine optische Schnittstelle mehr haben...

[CaCicala]

😔stimmt. Da hatte ich nicht drangedacht. Meine Heizung hat noch ein Vitoconnect Interface über das "V".

Die Anforderung von Ausleseintervallen <=1sekunde halte ich für "overdone". Deine Heizung ist ja keine Mondrakete. Wasser als Medium hat eine sehr hohe Inertialität, 90 oder 120 Sekundenintervalle oder noch länger reicht normalerweise. Ich mache das mit Node-Red - hat übrigens auch Interfaces zu Modbus - und in meinem Blok dokumentiert. Ob so etwas für deine Anforderungen taugt, weiß ich natürlich nicht.

Trotzdem: Weiterhin viel Spaß

Chris

[Daniel0]

Danke für deinen Hinweis auf Node-Red.

Ich habe eine Schnittstelle zur Cloud-API bereits in c/cpp mit libcurl, json parser, etc. implementiert und sie funktioniert auch. Es ist aber einfach nur wahnsinnig umständlich und die restlichen Gründe, die dagegen sprechen, wurden ja hier und auch in anderen Threads schon ausführlich aufgezählt.

Das mag Ansichtssache sein, aber ich halte 1sek Intervalle durchaus für gerechtfertig.

Beispielsweise die Solarkollekturtemperatur ändert sich innerhalb einer Minute tw. um mehr als 1°C. Dargestellt mit einer Nachkommastelle springt sie dann z.B. von 61.2C auf 62.4°C. Viel schöner wäre es, wenn sie langsam in 0.1°C Schritten ansteigen würde.

Auch der Status der Pumpen (AN/AUS) hängt immer hinterher. Ich möchte nicht, dass es 2 oder mehr Minuten dauert, bis eine Pumpe als "AN" dargestellt wird, während (wieder Beispiel Solar) die Temperatur in den Leitungen bereits rasant ansteigt...

[null]

Befasst sich jemand mit sniffing am internen Can?

Ich bin da grad dran und hab zumindest lesend einige identifiziert.

Ich benutze canusb/oem und canmonitor pro von wgsoft.

Wenn ich ausreichend viele Datenpunkte identifiziert habe, werde ich den can sniffer an meinen Linuxserver ankoppeln, um die Daten der Haussteuerung zur Verfügung zu stellen.

Ich brauch allerdings nur lesenden Zugriff. Die Heizung tut, was sie soll - die Solarsteuerung und Heizungsunterstützung braucht nur ein paar Werte und Stati.

[null]

Die externe Can-SS ist übrigens ohne das korrekte Kommunikationsprofil nutzlos - es werden keine Daten "gebroadcastet".

[Daniel0]

---

@null  schrieb:

Befasst sich jemand mit sniffing am internen Can?

Ich bin da grad dran und hab zumindest lesend einige identifiziert.

---

Hört sich interessant an 🙂

Ich hatte vor einiger Zeit mal einen CAN Transceiver  (mit abgeschaltetem Ausgangstreiber) + Logic Analyzer an den internen CAN gehängt und ein paar Daten mitgeschrieben. Habe es dann aber nicht mehr weiter verfolgt.

Wenn du schon einige Daten identifizieren konntest, werde ich wohl nochmal versuchen 😉

Guter Hinweis auch bezügl. dem Kommunikationsprofil.