It might be the binding (the logfile suggests so). Unfortunately I have no time in the near future to test this out with your config.
You could try with a slightly older version. Remove the binding from openhab and placing e.g. version 4.0.20 in your add-ons folder (file ownership openhab:openhab). This will require a clear cache to remove the old binding from the cache as well, after which the old version should be working.
As far as I know 4.0.20 still works with OH5.
Thanks for this hint, will give it a try and let you know.
As a placeholder I will add the following links to other OH community topics.
How to implement Thing upgrades
Possible solution posted by Rich Koshak to recreate Thing
But the first one might be the most relevant due to ebus binding not resolving the message. So it might have to do with either a problem in the OH5 json database during upgrade (hence recreating the Thing), or something in the binding might use some improvement (but just a wild guess).
Gave this a try. Ebus binding 4.0.20 works out for OH 5.2.0 but doesnât solve my problem. Thus, its likely not the binding or, w.r.t. the observed phenomenon, there is no difference between the 4.0.20 and the 5.0.0 binding.
So i might have lost the return temperature during an OH update. Unfortunately i didnât recognize that because the last valid item value has been persisted. I have overall roughly 90 items for my heatpump. But why is this single item affected?
Looking to the links you posted, especially the upper one, i am not able to conclude if there is something i could do? I tested the proposal of Rich, deleted the thing and recreated a new thing with the same UID. But this didnât help as well.
The upper link was more like a placeholder for me, indicating maybe something could be done in the binding, but thinking more and more about it, that is just to ease migration for users from one binding version to the next. I doubt it being of use for the binding developer, but certainly not for the end user like you and me.
I had most hope for Richâ suggestion, but like you tried, without success. One last try would be creating a whole new dummy thing (besides your existing one) and linking a new item to the new channel linked to the unresponsive value. See what that brings. If that doesnât work either, discard the dummy item and thing again.
Or make one additional config containing only that value and see if it works from that config file⊠just trying different ways to check what workaround works and what doesnât (hoping there is one that works can give a clue about the problem, as currently I am getting more and more clueless).
Have not been able to achieve something up to now.
But i gained a new error message in the log because i entered the adress for a custom config file (containing the ReturnTemp only) by accident as âbundle URLâ (4th line in MainUI config screen. Tried to delete this using MainUI but ended in some relic which causes the error message.
2026-03-04 14:48:11.221 [INFO ] [internal.things.EBusTypeProviderImpl] - Load custom 'url' configuration file 'file:///C:/openHAB3/userdata/vaillant/Circulation_Pump_config.json' ...
2026-03-04 14:48:11.225 [INFO ] [internal.things.EBusTypeProviderImpl] - Load custom 'url1' configuration file 'file:///C:/openHAB3/userdata/vaillant/hmu08_config.json' ...
2026-03-04 14:48:11.327 [INFO ] [internal.things.EBusTypeProviderImpl] - Load custom 'url2' configuration file 'file:///C:/openHAB3/userdata/vaillant/yield_config.json' ...
2026-03-04 14:48:11.354 [INFO ] [internal.things.EBusTypeProviderImpl] - Load custom 'bundleUrl' configuration bundle ' ' ...
2026-03-04 14:48:11.354 [ERROR] [internal.things.EBusTypeProviderImpl] - Error on loading configuration by url: no protocol:
Edit on 06.03.2026: The bundle link is stored within the ebus.config file (looked initially into a wrong backup file) and i got it back to normal by deleting the whole âbundle URLâ line again.
I also apologize if i take too much of your time.