Viessmann API binding for 3.4.x [3.4.0;3.5.0)

Screenshot from 2022-09-19 12-44-16

This binding integrates Viessmann heating devices using the Viessmann API.
It provides information similar to what you can get through the ViCare mobile app.

Please note this binding is unofficial and not endorsed by Viessmann in any way.


This binding requires OpenHAB 3.4

Upgrading from previous versions

Remove the old binding, and then install the new one via the bindings page. There is no need to add or remove any of the Things they will still work with the new binding.

Supported Devices

This binding has only been developed against a Vitodens 100-W in a fairly
basic configuration, however it should be able to work against a range of other Viessmann heating and ventilation
devices including heat pumps and solar heating, although not all features on these may be supported yet.

Supported Features

Below is an incomplete summary of the main features supported - depending on your boiler model and/or heating
configuration some or all of these may or may not be present:

  • Read and write of active heating circuit operating mode.
  • Temperature sensors
  • Temperature setpoints (read/write)
  • Supply temperature max/min limit (read/write)
  • Burner status
  • Burner modulation
  • Burner statistics (hours and starts)
  • Circulation pump status
  • Frost protection status
  • Basic text properties: device serial number etc.
  • DHW, Heating and Total consumption statistics
  • Program mode temperature settings
  • DHW Heating status
  • DHW Charging active
  • DHW Hot water storage temperature
  • DHW Primary and Circulation Pump Status
  • DHW target temperature (read/write)
  • DHW One time charge mode (read/write)
  • DHW Temperature Hysteresis (read/write)
  • Holiday program settings (read-only)
  • Holiday-at-home program settings (read-only)
  • Heating curve settings
  • Heating circuit names
  • Heating circuit operating mode (read/write)
  • Heating circuit supply temperature
  • Extended heating mode
  • Solar production statistics
  • Solar collector temperature
  • Solar circuit pump status
  • Heat pump compressor status
  • Heat pump compressor statistics
  • Heat pump primary and secondary supply temperature sensors
  • Ventilation operating mode and operating program
  • Ventilation holiday program (read-only)
  • Heating buffer temperature sensors


In order to use the binding, you will need to have a Viessmann API account and
configure it with the redirect URL for your OpenHAB installation and then authorise
the binding. Follow the instructions in openhab at http://<Your OpenHAB>/vicare/setup

Create an instance of the Viessmann API Bridge thing, and configure it with your Client ID
which you should obtain from the Viessmann Developer portal. The developer portal should be
configured with the redirect URI shown on the setup page. Then you should be able to
authorise the Viessmann binding by clicking on the Authorise button on the setup page.

After authorising the binding, then it should automatically discover any heating devices you have
and they will appear in your Inbox.



  • Issue #44 DEVICE_COMMUNICATION_ERROR no longer causes the bridge status to be marked Offline
  • Issue #45 Change iotServerUri configuration parameter so that it doesn’t include the API version
  • Issue #43 Support gas consumption statistics reporting in kWh.
    Upgrade note: Existing gas consumption statistics Items may need to be recreated in order to output in kWh.


  • Issue #39 Location of the response capture file is now shown in the bridge properties.
  • Issue #38 Support for heating.dhw.charging
  • Issue #40 Support heating.compressors.n.statistics for load classes
  • Support for cumulative solar power production statistic


  • Issue #35 Migrated to use new feature endpoints
  • Issue #34 Make v3 identity provider endpoint the default
  • Issue #36 Support DHW Operating Modes after API Change
  • Issue #37 Support for ventilation system


  • Add official support for OpenHAB 3.4
  • Issue #30 Add support for writing to heating circuit eco/comfort operating program active status (not all systems support this)
  • Issue #27 Add support for heating circuit room temperature sensor

Known Issues

Please note due to recent changes in the underlying Viessmann API, some features that were
previously supported under one name may now be reported elsewhere and therefore any existing Item links may need to be updated.


Github source code
Github Release binary

1 Like

Hi rtuck,

I want to upgrade to 3.4 binding from my working 3.3 setup. What is the correct procedure? I went to Settings->Bindings and installed Viessmann API binding for 3.4.x [3.4.0,3.5.0) and removed Viessmann API binding for 3.3.x [3.3.0,3.4.0)
But how do I upgrade Bridge API in Things? It still shows 3.3.5 for Thing Properties. If I go to Things->Add->Viessmann API Binding I have there Viessmann API Bridge listed twice (as well as Heating Circuit and Heating Device). Do I have to delete the old binding from Things and start from scratch? Thanks.

There’s no need to add new items or things, delete the ones you’ve added and retain the originals. If you didn’t remove the old binding first, then it may be that it didn’t properly start the new binding due to clashing the one that was already installed so you may have to restart openhab for it to initialise properly.

So far I did only add 3.4 binding and remove 3.3 one. I’ve restarted OH (or the whole Ubuntu system) but the bridge API still shows 3.3.5.

Here’s output from OH console:

