With this binding, heating and ventilation systems that have an eBUS can be addressed. The corresponding hardware is required. Connections are possible via serial, TCP and ebusd.
or just check GitHub Releases for the latest or older versions.
or just check GitHub Releases for the latest or older versions.
Thanks, I replaced the old binding with the new version and so far it looks good.
Have upgraded to OH 5.0.3 today and your binding remains being my favorite. It works out really great and provides me full insight into my Vaillant aroTherm plus (overall >80 eBUS parameters). Many thanks for all your work. And have a nice Advent time.
In the meantime i have upgraded to 5.1.0 and 5.2.0-SNAPSHOT #5090. An issue is that the eBUS binding from the OH marketplace is deinstalled automatically during each upgrade procedure.
Normally not a problem if the marketplace is available for reinstallation of the binding. But there is a bug, present since many weeks, where the marketplace disappears temporarily. Then it only helps to wait until it is back by accident.
Also tested the .kar file within the addon folder. This works for eBUS but the MainUI actually only handles .jar files properly but not .kar files. A .kar installation is not shown in MainUI as installed and the custom file setup screen is missing then. The actual eBUS .jar doesn’t work out due to missing dependecies.
It would be nice to have the binding being part of the OH core to overcome these issues.
I have the same problem with the automatic uninstallation;
I already observed this problem in version 4.
Yes, the availability issue of the marketplace is pretty old. I also have seen posts which describe the root cause but the maintainers don’t get it solved.
Hi, can you give some more insides how you managed this . I have already a ebus shield c6 hardware and also a Vaillant Therm, but not sure how to configure this binding with any config file. Thanks a lot.
Am not sure if i understood what you are exactly looking for? Maybe this thread can help you:
If not, feel free to contact me again.
oh wow this is impressive - I just need to get my ebus adapter to be connected - as it ist in my owned neighbour house and I have to switch off power first. Thank you anyway and I may come back to you.
Hi, so finally I have connected my ebus shield c6 to the bus - installed ebusd on my raspberry pi 4 - and the binding and bridge on OH - finally I managed that I get the number of recieved telegrams reported, but the things / channels of any VRC700 object does not show any result.
The adapter is connected via USB to the raspberry (/dev/ttyACM0) but I could not get the USB to transmit values so I switched back to the WLAN version. Anything which needs to be adjusted in the binding or the things ? . ebusd is currently not running on the raspi. Thanks a lot for any help 
I have my ebusd adapter disabled in openHAB because my production coupler is an Esera LAN eBUS adapter. There are two ways of connecting to the ebusd adapter:
Onyl way 2. enables the full advantage of ebusd (zero roundtrip time).
See also here:
As soon as your basic setup will work, this might also be interesting for you: Https://community.openhab.org/t/configurations-for-the-ebus-binding-3-4-0-4-0-0/145714
It helps to understand how ebus telegrams work.
Ok thank you very much.
Yesterday with a little bit help of ChatGPT I managed to get the ebusd adapter running on the Raspi . Connected via USB.
It could load the vaillant config and discovered the vrc controller as well as the gas therm. All the signals are hex coded. Didn’t manage to get anything else than “telegrams received” in the openhab bridge. So I will move forward.
Just one question do I need to enter some cfg file in the edbus binding, to get the codes translated ?
BR
If you need extra config files depends on which parameters you want to retrieve. The ebus binding already contains some basic setup, for me the 4 lower things VRC720….
For the upper 4 things i have loaded custom config files. See here: Configurations for the eBUS-binding [3.4.0, 5.2.0]
thank for your hints
I finally want to update that I managed it, but not with the ebus binding - this made me headache with all the things which didnt work in my setup.
I switched over to MQTT which works now perfekt as far as I see - the edbus.service file needs to be updated in the ExecStart= line so that mqtt is in service - than you can easily grab the published values of the MQTT State Topic via a mosquitto broker and then use the MQTT bridge.
Create a generic MQTT thing and then the appropriate channels e.g heating water → at a link as item and then you have it in openhab
again thanks for your time and help
best regards
Today i detected by accident that one Vaillant HMU parameter is frozen since a while. Therefore i didn’t detect it earlier. It is the HC return temperature which i load through a custom config file hmu08_config.json. It worked out for a long time, e.g. using OH 3.4.5. My feeling is, that i lost it due to an OH/ebus-binding update. I started to upgrade OH by end of last year and the ebus binding accordingly.
In the meantime, i am on OH 5.2.0-SNAPSHOT #5187 and use the latest marketplace ebus binding.
Polling is registered but then i discovered the following log messages:
2026-02-23 14:49:34.032 [WARN ] [core.thing.internal.ThingManagerImpl] - Channel types or config descriptions for thing 'ebus:HMU01:e2026358ab:5e2277dc59' are missing in the respective registry for more than 120s. In case it does not happen immediately after an upgrade, it should be fixed in the binding.
2026-02-23 14:49:34.055 [WARN ] [core.thing.internal.ThingManagerImpl] - Failed to normalize configuration for thing 'ebus:HMU01:e2026358ab:5e2277dc59': {thing/channel=Type description ebus:HMU01_HCReturnTemp_HCReturnTemp for ebus:HMU01:e2026358ab:5e2277dc59:HMU01_HCReturnTemp#HCReturnTemp not found, although we checked the presence before.}
The answer to the polled ebus telegram is:
2026-02-24 09:16:32.645 [TRACE] [s.internal.handler.EBusBridgeHandler] - Unknown telegram FF 08 B5 14 05 05 29 03 FF FF B0 00 04 29 00 9E 01 30 00
@csowada: do you have any idea what i could do?
Edit: another telegram for the HC forward temperature (identical structure) still works out normal. This is very strange.
These are the 2 entries of my custom config file. The upper one (HCForwardTemp) works out, the lower one (HCReturnTemp) doesn’t since a while.
{
"label": "Vorlauf Temperatur",
"id": "HCForwardTemp",
"command": "B5 14",
"get": {
"master": [
{"type": "static", "default": "05 28 03 FF FF"}
],
"slave": [
{"type": "byte"},
{"type": "byte"},
{"name": "HCForwardTemp", "type": "word", "label": "Vorlauf Temperatur", "min": 0, "max": 1000, "factor": 0.1, "format":"%.1f °C"}
]
}
},
{
"label": "RĂĽcklauf Temperatur",
"id": "HCReturnTemp",
"command": "B5 14",
"get": {
"master": [
{"type": "static", "default": "05 29 03 FF FF"}
],
"slave": [
{"type": "byte"},
{"type": "byte"},
{"name": "HCReturnTemp", "type": "word", "label": "Rücklauf Temperatur", "min": 0, "max": 1000, "factor": 0.1, "format":"%.1f °C"}
]
}
},
@Chiuaua79 : Cor, are you still reading here? Do you have any hint for me?
It looks like the channel link is suddenly broken.
Have you tried restarting?
Clearing the OH cache?
In this case possibly relinking the item to the channel (is the channel even present in your thing?)
Thanks for your quick reply. Have tested this without any success. The entries in org.openhab.core.thing.link.ItemChannelLink.json are looking identical for HCForwardTemp and HCReturnTemp.
The channel comes from my custom config file. Have also created a new item. What i don’t understand is, that the polling is registered, the sent poll telegrams result in an answer, but the answer cannot be resolved (Found 0 command methods for this telegram)?
If you look onto my last post resolving the appropriate ebus telegram, do you still think that the channel link is broken? If yes, where could i further search for this?
Here are both log strings for ReturnTemp and ForwardTemp from csv.-files if “advanced logging” is enabled:
02.03.2026 08:28 FF 8 B5 14 05 05 29 03 FF FF B0 00 04 29 00 C8 01 A6 00
02.03.2026 08:24 FF 8 B5 14 05 05 28 03 FF FF EE 00 04 28 00 E6 01 E9 00 GET > HMU01.HCForwardTemp
The upper telegram remains unresolved.