OH + MQTT + Openv

On request I’m posting my solution to integrate my openv-installation into OpenHAB.

Openv is an open source interface to read/write to Viessmann boilers and heating systems.
I’ve got a Viessmann Vitodens with a vitotronic 200 interface to which I can communicate using the openv usb-optolink adapter.
more info: openv.wikispaces.com


  • raspberry pi 1 running raspbian jessie as openhab server and mqtt broker (mosquitto), ip
  • raspberry pi 2 running raspbian jessie as viessmann-interface (vcontrol as deamon as explained on the openv-website), ip
  • both connected through wifi on the same subnet

raspi 1:

getTempCollector getTempCollector getTempWWSolar getTempWW


mosquitto_pub -h -p 1883 -t heating/$C2 -m $2
mosquitto_pub -h -p 1883 -t heating/$C3 -m $3
mosquitto_pub -h -p 1883 -t heating/$C4 -m $4
mosquitto_pub -h -p 1883 -t heating/$C5 -m $5[/code]

#!/bin/sh vclient -h -f /home/pi/commands.txt -t /home/pi/update_heating.tmpl -x /home/pi/update_heating.sh
empty file

both cron.sh and update_heating.sh are made executable.

cron.sh is executed every 5 minutes using…cron.
The reason why the commands start with the getTempcollector command twice is because I saw that the adapter sometimes didn’t give any value on the first command. (as if it was not ready yet) In the template file you can see that only the second+ return values are used.

raspi 2:
mosquitto broker running listening on
openhab-cfg updated to appropriate values.

item defined asNumber Temperature_solar_collector "Temperatuur zonnecollector [%.1f °C]" <temperature> (Heating) {mqtt="<[mosquitto:heating/getTempCollector:state:default]"}

I’m currently working on a python script to have more control as vclient tends to be buggy sometimes.
The script directly talks to vcontrol on it’s telnet-like interface. python also has a mqtt-library so it will all be a bit more “readable” compared to the setup above.


Thank you, Bert.

With the help of your little tutorial I had my viessmann values in openhab within minutes…


Meanwhile, my setup has proven some reliability as it is running for a couple of months without a single problem.
However, I’m still planning in bypassing the vclient using a Python script and do some error checking. The 128°C water temperature is still present.

For another project I stumbled upon Homie for ESP8266 (and I found out it is already known in this community. Luckily, someone is already porting it to Python. Perhaps I could make a Python-home-openv script?

Anyone interested in a joint-effort? (I’m a jack of all trades and really a master of none; spare time could also be a showstopper).

1 Like

I did some improvements on my site:

  • made a small python script, executed every x minutes using cron
  • the fetched values are directly put into a InfluxDB (I want to see graphs, not values)

I’m still plannig to distribute the values using the Homie framework. But it’s already a huge step for me doing this (as I have zero experience in Python)
Boolean or text values are not implemented yet
(feel free to contribute!)

#!/usr/bin/env python
import sys
import telnetlib
import requests
import sys
import re
re_float = re.compile('([-+]?[0-9]*\.?[0-9]+)')
import decimal

#start telnet to vcontrold
tn = telnetlib.Telnet("localhost",3002)

#define commands
w, h = 3, 4;
commands = [[0 for x in range(w)] for y in range(h)] 
commands[0][0] = "TempDHW"
commands[0][1] = "getTempDHW"
commands[1][0] = "TempDHWSolar"
commands[1][1] = "getTempDHWSolar"
commands[2][0] = "TempSolarCollector"
commands[2][1] = "getTempSolarCollector"
commands[3][0] = "TempOutside"
commands[3][1] = "getTempOutside"

#InfluxDB properties
IP = "x.x.x.x"
DB = "name_of_db" 
USER = "user"
PASSWORD = "pass"

#loop through commands and save values in commands array
for x in range(0,h):
	#avoid bug in vcontrold where "ready to receive"-statement is mistaken for a real value
	#avoid 0-value if vcontrol is not ready yet (don't know where that error comes from)
	value = 128.5
	while value==128.5 or value==0.0:
		tn.write(commands[x][1] + "\n")
		value = tn.read_until("vctrld>")
		value = re_float.search(value).group(1)
		value = decimal.Decimal(value)
		commands[x][2] = round(value,1)
	#print("{}: {}".format(commands[x][0], value))

for x in range(0,h):
	v = "{} value={}".format(commands[x][0], str(commands[x][2]))
	r = requests.post("http://%s:8086/write?db=%s" %(IP, DB), auth=(USER, PASSWORD), data=v)
	if r.status_code != 204:
		print 'Failed to add point to influxdb (%d) - aborting.' %r.status_code

.From here it’s easy to adapt and extend.

Cron is set to 5 minutes:

*/5 * * * *   user python /path/to/script.py > /path/to/script.log 2>&1

(Obviously you need a working vcontrold with commands defined as stated in the script)

Hello Bert,

my experience with vcontrold and MQTT/openhab are also a bit mixed. The problem with max values (128.5°C) exists for other values (e.g. burner hours) as well. I catch them within openhab with proxy items, which I check for the max values.
In my setup I have a dedicated RasPi2 just for vcontrold and the MQTT Client. I am looking forward to get this piece of software to an ESP8266. From the high fly view it should be no problem to serve the optical Serial interface as well as doing the MQTT communication. In detail there is too less sparetime to go for this approach… and the actual system is working well…


I’m thinking the same. It would be great if the vconrold runs on an ESP. It would be even greater if my USB optolink could be used via the USB-port on my wemos D1 mini.

Meanwhile, my Python script is running on a RPI1. Mosquitto and InfluxDB (and Grafana) are also on this RPI. (Influx runs on a Pi1).
I’ve put all my smarthome devices on a separate subnet which doesn’t have Internet access. The Openhab server is on a Pi 3 on my main LAN/subnet and can access both subnets.

So many ideas, so little time…

The ESP8266 version is on it’s way. I’ve soldered the optical interface and working on the mechanical part.
For the software: I’m focussing on the “P300”-protocol as this is understood by my boiler. I’ve already managed to connect but there are still a lot of bugs and I’m even considering a complete rewrite (yeah, planning and diagramming should be done before startnig to code).
But I’m getting there.

I’m thinking to release in about a week for the first raw version, depending on spare time.

First largely untested version of the P300 protocol for ESP8266 is published.

Warning: the code is largely untested as this is a rewrite/copy-paste from the first version which worked up to a certain level.

Testing and debugging is foreseen for Wednesday.
Coding the transformation functions is also for wednesday. This should be trivial as I don’t plan to integrate the enums.

First working version is published!

I’ve made a ESP8266 using firmware depending on: Homie, my VitoWifi and a telnet-server-like printer just to see what the ESP is doing.
On the hardware side, I’ve just followed http://openv.wikispaces.com/Bauanleitung+ESP8266.

I must say, it is working flawlessly up to now.