openhab> feature:list | grep vicare
com.qubular.openhab-binding-vicare-feature        x 3.4.0            x x        x Started     x com.qubular.openhab-binding-vicare-feature x com.qubular.openhab-binding-vicare-feature
openhab> bundle:list | grep vicare
235 x Active  x  80 x 3.3.5                  x com.qubular.openhab-binding-vicare-bundle
236 x Active  x  80 x 3.3.5                  x com.qubular.vicare-osgi
257 x Waiting x  80 x 3.4.0                  x com.qubular.openhab-binding-vicare-bundle
258 x Active  x  80 x 3.4.0                  x com.qubular.vicare-osgi

For whatever reason, looks like it didn’t get removed properly, try doing a bundle:uninstall from the console for the old version (both parts 235, 236)

1 Like

Thanks, bundle:uninstall did the trick. Now, the bridge is reporting 3.4.0 and have bunch of new channels for my Vitodens 200-W. Do you know by any chance what are Viessmann’s plans with different data points regarding consumption? e.g.heating.power.consumption.heating and heating.power.consumption.summary.heating? Just so many consumption stats which could all be replaced with just one total consumption number that can be graphed any way I want for any period I want.

Hi @rtuck99!

GREAT WORK so far! Came across this new ViCare API Binding through my search how to implement my new heat pump into openHAB! Worked at the first try and I LOVE IT! THANK YOU SOOO MUCH!

Only one question at the moment: Is there a chance that in the Viessmann API is a switch or at least a string available, which reflects a so called “EVU Sperre”? Heat pump systems can be switched off with the help of an external relais (property of the local power / grid supplier) and my Vitocal 222-S shows this with an symbol at the heater control unit. So they can show the status of this “external contact” at least on the device and maybe it is available also in the API?

Please let me know if you need some more information or testing or… :slight_smile:

Thanks in advance for your GREAT WORK! :heart_eyes:

Hi @rtuck99,

a really great binding which I love to use!

Switching between dhwAndHeating/dhw/standby actively saves energy for me.

I am currently trying to set the hot water temperature. The idea is to only heat it to 60°C for an hour every other day to avoid legionella, otherwise a lower temperature is enough for me.

Unfortunately, the value I set in OpenHab (heating_dhw_temperature_main) is not accepted and is overwritten with the configured value in the Viessmann time program, even if the time program is inactive or the corresponding day has even been deleted.

I use Openhab 3.4.2 and the binding version 3.4.

Am I doing something wrong by simply setting the value of the item?

Hi scuba!

As I now have the possibility to check these things, I can confirm, that setting the DHW target temperature is working!
I linked an item called “Viessmann_Vitocal_222_S_DHW_Target_Temperature” against the channel “vicare:heating:3b04155dc6:b74898a3-d63f-3859-88d2-c9c65a09f5b7:heating_dhw_temperature_main” and the LOG shows, that this is working:

2023-03-26 09:42:21.469 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'Viessmann_Vitocal_222_S_DHW_Target_Temperature' received command 45
2023-03-26 09:42:21.474 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Viessmann_Vitocal_222_S_DHW_Target_Temperature' predicted to become 45
2023-03-26 09:42:21.481 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Viessmann_Vitocal_222_S_DHW_Target_Temperature' changed from 49 °C to 45 °C

So the new value was accepted and I checked via the ViCare App that the value was reflected at the Viessmann server (and supposed to be accepted by the heater itself).

If this does not work for you, please check your item definition and channel linking. The item should be of Number:Temperature (UoM type).

Hello Burki,

Thank you for your quick response!

Unfortunately, success has not yet come. Here is my item definition:
Number:Temperature Viessmann_DHW_Target “DHW target temperature new” (gEveryMinute) {channel=“vicare:heating:23be91b3d7:163f539d-dd98-3493-9522-26a506a61922:heating_dhw_temperature_main”}

And here is the corresponding event log:
2023-03-26 10:55:10.142 [INFO ] [openhab.event.ItemCommandEvent ] - Item ‘Viessmann_DHW_Target’ received command 50 °C
2023-03-26 10:55:10.147 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item ‘Viessmann_DHW_Target’ predicted to become 50 °C
2023-03-26 10:55:11.326 [INFO ] [openhab.event.ItemCommandEvent ] - Item ‘Viessmann_DHW_Target’ received command 45 °C
2023-03-26 10:55:11.330 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item ‘Viessmann_DHW_Target’ predicted to become 45 °C
2023-03-26 10:55:11.346 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item ‘Viessmann_DHW_Target’ changed from 50 °C to 45 °C

And then comes the unexpected:
2023-03-26 10:55:21.354 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item ‘Viessmann_DHW_Target’ changed from 45 °C to 55 °C

The value will be written back from somewhere a little later. Unfortunately, the set value is never displayed in the Vicare either, only the value set in the time program is displayed.

Do you have to switch off the time program or will it be overwritten?

Hmmm… strange!

