ebusd icon indicating copy to clipboard operation
ebusd copied to clipboard

ebusd and Vaillant Ecotec Plus (Vaillant VCW PL 296), cant get ebusctl to talk to ebusd reliably

Open polprog opened this issue 2 years ago • 24 comments

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

-- ebusd-pierwszy-vaillant.log

polprog avatar Aug 26 '22 10:08 polprog

You are from Poland?

pepsonEL avatar Aug 26 '22 10:08 pepsonEL

Yeah

polprog avatar Aug 29 '22 20:08 polprog

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

mf76130 avatar Aug 31 '22 05:08 mf76130

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: @.***>

polprog avatar Aug 31 '22 08:08 polprog

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

mf76130 avatar Aug 31 '22 08:08 mf76130

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: @.***>

polprog avatar Aug 31 '22 22:08 polprog

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

mf76130 avatar Sep 06 '22 14:09 mf76130

I did run it with --checkconfig and it reported no errors

polprog avatar Sep 11 '22 09:09 polprog

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?

mf76130 avatar Sep 12 '22 04:09 mf76130

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 avatar Sep 14 '22 04:09 mf76130

@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?

polprog avatar Sep 15 '22 22:09 polprog

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" image subfolder vaillant: image

mf76130 avatar Sep 16 '22 03:09 mf76130

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

john30 avatar Sep 17 '22 06:09 john30

ebusd 22.4 is out and it continues to try scanning devices until successful, maybe that helps

john30 avatar Sep 18 '22 21:09 john30

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.

polprog avatar Sep 22 '22 18:09 polprog

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.

polprog avatar Sep 22 '22 19:09 polprog

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).

john30 avatar Sep 24 '22 12:09 john30

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: @.***>

polprog avatar Sep 24 '22 12:09 polprog

https://github.com/john30/ebusd/wiki/6.-Hardware#adjusting-the-potentiometer

john30 avatar Sep 24 '22 12:09 john30

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?

polprog avatar Sep 24 '22 19:09 polprog

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

polprog avatar Sep 24 '22 20:09 polprog

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

john30 avatar Oct 03 '22 05:10 john30

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". obraz 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.)

polprog avatar Oct 03 '22 17:10 polprog

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

john30 avatar Oct 03 '22 17:10 john30