ebusd
ebusd copied to clipboard
ebusd and Vaillant Ecotec Plus (Vaillant VCW PL 296), cant get ebusctl to talk to ebusd reliably
Description
Im trying to set up ebusd with a Vaillant VCW PL 296 boiler and I cannot get ebusctl to reliably talk to ebusd.
Very often the commands just fail silently after 30 or so seconds. example:
boiler@boiler:~$ ebusctl
localhost: info
version: ebusd 22.3.p20220508
device: /dev/ttyUSB0
signal: acquired
symbol rate: 22
max symbol rate: 29
reconnects: 0
masters: 2
messages: 1
conditional: 0
poll: 0
update: 0
address 03: master #11
address 31: master #8, ebusd
address 36: slave #8, ebusd
localhost: help [30 sec wait no output]
localhost: read [30 sec wait no output]
localhost: info [30 sec wait, no output]
localhost: q
[immediate exit]
boiler@boiler:~$ ebusctl read Flame # prints output below after a long delay
ERR: element not found
boiler@boiler:~$
I've let ebusd run overnight with the following options in /etc/default/ebusd EBUSD_OPTS="--scanconfig -c /home/boiler/ebusd-configuration-master/ebusd-2.1.x/"
The path to -c is where I have cloned the ebusd-configuration repository. The raspberry pi this system is running on is not currently connected to a the internet, i have to run a cable to the boiler cabinet. I'm using a point to point link on my laptop (laptop runs dhcpd on it's ethernet port)
I am using an esera USB-eBus coupler on /dev/ttyUSB0
in case this is a boiler-ebusd communications issue I've attached an ebusd log that I captured earlier by manually running ebusd (note that kociol
is polish for boiler, this is the actual RasPi hostname)
ebusd-pierwszy-vaillant.log
In this log file ebusd recognizes my boiler:
2022-08-24 20:45:26.891 [bus notice] scan 08: ;Vaillant;BAI00;0516;7401
2022-08-24 20:45:26.891 [update notice] store 08 ident: done
2022-08-24 20:45:26.891 [update notice] sent scan-read scan.08 QQ=31: Vaillant;BAI00;0516;7401
2022-08-24 20:45:26.891 [bus notice] scan 08: ;Vaillant;BAI00;0516;7401
Note that it uses a different set of CSV files, I tried to manaully mirror https://upd.ebusd.eu/ to download all the files into the folder which is specified in the command there. It reported a lot of CSV errors so I decided to clone the repo instead.
How can i read out the register values and data from my boiler?
Actual behavior
ebusctl fails silently
Expected behavior
ebusctl should at least report TCP timeout
ebusd version
22.3
ebusd arguments
--scanconfig -c /home/boiler/ebusd-configuration-master/ebusd-2.1.x/
Operating system
Debian 11 (Bullseye) / Raspbian 11 / Ubuntu 20-21
CPU architecture
armv7l
Dockerized
No response
Hardware interface
Esera USB
Related integration
No response
Logs
You are from Poland?
Yeah
Did you restart the Bus of your Heating system or the whole heating system after you started the edbusd?
Oh just had a look on the logfile, your csv files are broken, there is data missing in them 2022-08-24 20:45:26.896 [main error] error reading templates in vaillant: ERR: end of input reached, last error: vaillant/_templates.csv:8: ERR: end of input reached, no fields 2022-08-24 20:45:26.897 [main error] error reading scan config file vaillant/08.bai.csv for ID "bai00", SW0516, HW7401: ERR: missing argument, vaillant/08.bai.csv:8: ERR: missing argument, circuit 2022-08-24 20:45:26.897 [main error] scan config 08: ERR: missing argument
I tried restarting the whole system, the usb adapter and the boiler are the only devices on the bus. ebusd then gets the signal again but it does not change anything
śr., 31 sie 2022, 07:03 użytkownik mf76130 @.***> napisał:
Did you restart the Bus of your Heating system or the whole heating system after you started the edbusd?
— Reply to this email directly, view it on GitHub https://github.com/john30/ebusd/issues/635#issuecomment-1232466550, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABIK5E66OXY5CX3WTZ7EH3TV33RR3ANCNFSM57WFNF4Q . You are receiving this because you authored the thread.Message ID: @.***>
I am not an expert on the program, but the error message you shared says that these 2 files in the vaillant folder are not correct: _templates.csv 08.bai.csv
try to download working ones from github https://github.com/john30/ebusd-configuration/tree/master/ebusd-2.1.x/en
I noticed that, later I cloned the ebusd-configuration repo and was pointing the daemon to it's path. This stopped the unknown message errors in the log, but since then ebusd does not identify my boiler. Sometimes it will print that a new bus master was found but it does not identify it like in the first log.
śr., 31 sie 2022, 10:21 użytkownik mf76130 @.***> napisał:
I am not an expert on the program, but the error message you shared says that these 2 files in the vaillant folder are not correct: _templates.csv 08.bai.csv
try to download working ones from github https://github.com/john30/ebusd-configuration/tree/master/ebusd-2.1.x/en
— Reply to this email directly, view it on GitHub https://github.com/john30/ebusd/issues/635#issuecomment-1232620381, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABIK5EZH5ZBXJ5XIOVJUQKDV34IXBANCNFSM57WFNF4Q . You are receiving this because you authored the thread.Message ID: @.***>
Did you test your config with --checkconfig? example: run in the terminal: ebusd --configpath=/etc/ebusd/ -d /dev/ttyUSB0 --latency=0 --loglevel=info --poll=9 --scanconfig=full --httpport=8889 --htmlpath=/var/ebusd/html --checkconfig
this then shows you if there are problems with the files or the config
I did run it with --checkconfig and it reported no errors
I have a similar behaviour- Yesterday i moved my esera adapter and my vr900 into my switchboard and used a cat 6 cable for the bus. On the first start, VR900 said, unknown bus signal and the esera + pi recognised on address 15 the 7000 and loaded 15.700.csv and did recognise all data from it. After the 3rd reboot VR900 worked again and esera + pi didn't recognise address 15 anymore. Running over night now it found the 7000 again but did not load the csv.
I don't understand why it only can load the csv files on the start and not during a run. Maybe static load of the csv files could fix that? Is there a way to set in the config always load csv file 08.hmu,csv and 15.700.csv?
I just started testing without --scanconfig I just have the files i need local stored and now i get more data. Just waiting if i also get the energy values later on, as the 15.700 always took longer to be recognised
@mf76130 Can you post the entire command you are running or have in /etc/default/ebusd
? How did you tell which files you need locally?
Scanconfig found the devices over time anyhow, but didn't load files, but with the info about the devices i could see which files i needed (08.hmu.csv and 15.700.csv), the rest is just the minimum standard files you need.
also running ebusctl scan
and later ebusctl scan result
show your devices
08;Vaillant;HMU01;0306;8802
15;Vaillant;70000;0209;4103
e8;Vaillant;FMU00;0202;6502
Running
ebusctl --configpath=/etc/ebusd/ -d /dev/ttyUSB0 --checkconfig
shows you also if files you need for your csv are missing
config:
EBUSD_OPTS="--configpath=/etc/ebusd/ -d /dev/ttyUSB0 --latency=0 --pollinterval=120 --loglevel=debug --mqttint=/etc/ebusd/mqtt-hassio.cfg --mqttjson --mqtthost=192.168.0.17 --mqttport=1883 --mqttuser=mysupersecretusername --mqttpass=mysupersecretpassword --mqttjson"
subfolder vaillant:
when the communicaion is so unreliable, then the scanning can't work very well. with the next release, this should be much better as the scanning will continue until successful. until the release is available, you can clone the repo and build the binary yourself
ebusd 22.4 is out and it continues to try scanning devices until successful, maybe that helps
Updated to 22.4 (deb file for buster on arm7). Checking config returns this output
$ ebusd -c /home/boiler/ebusd-configuration-master/ebusd-2.1.x/en --checkconfig
2022-09-22 19:29:44.457 [main notice] ebusd 22.4.v22.4 performing configuration check...
2022-09-22 19:30:23.479 [main notice] found messages: 13646 (444 conditional on 164 conditions, 17 poll, 69 update)
Which I guess means that it is OK. Running 22.4 like this
$ sudo ebusd -c /home/boiler/ebusd-configuration-master/ebusd-2.1.x/en -s -f --loglevel=debug --lograwdata
Generally starts okay:
2022-09-22 19:34:46.863 [main notice] ebusd 22.4.v22.4 started with auto scan on device /dev/ttyUSB0
2022-09-22 19:34:46.864 [main info] loading configuration files from /home/boiler/ebusd-configuration-master/ebusd-2.1.x/en/
2022-09-22 19:34:46.864 [main debug] reading directory /home/boiler/ebusd-configuration-master/ebusd-2.1.x/en/
2022-09-22 19:34:46.864 [main debug] file type of /home/boiler/ebusd-configuration-master/ebusd-2.1.x/en/memory.csv is file
2022-09-22 19:34:46.864 [main debug] file type of /home/boiler/ebusd-configuration-master/ebusd-2.1.x/en/_templates.csv is file
2022-09-22 19:34:46.865 [main debug] file type of /home/boiler/ebusd-configuration-master/ebusd-2.1.x/en/vaillant is dir
2022-09-22 19:34:46.866 [main debug] file type of /home/boiler/ebusd-configuration-master/ebusd-2.1.x/en/broadcast.csv is file
2022-09-22 19:34:46.866 [main info] reading templates /
2022-09-22 19:34:46.871 [main info] read templates in /
2022-09-22 19:34:46.871 [main info] reading file memory.csv
2022-09-22 19:34:46.874 [main info] successfully read file memory.csv
2022-09-22 19:34:46.874 [main info] reading file broadcast.csv
2022-09-22 19:34:46.878 [main info] successfully read file broadcast.csv
2022-09-22 19:34:46.878 [main info] read config files, got 11 messages
2022-09-22 19:34:46.897 [bus notice] bus started with own address 31/36
2022-09-22 19:34:46.898 [main info] registering data handlers
2022-09-22 19:34:46.898 [main info] registered data handlers
2022-09-22 19:34:46.928 [bus debug] ERR: SYN received during no signal, switching to ready
2022-09-22 19:34:46.928 [bus notice] signal acquired
Then it finds the boiler:
2022-09-22 19:36:37.314 [bus notice] new master 03, master count 2
2022-09-22 19:36:37.351 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2022-09-22 19:36:37.822 [bus notice] <0364b5120202fe98
2022-09-22 19:36:41.795 [main debug] performing regular tasks
2022-09-22 19:36:41.796 [bus info] scan 08 cmd: 3108070400
2022-09-22 19:36:41.814 [bus debug] start request 31
2022-09-22 19:36:41.814 [bus debug] arbitration start with 31
2022-09-22 19:36:41.903 [bus notice] >31
2022-09-22 19:36:41.947 [bus notice] >31
[ last message repeated a significant number of times ]
2022-09-22 19:36:42.585 [bus debug] arbitration lost
2022-09-22 19:36:42.586 [bus debug] ERR: arbitration lost during ready, retry
2022-09-22 19:36:42.651 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2022-09-22 19:36:42.651 [bus debug] start request 31
2022-09-22 19:36:42.651 [bus debug] arbitration start with 31
2022-09-22 19:36:43.121 [bus notice] >31<0364b5120202fe98
2022-09-22 19:36:43.167 [bus notice] >31
2022-09-22 19:36:43.211 [bus notice] >31
[ And so on... ]
Which leads me to the conclusion there must be some issues on the bus. I will take a look at the physical layer for now, unless you have some other idea.
On the electrical level the bus signalling looks OK. BUS+ goes to A on the esera coupler and BUS- goes to B, just to make sure - is that right?
I've seen the repeated 0x31 byte on the oscilloscope on the bus.
I've also noticed that running it without --scanconfig makes it traverse all the CSV files, while running with --scanconfig only the files listed in the previous comment's log.
Then i've changed the ebusd address to 77
and the repeated pattern sent changed to > 77
which im assuming is not right, as ebusd simply spams the bus with it's own address.
I've checked this on the latest config. Also, in this state (keeps sending own address), it cannot be stopped with SIGINT from the terminal. I have to kill -9 it.
as you can see in the log, the sent data (>31
) can never be retrieved back (missing <31
), so the adapter is either not able to write to the bus or it doesn't interpret the read value correctly, which is most certainly due to not well adjusted poti. this way you can't use it for writing and you'd better switch to readonly mode.
the pattern you see is due to ebusd trying to get an arbitration in order to send a message. if it never receives back the sent value, it is a permanent error. you should see on the oszi that ebusd only sends its own address immediately after a received SYN (0xaa).
Thank you, I will try the readonly mode for now. What is poti and how can I adjust it?
sob., 24 wrz 2022, 14:09 użytkownik John @.***> napisał:
as you can see in the log, the sent data (>31) can never be retrieved back (missing <31), so the adapter is either not able to write to the bus or it doesn't interpret the read value correctly, which is most certainly due to not well adjusted poti. this way you can't use it for writing and you'd better switch to readonly mode.
the pattern you see is due to ebusd trying to get an arbitration in order to send a message. if it never receives back the sent value, it is a permanent error. you should see on the oszi that ebusd only sends its own address immediately after a received SYN (0xaa).
— Reply to this email directly, view it on GitHub https://github.com/john30/ebusd/issues/635#issuecomment-1256954392, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABIK5E3NGBU74LWICLKSEPLV73VOFANCNFSM57WFNF4Q . You are receiving this because you authored the thread.Message ID: @.***>
https://github.com/john30/ebusd/wiki/6.-Hardware#adjusting-the-potentiometer
I've adjusted the potentiometer and ran ebusd like this
sudo ebusd -c /home/boiler/ebusd-configuration/ebusd-2.1.x/en -f -d/dev/ttyUSB0 --scanconfig
It finds the master but fails to load a CSV file and there are no parameters available
2022-09-24 20:20:59.107 [main notice] ebusd 22.4.v22.4 started with auto scan on device /dev/ttyUSB0
2022-09-24 20:20:59.129 [bus notice] bus started with own address 31/36
2022-09-24 20:20:59.163 [bus notice] signal acquired
2022-09-24 20:21:34.355 [bus notice] new master 03, master count 2
2022-09-24 20:21:36.857 [main error] scan config 08: ERR: read timeout
2022-09-24 20:22:08.963 [main error] scan config 08: ERR: ACK error
2022-09-24 20:23:18.671 [main error] scan config 08: ERR: read timeout
As i saw in other blog posts it should print out some information about the new device like Vaillant;BAI00;0204;9602
or similar (the numbers would be different) when a new master is found.
When I restart the boiler while ebusd is running i get the following messages
2022-09-24 20:26:32.024 [bus error] signal lost
2022-09-24 20:26:32.687 [bus notice] signal acquired
2022-09-24 20:26:32.754 [bus notice] new master 03, master count 2
2022-09-24 20:26:32.754 [update notice] received update-read broadcast error QQ=03: BAI
2022-09-24 20:26:36.921 [main error] scan config 08: ERR: read timeout
2022-09-24 20:26:57.815 [main error] scan config 08: ERR: read timeout
2022-09-24 20:30:29.482 [main error] scan config 08: ERR: ACK error
2022-09-24 20:31:41.596 [main error] scan config 08: ERR: wrong symbol received
2022-09-24 20:34:05.831 [main error] scan config 08: ERR: ACK error
2022-09-24 20:37:42.162 [main error] scan config 08: ERR: read timeout
2022-09-24 20:38:54.254 [main error] scan config 08: ERR: wrong symbol received
And the messages repeat more less like that. Is there some setting on the boiler to enable something? I am not sure what the problem is because when running ebusd with the raw log options i saw messages coming to ebusd.
Is this a hardware/communications issue?
I have ran it with --lograwdata again. here is the bytes on the bus
$ sudo ebusd -c /home/boiler/ebusd-configuration/ebusd-2.1.x/en -f -d/dev/ttyUSB0 --latency=200 --lograwdata -s
2022-09-24 21:09:22.891 [main notice] ebusd 22.4.v22.4 started with auto scan on device /dev/ttyUSB0
2022-09-24 21:09:22.913 [bus notice] bus started with own address 31/36
2022-09-24 21:09:22.954 [bus notice] signal acquired
2022-09-24 21:09:22.988 [bus notice] new master 03, master count 2
2022-09-24 21:09:23.499 [bus notice] <0364b51202020066
2022-09-24 21:09:28.803 [bus notice] <0364b51202020066
2022-09-24 21:09:33.018 [main error] scan config 08: ERR: wrong symbol received
2022-09-24 21:09:33.065 [bus notice] >3108070400d1<51f5
2022-09-24 21:09:45.114 [bus notice] >3108070400d1
2022-09-24 21:09:45.115 [main error] scan config 08: ERR: read timeout
2022-09-24 21:10:33.632 [bus notice] >3108070400d1
2022-09-24 21:10:33.633 [main error] scan config 08: ERR: read timeout
seems like the target does not respond in time. you might want to increase the read timeout as well for testing by adding e.g. --receivetimeout=80
I've checked the bus voltages again and noticed that the bytes sent by ebusd have a way smaller amplitude (i think they are not valid levels). It might be an issue with the adapter, but I'm not sure how would it win the arbitration in this case. Setting --receivetimeout=80
has caused the errors to be either "wrong symbol received" or "timeout".
The burst is the idle ACK word from the boiler, the weak signal on the left side is from the adapter. Sometimes it appears after the idle ACK. Turning the potentiometer does not adjust it enough to match or even make the amplitude higher. (I'll try to get another adapter or this one replaced - please don't close the issue yet.)
in this case the pull down to the low level of the interface is not right. it has to be around (or below iirc) 12V, so I guess the output stage of the interface is not OK