Viessmann API binding for 3.3.x [3.3.0;3.4.0)

Hi there, if you can follow the instructions elsewhere in this forum, to enable the Response Capture Debug option, and DM me the responseCapture.json file.

I should then be able to see what information it’s sending.

Hi,

How many heating devices do you have as things in the API? It will make one request for each device you have. Therefore if you have 2 devices, you can’t set the polling interval any more frequent than 120s.

The queries are cached for the duration of the polling interval, so it shouldn’t result in excessive requests.

Have created an issue for your exception

Good morning,

should have seen that myself earlier in the thread…

Please find attached the responsecapture.json. Not sure whether this is a good enough sample, no solar energy being made right now. I will get another one when the sun is shining, hope it won’t take too long for that to happen :slight_smile:

Thanks,
Georg

responseCapture.json (71 KB)

Thank you. I have only one Viessmann device. I reduced the Polling Interval to 75s since some days. But yesterday https://app.developer.viessmann.com/transactions shows 1633 requests and on 18.12.2022 there have been 2397 requests.

Does not make any sense, how can this be?

Can you please have a look in your openhab.log file and see if there are any errors being generated, at the point just before it starts giving you the 429 error?

I’m speculating here, but I’m guessing that the Viessmann API was returning something unexpected (maybe due to a server outage at their end), which meant the cache could not be filled (normally it would fill with the error), then eventually it reached the request threshold and started returning 429.

You might have to go back a fair way through the log files as if you have a lot of properties, you might have a lot of failed requests.

Wow, there are literally thousands of errors from ViessmannBridge since I upgraded to 3.3.5:

2022-12-21 08:57:47.230 [WARN ] [ar.vicare.internal.VicareServiceImpl] - Unable to request features from IoT API, server returned 502, DEVICE_COMMUNICATION_ERROR: DEVICE_COMMUNICATION_ERROR
2022-12-21 08:57:47.231 [WARN ] [.vicare.internal.VicareBridgeHandler] - Unexpected exception refreshing
java.util.concurrent.CompletionException: java.io.IOException: Unable to request features from IoT API, server returned 502, DEVICE_COMMUNICATION_ERROR: DEVICE_COMMUNICATION_ERROR
	at java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331) ~[?:?]
	at java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:346) ~[?:?]
	at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:632) ~[?:?]
	at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506) ~[?:?]
	at java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088) ~[?:?]
	at com.qubular.openhab.binding.vicare.internal.VicareBridgeHandler.lambda$getFeatures$7(VicareBridgeHandler.java:212) ~[?:?]
	at java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1700) ~[?:?]
	at java.util.concurrent.CompletableFuture$AsyncSupply.exec(CompletableFuture.java:1692) ~[?:?]
	at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290) ~[?:?]
	at java.util.concurrent.ForkJoinPool$WorkQueue.helpAsyncBlocker(ForkJoinPool.java:1144) ~[?:?]
	at java.util.concurrent.ForkJoinPool.helpAsyncBlocker(ForkJoinPool.java:3151) ~[?:?]
	at java.util.concurrent.CompletableFuture.waitingGet(CompletableFuture.java:1817) ~[?:?]
	at java.util.concurrent.CompletableFuture.join(CompletableFuture.java:2043) ~[?:?]
	at com.qubular.openhab.binding.vicare.internal.VicareBridgeHandler.handleBridgedDeviceCommand(VicareBridgeHandler.java:170) ~[?:?]
	at com.qubular.openhab.binding.vicare.internal.VicareDeviceThingHandler.syncHandleCommand(VicareDeviceThingHandler.java:302) ~[?:?]
	at com.qubular.openhab.binding.vicare.internal.VicareDeviceThingHandler.lambda$handleCommand$3(VicareDeviceThingHandler.java:293) ~[?:?]
	at java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1736) [?:?]
	at java.util.concurrent.CompletableFuture$AsyncRun.exec(CompletableFuture.java:1728) [?:?]
	at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290) [?:?]
	at java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020) [?:?]
	at java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656) [?:?]
	at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594) [?:?]
	at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183) [?:?]
Caused by: java.io.IOException: Unable to request features from IoT API, server returned 502, DEVICE_COMMUNICATION_ERROR: DEVICE_COMMUNICATION_ERROR
	at com.qubular.vicare.internal.VicareServiceImpl.getFeatures(VicareServiceImpl.java:233) ~[?:?]
	at com.qubular.openhab.binding.vicare.internal.VicareBridgeHandler.lambda$getFeatures$7(VicareBridgeHandler.java:206) ~[?:?]
	... 17 more

But there is no 429 error.

Error 502 is usually when your boiler has gone offline.
You will get a lot of exceptions, but this will be more than the number of requests, because the request is cached as a CompletableFuture and the exception handler is triggered each time. I will turn down the logging verbosity in the next release to reduce the log spam.

But I can’t see how you can get too many actual requests, unless you have more than one bridge, or more than one boiler Thing.

The only other way of sending too many requests is if you are making writes to e.g. the program temperatures.

I don’t make any writes nor something else. Seems, that the Viessmann API server had an issue on that day.

Above I wrote that I had 1633 requests on 19.12.2022. Now there is shown a number of 2396.

I think the issue was by Viessmann, this api counter does not count correct.

With error 502: My Viessmann boiler has a constant wifi connection without failure, so how could this be? With 3.3.4 I did not had these many errors.

