Viessmann API binding for OpenHAB 4.0 [4.0.0;5.0.0)

[rtuck99]

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.

Requirements

This binding requires OpenHAB 4.0. For earlier versions of OpenHAB please refer to previous versions of this binding on
the community marketplace discussion for the corresponding binding version.

Upgrading from OpenHAB 3.4

It is advisable to remove previous versions of the plugin before upgrading OpenHAB.

However if you have upgraded to OpenHAB 4.0 and still have the old binding installed, remove it from the
Settings->Bindings admin page. This may fail, in which case you will need to log into the OpenHAB shell
and run

feature:list | grep qub

If the feature is still installed, remove it with

feature:uninstall com.qubular.openhab-binding-vicare-feature

However if removal of the feature did not succeed, the bundles may also need to be removed. If the following

bundle:list | grep qub

shows that the bundles are still installed, then remove them as follows

bundle:uninstall com.qubular.openhab-binding-vicare-bundle
bundle:uninstall com.qubular.vicare-osgi

Once the old binding is fully removed, you can install the new version from the Settings->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

Generic Device Support

The has generic read-only support for unrecognised devices which will report read-only
values for boolean, string and numeric properties.

Configuring

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.

Note that the API is rate-limited to 1450 requests per day, or approximately once every 60 seconds;
exceeding the threshold incurs a lockout for the rest of the day.
The default polling interval is configured to 90 seconds to leave some headroom for additional requests.
If you have multiple heating devices configured then you may need to increase the polling interval.

Changelog

4.0.3

• Fix for #57 Rework prefetching
• Add generic read-only support for unrecognised devices and boolean, string and numeric properties

4.0.2

• Fixed #55 Karaf refreshes binding on restart and unloads it
• Fix for #57 Threading issues and log spam after HTTP connection EOF
• Fix for #56 support for heating.buffer.sensors.temperature.main temperature value

4.0.1

• Fixed #48 Slow startup of Viessmann binding under 4.0.0
• Fixed #50 Viessmann bridge can’t be added
• Fixed #54 Feature endpoint now returns incorrect payload

4.0.0

This version introduces support for OpenHAB 4.0

Resources

Github source code
Github Release binary

[Udo_Hartmann]

Getting errors (worked flawless with 3.4.4)

What did I do: uninstalled old Binding, checked if uninstalled, installed new binding, checked if installed

openhab> feature:list | grep qub
com.qubular.openhab-binding-vicare-feature        x 4.0.0            x x        x Started     x com.qubular.openhab-binding-vicare-feature x com.qubular.openhab-binding-vicare-feature
openhab> bundle:list | grep qub
309 x Active    x  80 x 4.0.0                  x com.qubular.openhab-binding-vicare-bundle
310 x Active    x  80 x 4.0.0                  x com.qubular.vicare-osgi

