Fix Channel type ‘viessmann:type-literperminute’ is not known
Reorganization of channel-types: Starting the binding takes about 3 minutes
and results in the following warnings, which will not occur on the next restart:
[WARN ] [.core.thing.internal.ThingManagerImpl] - Failed to normalize configuration for thing 'viessmann:device:abcdefg:xxxxxxxxx:0':
{thing/channel=Type description viessmann:type-string for viessmann:device:abcdefg:xxxxxxxxx:0:heating-circuits-0-operating-programs-active not found,
although we checked the presence before.}
Version 5.1.0.202509101920
New authorization process (PKCE)
Updated channel description
Migration method for channel naming convention (channels and item links updates automatically)
In case people wonder what makes it different compared to the other Viessmann binding:
AFAIK the other Viessmann binding only lets you read the slope and level of the heating curve, although the Viessmann API allows you to set it.
With this binding however you can set slope and level and thus save some energy on cold but sunny days, when the room temperatures rise beyond your “I need heating” limit. There is simply no perfect static curve and with all the sensors available and openhab you can use this binding for a smart heating curve control.
There might be other differences but that is the one I appreciate.
@rogrun Please remove this Binding from the marketplace and use the 3rd-Party Marketplace instead. The openHAB marketplace is for org.openhab Bindings only.
Is there any chance to update openhab that the vicare data will be migrated to the new viessmann binding? Currently i only see “handler not found” for vicare and it seems that i have to delete and re create it with the new binding.
AFAIK currently there is no upgrade path, neither for those using the smarthome j version of this binding nor for the vicare.
There might be an upgrade path for the smarthome j version in the future, since the “only” difference is that it was moved to the marketplace and thus the namespace was adapted.
Since the vicare binding was created separately to this binding, there will probably not be any upgrade path. That is purely my assumption, maybe rogrun invests the time to create that functionality for the other binding’s users.
Sommaybe you wait until rogrun returns from vacation and comments on his plans.
Hi everyone,
I’m working on an upgrade path for Smarthome/J users. However, the naming convention for channels and channel types is difficult to implement because all channels in the device are created dynamically and depend on the installation.
The binding itself is already functional and works as a direct replacement for the Smarthome/J binding (without any necessary adjustments to the channels and their item links).
There will be no upgrade path for Vicare, as it is a completely different binding that accesses the OPTO directly offline. Whereas the Viessmann binding accesses the Viessmann API via the Internet.
sorry I’m a beginner, so sorry for stupid questions ;-).
I managed to install the original viessmann binding on OH4. But with moving to OH5, that one didm’t work. So I’ve tied this one, but here I’me also struggeling with the setup.
I’ve started with the thing “Viessmann Account". I’ve entered the ClientID from the Viessmann developer portal. For eMail Adress and Password I’ve used my credentions for the Viessmann developer portal.
But I always get a configuration pending with “Login fails. Please check API Key.”.
Is there a more detaild description how to set up the binding? Now I’m stucked
Unfortunately, I do have the same issue here with Viessmann Binding and OH5. As I rely on OH to control heating and DWH temperatures and times, I had to roll back to OH4 for now, until this is solved.
Hi Ronny, many thanks for your binding and your support!!
I have the same issue as mentioned above: “Login failed. Please check API Key”. My guess: the redirect URI does not work. When tryinghttp://localhost:8080/viessmann/authcode the system fails to return the correct page and comes up with: {“error”: “invalid-code-request”}. The Viessmann API is running correctly with my credentials on browser requests (independent from OH).
Unfortunately I have no direct access to the system right now. I’m on holiday and have only access to the web front-end.
But calling http://localhost:8080/viessmann/authcode results into the same error.
Please check the Redirect URIs in the Viessmann Developer Portal (Viessmann Developer Portal | Viessmann Developer) for your client. They must contain http://localhost:8080/viessmann/authcode/
If this URI is missing, you will receive this error message.
Thanks for the info. Yes I have checked it before and its the same uri on both ends - Viessmann Developer Portal as well as OH call (instead of “localhost” I have the IP of my local Raspi OH-Server http://192.168.178.xx:8080/viessmann/authcode but also tried “localhost” on both ends without success). Also tried after one hour to ensure, that changes on the Viessmann side might take some time.
Since we are running out of other options, also the less likely reasons. Did you change the http port of openhab? E.g. in docker something like OPENHAB_HTTP_PORT=xxxx?
Thanks a lot for pointing me in the right direction! In fact deleting and adding the redirect URL again (including slash at the end) did the trick. So obviously I must had made a mistake there. OH5 has just been able to establish the connection and discover gateway and device. Now that Viessmann seems to work on my setup, I can give OH5 a second try.
At first, I’ve added the ‘/’ at the end of the URL, but still the same error.
Then I’ve checked the settings in OH (Settings->Network), and there was a radio button “Primary IP-Address” with the local IP-adress of the server. This was unselected. After activating, the Binding worked!!!
i just upgraded to OH5.0.1 and installed the Viessmann Binding to connect to my Heatpump and Gasboiler (Vitodens 300-W).
While the Heatpump thing works like a charm, the Gasboiler thing goes online and then offline again after acouple of seconds showing the following
Status: UNINITIALIZED
HANDLER_INITIALIZING_ERROR
Channel type ‘viessmann:type-literperminute’ is not known
Can someone provide me with a hint on howto fix this issue?
Some furhter logging info:
2025-09-21 14:15:26.397 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'viessmann:device:2444b05652:7724827013812220:0' changed from ONLINE to UNINITIALIZED (HANDLER_INITIALIZING_ERROR): Channel type 'viessmann:type-literperminute' is not known
==> /logs/openhab.log <==
2025-09-21 14:15:26.397 [ERROR] [core.thing.internal.ThingManagerImpl] - Exception occurred while initializing handler of thing 'viessmann:device:2444b05652:7724827013812220:0': Channel type 'viessmann:type-literperminute' is not known
java.lang.IllegalArgumentException: Channel type 'viessmann:type-literperminute' is not known
at org.openhab.core.thing.internal.ThingHandlerCallbackImpl.createChannelBuilder(ThingHandlerCallbackImpl.java:222) ~[?:?]
at org.openhab.binding.viessmann.internal.handler.DeviceHandler.createChannel(DeviceHandler.java:710) ~[?:?]
at org.openhab.binding.viessmann.internal.handler.DeviceHandler.handleUpdate(DeviceHandler.java:553) ~[?:?]
at org.openhab.binding.viessmann.internal.handler.ViessmannGatewayHandler.updateFeaturesOfDevice(ViessmannGatewayHandler.java:347) ~[?:?]
at org.openhab.binding.viessmann.internal.handler.DeviceHandler.initChannelState(DeviceHandler.java:185) ~[?:?]
at org.openhab.binding.viessmann.internal.handler.ViessmannThingHandler.initDeviceState(ViessmannThingHandler.java:60) ~[?:?]
at org.openhab.binding.viessmann.internal.handler.DeviceHandler.initialize(DeviceHandler.java:109) ~[?:?]
at jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:580) ~[?:?]
at org.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:149) ~[?:?]
at org.openhab.core.internal.common.Invocation.call(Invocation.java:52) ~[?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:317) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642) ~[?:?]
at java.lang.Thread.run(Thread.java:1583) [?:?]
