Viessmann API binding for OpenHAB 4.0 [4.0.0;5.0.0)

Add-on Marketplace Bundles
, , ,
103

If you could help me how to pull that json file/dump for a Vitocaldens (as I have) I could try things

104

When I send setpoint data like the heating_circuit_0_operating_programs_reduced to the Viessmann cloud then only integer numbers are accepted. Float setpoints like 14.2 are rejected.
Would such a check in our binding be possible?

105

For me the Viessmann binding is broken too. I’m on Openhab 4.3.2 right now and I can install the binding but after configuring it, it never comes online, it always stays on “unknown”. On the configuration page “/vicare/setup” it seems to me, the binding is authorized and i can see my devices listed. But unfortunately, it stays “unknown”.

Can you tell me please, which other binding you are using? I only can find the Vitotronic binding, but as far as I remember this does only work with a local opto coupler device?

106

Ok, I think I need to correct myself, after posting my previous post, I decided to give it on more try and after disabling and enabling again, it finally came up online.

107

Hi Uli, can you distribute the Json file ?

108

Here is my JSON (Vitocal 252a with Vitotrol 300e remote control).
I generated one for the Vitrotrol as well but that is empty.
I can see the room temperature in a channel but not the humidity sensor.
Anyway, I hope that JSON helps.
responseCapture.json (148.2 KB)

1 Like
109

Binding works perfect within my OpenHAB installation running on Xubuntu 24.04 on Intel NUC.
But every second or third OpenHAB update or OpenHAB-AddOn update, the binding gets deinstalled (removed). As a result, the thing for the Vitodens gas heater goes offline. Re-installing the binding makes everything working again.
Why do OpenHAB updates or OpenHAB-AddOn updates (unwanted) remove the binding?
I have some other bindings installed like Homematic, Mosquitto, Astro, etc., but only this binding have this strange behavior.

110

Same here - sometimes it is even deinstalled/removed after a reboot.
As result, looking for the installed Viessmann binding is the first thing after every work on the server


111

Same with my Installation. Uli

112

+1
This also happens with my system. After an update, I first check whether I need to install the Viessmann binding.

113

For this reason I created a script which runs when start level 70 has been reached. The script checks if marketplace addons need to be restored after a restart. The list of marketplace addons are stored in an item (which gets updated by another script).
I am sure you can do it on your own, but here you have a copy paste template:

//This script needs to be run when startlevel = 70
//item name where the id of marketplace addons are stored: vInstalledMarketplaceBindings
var apiToken = "oh.rules.DhBqiiRJiotlpI2TL...";
var header = { "Accept": "application/json",
               "Authorization": "Bearer " + apiToken};
var contentType = "text/plain";

//filtering not required here, but I use this script for storing jar-installed bindings, too.
JSON.parse(items.vInstalledMarketplaceBindings.state).filter(e => e.uid.toString().startsWith("marketplace:")).forEach(e  => {
  var addonId = e.uid.toString().split("marketplace:")[1];
  var urlIsInstalled = "http://localhost:8080/rest/addons/" + addonId + "?serviceId=marketplace";
  var bindingIsInstalled = JSON.parse(actions.HTTP.sendHttpGetRequest(urlIsInstalled, header, 4000));
  if (!bindingIsInstalled.installed) {
    var urlInstall = "http://localhost:8080/rest/addons/" + addonId + "/install?serviceId=marketplace";
    var result = actions.HTTP.sendHttpPostRequest(urlInstall, contentType, "", header, 4000);
    console.log("Info: Binding " + addonID + " installed", result);
  }
});

Here is the script to automatically store the id of all installed marketplace addons in an item:

function getInstalledBindingByServiceID(serviceID) {
//valid parameters: marketplace, jar, karaf, json
  var apiToken = "oh.rules.DhBqiiRJiotlpI2TL4HF...";
  var header = { "Accept": "application/json",
                 "Authorization": "Bearer " + apiToken};
  var contentType = "text/plain";
  var url = 'http://localhost:8080/rest/addons?serviceId=' + serviceID;
  var getBindings = JSON.parse(actions.HTTP.sendHttpGetRequest(url, header, 4000));
  var getInstalledBindings = getBindings.filter(e => e.installed == true).map(e => ({uid: e.uid,label: e.label}));
  return getInstalledBindings;
}

var installedMarketplaceBindings = getInstalledBindingByServiceID("marketplace");
var installedBindings = JSON.stringify([installedMarketplaceBindings]);
items.vInstalledMarketplaceBindings.sendCommandIfDifferent(installedBindings);

and don’t forget to persist the item containing the addon ids :slight_smile:

1 Like
114

For sure this should not be necessary at all :wink:
But still, that’s a nice work around.

1 Like
115

I followed the discussion around this topic. There are reasons why marketplace addons are removed after an update (in some cases openhab was unable to start). I never experienced this and took the risk to have less work after reboots or updates.

1 Like
116

But it still happens. The question is, is it the Addon or Openhab? The script looks nice, but I can’t do anything with it. It may fix the symptoms but the actual error remains.

117

If the binding is removed after a restart it is a bug. All marketplace bindings are removed intentionally, by design after an update of openhab or a clean cache. This is not in the hands of the binding‘s developer. You could change the script which performs the clean cache, but that might be overwritten during the next update.

118

Ok, for me this only happens with updates and clean cache. Even if this is intentional, I don’t like it.

119

grafik
grafik799×635 13.6 KB

I jost lost the cannel to see if the compressor is active.
Does everyone else has the same issue?
Thanks.

120

Since the start of April, I get for the binding of the following error message:

 [ar.vicare.internal.VicareServiceImpl] - Unable to refresh, access server sent 400

I checked on the Viessmann API site that the client ID is still correct, this seems to be so.
As I see here, nobody else experienced this?
Damn, so I try to figure out what could be the culprit.
If anybody has any Ideas, please let me know.

As a small hint, For me also the binding is a hit-and-miss during a reboot phase. Sometimes it is there, sometimes it is not installed.

Edit:
Okay, I think I solved the problem myself.
As the error message pointed out: The 400 error points to a bad request.
In my case, this needed a “reauthorization” in the Viessmann API Page.

Now the Binding works again.

So i just hope that I don’t need to do this to often after a reboot.

121

Same here, I lost connection 2 days ago, same action - and it works again