Viessmann API mit OH3 auf RPi

[nw378]

ja funktioniert im readonly Modus.
Gibt es auch einen RW Modus mit dem ich die Heizung aktiv steuern kann?

Mit Vcontrold steuer ich die Heizung, z.B. Nur Warmwasser/Heizen. auch ämdern der Heizkurve etc. ist denkbar.

Bei Interesse kann ich dir weitere Details nennen.

[chrisfetz]

Hallo!

So ganz frisch ist das Thema nicht, mal schaun ob noch jemand antwortet.
Ich bin gerade dabei, meine Viessmann Heizung mit vcontrold an mein openhab (3) anzuhängen.
Mit Viessmann binding und optolink habe ich das nicht zum Laufen bekommen.
Der zweite Anlauf ging über vcontrold und vmon. Das ging zuerst auch nicht, bis ich auf das Thema http-Authentifizierung der Rest-Api von openhab 3 gestossen bin und im vmon gefixt (bzw. erweitert) habe. Jetzt humpelt es langsam los mit den folgenden Problemen:

von meinem Windows Laptop aus verhält es sich so:
- auf der Shell sind einige Sonderzeichen verhauen (zB. °C)
- die Werte erscheinen im openHab korrekt

lasse ich vmon auf dem selben rpi3 laufen wie vcontrold (und wo auch der usb-Adapter an der Heizung hängt), sieht es so aus:
- auf der Shell sind die Sonderzeichen korrekt
- openHab antwortet mit dem Status 400
- die Namensauflösung hat irgendein Problem, es funktioniert bisher nur mit Angabe der ip auf dem rapsi, das könte aber auch an adguard home liegen. Der scheint noch mehr Probleme zu haben in einer gemischten Umgebung mit IPv4/v6 von Linux/Android-Systemen aus.

Weiß jemand:
welche Zeichenkodierung vcontrold ausgiebt (bzw. vielleicht direkt die Heizung)?
welche Zeichenkodierung openhab erwartet?
was java intern macht, muss ich auch noch rausfinden, das sollte sich aber finden. Ist etwas her, dass ich java zuletzt angefasst habe.

Und dann hat die USB-Anbindung von vcontrold noch ein Problem. Im dmesg sehe ich immer wieder Meldungen, dass die Verbindung zum UART mit Fehler abgerissen ist. Kurz darauf meldet er sich unter anderem device manchmal wieder.

@nw378: ich sehe gerade, Deine Lösung basiert auch auf openhab 3 - kannst Du bitte mal grob skizieren, welche Komponenten wie zusammen arbeiten?

Viele Grüße,
Christoph

P.S.: mein modifizierter vMon findet sich hier: https://github.com/chriskloe/vMon
und hier: https://github.com/openv/openv/wiki/openHab-Integration habe ich ein paar Ergänzungen eingearbeitet

[udo1toni]

openHAB arbeitet mit UTF-8, gewöhnlich ist natürlich de_DE.utf8 auf dem Raspberry gesetzt. Bei vcontrold muss ich passen.

[nw378]

Wenn vcontrold läuft, kannst du mittels exec-Binding direkt in openHAB einlesen, z. B.:

Code: Alles auswählen

Thing exec:command:getHeizungsdaten "Viessmann Heizungsdaten"      [command="vclient -h 192.168.178.60:3002 -c getSolarLeistung, getBetriebArtM2, getTempA, getBrennerStunden1, getTempWWist, getTempWWsoll, getTempKist, getTempKsoll, getTempAbgas, getBrennerStarts, getLeistungIst, getNeigungM2, getNiveauM2, getTempVListM2, getTempKol, getTempSpu, getPumpeStatusM2, getPumpeDrehzahlM2, getPumpeStatusSolar, getPumpeDrehzahlSolar, getError0, getBrennerStatus, getTempVLsollM2", interval=120, timeout=20]

Ausgabe im Logfile sieht dann so aus:

Code: Alles auswählen

