Wiki contribution #781
Mathadon
started this conversation in
Show and tell
Wiki contribution
#781
Replies: 1 comment 1 reply
-
|
Fantastic piece of work, thanks for making it available. It answered a number of questions that I couldn't find answers to elsewhere. I built several of those ebuzzz adapters for myself and others. It works really well on Vaillant boilers. Mike |
Beta Was this translation helpful? Give feedback.
1 reply
-
|
thank you @Mathadon . This Wiki contribution should be referenced on the homepage. Great stuff. |
Beta Was this translation helpful? Give feedback.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I had some difficulty finding my way through the documentation and GitHub issues trying to set set points for my boiler. I would like to contribute my findings of how I eventually got things working and important steps in the process, such that other can apply it to their case/device. My suggestion would be to include this post as a wiki page and I'd be glad to further clarify in this discussion in case it is not clear.
Goal
I want to control my Bulex (Saunier Duval) Thermomaster: be able to set its supply water set point for the heating system of my house. The heater supports
ebusso I ended up on this Github repository a few years ago but only now managed to find the time to dig a bit deeper and finally got things working.Hardware
I bought an Esara ebusd USB coupler and 'tuned' the potentiometer a few years ago. I can't comment on the process since I don't recall. In the meantime it seems however that this device is no longer needed since a raspberry Pi's GPIO pins can be used as well. See more about this on this wiki page. I did not test this yet but I intend to in the (perhaps very distant) future.
Edit 9/3/2023, caution, only more or less accurate:
I connected the USB coupler to my boiler, which roughly consisted of the following steps:
Next, I coupled the USB port of the coupler to a Raspberry pi. After logging in to the raspberry pi through ssh (or in a different way), the coupler should now be listed under
ls /dev/ttyUSB0.Installing ebusd
Install libtool if you didn't do so before:
sudo apt-get update && sudo apt-get install libtoolThe following steps were taken to install
ebusd, based on the documentation.git clone https://github.com/john30/ebusd.git cd ebusd ./autogen.sh sudo make install-stripStarting ebusd
At this point ebusd is installed but not running. It took a while before I understood that
ebusdis intended to run in the background: you start up a process using the commandebusdand you can communicate with that 'daemon' using tcp using the commandebusctl. Furthermore, the ebusd log can be inspected at/var/log/ebusd.logand contains a log of the information that passes on the bus.Ebusd can be started from the command line and requires some parameters/arguments. Defaults for these parameters can be set using environment variables or in the file
/etc/default/ebusdbut somehow that file is ignored for me. I still have to pass all the arguments toebusd. The following set of arguments worked for what I wanted to achieve:Some clarification:
-d /dev/ttyUSB0points ebusd to the device I want to use.--enablehexenables a mode where you can directly write hexadecimal commands to the bus. I needed--scanconfig=fullinstead of--scanconfigto get my device detected. Scanconfig documentation here.Scanning the bus
At this point you should be able to run:
and get an output like this:
However, if you didn't wait long enough after starting
ebusd, it didn't have time yet to detect which devices were on the bus, and you can get something like this:You get the same output when not using
--scanconfig=full. The log does not show which type of devices are connected and that's not a good sign.Inspecting the log
At his point it's useful to have a look at the log, which may look like this:
The most important lines are these:
which indicate that a boiler 'bai' was found at address 8 and a thermostat on address 15. The configuration files
08.bai.csvand15.e7c.csvwere loaded that allow human interpretation of the messages that are sent between these two devices. Note thatebusctl inforeturns some more information about the master and slave addresses of both devices.The configuration files that are mentioned above are hosted at https://github.com/john30/ebusd-configuration and are automatically downloaded by ebusd by default. You can also download them manually, modify them if needed and point ebusd to the path of the configuration files. See the documentation for more information.
Listening on the bus
Before controlling my boiler, I wanted to see what communication is passing on the bus between the existing Exacontrol C7 thermostat and the Thermomaster.
You can do this by using the command
ebusctl listen, which prints commands to the terminal at the time that they appear on the bus, e.g.:but I found that inspecting the log
/var/log/ebusd.logis more handy since it provides more information (timestamps and an indication of what is a read and what is a write command):From this output it seems that the thermostat uses the command
Status01andStatus02to request information from the boiler (QQ=10 is the master address of the thermostat, which is the sender of the command, documentation here).Furthermore, the thermostat issues a write command
SetMode, this is the interesting part! More about that later.Issuing a read command
So the thermostat reads data from the boiler. That sounds pretty benign, let's try to mimic that using the
readcommand before attempting to write to the bus and make something go horribly wrong:If you didn't wait long enough after starting ebusd, or something else went wrong, you can get the following result:
this means that 'Status01' is not recognised using the loaded configuration files (which may be none at all).
If everything is working properly you get something like:
which lists two temperatures and something that is 'off': supply and return water temperature and the circulation pump.
However, issuing this command multiple times in a row results in the same result, even when the display of the heater shows that the temperatures are changing. That's because by default the cached result is returned. Use the
-fflag to force read from the bus:Issuing a write command
Writing is where things get difficult. Ebusd was designed to protect you from doing stupid things to your boiler. So proceed with care here, these instructions worked for me, but there is no guarantee that it will result in the expected outcome for you too.
Looking again at the log, we see things like:
Based on this line
in the configuration file of hcmode the '68' is the desired flow temperature. So it would be tempting to try
ebusctl write -c bai SetMode '50.0;54.0;-;-;-;on'based on this post to try to write a set point of 50 degrees. The result is:
Based on this post that's because the field is not intended to be written: it has the specification
uw.The underlying problem is that the thermostat writes
SetModeevery 10 seconds so anything that we write would be overwritten pretty soon by the thermostat. So ebusd does not allow writing to this command. However, I want my Raspberry pi to replace the thermostat, so I would not have that problem. @andig and @Mateo89 suggest to create a new definition that haswiinstead ofuwto cope with this here.However, it's not really clear to me from these posts why one thing works and another thing does not. It's a bit black magic and that doesn't feel reassuring to go forward. At the end of the day, the messages that are sent to the boiler are really not that complex. How hard can it be to correctly mimic them? So I tried to directly write HEX messages to the boiler instead of creating a custom message definition.
Issuing a hex command
As mentioned before, ebusd interprets command using configuration files. The data that is sent over ebus are just bits and bytes with a specific format. Let's try to mimic those instead. Some examples can be shown using
ebusctl grab:It looks like the format here is
<HEX command> / <HEX response> = <number of these responses> : <interpreted device> <interpreted command>.So the command for our previous read request
Status01is1008b5110101, where10is the sender address,08is the receiver address.Se we can do this:
to execute the Status01 command and we receive the result
094e4c0080ffff0000ff. Note that we had to drop the sender address for this to work since ebusd automatically adds the sender address. And we do not need to-f(orce)anything since hex command results are not cached.So on to writing.. Let's decode these messages from
ebusctl grab:Based on an educated guess they correspond to the following messages from the log:
So it seems that the number
73corresponds to 57.5 degrees, since it is pretty much the only thing that changed between these hex commands. After some digging in here (temp1), a link betweentemp1andD1Chere, and the following codefrom https://github.com/john30/ebusd/blob/bc3e6110c7f6e12d9912e09d061c9dd5f335de39/src/lib/ebus/datatype.cpp it seems that the two hex numbers are converted in a temperature using the following math:
indeed, (7*16+3)/2=57.5C.
So we can substitute the temperature in the message
08b510090000<HEX TEMP HERE>76ffff000100to write a temperature set point and to enable the pump. The response of the boiler should be0101:and we'll just write
08b5100900000076ffff010100to disable the boiler.Note that the thermostat should be disconnected if you don't want it to overwrite your commands.
This seems to work fine for me but without extensive testing so far. It seems that the boiler remembers this command for 15 minutes and after that timeout period it shuts itself down. So the system seems robust against a sudden disconnection of the raspberry pi.
Edit: When testing a Vaillant boiler, it did NOT shut itself down after not sending new commands to the boiler.
Edit2: It seems that the Bulex boiler also does not shut itself down. It maintains the latest temperature set point.
It was quite a challenge to piece together everything to get this working. I hope this helps someone :)
Beta Was this translation helpful? Give feedback.
All reactions