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.
…and that was the issue, thank you.
I was running 3.2.0. Upgrading to 3.4.0 solved the problem and all is now well and reading as expected.
Thank you once again.
Hi Nadalio,
I think this might be related to the way OpenHAB manages item state. I suspect the relevant bit of info is here:
https://www.openhab.org/docs/developer/bindings/thing-xml.html#auto-update-policies
The binding uses default auto update policy for all channels - generally speaking it doesn’t make any assumptions about
what sending a command via a write-only channel does. It will send the command immediately from such a write-only channel, however it doesn’t update the
corresponding state of any associated readable channels until the next polling cycle. OpenHAB using the default auto update policy will try and set the state of the write-only
channel but doesn’t know about the other DHW channels so can’t update those.
You should be able to confirm that the command is sent immediately from the Vicare app if it shows the status.
As the read-only command channels are never updated by the binding, they will just reflect whatever the last thing written by OpenHAB was.
Thank you. Works fine!
You are right, the update is sent immediately. Also it does not matter when “Deactivate DHW One Time Charge” stays on “ON”, because when setting the command to ON again it will sent the command again anyway.
Is there also a command to set the DHW-temperature? I did not see any.
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.
Thank you for answering-
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?
I have a Debian 11 VM with openhabian installed so the upgrade went through the package 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.
I de-installed the binding several times without any outcome. Lastly I de-installed the binding and forced the removing of the things. Now I have 3.3.6 installed and the API is online, the autodiscovered thing failed to initiaze and I cant add a thing manually:
Update: I looked at the wrong place for my setup and now I have everything running.
Hi,
Did you create the heating thing through the UI by adding it from your inbox, or from a config file? It seems that the binding can’t find the hidden deviceUniqueId property in the heating device. This is populated by the binding by discovering it via the Viessmann API when it’s created from the inbox, and for this reason it’s not supported to create Things other than by adding the discovered items. When you say the autodiscovered thing failed to initialize, was it created or did it just not appear?
If you have it, it will be called DHW Target Temperature aka heating_dhw_temperature_main. It should be possible to set it, you will need to change the default UI control type OpenHAB uses by setting the ui widget metadata, as by default it will just present them all as a number.
Thanks, it works out of the box:
events.sendCommand("ViessmannVitodens200_DHWTargetTemperature", 29);
Hi and thanks a lot for your support and effort.
It is now working well!
Anyone an Idea? @rtuck99 maybe? Edit: Nevermind, after updating from 3.3.5 to 3.3.6 it started working!
Hello seems I am missing the temperature sensor from the viessmann thermostat which connected to my boiler.
I can see it in the json so I think it might be due to the above disussion.
{
“properties”: {
“value”: {
“type”: “number”,
“value”: 19.1,
“unit”: “celsius”
},
“status”: {
“type”: “string”,
“value”: “connected”
}
},
“commands”: {},
“apiVersion”: 1,
“uri”: “https://api.viessmann.com/iot/v1/equipment/installations/76813/gateways/123/devices/0/features/heating.circuits.0.sensors.temperature.room”,
“gatewayId”: “123”,
“feature”: “heating.circuits.0.sensors.temperature.room”,
“timestamp”: “2023-01-16T14:08:02.962Z”,
“isEnabled”: true,
“isReady”: true,
“deviceId”: “0”
},
Do you need the whole json or just the above snippet?
Seems this is already on the list for release 3.4.0 according to GitHub so I will wait for that and test when it is released. Thanks!
