Ebus binding

My problem was solved and it’s working right now, thanks!

Good to know. Thank you for your fast feedback
I’ll create a PR to provide an offical fixed version.

hello everone, I’m new in this forum hence true warm welcome.
I have 2 issues with my ebus biding (HW used is the one described on the FHEM website). Heating unit is vaillant, I use parsers bai00 and vrc470 (from the binding).
I have no clue if issues are related, I don’t think they are.
Issue #1 is: after some random time (or rather it looks random to me) my binding loses connectivity with the ebus which is represented by - eBUS read timeout occured, no data on bus … message
Issue #2: I can’t set values on eBUS. whatever I set can be seen in the log but then gets overriden by the value from the installation. I’m testing item for dhw operating mode (as it’s pretty convenient due to summer time)
Number ebus_vrc470_dhw_program_dhw_circuit “DHW Operation mode [%d]” (vaillant) { ebus=“id:dhw.program_dhw_circuit, set:dhw.set_program_dhw_circuit.program, refresh:60” }
this one is simplified as what I initially had was with MAP transformation but I thought this could be a problem and I removed it.

I have all log in TRACE in the file but don’t know if I can attach it here and probably just small sections won’t tell much…
I even tried latest jar from csowada above but no difference. can anyone help? I lost many evenings on this that it’s time to asked smarter people :slight_smile:

Hi i detected two bugs:

  1. when tring to change heat curve i get error like below