1. In Things, I can’t create a bridge (there simply is nothing to select after Add Thing->Vicare...->
2. the old Bridge remains at “unknwn” status.
3. If I take a look at http://…/vicare/setup, I’m getting The binding is AUTHORISED. but also a 404 under device list. If I pause the bridge and then unpause, it suddenly gets online. I now get four devices at vicare/setup and as consequence a newly found Thing.
4. the new thing stays offline with comm error, no matter if i use the given uid or change it. Same as the old one

[rtuck99]

Hi Udo,

1. I can reproduce this - it seems something has changed in the Add Thing dialog and it now looks for the binding using the feature name instead of the binding name, for some reason OpenHAB seems to expect they are the same whereas previously it didn’t. Looking into this to exactly where it’s getting this name from. This will be problematic for new installs but upgrades like you should be ok since you shouldn’t need to touch any of this.

2. The old bridge and Things should continue to work so you shouldn’t need to add new ones. At least, it does for me. It does take a while to startup, during which it says something like NOT_YET_READY but after 2 mins it should be ok. It’s possible this delayed startup also gets in the way of the polling for other things.The delay is due to new checks which interfere with the dynamic channel types as OpenHAB now expects channel types for Things that aren’t yet initialized (and thus don’t have any channel types). There is a timeout, after which it gives up, then everything seems to work more-or-less normally. Hopefully I can re-jig the initialization of the channel types.

3 + 4. Not sure what is happening here, it may be getting confused if you have 2 bridges.

[Udo_Hartmann]

Well, I don’t have two bridges (and never had… couldn’t have built a second, see point 1…) Lucky me my bridge is configured manually via text files.

By the way, it’s not possible to configure the thing manually, which is a pity, my heating system is the only hardware which can’t be stored completely in a things file.

[rtuck99]

I’m curious to know, what is the use case for storing the Thing in a file? I don’t officially support it. There shouldn’t be any need to.

I have mine but that’s only to take advantage of undocumented debug properties.

[Udo_Hartmann]

The use case is, I don’t like UI configuration It’s as simple as that.

I’m an openHAB user since 2012.
openHAB1.0 was out and there was no installer yet - but it was a no-brainer to get it up and running in five Minutes from first download to the first real light switched via openHAB Classic UI (yes, real five Minutes).
I had done some other tests with various systems, and openHAB was by far the best at that time.

I’m totally aware of the benefit of a UI driven configuration, but I’m fast with a good editor (in 2012 there was the openHAB Designer, and now there is VS Code with the openHAB Plugin - much better )

I’m not aware of any special things which has to be done to get a things configuration via text file, but of course one has to know the configuration parameters, which should be visible in the yaml code (no, they’re not…)

[rtuck99]

Well I’m afraid you’ll just have to be disappointed. I’m unlikely ever to support text-based configuration, mainly because the channels contain properties populated from the API, in order to maintain the correct link between OpenHAB channels and the corresponding API feature/property combinations. There shouldn’t be any need for text-based config, as all channels are created by the binding and you can’t manually add any.

[rtuck99]

It should now be possible to add Things if you uninstall + reinstall the binding as I have renamed the file which seems to now satisfy the gods of the CommunityMarketplaceAddOnService

[Udo_Hartmann]

Will check later, but for now: My vicare is online again! So obviously I was too impatient

Thanks a lot for your work!

[Udo_Hartmann]

Jepp, now completely working as intended, Thanks a lot!

[prior_philip]

@rtuck99
Confirmed. Binding now works.
I see duplicated channel labels though. Maybe thats not supposed to be:

[rtuck99]

No, that actually is supposed to be - the API reports the name twice in two different ways.

[prior_philip]

Does the API also reports the label?
Then they report same label name for different channels. Nothing I’d consider as good practice.

[Nadalio (Nada)]

Hi,
today I updated to OH 4.0.1 (from 3.4.4) and also removed the 3.4 Vicare binding, added the new one here. But now I get thousands of errors in my logfile after 2 hours of uptime (every 75s, which is my bridge “Polling Interval”):

2023-08-05 15:28:23.061 [WARN ] [re.internal.VicareDeviceThingHandler] - Unexpected exception handling command REFRESH for channel vicare:heating:73a6950753:30d23790-ab86-3836-8e84-1c421bc1139d:heating_circuits_1_heating_curve_shift
java.util.concurrent.CompletionException: java.lang.NoSuchMethodError: 'void org.openhab.core.library.types.DecimalType.<init>(double)'
	at java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:315) ~[?:?]
	at java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:320) ~[?:?]
	at java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1807) ~[?:?]
	at java.util.concurrent.CompletableFuture$AsyncRun.exec(CompletableFuture.java:1796) ~[?:?]
	at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:373) ~[?:?]
	at java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1182) ~[?:?]
	at java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1655) ~[?:?]
	at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1622) ~[?:?]
	at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:165) ~[?:?]
Caused by: java.lang.NoSuchMethodError: 'void org.openhab.core.library.types.DecimalType.<init>(double)'
	at com.qubular.openhab.binding.vicare.internal.VicareDeviceThingHandler$1.visit(VicareDeviceThingHandler.java:272) ~[?:?]
	at com.qubular.vicare.model.features.CurveFeature.accept(CurveFeature.java:32) ~[?:?]
	at com.qubular.openhab.binding.vicare.internal.VicareDeviceThingHandler.lambda$syncHandleCommand$5(VicareDeviceThingHandler.java:171) ~[?:?]
	at java.util.Optional.ifPresent(Optional.java:178) ~[?:?]
	at com.qubular.openhab.binding.vicare.internal.VicareDeviceThingHandler.syncHandleCommand(VicareDeviceThingHandler.java:170) ~[?:?]
	at com.qubular.openhab.binding.vicare.internal.VicareDeviceThingHandler.lambda$handleCommand$3(VicareDeviceThingHandler.java:159) ~[?:?]
	at java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1804) ~[?:?]
	... 6 more