2022-11-11 15:53:52.219 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Heizungsdaten' changed from getSolarLeistung:
23592.000000 
getBetriebArtM2:
H+WW
getTempA:
14.400000 Grad Celsius
getBrennerStunden1:
5012.066895 Stunden
getTempWWist:
58.900002 Grad Celsius
getTempWWsoll:
60.000000 Grad Celsius
getTempKist:
48.299999 Grad Celsius
getTempKsoll:
34.400002 Grad Celsius
getTempAbgas:
41.000000 Grad Celsius
getBrennerStarts:
6233.000000 
getLeistungIst:
0.000000 %
getNeigungM2:
0.200000 
getNiveauM2:
2.000000 
getTempVListM2:
26.000000 Grad Celsius
getTempKol:
52.599998 Grad Celsius
getTempSpu:
43.799999 Grad Celsius
getPumpeStatusM2:
1
getPumpeDrehzahlM2:
47.000000 %
getPumpeStatusSolar:
1
getPumpeDrehzahlSolar:
0.000000 %
getError0:
Mi,14.09.2022 15:25:21 UNKNOWN (80)
getBrennerStatus:
0
getTempVLsollM2:
26.400000 Grad Celsius to getSolarLeistung:
23592.000000 
getBetriebArtM2:
H+WW
getTempA:
14.300000 Grad Celsius
getBrennerStunden1:
5012.066895 Stunden
getTempWWist:
58.900002 Grad Celsius
getTempWWsoll:
60.000000 Grad Celsius
getTempKist:
48.299999 Grad Celsius
getTempKsoll:
34.400002 Grad Celsius
getTempAbgas:
39.299999 Grad Celsius
getBrennerStarts:
6233.000000 
getLeistungIst:
0.000000 %
getNeigungM2:
0.200000 
getNiveauM2:
2.000000 
getTempVListM2:
26.000000 Grad Celsius
getTempKol:
53.200001 Grad Celsius
getTempSpu:
43.900002 Grad Celsius
getPumpeStatusM2:
1
getPumpeDrehzahlM2:
47.000000 %
getPumpeStatusSolar:
1
getPumpeDrehzahlSolar:
0.000000 %
getError0:
Mi,14.09.2022 15:25:21 UNKNOWN (80)
getBrennerStatus:
0
getTempVLsollM2:
26.400000 Grad Celsius

Diesen String zerlege ich dann zeilenweise und habe so meine Daten.
Kommandos an die Heizung lassen sich so übrigens auch senden, also Wechsel der Betriebsart o. ä.

[udo1toni]

Ich möchte empfehlen, den Output auf json umzustellen.

Ich habe ja auch eine Viessmann Heizung, mich aber bisher noch gar nicht damit beschäftigt. Aber der vclient kennt auch die Option -J, welche die Antwort als JSON Objekt ausliefert. In openHAB lässt sich das dann leicht über JSONPath in die Einzelwerte zerlegen.

[tomtom97]

Hallo allerseits,

ich habe das ganze hier nur mit vcontrold gelöst:

Ein Cronjob auf dem Heizungs-RasPi wird alle 5min ausgeführt:

Code: Alles auswählen

2,7,12,17,22,27,32,37,42,47,52,57 * * * * /usr/local/bin/vclient -h localhost -p 3002 -f /home/pi/mqtt/vito-commands.txt -t /home/pi/mqtt/mqtt-update-heating.tmpl -x /home/pi/mqtt/update_heating.sh

Dieser führt die Kommandos aus der vito-commands.txt aus:

Code: Alles auswählen

gettempA
gettempWW
getbrennstarts
gettempKessel
gettempVLM2
getbaktpower
getBrennerStunden1
getkwhSol
getSolarStunden
gettempKoll
gettempWWSol
unit off
getspldpump
gethkpumpM2
getsolarpump
getBetriebartM2
getBetriebartA1M1
getsammelstoer
getPartybetriebM2
getPartybetriebA1M1

Füllt mit den Rückgabewerten das Template mqtt-update-heating.tmpl :

Code: Alles auswählen

#!/bin/sh
MQTTHOST=<IP-Adresse-des-MQTT-BrokersA
MQTTPORT=<POrt-des-MQTT-Brokers>
MQTTUSER=<MQTT-Benutzername>
MQTTPASS="<MQTT-Passwort>"