My program is actually “dhwAndHeating” with time program active for the DHW pump. I did not stop the program or change the mode of the system. And it simply works.

Another idea: are your things (vicare:bridge and your vicare:heating) online?

Eventually you should enable TRACE logging or DEBUG logging to get more insights on what is going on / what the binding does or not. But this belongs to @rtuck99 as I have no knowledge about this binding from a developers perspective.

How exactly to you set the DHW target temperature? A slider on HABpanel or sitemap or through a rule or…?

It’s the same situation, dhwAndHeating and also a running DHW Programm.

All things are permanently online.

Originally the temperature values were set from the UI:
Setpoint item=Viessmann_DHW_Target minValue=8 maxValue=60 step=5

Currently I have written a small program that is called every 5 seconds:
if (itemRegistry.getItem(‘Viessmann_DHW_Target’).getState() != 50){
events.sendCommand(‘Viessmann_DHW_Target’, 50);‘Viessmann_DHW_Target was reset.’)

It is noticeable that there are regular “updates” from Viessmann and then the value is reset by the program. Here’s an example:
2023-03-26 13:48:09.239 [INFO ] [re.internal.VicareDeviceThingHandler] - Update vicare:heating:23be91b3d7:163f539d-dd98-3493-9522-26a506a61922:heating_dhw_operating_modes_active with balanced
2023-03-26 13:48:09.239 [INFO ] [re.internal.VicareDeviceThingHandler] - Update vicare:heating:23be91b3d7:163f539d-dd98-3493-9522-26a506a61922:heating_controller_serial with ���������� ������
2023-03-26 13:48:09.243 [INFO ] [re.internal.VicareDeviceThingHandler] - Update vicare:heating:23be91b3d7:163f539d-dd98-3493-9522-26a506a61922:heating_circuits_0_operating_programs_active with normal
2023-03-26 13:48:09.244 [INFO ] [re.internal.VicareDeviceThingHandler] - Update vicare:heating:23be91b3d7:163f539d-dd98-3493-9522-26a506a61922:heating_circuits_0_operating_modes_active with dhwAndHeating
2023-03-26 13:48:09.246 [INFO ] [re.internal.VicareDeviceThingHandler] - Update vicare:heating:23be91b3d7:163f539d-dd98-3493-9522-26a506a61922:device_serial with ���������� ������
2023-03-26 13:48:09.247 [INFO ] [re.internal.VicareDeviceThingHandler] - Update vicare:heating:23be91b3d7:163f539d-dd98-3493-9522-26a506a61922:heating_boiler_serial with ���������� ������
2023-03-26 13:48:14.261 [INFO ] [.openhab.model.script.Rules.sendInfo] - Viessmann_DHW_Target was reset.


I have upgrade my openhab from the last stable to the 4 m and now i lost the Viessmann binding its not exist anymore. i cant even find it on the add-ons to install again.
Any help


Hi Nikos,

I think almost every binding is not meant to be available in OH4 at this early time. At least this Viessmann binding is made for the latest stable OH3.4 only. It also does not run on OH2.x or OH3.2 or 3.3.

Thanks for your reply.
Do you know if it will be available for the 4 version?

This binding is a development from @rtuck99 - I don’t know if he or anybody else is willing to rewrite the binding for OH4. Hopefully yes, but of course - there is no guarantee. Like with any other binding, too. But the community is alive and sooner or later there was somebody to code a binding for everything so far… :wink:

1 Like

Hi, looking at the log, I suspect one of two things:

  • the value is being sent to the API as otherwise I would expect a WARN level error message that you should see, assuming that your log4j2.xml is configured to show it. Then something is countermanding it (either from OpenHAB or somewhere else)
  • the value is dropped by the binding because the control that sends it maybe is sending an unrecognised value type. I suspect it may be this.

Increase the log level to TRACE by inserting the following into log4j2.xml

            <Logger level="TRACE" name="com.qubular"/>

Hopefully that will show some more detailed output. Unfortunately OpenHAB doesn’t really provide bindings any great way of reporting transient errors due to failure to execute commands for some errors there may be a status change on the binding or the item, but it’s likely to only be momentary.

For reference, it works on my install and my Item configuration is as follows:

Thank you,
I’m not quite sure I understand what EVU Sperre is. From what you are saying and what I can glean, it sounds like it’s a system where the electricity provider can shut off the power to your heat pump?

I can’t find anything relevant in the API documentation at

(you may need to register for an account in order to read it)

so I assume it’s not supported, unless you can find anything there that looks like it.

Does it shut off power to the whole system, or just the compressor? i.e. would the embedded system in the heat pump still be able to report its status over the network back to Viessmann?

Hi nikos, I’m not planning on releasing a v4 of the binding yet, I have yet to build against the 4.0 openhab jars, at some point I will create a branch in github for it, but probably won’t make a release version until OH4 itself is released proper.

1 Like

Hi scuba, why not use built-in hygiene program which can be set to particular time and day/days in a week?