This seems to be the issue (?), method not found:

void org.openhab.core.library.types.DecimalType.<init>(double)

Any idea how to fix this?

The binding itself works (shows correct values, sets values), but produces these errors e.g. when setting temperatures.

Thanks.

[rtuck99]

Hi,

I am not seeing this issue on my install. However I am seeing something similar with my Glowmarkt plugin at startup.

Although it doesn’t seem to affect operation, so I guess it’s intermittent, as otherwise I wouldn’t be getting smart meter data.

When you are getting this error, it will be preventing updates to the values so the values you see will be out of date.

I don’t think this is a bug in the binding - the code in question hasn’t changed in my binding or in OpenHAB. The exception is caused because it has a problem autoboxing from
double to java.lang.Number

However it compiles correctly and passes unit tests without issue, and also runs at least some of the time.
Java Language Specification 5.3 states

https://docs.oracle.com/javase/specs/jls/se17/html/jls-5.html#jls-5.3

Invocation contexts allow an argument value in a method or constructor invocation (§8.8.7.1, §15.9, §15.12) to be assigned to a corresponding formal parameter.

<…>

Loose invocation contexts allow a more permissive set of conversions, because they are only used for a particular invocation if no applicable declaration can be found using strict invocation contexts. Loose invocation contexts allow the use of one of the following:

<…>

• an unboxing conversion followed by a widening primitive conversion

Which is what I’d expect - double → java.lang.Double → java.lang.Number
This worked fine in 3.4, and indeed I previously had issues from people using old versions of the binding because OpenHAB used to have the primitive type constructors but then removed them, the change didn’t require any code changes but did need a recompile.

I suspect that this issue is actually a problem with OpenJDK, (probably in the VM as it’s intermittent?) I can’t find anything in their issue tracker however, and to give them a bug report would need to reduce it down to a simple test case, reproducing may be tricky since it doesn’t manifest itself in the simplest case.

I’ve raised a bug for this in my bug tracker

https://github.com/rtuck99/openhab-binding/issues/53

I expect I’ll just have to insert some explicit casts or something. Ugh.

[Nadalio (Nada)]

Thank you. But I don’t understand much of what you described

When I change the temperature by my OH4-slider, it is transmitted to my Vitodens 222F. But seems you are right, the data is not read the other way from the heater to OH4.

Am I right that I can’t do anything?

Forgot to mention that I run OH4 on Windows 10, I don’t know if this matters. Until today OH 3.4.4 ran smoothly for months with the Viessmann binding.

[Nadalio (Nada)]

I have some news: I deleted all links and items of the Viessmann binding and also deleted the bridge and binding. After reinstalling the binding, connecting the API and adding my needed channels and items (which now have a lot of “_” in the names, so I had to change my UI and some rules) the errors and warnings in the log from above are gone.

I found a difference in the bridge:
In my old bridge “Access Server URI” was

https://iam.viessmann.com/idp/v2/token

but in the new bridge it is now

https://iam.viessmann.com/idp/v3/token

The “IoT Service Endpoint” was “https://api.viessmann.com/iot/v1/” and now is “https://api.viessmann.com/iot/”. Seems that on some binding update this was changed in the past and perhaps was the cause of these errors.

But now I have “new” errors: Every time I start or stop One-Time-DHW-Charge in OH4, the change is submitted to Viessmann servers (and when changing in Viessmann Android App it is transmitted to OH4), but I get this:

2023-08-05 22:31:34.010 [WARN ] [re.internal.VicareDeviceThingHandler] - Unexpected exception handling command ON for channel vicare:heating:73a6950753:30d23790-ab86-3836-8e84-1c421bc1139d:heating_dhw_oneTimeCharge_activate
java.util.concurrent.CompletionException: com.google.gson.JsonSyntaxException: java.lang.IllegalStateException: Expected BEGIN_OBJECT but was BOOLEAN at line 1 column 13 path $.data
	at java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:315) ~[?:?]
	at java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:320) ~[?:?]
	at java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1807) ~[?:?]
	at java.util.concurrent.CompletableFuture$AsyncRun.exec(CompletableFuture.java:1796) ~[?:?]
	at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:373) ~[?:?]
	at java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1182) ~[?:?]
	at java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1655) ~[?:?]
	at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1622) ~[?:?]
	at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:165) ~[?:?]
Caused by: com.google.gson.JsonSyntaxException: java.lang.IllegalStateException: Expected BEGIN_OBJECT but was BOOLEAN at line 1 column 13 path $.data
	at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.read(ReflectiveTypeAdapterFactory.java:270) ~[?:?]
	at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$1.read(ReflectiveTypeAdapterFactory.java:161) ~[?:?]
	at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.read(ReflectiveTypeAdapterFactory.java:266) ~[?:?]
	at com.google.gson.Gson.fromJson(Gson.java:1058) ~[?:?]
	at com.google.gson.Gson.fromJson(Gson.java:1016) ~[?:?]
	at com.google.gson.Gson.fromJson(Gson.java:959) ~[?:?]
	at com.google.gson.Gson.fromJson(Gson.java:927) ~[?:?]
	at com.qubular.vicare.internal.VicareServiceImpl.sendCommand(VicareServiceImpl.java:269) ~[?:?]
	at com.qubular.openhab.binding.vicare.internal.VicareBridgeHandler.sendCommand(VicareBridgeHandler.java:223) ~[?:?]
	at com.qubular.openhab.binding.vicare.internal.VicareBridgeHandler.handleBridgedDeviceCommand(VicareBridgeHandler.java:200) ~[?:?]
	at com.qubular.openhab.binding.vicare.internal.VicareDeviceThingHandler.syncHandleCommand(VicareDeviceThingHandler.java:307) ~[?:?]
	at com.qubular.openhab.binding.vicare.internal.VicareDeviceThingHandler.lambda$handleCommand$3(VicareDeviceThingHandler.java:157) ~[?:?]
	at java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1804) ~[?:?]
	... 6 more
Caused by: java.lang.IllegalStateException: Expected BEGIN_OBJECT but was BOOLEAN at line 1 column 13 path $.data
	at com.google.gson.stream.JsonReader.beginObject(JsonReader.java:395) ~[?:?]
	at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.read(ReflectiveTypeAdapterFactory.java:259) ~[?:?]
	at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$1.read(ReflectiveTypeAdapterFactory.java:161) ~[?:?]
	at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.read(ReflectiveTypeAdapterFactory.java:266) ~[?:?]
	at com.google.gson.Gson.fromJson(Gson.java:1058) ~[?:?]
	at com.google.gson.Gson.fromJson(Gson.java:1016) ~[?:?]
	at com.google.gson.Gson.fromJson(Gson.java:959) ~[?:?]
	at com.google.gson.Gson.fromJson(Gson.java:927) ~[?:?]
	at com.qubular.vicare.internal.VicareServiceImpl.sendCommand(VicareServiceImpl.java:269) ~[?:?]
	at com.qubular.openhab.binding.vicare.internal.VicareBridgeHandler.sendCommand(VicareBridgeHandler.java:223) ~[?:?]
	at com.qubular.openhab.binding.vicare.internal.VicareBridgeHandler.handleBridgedDeviceCommand(VicareBridgeHandler.java:200) ~[?:?]
	at com.qubular.openhab.binding.vicare.internal.VicareDeviceThingHandler.syncHandleCommand(VicareDeviceThingHandler.java:307) ~[?:?]
	at com.qubular.openhab.binding.vicare.internal.VicareDeviceThingHandler.lambda$handleCommand$3(VicareDeviceThingHandler.java:157) ~[?:?]
	at java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1804) ~[?:?]
	... 6 more