mosquitto_pub -h ${MQTTHOST} -p ${MQTTPORT} -u ${MQTTUSER} -P ${MQTTPASS} -t heating/$C1 -m $1
mosquitto_pub -h ${MQTTHOST} -p ${MQTTPORT} -u ${MQTTUSER} -P ${MQTTPASS} -t heating/aussentemperatur -m $1
mosquitto_pub -h ${MQTTHOST} -p ${MQTTPORT} -u ${MQTTUSER} -P ${MQTTPASS} -t heating/$C2 -m $2
mosquitto_pub -h ${MQTTHOST} -p ${MQTTPORT} -u ${MQTTUSER} -P ${MQTTPASS} -t heating/warmwassertemperatur -m $2
mosquitto_pub -h ${MQTTHOST} -p ${MQTTPORT} -u ${MQTTUSER} -P ${MQTTPASS} -t heating/$C3 -m $3
mosquitto_pub -h ${MQTTHOST} -p ${MQTTPORT} -u ${MQTTUSER} -P ${MQTTPASS} -t heating/brennerstarts -m $3
mosquitto_pub -h ${MQTTHOST} -p ${MQTTPORT} -u ${MQTTUSER} -P ${MQTTPASS} -t heating/$C4 -m $4
mosquitto_pub -h ${MQTTHOST} -p ${MQTTPORT} -u ${MQTTUSER} -P ${MQTTPASS} -t heating/kesseltemperatur -m $4
mosquitto_pub -h ${MQTTHOST} -p ${MQTTPORT} -u ${MQTTUSER} -P ${MQTTPASS} -t heating/$C5 -m $5
mosquitto_pub -h ${MQTTHOST} -p ${MQTTPORT} -u ${MQTTUSER} -P ${MQTTPASS} -t heating/heizkreisM2/vorlauftemperatur -m $5
mosquitto_pub -h ${MQTTHOST} -p ${MQTTPORT} -u ${MQTTUSER} -P ${MQTTPASS} -t heating/$C6 -m $6
mosquitto_pub -h ${MQTTHOST} -p ${MQTTPORT} -u ${MQTTUSER} -P ${MQTTPASS} -t heating/brenner/leistung -m $6
mosquitto_pub -h ${MQTTHOST} -p ${MQTTPORT} -u ${MQTTUSER} -P ${MQTTPASS} -t heating/$C7 -m $7
mosquitto_pub -h ${MQTTHOST} -p ${MQTTPORT} -u ${MQTTUSER} -P ${MQTTPASS} -t heating/brenner/stunden -m $7
...

und erstellt daraus das Shellscript update_heating.sh, welches im Anschluss ausgeführt wird.

Damit hat man alle Meßwerte der Heizung im MQTT verfügbar und kann sie vom openHAB auswerten/anzeigen/als Diagramm darstellen lassen.

Die Steuerung der Heizung über openHAB nimmt dann einen anderen weg: Wie oben schon erwähnt über das exec Plugin direkt auf dem openHAB-Server.

Viele Grüße

Thomas

[tomtom97]

Gleich noch was dazu:

Und dann hat die USB-Anbindung von vcontrold noch ein Problem. Im dmesg sehe ich immer wieder Meldungen, dass die Verbindung zum UART mit Fehler abgerissen ist. Kurz darauf meldet er sich unter anderem device manchmal wieder.

Das wechselnde Device bekommt man mit einer udev-Regel weg:

Lege eine Datei /etc/udev/rules.d/70-lesekopf.rules mit folgendem Inhalt an:

Code: Alles auswählen

SUBSYSTEM=="tty", ATTRS{product}=="FT232R USB UART", ATTRS{serial}=="A800xxxx",SYMLINK+="vitoir0"

Anstelle "A800xxxx" ist natürlich die Seriennummer Deines USB-Adpaters einzutragen.
Dann findest Du den USB-Adapter immer unter /dev/vitoir0

Viele Grüße

Thomas

[udo1toni]

