Binding for Viesmann Heating unit

[openhab-bot]

From metzner....@gmail.com on September 28, 2013 21:31:45

A Binding for the Viessmann KM-Bus to control an read information from a huge range of Viessmann Heating e.g. Heatpunp

Information about the Hardware, KM-Bus and a Software written in c can be found here: http://openv.wikispaces.com/ The output of the vclient looks like:

$ vclient -h 127.0.0.1:3002 -c getTempA,getTempWWist,getTempLuftVL,getStatusVerdichter,getEinschaltungen

Message from syslogd@raspberrypi at Sep 28 20:24:04 ... vito[2894]: konfiguriere serielle Schnittstelle /dev/ttyUSB0 getTempA: 17.700001 Grad Celsius getTempWWist: 49.200001 Grad Celsius getTempLuftVL: 23.299999 Grad Celsius getStatusVerdichter: 00 getEinschaltungen: 5413.000000

The example vcontrold.xml und vito.xml are attached.

Attachment: vcontrold.xml vito.xml

Original issue: http://code.google.com/p/openhab/issues/detail?id=477

[openhab-bot]

From abode...@gmail.com on September 30, 2013 01:11:09

A Java class in developement status is also existing you can find it under http://openv4j.sourceforge.net/index.html .

[openhab-bot]

From teichsta on November 05, 2013 14:53:56

Labels: To-Github

[steand]

I have the idea to connect openHAB (2) direcly to optolink (Viessmann). At time i have a native java prototype on RPI to get data from my Pellet-Heating P-300 (datalogger). Maybe it is also interesed to build a abstraktion layer for heating systems. What you think about this idea.

[kaikreuzer]

Maybe it is also interesed to build a abstraktion layer for heating systems.

What kind of structure / features would you see in such an abstraction layer?

[steand]

Each manufacturer heating and each heating system of this vendors has it own implementation of pumps, thermostats, etc. If you want to manage "smart" you need on the control plane a general definition of the actors and sensors of all heading systems. The abstraction layer should cover all vendor specific implementation. As I understand this could be realeased with smarthome/OpenHAB: For all vendor's and for all heating systems the same "Thing-Types" can be used. So it is posible to build a unified monitoring and control layer for all heating systems. In my mind OpenHAB can realized this abstraction layer: Maybe each vendor/heating systems can be impement as a independent binding, but it is a good idea to use a template for "Thing-Types". (or a common class) I belive, it is not a good idea to build stacks of abstraction layers. I am a fun of flat architectur's - it keeps the software system more flexible and more easy. (horizontal integration) But to describe an architecture, I must have a better understanding of openHAB.

[HolgerHees]

This would be a nice feature. Currently I use "openv" too. I read the data every minute and send it via REST API to openhab. The daemon is also used to control the heating mode.

more details can be found here http://www.intranet-of-things.com/house/heating

and here is a prototype of a vitotronic binding:

https://github.com/pinguin45/openhab/tree/master/bundles/binding/org.openhab.binding.vitotronic

[steand]

Hi Holger, Ups I didn't saw the binding for vitotronic. (thanks for information) I have also a selfmade optolink adapter in place. But i am implement a new software: A "Heading Server" for Vitotronic Systems, written in JAVA. It will use the RPI UART native (RxTx) (like binding vitotronic). It works basicly (Read data from optolink). Next i like to implement the connector to openHab2, independent from the heading system type. The basic architecture idea is: The binding subscribes data (Thinks) from the a "Java Heading Server". The "Java Heading Server" reads the data from the heading and send this periodic to the binding, if data are changed. The idea of software architecture is:

1. The Heading Server and openhab can, but not must, run seperated PI's. (I use one PI B for the heading and my solar system, one PI B for homegear it is go ging to replace Max! and i will expand it with homematic devices. For openHAB2 i have ordered a PI 2 :sunglasses: :thumbsup: )
2. Than the openhab binding is a abstract interface for multible Headings (IoT)
3. The openhab2 binding can discover the "thinks" of heading

If you have idea's what is need more, feel free to send this to me.

PS: Idea's what Thinks (like thermostats, pumps, valve, ..) are must impemented for headings are welcome.

[HolgerHees]

I'm looking forward to see this binding in action :-)

One suggestion is to make the hex command values configurable like vcontrold is doing that. Because there are so many different vitotronic systems which needs different hex values for the "same" command.

in openv (vcontrold) you have 2 config files.

the first one (vcontrold) defines the following data

• "units" a very flexible way to define how data are interpreted. You can set a formula or a bytemask mapping etc...
• "protocols" describes how a complete getCommand or setCommand hex data stream must look.

the second one (vito.xml) defines the command data

• which protocol is used (setCommand or getCommand)
• hex address of the command
• data size
• unit

if you like, i can send you my working config files to show you how flexible it is.

the other vitotronic binding which i suggest to you uses hard coded hex addresses. This is why I can't use it. Because my system has other addresses.

[steand]

I know this. I am a member (vstyx) of openv. I start with vcontrold also.Than i wrote a simple logger for my P300 in java, only for learning more about vito. My implenentation will be more slim and I use only one xml-file for the addresses. The protokol self is implemented in a java class. If you want, i can publish the code on github, but it is a early version.

[HolgerHees]

Unfortunately I just have not enough time for testing or giving some useful comments. :-( but hopefully in the spring!

[teichsta]

spring has started :-)

[steand]

To the start of spring I have published the vitotronic binding and the optolink adapter... so let's try it. 😆 PS: I am in France (holiday) until mid of may.

[teichsta]

any update on this one @steand?

[steand]

Hello Thomas,

I had implement a binding for Viessmann (vitotronic) in openhab2 only. In openhab2 the binding is stable. I didn't got a requirement to develop a solution for openhab 1.x (I think this make no sence also) . So this issue can closed. Thanks.

Regards Stefan.

[affezibbl]

Hi Stefan,

I'm running a vitotronic 200 and a vitocal 350, protocol WPR300 and I'm looking forward to have a native OH binding to get rid of my optlolink-to-c#-to-REST-to-OH workaround. Can I have a look to the source of your 1.8ish viessmann binding? Then I knew if your binding would meet my needs or I could make suggestions what could be evolved.

regards, marcus

[steand]

@affezibbl Hello Marcus,

The vitotronic implementation works only for Openhab2. I have no implementation for 1.8. Please look to: https://github.com/openhab/openhab2/blob/master/addons/binding/org.openhab.binding.vitotronic/README.md I didn't had a requirement to develop a binding in OH1. By myself i have no OH1 running -> I start with OH2 directly. So it is difficult for me to downgrade this binding. If you interesed in the develop please look to: https://github.com/openhab/openhab2/blob/master/addons/binding/org.openhab.binding.vitotronic For future discusion about implementation of aditional features for vitotronic it is better to go to https://community.openhab.org/c/openhab-2/bindings.

Regards Stefan

@teichsta Thomas, I think we can close this issue. Thanks

[affezibbl]

Hi Stefan,

I'm absolutely fine with waiting for OH2 to use the viessmann binding. I thought your binding would be for OH 1.8 and therefore not yet part of the OH 1.x deployment package. Right now, I'm getting familiar with the architecture of your binding and OH2 itself, which I did not look at yet.

regards marcus

[teichsta]

Thomas, I think we can close this issue. Thanks

thanks for the update!