2017-08-03 22:47:03.625 [WARN ] [org.apache.karaf.services.eventadmin] - EventAdmin: Exception during event dispatch [org.osgi.service.event.Event [topic=openhab/command/cv_heating_curve] {bridgemarker=true, item=cv_heating_curve, command=0.40000004} | {org.osgi.service.cm.ManagedService, org.osgi.service.event.EventHandler}={event.topics=openhab/*, service.pid=org.openhab.ebus, component.name=org.openhab.binding.ebus, component.id=7, service.id=294, service.bundleid=182, service.scope=bundle} | Bundle(org.openhab.binding.ebus_1.10.0 [182])]
at java.lang.System.arraycopy(Native Method)[:1.8.0_131]
at org.openhab.binding.ebus.internal.connection.EBusCommandProcessor.composeEBusTelegram(EBusCommandProcessor.java:242)[182:org.openhab.binding.ebus:1.10.0]
at org.openhab.binding.ebus.internal.connection.EBusCommandProcessor.composeSendData(EBusCommandProcessor.java:334)[182:org.openhab.binding.ebus:1.10.0]
at org.openhab.binding.ebus.internal.EBusBinding.internalReceiveCommand(EBusBinding.java:76)[182:org.openhab.binding.ebus:1.10.0]
at org.openhab.core.binding.AbstractBinding.receiveCommand(AbstractBinding.java:97)[186:org.openhab.core.compat1x:2.1.0]
at org.openhab.core.events.AbstractEventSubscriber.handleEvent(AbstractEventSubscriber.java:45)[186:org.openhab.core.compat1x:2.1.0]
at org.apache.felix.eventadmin.impl.handler.EventHandlerProxy.sendEvent(EventHandlerProxy.java:415)[6:org.apache.karaf.services.eventadmin:4.0.8]
at org.apache.felix.eventadmin.impl.tasks.HandlerTask.run(HandlerTask.java:90)[6:org.apache.karaf.services.eventadmin:4.0.8]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)[:1.8.0_131]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_131]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_131]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_131]
at java.lang.Thread.run(Thread.java:748)[:1.8.0_131]

  1. reading of heating.temp_d_day / heating.temp_d_night is wrong after comma ex. set on vr470 19,5degC read 19,0 in ebus binding

@ csowada could you please resolve those issues?

Can you send me the raw Telegrams please.

@csowada, you asked me or @Kristo?
if myself I’m happy to share the log file but not sure how to do it in this forum. do you want copy paste here?
just in case it is useful - my try to change dhw mode to anything (I tried from 2=Auto to 1=On)
2017-08-03 21:48:30.932 [TRACE] [nal.connection.AbstractEBusConnector] - Auto-SYN byte received
2017-08-03 21:48:31.044 [TRACE] [onnection.AbstractEBusWriteConnector] - readin delay 47483
2017-08-03 21:48:31.060 [DEBUG] [onnection.AbstractEBusWriteConnector] - Succcesful send: FF 15 B5 09 03 0D 42 00 EC 00 01 02 99 00 AA
2017-08-03 21:48:31.063 [DEBUG] [inding.ebus.internal.parser.Analyses] - FF 15 B5 09 03 0D 42 00 EC 00 01 02 99 00 AA
2017-08-03 21:48:31.064 [TRACE] [onnection.AbstractEBusWriteConnector] - No access to ebus because the lock counter …
2017-08-03 21:48:31.065 [DEBUG] [inding.ebus.internal.parser.Analyses] - >>> DHW Operation mode
2017-08-03 21:48:31.067 [TRACE] [nal.connection.AbstractEBusConnector] - Auto-SYN byte received
2017-08-03 21:48:31.069 [TRACE] [inding.ebus.internal.parser.Analyses] - >>> dhw.program_dhw_circuit.program 2 DHW Operation mode
2017-08-03 21:48:31.070 [TRACE] [inding.ebus.internal.parser.Analyses] - >>> Auto
2017-08-03 21:48:31.076 [TRACE] [onnection.AbstractEBusWriteConnector] - No access to ebus because the lock counter …
2017-08-03 21:48:31.080 [TRACE] [nal.connection.AbstractEBusConnector] - Telegram too small, skip! Buffer: 00 AA
2017-08-03 21:48:31.181 [DEBUG] [inding.ebus.internal.parser.Analyses] - 70 08 B5 11 01 01 57 00 09 4F 4F E0 18 FF 56 00 00 37 71 00 AA
2017-08-03 21:48:31.182 [DEBUG] [inding.ebus.internal.parser.Analyses] - >>> Unknown ----------------------------------------
2017-08-03 21:48:31.183 [TRACE] [ding.ebus.internal.parser.BruteForce] - 70 08 B5 11 01 01 57 00 09 4F 4F E0 18 FF 56 00 00 37 71 00 AA
2017-08-03 21:48:31.184 [TRACE] [ding.ebus.internal.parser.BruteForce] - Pos WORD UInt DATA2B DATA2C DATA1c BCD
2017-08-03 21:48:31.185 [TRACE] [ding.ebus.internal.parser.BruteForce] - -----------------------------------------------------------------------------
2017-08-03 21:48:31.186 [TRACE] [ding.ebus.internal.parser.BruteForce] - 6 — 1 — — — 1
2017-08-03 21:48:31.187 [TRACE] [ding.ebus.internal.parser.BruteForce] - ---------------------------------- Answer ----------------------------------
2017-08-03 21:48:31.188 [TRACE] [ding.ebus.internal.parser.BruteForce] - 6 20303 79 79.30859 1268.9375 39.0 55
2017-08-03 21:48:31.190 [TRACE] [ding.ebus.internal.parser.BruteForce] - 7 -8113 79 -31.691406 -507.0625 112.0 55
2017-08-03 21:48:31.191 [TRACE] [ding.ebus.internal.parser.BruteForce] - 8 6368 224 24.875 398.0 12.0 -20
2017-08-03 21:48:31.193 [TRACE] [ding.ebus.internal.parser.BruteForce] - 9 -232 24 -0.90625 -14.5 127.0 18
2017-08-03 21:48:31.195 [TRACE] [ding.ebus.internal.parser.BruteForce] - 10 22271 255 86.99609 1391.9375 43.0 5
2017-08-03 21:48:31.196 [TRACE] [ding.ebus.internal.parser.BruteForce] - 11 86 86 0.3359375 5.375 0.0 56
2017-08-03 21:48:31.198 [TRACE] [ding.ebus.internal.parser.BruteForce] - 12 0 0 0.0 0.0 0.0 0
2017-08-03 21:48:31.199 [TRACE] [ding.ebus.internal.parser.BruteForce] - 13 14080 0 55.0 880.0 27.0 0
2017-08-03 21:48:31.201 [TRACE] [ding.ebus.internal.parser.BruteForce] - 14 — 55 — — — 37
2017-08-03 21:48:31.202 [TRACE] [ab.binding.ebus.internal.EBusBinding] - No valid parser result for raw telegram!
and after
2017-08-03 21:48:50.855 [TRACE] [onnection.AbstractEBusWriteConnector] - readin delay 47705
2017-08-03 21:48:50.873 [DEBUG] [onnection.AbstractEBusWriteConnector] - Succcesful send: FF 15 B5 09 04 0D 42 00 01 E5 00 01 02 99 00 AA
2017-08-03 21:48:50.873 [TRACE] [onnection.AbstractEBusWriteConnector] - No access to ebus because the lock counter …
2017-08-03 21:48:50.874 [TRACE] [nal.connection.AbstractEBusConnector] - Auto-SYN byte received
2017-08-03 21:48:50.875 [DEBUG] [inding.ebus.internal.parser.Analyses] - FF 15 B5 09 04 0D 42 00 01 E5 00 01 02 99 00 AA
2017-08-03 21:48:50.876 [DEBUG] [inding.ebus.internal.parser.Analyses] - >>> DHW Operation mode
2017-08-03 21:48:50.877 [TRACE] [inding.ebus.internal.parser.Analyses] - >>> dhw.program_dhw_circuit.program 1 DHW Operation mode
2017-08-03 21:48:50.878 [TRACE] [inding.ebus.internal.parser.Analyses] - >>> On
2017-08-03 21:48:50.887 [TRACE] [onnection.AbstractEBusWriteConnector] - No access to ebus because the lock counter …
2017-08-03 21:48:50.889 [TRACE] [nal.connection.AbstractEBusConnector] - Telegram too small, skip! Buffer: 00 AA
and again
2017-08-03 21:49:31.020 [TRACE] [onnection.AbstractEBusWriteConnector] - readin delay 47533
2017-08-03 21:49:31.038 [DEBUG] [onnection.AbstractEBusWriteConnector] - Succcesful send: FF 15 B5 09 03 0D 42 00 EC 00 01 02 99 00 AA
2017-08-03 21:49:31.041 [TRACE] [onnection.AbstractEBusWriteConnector] - No access to ebus because the lock counter …
2017-08-03 21:49:31.041 [DEBUG] [inding.ebus.internal.parser.Analyses] - FF 15 B5 09 03 0D 42 00 EC 00 01 02 99 00 AA
2017-08-03 21:49:31.042 [DEBUG] [inding.ebus.internal.parser.Analyses] - >>> DHW Operation mode
2017-08-03 21:49:31.043 [TRACE] [inding.ebus.internal.parser.Analyses] - >>> dhw.program_dhw_circuit.program 2 DHW Operation mode
2017-08-03 21:49:31.044 [TRACE] [inding.ebus.internal.parser.Analyses] - >>> Auto
2017-08-03 21:49:31.045 [TRACE] [nal.connection.AbstractEBusConnector] - Auto-SYN byte received
2017-08-03 21:49:31.053 [TRACE] [onnection.AbstractEBusWriteConnector] - No access to ebus because the lock counter …
2017-08-03 21:49:31.054 [TRACE] [nal.connection.AbstractEBusConnector] - Telegram too small, skip! Buffer: 00 AA
2017-08-03 21:49:31.100 [TRACE] [nal.connection.AbstractEBusConnector] - Auto-SYN byte received
overriding from ebus in OH2, but never changed in eBUS…
whole file in full TRACE can be sent over email (or attached here if it makes sense)

I want to share part of my custom json file for Vaillant VR630:
vr_630.json (7.7 KB)

Most of the commands I took from the ebusd-configuration, but some commands (getParameters, set_CircuitType, set_NightTemp etc) is not presented in ebusd-configuration, I found it by myself.

Items for example:

Number Vmc4_OperatingMode     "Operating mode"                   <i8_services>                      { ebus="id:circuits.Mode.operatingMode, dst:52, set:circuits.set_OperatingMode.value" }
Number Vmc4_TempDesired       "Desired temp [%d °C]"             <i8_temperature_set>               { ebus="id:circuits.Mode.tempDesired, dst:52, set:circuits.set_TempDesired.value" }
Number Vmc4_FlowTemp          "Current flow temp [%.2f °C]"      <i8_temperature>     (Temperature) { ebus="id:circuits.Status.FlowTemp, dst:52" }
Number Vmc4_FlowTempDesired   "Target flow temp [%.2f °C]"       <i8_temperature>                   { ebus="id:mc.FlowTempDesired.value, dst:52, refresh:304" }
Number Vmc4_PumpStatus        "Pump status [MAP(onoff.map):%s]"  <i8_pump>            (Boiler)      { ebus="id:mc.PumpStatus.value, dst:52, refresh:303" }
Number Vmc4_CircuitType       "Circuit type"                     <i8_circuit>                       { ebus="id:circuits.getParameters.circuitType, dst:52, refresh:3670, set:circuits.set_CircuitType.value" }
Number Vmc4_HeatingCurve      "Heating curve [%.1f]"             <i8_curve>                         { ebus="id:circuits.getParameters.heatingCurve, dst:52, set:circuits.set_HeatingCurve.value" }
Number Vmc4_OtShutdownLimit   "Max limit outs. temp [%d °C]"     <i8_temperature>                   { ebus="id:circuits.getParameters.otShutdownLimit, dst:52, set:circuits.set_OtShutdownLimit.value" }
Number Vmc4_FlowTempMin       "Minimum temp [%d °C]"             <i8_temperature>                   { ebus="id:circuits.getParameters.minTemp, dst:52, set:circuits.set_FlowTempMin.value" }
Number Vmc4_FlowTempMax       "Maximum temp [%d °C]"             <i8_temperature>                   { ebus="id:circuits.getParameters.maxTemp, dst:52, set:circuits.set_FlowTempMax.value" }
Number Vmc4_DayTemp           "Day temp [%d °C]"                 <i8_temperature>                   { ebus="id:circuits.getParameters.dayTemp, dst:52, set:circuits.set_DayTemp.value" }
Number Vmc4_NightTemp         "Night temp [%d °C]"               <i8_temperature>                   { ebus="id:circuits.getParameters.nightTemp, dst:52, set:circuits.set_NightTemp.value" }
Number Vmc4_PumpDelay         "Pump delay [%d m]"                <i8_delay>                         { ebus="id:circuits.getParameters.pumpDelay, dst:52, set:circuits.set_PumpDelay.value" }


Selection item=Vmc4_OperatingMode mappings=[1="Heating",3="Auto",4="Eco",5="Energy sav",2="Disabled"]
Setpoint item=Vmc4_TempDesired minValue=1 maxValue=65 step=1
Text item=Vmc4_FlowTemp
Text item=Vmc4_FlowTempDesired
Text item=Vmc4_PumpStatus
Selection item=Vmc4_CircuitType mappings=[128="Disabled",129="Mixing circuit",130="Fixed value",131="Cylinder circuit",132="Increase in return flow"]
Setpoint item=Vmc4_HeatingCurve minValue=0.1 maxValue=4 step=0.1
Setpoint item=Vmc4_PumpDelay minValue=0 maxValue=30 step=1
Setpoint item=Vmc4_OtShutdownLimit minValue=5 maxValue=50 step=1
Setpoint item=Vmc4_NightTemp minValue=15 maxValue=90 step=1
Setpoint item=Vmc4_FlowTempMin minValue=15 maxValue=90 step=1
Setpoint item=Vmc4_FlowTempMax minValue=15 maxValue=90 step=1

If somebody have a question about that - I’m glad to be helpful.

Could you please confirm if you are using custom json on Openhab2 ?
If yes could you please share Ebus.cfg file as i was not able to get proper configuration with custom

Yes, I’m using only custom json on Openhab2.

Default dir for a custom JSON is hidden very deep and it’s very inconvenient for editing. So I placed my custom JSON in Openhab2 config folder (/etc/openhab2) and in ebus.cfg my custom path looks ugly:

# Serial port of eBUS interface
# Valid values are e.g. COM1 for Windows and /dev/ttyS0 or /dev/ttyUSB0 for Linux

# Custom parser configuration file
# This example tries to load a configuration ${openhab_home}/configurations/ebus-config.json

# default uses common and all vendor specified telegrams

It will be very useful, if @csowada can make a change for using simple path definition: parserUrl=/etc/openhab2/bai.json. Maybe we already can use this, but I don’t know how.

@ morchee

Thank you now i can create my own custom :slight_smile:


I see that in ebusd csv files thay are using two levels of writing
1 - W - standard writing
2 - Wi - writing with installation privileges

is this second option supported by binding?

This no Problem for the binding. You can see the two different bytes per type on top of the file.
@all I hope have time this evening to check the issues.
Maybe the Version 2 of this binding is interesting for you, I am working in it since Winter.

@csowada, yes i’m interesting in version 2 could you please share?

I’d like to test it too if possible. many thanks in advance

this should normally work on Linux. Windows is a bit different.


More details on file URI syntax here:

1 Like


for your information, the version two alpha is out.

Hello eBUS users,

I need some tester to get feedback for the complete rewritten version for openHAB 2.0. You can now configure the binding from Paper UI, later it should work with Auto-Discovery. But this currently not my focus at the moment.
Currently I need feedback for stability and the basic communication on the bus like get, set polling etc.

1 Like

Hi Paul,
I do have a Weishaupt WTC as well and am interested in retrieving at leastsome basic information from it. I bought an Ebus coupler last year and tried to figure out the meaning of the telegrams but gave up after a couple of days.
I recently started with openhab an saw that there is a binding for the ebus. So I would now like to give it a new try.
First of all I tried some simple items with the common parser. my items file looks like this:

Number WTC_Status <temperature> {ebus="auto_stroker.status_auto_stroker, refresh:60"}
Number WTC_Temp_Kessel <temperature> {ebus="id:auto_stroker.temp_boiler, src:03, refresh:60"}

In my logfile I can see some entries related to the ebus, i.e.:

2017-11-01 15:07:44.189 [DEBUG] [inding.ebus.internal.parser.Analyses] - F1 FE 50 0A 0D 01 00 07 02 00 34 68 FF 00 80 00 00 08 5C AA
2017-11-01 15:07:44.190 [DEBUG] [inding.ebus.internal.parser.Analyses] -   >>> Unknown ----------------------------------------

Unfortunately I don’t get any values in my HABPanel.
Maybe you or somebody else here might give me a hint on how to start.

Best regards



before going back to testing your last Alpha, I made a setup based on the eBUS 1.x Binding (Testing) Binding.

So after all it seems that my boiler and VRC470 can both communicate with the ethernet coupler.

Here is my setup:



/* eBus VRC470 */
Number Controller_status_global_system_off     "Activation of operation mode system off - {0=Off, 1=On} [%.1f]"   <switch>    { ebus="id:controller.status_global_system_off, dst:15, refresh:300" }
Number Controller_temp_d_room_disp     "HC1 Currently displayed room desired temperature [%.1f °C]"   <temperature>    { ebus="id:controller.temp_d_room_disp, dst:15, refresh:300" }
Number Controller_temp_outside_status     "Outside temperature status - {0=Ok, 85=Circuit, 170=Cutoff} [%.1f]"   <switch>    { ebus="id:controller.temp_outside.status, dst:15, refresh:300" }
Number Controller_temp_outside_temp_outside     "Outside temperature [%.1f °C]"   <temperature>     { ebus="id:controller.temp_outside.temp_outside, dst:15, refresh:300" }
Number Controller_temp_room_status     "Room temperature status - {0=Ok, 85=Circuit, 170=Cutoff} [%.1f]"   <switch>    { ebus="id:controller.temp_room.status, dst:15, refresh:300" }
Number Controller_temp_room_temp_room     "Room temperature [%.1f °C]"   <temperature>     { ebus="id:controller.temp_room.temp_room, dst:15, refresh:300" }
Number Controller_temp_room_disp     "Room temperature Disp [%.1f °C]"   <temperature>     { ebus="id:controller.temp_room_disp, dst:15, refresh:300" }
Number Controller_dhw_program_dhw_circuit     "DHW Operation mode - {0=Off, 1=On, 2=Auto, 3=Auto Sunday, 4=Party, 6=LoadDHW, 7=Holiday} [%.1f]"   <switch>    { ebus="id:dhw.program_dhw_circuit, dst:15, refresh:300" }
Number Controller_dhw_temp_d_actual_dhw     "DHW actual desired temperature [%.1f °C]"   <temperature>     { ebus="id:dhw.temp_d_actual_dhw, dst:15, refresh:300" }
Number Controller_dhw_temp_d_dhw     "DHW setpoint [%.1f °C]"   <temperature>     { ebus="id:dhw.temp_d_dhw, dst:15, refresh:300" }
Number Controller_heating_program_heating_circuit             "HC1 Operation mode - {0=Off, 1=Manual, 2=Auto, 3=Day, 4=Night, 5=Summer} [%.1f]"   <switch>    { ebus="id:heating.program_heating_circuit, dst:15, refresh:300" }
Number Controller_heating_program_heating_circuit_special     "HC1 special Operation mode - {0=Nothing, 1=Party, 2=OneDayHome, 3=OneDayNotHome, 4=Holiday, 5=Home, 6=QuickVeto, 7=OneTimeVentilation, 8=WhisperMode, 9=LoadDHW} [%.1f]"   <switch>    { ebus="id:heating.program_heating_circuit_special, dst:15, refresh:300" }
Number Controller_heating_temp_d_day               "HC1 Day setpoint [%.1f °C]"              <temperature>     { ebus="id:heating.temp_d_day, dst:15, refresh:300" }
Number Controller_heating_temp_d_night             "HC1 Night setpoint [%.1f °C]"            <temperature>     { ebus="id:heating.temp_d_night, dst:15, refresh:300" }
Number Controller_heating_temp_d_room_override     "HC1 Manual override setpoint [%.1f °C]"  <temperature>     { ebus="id:heating.temp_d_room_override, dst:15, refresh:300" }
Number Controller_heating_temp_hcurve              "HC1 Heating curve [%.1f]"                                  { ebus="id:heating.temp_hcurve, dst:15, refresh:300" }
Number Controller_heating_temp_vf1_status       "VF1 temperature status - {0=Ok, 85=Circuit, 170=Cutoff} [%.1f]"   <switch>          { ebus="id:heating.temp_vf1.status, dst:15, refresh:300" }
Number Controller_heating_temp_vf1_temp_vf1     "VF1 temperature [%.1f °C]"                                        <temperature>     { ebus="id:heating.temp_vf1.temp_vf1, dst:15, refresh:300" }
/* eBus ecocompact */
Number Boiler_Blocktime_Boiler              "Boiler Max. burner anti-cycling time heating at 20 °C  [%.1f min]"  <time>       { ebus="id:boiler.blocktime_boiler, dst:08, refresh:300" }
Number Boiler_level_part_load               "Boiler Heating partial load [%.1f kW]"                              <energy>     { ebus="id:boiler.level_part_load, dst:08, refresh:300" }
Number Boiler_mode_summer_winter_switch     "Summer/winter operating mode - {0=off, 1=on} [%.1f]"                <switch>     { ebus="id:boiler.mode_summer_winter_switch, dst:08, refresh:300" }
Number Boiler_modulation_pump               "Actual pump speed [%.1f rpm]"                                       <speed>      { ebus="id:boiler.modulation_pump, dst:08, refresh:300" }
Number Boiler_postrun_pump                  "Overrun time of internal pump for heating mode  [%.1f min]"         <time>       { ebus="id:boiler.postrun_pump, dst:08, refresh:300" }
Number Boiler_Pressure_status               "Status system pressure - {0=Ok, 85=Circuit, 170=Cutoff} [%.1f]"     <switch>     { ebus="id:boiler.pressure.status, dst:08, refresh:300" }
Number Boiler_Pressure                      "Boiler Pressure [%.2f bar]"                                         <pressure>   { ebus="id:boiler.pressure.pressure, dst:08, refresh:300" }
Number Boiler_speed_d_fan                   "Fan speed target value [%.2f rpm]"                                  <speed>      { ebus="id:boiler.speed_d_fan, dst:08, refresh:300" }
Number Boiler_speed_fan                     "Fan speed [%.2f rpm]"                                               <speed>      { ebus="id:boiler.speed_fan, dst:08, refresh:300" }
Number Boiler_state_diverter_valve         "Position of the diverter valve - {0=heating, 40=parallel, 100=dhw} [%.1f]"    <switch>     { ebus="id:boiler.state_diverter_valve, dst:08, refresh:300" }
Number Boiler_state_gas_valve              "Gas valve status - {240=off, 15=on}  [%.1f]"                                  <switch>     { ebus="id:boiler.state_gas_valve, dst:08, refresh:300" }
Number Boiler_state_pump                  "Status of internal pump - {0=off, 1=on} [%.1f]"                                <switch>     { ebus="id:boiler.state_pump, dst:08, refresh:300" }
Number Boiler_state_pump_ext              "Status of external heating pump - {0=off, 1=on} [%.2f]"                        <switch>     { ebus="id:boiler.state_pump_ext, dst:08, refresh:300" }
Number Boiler_state_return_regulation     "Heating flow/return regulation changeover - {0=flow, 1=return} [%.1f]"         <switch>     { ebus="id:boiler.state_return_regulation, dst:08, refresh:300" }
Number DHW_Temperature_Cylinder_Top     "DHW Temperature Cylinder Top [%.1f °C]" <temperature>     { ebus="id:dhw.temp_cylinder.temp_cylinder, dst:08, refresh:300" }
Number Boiler_Temperature_Target_Supply "Boiler Temperature Target Supply [%.1f °C]"  <temperature>  { ebus="id:boiler.temp_d_flow, dst:08, refresh:300" }
Number Boiler_Temperature_Supply   "Boiler Temperature Supply [%.1f °C]" <temperature>    { ebus="id:boiler.temp_flow.temp_flow, dst:08, refresh:300" }
Number Boiler_Temperature_Return   "Boiler Temperature Return [%.1f °C]" <temperature>    { ebus="id:boiler.temp_return.temp_return, dst:08, refresh:300" }
Number Boiler_dhw_temp_cylinder_temp_cylinder   "Measured value of hot water sensor [%.1f °C]" <temperature>    { ebus="id:dhw.temp_cylinder.temp_cylinder, dst:08, refresh:300" }
Number Boiler_dhw_temp_d_cylinder   "Cylinder temperature target value [%.1f °C]" <temperature>    { ebus="id:dhw.temp_d_cylinder, dst:08, refresh:300" }
Number Boiler_dhw_temp_d_dhw   "Hot water temperature target value [%.1f °C]" <temperature>    { ebus="id:dhw.temp_d_dhw, dst:08, refresh:300" }
Number Boiler_heating_runtime   "Operating hours, heating [%.1f h]"                            { ebus="id:heating.runtime, dst:08, refresh:300" }
Number Boiler_heating_starts   "Burner start-ups in heating mode (x100) [%.1f]"                { ebus="id:heating.starts, dst:08, refresh:300" }

This config have still some work to sort out unusefull data, but at least I have a baseline to work on and gets data from the boiler and from the VRC470.
I get the ebus-all,debug,unknown.csv file after some days, and used a pivot table in Excel to get some stat on the error telegrams. Sorting with Type, SRC, DST, CMD and Comment, I get apparently only unknown messages:

How should I interpret the fact that only messages from the VRC to broadcast or to the boiler are marked here ? Did I miss an option in the “record” parameter, or is it that just these telegram are missing definition and that others are properly identified ?

Hi Thomas,

I’ve not managed to decode much from the communication, Below the items
I’m using wish there was more documentation on the Weishaupt protocol.
Too bad they do not disclose anything.

I have following items configured: ( these remained after I had items
configured for about anything this binding could deliver and then picked
out the ones that returned some data. I did not dig further into the
meaning of the status flags, but I think they have to do with what is
set on the thermostat (day/night summer/vacation or so)

Number HU_Temp_T_Warm_Wather “Hotwater (target) temp. [%.1f °C]”
(HeatingUnit,Temperature) {
Number HU_Temp_T_Heat_Vessel “Boiler (target) temp. [%.1f °C]”
(HeatingUnit,HU_Chart1,Temperature) {
Number HU_Temp_OutdoorC “Outdoor temp. [%.1f °C]”
(HeatingUnit,Temperature) {
String HU_Time “Thermostat time
(HeatingUnit) { ebus=“id:common.time”}
Number HU_StatusReq1 “Status Request 1 [%s]”
{ ebus=“id:controller.status_heat_req1”}
Number HU_StatusReq2 “Status Request 2 [%s]”
{ ebus=“id:controller.status_heat_req2”}

in the openhab.cfg file I have following relating to the eBus (I’m
running 1.8.3 version of OH still)


Write all/debug/unknown telegrams to a CSV file in folder


logfile is at /var/lib/openhab/persistence/ebus/ebus-all,debug,unknown.csv


I hope this may help you.

I have thrown all my E-bus and Weishaupts WTC related notes I gathered
when looking into the matter into a document. Hope it can help anyone
forward. A few WTC related details are from the WTC manual in Dutch.
You should however be able to find the same info in your own language or
use google translate.


My plan was to use the ebus to somehow be able to send a command to the
system to turn On/Off the central heating depending on someone being in
the house or coming home. But it looks that sending info to the WTC is
not going to happen. So my backup plan is to use a relay to tell the
WTC that the condensate pump reservoir is full which will make the
system go into a STOP condition ( using H2 input on the WTC) . (not
ideal, but should do the trick but don’t like the, fact to come with
live 220V power near my rPi since the switch on the WTC is not galvanic
isolated) This is why you see also some documentation on the internal
settings of the WTC so I can use one of the contacts to put the system
in error mode. (my heating installer had not bothered to connect that
condensate overflow fault line and so I had some small flooding when it
failed… this is now taken care off)


In order to simplify things creation from the definition available from the json documentation (https://github.com/openhab/openhab1-addons/blob/1.8/bundles/binding/org.openhab.binding.ebus/docs/json-files/common.md)

I made an Excel spreadsheet generator.

Things definition are created from id, type and comment from the json documentation, as well as prefix name, type, data format, destination address that can easily manipulated within the spreadsheet. These things definition can then just be copy and paste in items file.

The spreadsheet calculate too sitmap text object definition that just have to be copy & paste to.