Ich habe mich nun ein wenig mit der Materie auseinandergesetzt. Leider (oder vielleicht auch gut so) kann ich vcontrold nicht verwenden, mein Gerät ist zu neu und hat eine Anbindung über ein WLAN Modul.
Leider kann man die Daten nicht lokal abgreifen, sondern muss über die Klaut gehen. Wobei ich ja noch nachvollziehen kann, dass eine lückenlose Anlagenüberwachung eben auch einen besseren Service ermöglicht, aber wäre es so schlimm, zusätzlich eine lokale API zur Verfügung zu stellen, wo ich schon die Internetleitung kostenfrei zur Verfügung stelle?
Nun gut...

API-Zugang hatte ich offensichtlich schon eingerichtet (vielleicht im Rahmen der ViCare App?), API Key allerdings noch nicht erzeugt.
Gut, Doku ist ja einigermaßen verständlich.
Leider klappt der Zugriff auf den redirect nicht (invalid redirect uri, obwohl 1:1 aus der setup-Seite rauskopiert), aber ein Blick in den Seitenquelltext verrät, welche Adresse beim Klick auf den Button aufgerufen wird. Also flugs die Adresse manuell aufgerufen und schon ist der API Key autorisiert (da ist wohl noch ein Bug im Code...)
Anschließend Thing (Bridge) angelegt und API Key eingetragen, sofort Online, Kessel erscheint auch umgehend.
Nächster Hemmschuh: Man kann über die UI keine Links erzeugen, egal was man anklickt, es kommt immer eine Fehlermeldung, dass "i" ungültig sei.
Aber ich habe ja VSCode und kann mir dort eine Textdatei erzeugen. Nun gut, fast, denn aus irgendeinem Grund bekommt VSCode nicht mit, welche Itemtypen erzeugt werden sollen.
Findige openHABler können aber Textdateien anhand der Channel Links sortieren (nein, manuell...) und so die fehlenden Schlüsselworte nachtragen.
Lohn der Mühe: diverse Daten aus der Heizungsanlage.

Witzig: in VSCode werden wesentlich mehr Channel angezeigt als in der UI (es gibt keine Schaltfläche "Show Advanced" wie in anderen Bindings).
Also, da ist noch jede Menge Luft nach oben aber ich muss sagen, wenn es mal läuft...

Wird langsam Zeit, dass ich mal ernsthaft versuche, mein Produktivsystem auf OH3.4 zu heben.

[chrisfetz]

Sorry für die Verzögerung, ich war mal wieder auf Reisen.
Über welche Schnittstelle die Heizung angesprochen wird hat fast nichts mit dem Alter der Heizung zu tun. Eher damit, ob Dir der GWS-Installateur Deiner Wahl die vitoconnect aufgeschwa^Wangedreh^Wverkau^Weingebaut hat.
Hintergrund ist der: alle Heizungen haben eine IR-basierte Schnittstelle. Nach der Idee von Viessmann dockt dort das Modul vitoconnect an, das praktisch ein gutes altes Fernwartungsmodul ist und sich per wlan und Internet bei Viessmann meldet.
Nun gibt es auch einfache USB-Adapter die per RS232 über USB an IR mit der Heizung reden. Eine Softwarelösung, um dort anzudocken heißt vcontrold. Dann gibt es noch eine cloud-Lösung, wo man seine an Viesmann geschickten Daten wieder bei Viessman abholt.
Da bei mir vitoconnect nicht verbaut ist, gehe ich da den direkten Weg.

Ich mach mich dann mal dran und übersetze vlient noch auf dem server, dann gibt es die udev-Regel und dann schaun wir mal, wie es mit den Daten dann weiter geht. Vielen Dank für die Inspiration!

Viele Grüße,
Christoph

[udo1toni]

Ja, aber Nein.

Die Schnittstelle ist belegt, da steckt ein Adapter drauf, dessen Kabel in das Gerät geführt ist. Ich nehme mal an, dass die Vitoconnect auch dort andockt. Der Servicetechniker kann dann die Schnittstelle temporär abziehen (das könnte ich auch, aber eben nicht dauerhaft...).