This thread is talk about the eBUS adapter and ebusd software used to talk to eBUS enabled heating systems.
This is primarily Vaillant heat pumps and combi boilers.
But Atag boilers also allow connectivity.
You can purchase the hardware adapter from here (it ships from Germany)
https://ebusd.eu/myadapter/
With documentation to the latest software here:
I purchased the Rasperry Pi version of the adapter with a view to hooking up to my 5kW Arotherm Plus heatpump.
It slots into the GPIO header of the Pi and then is seen as a serial device from within Raspian OS.
You connect the eBUS connection using two wires to your devices.
I have all my eBUS connections coming into a Wago junction box so it was easy to add the eBUS into there. (ie heat pump controller, sensocomfort, internet gateway etc)
Note: the software uses minimal CPU resource etc, so any any old Pi should do the trick, even a Zero W should work. But as I wanted wired ethernet the only spare I had was a 4GB Pi4ā¦ so MASSIVE overkill for this.
Iām going from memory here as it was months ago that I set it up, but the software was no walk in the park. Itās as far removed from next, next, next, install complete as you can get.
Get ready for a rocky ride in the command line.
The software is located here
Once installed the biggest trouble was getting the software to pull in the fields from your particular device.
There are a bunch of config files that have mappings that map data from the ebus stream to actual known variables/data elements. ie, someone has worked out 1:1 what each piece of data relates to what field (ie flow temperature)
You can get a sense from this section on github
Just dive into into the following for example
Once you manage to get some data from your device into ebusd then you can fire this over to your local MQTT and then onto Home Assistant via auto discovery.
There are literally 100s of fields starting ebusd* in my Home Assistant.
Because I installed mine at the end of the heating season, Iāve barely played with it.
My initial thought was to ignore all the 100s of fluff sensors and see if I could just pull:
So that I could throw this over into emoncms and see what the Heat Pump App looked like with that data and see how it compared to my Sontex and SDM120 setup.
For those that might find it useful until this one builds up, thereās a 3 page ebusd thread on a Dutch forum(use the browser translate function).
@Zarch coincidentally, my adapter is on its way so very interested in seeing how it works. For me I am looking to connect it to an ATAG boiler.
Thanks for everything so far.
I was pleased when the adaptor turned up at v5, with built in wifi. Not done much yet, other than scan the bus using ebusd on Raspian, so all the posts above are very helpful.
Found that the ebusd package would not install on Ubuntu 22.04 when I tried, due to deprecated ssl library dependency. May have been sorted by now.
First play trying to match real data from my SDM120, heat meter and known temperature probes against the data coming from the ebusd (via Home Assistant)
Flow and Return look pretty usable, as do the indoor and outdoor temps.
Flow rate looks to be recording high (and not frequent enough)?
Same with electric in and heat out. Not sure how usable those are gonna be?
If we could get more frequent flow rate we could use that to determine heat out
Heat Output = Flow Rate x DT (flow minus return) x SHC (4.2 for water, 3.8 for gycol).
But weāll get no COP without decent electrical input
COP = heat output / electrical input.
Perhaps Iām not running the right config files (definitely a possibility) and there are better/more instant/frequent fields available for elec in, heat out and flow rate?
Could be the way HA records it. It only records changes IIRC.
Iād just fire the data out via MQTT or the HA emoncms integration (actually I use Node-RED addon in HA to do that as I can send a single MQTT JSON and poll the HA sensor at the rate I want).
This is incorrect.
ebusd does not update every key-value pair for every request. It returns the cached value for the last time it was read from the ebus.
It is correct - my post refers to polling the HA Sensors, not the eBus sensors.
Just wanted to make sure people wouldnāt think that to be possible, because ebusā behavior and limitations can be quite surprising 
On request, hereby the values I fetch from the eBUS (using v3 adapter, v5 is on itās way to here).
I used this csv instead of the base hmu csv: https://github.com/john30/ebusd-configuration/blob/22c230cb6d8b7a24af33efe4a437a1e477783786/ebusd-2.1.x/en/vaillant/08.hmu.csv
In Home Assistant some sensors get auto-discovered, others donāt. For example COP sensors are not mqtt auto disco, so I made these entries in configuration.yaml
- name: "ebusd hmu CopHc"
unit_of_measurement: ''
value_template: "{{value_json[\"0\"].value}}"
state_topic: "ebusd/hmu/CopHc"
state_class: measurement
- name: "ebusd hmu CopHcMonth"
unit_of_measurement: ''
value_template: "{{value_json[\"0\"].value}}"
state_topic: "ebusd/hmu/CopHcMonth"
state_class: measurement
- name: "ebusd hmu CopHwc"
unit_of_measurement: ''
value_template: "{{value_json[\"0\"].value}}"
state_topic: "ebusd/hmu/CopHwc"
state_class: measurement
- name: "ebusd hmu CopHwcMonth"
unit_of_measurement: ''
value_template: "{{value_json[\"0\"].value}}"
state_topic: "ebusd/hmu/CopHwcMonth"
state_class: measurement
- name: "ebusd hmu WaterThroughput"
unit_of_measurement: 'l/h'
value_template: "{{value_json[\"0\"].value}}"
state_topic: "ebusd/hmu/WaterThroughput"
state_class: measurement
- name: "ebusd hmu FlowPressure"
unit_of_measurement: 'bar'
value_template: "{{value_json[\"0\"].value}}"
state_topic: "ebusd/hmu/FlowPressure"
state_class: measurement
- name: "ebusd hmu SourcePressure"
unit_of_measurement: 'bar'
value_template: "{{value_json[\"0\"].value}}"
state_topic: "ebusd/hmu/SourcePressure"
state_class: measurement
- name: "ebusd hmu BuildingCircuitWaterPressure"
unit_of_measurement: 'bar'
value_template: "{{value_json[\"0\"].value}}"
state_topic: "ebusd/hmu/BuildingCircuitWaterPressure"
state_class: measurement
- name: "ebusd hmu LowPressure"
unit_of_measurement: 'bar'
value_template: "{{value_json[\"0\"].value}}"
state_topic: "ebusd/hmu/LowPressure"
state_class: measurement
- name: "ebusd hmu HighPressure"
unit_of_measurement: 'bar'
value_template: "{{value_json[\"0\"].value}}"
state_topic: "ebusd/hmu/HighPressure"
state_class: measurement
Then pushing some of these sensors to a local emoncms instance:
emoncms_history:
api_key: hiddenapikey
url: http://someurlhere
inputnode: 10
whitelist:
- sensor.wp_temps_temperature_6
- sensor.wp_temps_temperature_1
- sensor.wp_temps_temperature_3
- sensor.wp_temps_temperature_9
- sensor.wp_temps_temperature_4
- sensor.wp_temps_temperature_5
- sensor.wp_temps_temperature_8
- sensor.wp_temps_temperature_10
- sensor.wp_temps_temperature_2
- sensor.wp_temps_temperature_7
- sensor.ebusd_hmu_status01_temp1_4
- sensor.ebusd_hmu_waterthroughput
- sensor.ebusd_hmu_currentconsumedpower
- sensor.ebusd_hmu_currentyieldpower
- sensor.ebusd_hmu_cophc
- sensor.ebusd_hmu_cophcmonth
- sensor.ebusd_hmu_cophwc
- sensor.ebusd_hmu_cophwcmonth
- sensor.ebusd_hmu_flowtemp
- sensor.ebusd_hmu_returntemp_temps2
- sensor.v_wp_sdm230
- sensor.a_wp_sdm230
- sensor.va_wp_sdm230
- sensor.w_wp_sdm230
- sensor.kwh_imp_wp_sdm230
- sensor.v_wp_weerstand_sdm230
- sensor.a_wp_weerstand_sdm230
- sensor.va_wp_weerstand_sdm230
- sensor.w_wp_weerstand_sdm230
- sensor.kwh_imp_wp_weerstand_sdm230
- sensor.ebusd_700_displayedoutsidetemp_tempv
- sensor.ebusd_700_z1roomtemp_tempv
scan_interval: 15
Then in emoncms I made some input processing comboās to calculate heating or cooling in W
Calculated heat data ( heat transfer (W) = specific heat (J/kg.K) x flow rate (kg/s) x DT (K) )
Thanks really useful. I had a custom 08.hmu file which missed the waterthroughput attribute. Iāve now got this coming through (into node-red) and will start to calculate the Wh Accumalator so that I can take advantage of the heat pump dashboard. I measure power into the heat pump via a CT clamp.
Found that when driving towel rails the CoP is exaggerated.
So Iāve amended the flow to only calculate heat if flow / return delta > 1.5C
That looks like an error in one of the sensor readings resulting in the dT being higher than it actually is, since the compressor isnāt running the dT should quite quickly drop to close to zero. Measuring accurate heat transfer with low dT is quite tricky, this is why heat meters have a pair of temperature sensors which are calibrated together.
Just found out that these COP figures are the āworking figureā totals from the heat pump controller.
Excellent, saves me having to go to the controller / plant room to get these.
Hi guys,
Iām keen to join the ebus party on this thread. Iāve now got a Vaillant Arotherm+ up and running with an ebus reader connected to an emonBase via USB and running the ebusd docker container. I used this command to run the docker container and connect to the emonSD MQTT server
docker run -d --name=ebusd --device=/dev/ttyACM0 -p 8888 john30/ebusd --scanconfig -d /dev/ttyACM0 --mqttport=1883 --mqtthost=192.168.86.36 --mqttuser=emonpi --mqttpass=emonpimqtt2016
Looking at docker logs everything seems to be working fine, it seems to have detected the ebus:
2023-10-16 16:39:29.051 [main notice] ebusd 23.2.23.2 started with auto scan on device: /dev/ttyACM0
2023-10-16 16:39:29.899 [bus notice] bus started with own address 31/36
2023-10-16 16:39:29.901 [mqtt notice] connection established
2023-10-16 16:39:29.922 [bus notice] signal acquired
Iām trying to use automatic configuration with --scanconfig which a thought would automatically identify messages on the bus and download the relevant .csv config files, however this doesnāt seem to be happening. Hereās the only data being posted to MQTT so far:
ebusd/global/signal true
ebusd/global/version ebusd 23.2.23.2
ebusd/global/running true
ebusd/global/scan finished
ebusd/global/updatecheck OK
Any ideas what Iām missing? Are you guys using autoconfiguration? If not, any tips on how to setup a configuration to read basic data from an Arotherm+? I would particularly like to read DWH temperature and outdoor temperature.
Iāve been using Jones config files
Download those versions of files and then point the config file to where you downloaded
cat /etc/default/ebusd
EBUSD_OPTS="--scanconfig=full --configpath=/home/mick/jones/ebusd-configuration/ebusd-2.1.x/en -d ens:/dev/ttyAMA0 --latency=60 --loglevel=debug --mqtthost=carbone.lan --mqttport=1883 --mqttint=/etc/ebusd/mqtt-hassio.cfg --mqttjson"
Use the likes of ebusctl find -V to see all what is being discovered and ebusctl info.
I really need to write all this down as I have to refresh my memory (or like through my bash history) all the time. 
Thanks thatās really useful, Iāve got JonesPDās configuration loaded from https://github.com/jonesPD/ebusd-configuration/commits/master/ebusd-2.1.x
It looks promising
pi@emonhp:~ $ sudo docker logs ebusd
2023-10-16 23:59:39.309 [main notice] ebusd 23.2.23.2 started with full scan on device: /dev/ttyACM0
2023-10-16 23:59:40.145 [bus notice] bus started with own address 31/36
2023-10-16 23:59:40.180 [bus notice] signal acquired
2023-10-16 23:59:46.025 [bus notice] max. symbols per second: 101
2023-10-16 23:59:47.006 [bus notice] max. symbols per second: 116
2023-10-16 23:59:50.145 [main notice] starting initial full scan
2023-10-17 00:00:19.016 [bus notice] max. symbols per second: 157
2023-10-17 00:00:20.005 [bus notice] max. symbols per second: 184
2023-10-17 00:01:50.379 [main notice] update check: OK
However nothing extra is being posted to MQTT.
Attaching to the container to debug:
root@emonhp:/# ebusctl find -V
broadcast datetime = no data stored [ZZ=fe, passive read]
broadcast error = no data stored [ZZ=fe, passive read]
broadcast id = no data stored [ZZ=fe, passive read]
broadcast id = no data stored [ZZ=any, active read]
broadcast signoflife = no data stored [ZZ=fe, passive read]
memory eeprom = no data stored [ZZ=any, active read]
memory ram = no data stored [ZZ=any, active read]
root@emonhp:/# ebusctl info
version: ebusd 23.2.23.2
update check: OK
device: /dev/ttyACM0
signal: acquired
symbol rate: 94
max symbol rate: 170
scan: finished
reconnects: 0
masters: 1
messages: 11
conditional: 0
poll: 0
update: 4
address 31: master #8, ebusd
address 36: slave #8, ebusd
Everything looks correct, it seems to be detecting other devices on the bus and there are no errors. Is there anything else Iām missing to start it actually reading data?!
Could you double check the bus cabling?
mick@ebusd:~ $ ebusctl info
version: ebusd 23.1.23.1
update check: version 23.2 available, device firmware 1[3911] available, vaillant/08.hmu.csv: newer version available, vaillant/hcmode.inc: different version available
device: /dev/ttyAMA0, enhanced, firmware 1.1[3501].1[3501]
signal: acquired
symbol rate: 43
max symbol rate: 419
min arbitration micros: 7
max arbitration micros: 3613
min symbol latency: 2
max symbol latency: 11
reconnects: 1
masters: 6
messages: 590
conditional: 0
poll: 355
update: 10
address 00: master #1
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=HMU00;SW=0607;HW=5103", loaded "vaillant/08.hmu.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=BASV0;SW=0217;HW=8803", loaded vaillant/15.basv.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd, scanning
address 71: master #9
address 76: slave #9, scanned "MF=Vaillant;ID=VWZIO;SW=0202;HW=0103"
address f1: master #10
address f6: slave #10, scanned "MF=Vaillant;ID=NETX2;SW=4030;HW=5703"
mick@ebusd:~ $
The end of that output shows the devices it has found, which then shows the files it uses to decode the data.
The output from your āebusctl infoā just seems to show that it only knows about itself?
Also shown in your Masters:1 versus my Masters:6