I switched to 3.4. The binding is uninitalized and shows HANDLER_MISSING_ERROR. Several reboots, cache clearings an reinstallation of the binding doesn’t help. Is someone else experiencing this?

Hi there,

everything working except the consumption channels are not discovered/showing up. But they are included in the responseCapture.json. Did I miss a configuration step?

Hi all,
need urgent help.
Just updated to OH3.4 with this binding installed.
Now system doesn’t startup anymore.
Tried to remove this binding in several ways, but it keeps coming back.

2022-12-30 09:34:25.607 [INFO ] [community.CommunityKarafAddonHandler] - Reinstalling missing marketplace KAR: marketplace:139087

How can I get rid permanently of this binding?

I tried in Karaf:
openhab> kar:uninstall com.qubular.openhab-binding-vicare-feature-3.3.5.kar

but it doesn’t remove it.
It remains there!

anyone?
Sorry I am quite desperate as all my setup is dead

This binding doesnt seem to support at all with 3.4 (see here). But it is maybe not the cause for your dead setup, since I also updated to 3.4 and all works fine besides this binding.

Hello rtuck99!

Thank you for your work on this integration. I’ve installed and configured the binding to work with a E3_Vitodens_050_BHC_0122 boiler bt am having issues with some of the channels.

I have set up items for all listed components. Some read fine and others just show NULL values, especially the energy related ones.

For the items which fail, I see warnings in Frontail:

2023-01-03 12:54:37.732 [WARN ] [re.internal.VicareDeviceThingHandler] - Unexpected exception handling command REFRESH for channel vicare:heating:431dfa1ed2:05b0fa7d-6d15-37cf-b75b-503705644744:heating_power_consumption_summary_heating_currentDay

java.util.concurrent.CompletionException: java.lang.NoSuchMethodError: 'void org.openhab.core.library.types.DecimalType.<init>(java.lang.Number)'

	at java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314) ~[?:?]

	at java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:319) [?:?]

	at java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1739) [?:?]

	at java.util.concurrent.CompletableFuture$AsyncRun.exec(CompletableFuture.java:1728) [?:?]

	at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290) [?:?]

	at java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020) [?:?]

	at java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656) [?:?]

	at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594) [?:?]

	at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183) [?:?]

Caused by: java.lang.NoSuchMethodError: 'void org.openhab.core.library.types.DecimalType.<init>(java.lang.Number)'

	at com.qubular.openhab.binding.vicare.internal.VicareDeviceThingHandler$2.updateConsumptionStat(VicareDeviceThingHandler.java:313) ~[?:?]

	at com.qubular.openhab.binding.vicare.internal.VicareDeviceThingHandler$2.visit(VicareDeviceThingHandler.java:309) ~[?:?]

	at com.qubular.vicare.model.features.ConsumptionFeature.accept(ConsumptionFeature.java:38) ~[?:?]

	at com.qubular.openhab.binding.vicare.internal.VicareDeviceThingHandler.lambda$syncHandleCommand$5(VicareDeviceThingHandler.java:304) ~[?:?]

	at java.util.Optional.ifPresent(Optional.java:183) ~[?:?]

	at com.qubular.openhab.binding.vicare.internal.VicareDeviceThingHandler.syncHandleCommand(VicareDeviceThingHandler.java:303) ~[?:?]

	at com.qubular.openhab.binding.vicare.internal.VicareDeviceThingHandler.lambda$handleCommand$3(VicareDeviceThingHandler.java:293) ~[?:?]

	at java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1736) ~[?:?]

	... 6 more

responseCapture.json (18.7 KB)

Can you offer any advice?

Apologies for the delayed reply. Currently the binding doesn’t support 3.4.

I have on one occasion experienced something similar, it seemed to be some kind of problem with karaf caching bundles, if you look on other OpenHAB discussions you may find similar problems with other addons. However when I experienced it, it was likely caused by previous manual installation of the binding and failure to remove it properly before installing the newer. Unfortunately once karaf decides to get stuck, it can be difficult to convince it otherwise.

I can only suggest that you clear your karaf cache folders - I think this post may be helpful:

Sounds like you are on the wrong version of OpenHAB?

I have finally gotten round to upgrading to 3.4.0 and with the latest 3.3.6 version of the binding it’s working fine. However I don’t think I’ve done anything specific in the latest version to make it work.

Therefore I suspect that it’s something to do with your upgrade process. What kind of OpenHAB installation do you have (OpenHABian/docker/linux?) and what was your upgrade process?

It sounds to me like you don’t have the binding installed. If the karaf install was completely rebuilt during the update, I don’t think you will have the binding present as it’s a marketplace binding and not part of the standard install.

For me there was no need to reinstall the bindings as I work off a docker instance and the binding is retained during the update.

Hi,
I updated to 3.3.6 and found out that now I can set some settings instead of read only. That’s great, thanks!

“Activate DHW One Time Charge” and “Deactivate DHW One Time Charge” seems to work for me (but “Deactivate DHW One Time Charge” stays “ON” after data transmission, is this correct? Or is it reset on the next “ON” for “Activate DHW One Time Charge”?)

One question in respect to those switches: How can I make the data transmission immediately after changing “Activate DHW One Time Charge” or “Deactivate DHW One Time Charge”? The transmission only works every x seconds set in “Polling Interval”.

Thank you.