2023-08-05 22:32:48.252 [WARN ] [re.internal.VicareDeviceThingHandler] - Unexpected exception handling command ON for channel vicare:heating:73a6950753:30d23790-ab86-3836-8e84-1c421bc1139d:heating_dhw_oneTimeCharge_deactivate
java.util.concurrent.CompletionException: com.google.gson.JsonSyntaxException: java.lang.IllegalStateException: Expected BEGIN_OBJECT but was BOOLEAN at line 1 column 13 path $.data
	at java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:315) ~[?:?]
	at java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:320) ~[?:?]
	at java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1807) ~[?:?]
	at java.util.concurrent.CompletableFuture$AsyncRun.exec(CompletableFuture.java:1796) ~[?:?]
	at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:373) ~[?:?]
	at java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1182) ~[?:?]
	at java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1655) ~[?:?]
	at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1622) ~[?:?]
	at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:165) ~[?:?]
Caused by: com.google.gson.JsonSyntaxException: java.lang.IllegalStateException: Expected BEGIN_OBJECT but was BOOLEAN at line 1 column 13 path $.data
	at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.read(ReflectiveTypeAdapterFactory.java:270) ~[?:?]
	at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$1.read(ReflectiveTypeAdapterFactory.java:161) ~[?:?]
	at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.read(ReflectiveTypeAdapterFactory.java:266) ~[?:?]
	at com.google.gson.Gson.fromJson(Gson.java:1058) ~[?:?]
	at com.google.gson.Gson.fromJson(Gson.java:1016) ~[?:?]
	at com.google.gson.Gson.fromJson(Gson.java:959) ~[?:?]
	at com.google.gson.Gson.fromJson(Gson.java:927) ~[?:?]
	at com.qubular.vicare.internal.VicareServiceImpl.sendCommand(VicareServiceImpl.java:269) ~[?:?]
	at com.qubular.openhab.binding.vicare.internal.VicareBridgeHandler.sendCommand(VicareBridgeHandler.java:223) ~[?:?]
	at com.qubular.openhab.binding.vicare.internal.VicareBridgeHandler.handleBridgedDeviceCommand(VicareBridgeHandler.java:200) ~[?:?]
	at com.qubular.openhab.binding.vicare.internal.VicareDeviceThingHandler.syncHandleCommand(VicareDeviceThingHandler.java:307) ~[?:?]
	at com.qubular.openhab.binding.vicare.internal.VicareDeviceThingHandler.lambda$handleCommand$3(VicareDeviceThingHandler.java:157) ~[?:?]
	at java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1804) ~[?:?]
	... 6 more
Caused by: java.lang.IllegalStateException: Expected BEGIN_OBJECT but was BOOLEAN at line 1 column 13 path $.data
	at com.google.gson.stream.JsonReader.beginObject(JsonReader.java:395) ~[?:?]
	at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.read(ReflectiveTypeAdapterFactory.java:259) ~[?:?]
	at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$1.read(ReflectiveTypeAdapterFactory.java:161) ~[?:?]
	at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.read(ReflectiveTypeAdapterFactory.java:266) ~[?:?]
	at com.google.gson.Gson.fromJson(Gson.java:1058) ~[?:?]
	at com.google.gson.Gson.fromJson(Gson.java:1016) ~[?:?]
	at com.google.gson.Gson.fromJson(Gson.java:959) ~[?:?]
	at com.google.gson.Gson.fromJson(Gson.java:927) ~[?:?]
	at com.qubular.vicare.internal.VicareServiceImpl.sendCommand(VicareServiceImpl.java:269) ~[?:?]
	at com.qubular.openhab.binding.vicare.internal.VicareBridgeHandler.sendCommand(VicareBridgeHandler.java:223) ~[?:?]
	at com.qubular.openhab.binding.vicare.internal.VicareBridgeHandler.handleBridgedDeviceCommand(VicareBridgeHandler.java:200) ~[?:?]
	at com.qubular.openhab.binding.vicare.internal.VicareDeviceThingHandler.syncHandleCommand(VicareDeviceThingHandler.java:307) ~[?:?]
	at com.qubular.openhab.binding.vicare.internal.VicareDeviceThingHandler.lambda$handleCommand$3(VicareDeviceThingHandler.java:157) ~[?:?]
	at java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1804) ~[?:?]
	... 6 more

“Unexpected exception handling command ON for channel” seems to be an issue in the binding?

On changing the temperature in OH4 I get this error, but the temperature change is transmitted to the heater:

2023-08-05 22:22:47.915 [WARN ] [re.internal.VicareDeviceThingHandler] - Unexpected exception handling command 28 °C for channel vicare:heating:73a6950753:30d23790-ab86-3836-8e84-1c421bc1139d:heating_dhw_temperature_main
java.util.concurrent.CompletionException: com.google.gson.JsonSyntaxException: java.lang.IllegalStateException: Expected BEGIN_OBJECT but was BOOLEAN at line 1 column 13 path $.data
	at java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:315) ~[?:?]
...

It works now, but still getting all these log entries.

[rtuck99]

In my old bridge “Access Server URI” was

[https://iam.viessmann.com/idp/v2/token](https://iam.viessmann.com/idp/v2/token)

but in the new bridge it is now

[https://iam.viessmann.com/idp/v3/token](https://iam.viessmann.com/idp/v3/token)

This is normal - there was a change a few versions back where I updated the default token endpoint - but only for new installs. They haven’t disabled the old one.

The “IoT Service Endpoint” was “https://api.viessmann.com/iot/v1/” and now is “https://api.viessmann.com/iot/”. Seems that on some binding update this was changed in the past and perhaps was the cause of these errors.

This was a change in the latest version of the binding, it silently converts the old endpoint if you had it before - it won’t cause any problems.

But now I have “new” errors: Every time I start or stop One-Time-DHW-Charge in OH4, the change is submitted to Viessmann servers (and when changing in Viessmann Android App it is transmitted to OH4), but I get this:

2023-08-05 22:31:34.010 [WARN ] [re.internal.VicareDeviceThingHandler] - Unexpected exception handling command ON for channel vicare:heating:73a6950753:30d23790-ab86-3836-8e84-1c421bc1139d:heating_dhw_oneTimeCharge_activate
java.util.concurrent.CompletionException: com.google.gson.JsonSyntaxException: java.lang.IllegalStateException: Expected BEGIN_OBJECT but was BOOLEAN at line 1 column 13 path $.data
Caused by: com.google.gson.JsonSyntaxException: java.lang.IllegalStateException: Expected BEGIN_OBJECT but was BOOLEAN at line 1 column 13 path $.data
	at com.qubular.vicare.internal.VicareServiceImpl.sendCommand(VicareServiceImpl.java:269) ~[?:?]

For some reason, the API is not returning the expected payload after a command is sent - it reports 200 so presumably the set succeeds, however I’m expecting a JSON object back that looks like this:

{
“data”: {
“success”: true,
“message”: null,
“reason”: “COMMAND_EXECUTION_SUCCESS”
}
}

but for whatever reason, Viessmann are sending back this. (I managed to replicate on my system)

{“data”:true}

Using postman, it seems that they return this on the v1 endpoint, but on the v2 endpoint they are returning the usual payload.

This is a bit strange - a week or two ago, when I was updating for 4.0 I noticed on the Viessmann website they had updated the documentation to provide documentation for both the old v1 and now a new v2 endpoint,
however the documentation for both was identical so I didn’t change it. But it seems maybe they have done some work and mixed up the iot/features and iot/equipment endpoints, the latter is what is documented to return the boolean.

When you write a value, I always use the endpoint that’s returned in the API when the features are read, and so this has always been the v1 endpoint. I think this is a regression in their API.

Ironically, the change I just made that removes the version number from the configuration, now prevents you from fixing this issue yourself

Sigh, raised another bug, I think there are now quite a few to fix for 4.0.1

https://github.com/rtuck99/openhab-binding/issues/54

[rtuck99]

Well, I guess that whatever triggers this issue, when it happens, you won’t get any updates.
I don’t know if OS makes a difference, I suspect more likely it may make a difference which Java VM you are running.
I’m running the standard docker image, which uses OpenJDK 17. I can see from the java bug tracker and some JEPs like JEP 402 that there are changes happening in the area of primitive boxing so newer versions of java may also be introducing issues.

[Nadalio (Nada)]

When I set e.g. DHW temperature it is really set, although I always get the warning in the log. Same with DHW One Time Charge, it works, but I get a warning log entry.

At least my log now only grows with these active changes, not with every data update every 75s like it was before I did the complete new install of the binding.