Cannot get devices information through ebus

[AndreaRicci94]

Hi everybody and happy holidays,

I started using ebusd to control my Wolf heating system (made of a Wolf CHA+CHC heatpump, a BM2 control unit and a SM-1 Solar Module) but I am having a difficult time making it work.
I'm connecting to EBUS via ESERA Ebus Serial Coupler connected to a Raspberry PI 3 via a Waveshare Serial Hat.

I am able to collect raw data when setting the potentiometer, but I am not actually able to completely eradicate the following error:
ERR: read timeout during receive command, switching to skip

Let's say that it appears every second or so (I believe it's too much, but I have already made a complete spin of the poti without improvement). This is a part of the log (first line is the command I use):

ebusd -f -c /tmp --logareas bus --loglevel debug --lograwdata=bytes -d /dev/ttySC0
2022-12-28 16:45:50.767 [bus notice] bus started with own address 31/36
2022-12-28 16:45:50.823 [bus notice] <aa
2022-12-28 16:45:50.823 [bus debug] ERR: SYN received during no signal, switching to ready
2022-12-28 16:45:50.823 [bus notice] signal acquired
2022-12-28 16:45:50.999 [bus notice] <aa
2022-12-28 16:45:51.088 [bus notice] <aa
2022-12-28 16:45:51.176 [bus notice] <aa
2022-12-28 16:45:51.264 [bus notice] <aa
2022-12-28 16:45:51.355 [bus notice] <fd
2022-12-28 16:45:51.441 [bus notice] <aa
2022-12-28 16:45:51.529 [bus notice] <fa
2022-12-28 16:45:51.618 [bus notice] <aa
2022-12-28 16:45:51.706 [bus notice] <aa
2022-12-28 16:45:51.794 [bus notice] <aa
2022-12-28 16:45:51.883 [bus notice] <aa
2022-12-28 16:45:51.971 [bus notice] <ff
2022-12-28 16:45:52.059 [bus notice] <aa
2022-12-28 16:45:52.148 [bus notice] <aa
2022-12-28 16:45:52.236 [bus notice] <aa
2022-12-28 16:45:52.324 [bus notice] <aa
2022-12-28 16:45:52.414 [bus notice] <fd
2022-12-28 16:45:52.501 [bus notice] <aa
2022-12-28 16:45:52.589 [bus notice] <fa
2022-12-28 16:45:52.677 [bus notice] <aa
2022-12-28 16:45:52.777 [bus notice] <aa
2022-12-28 16:45:52.777 [bus notice] <fd
2022-12-28 16:45:52.777 [bus notice] <fe
2022-12-28 16:45:52.778 [bus notice] <50
2022-12-28 16:45:52.778 [bus notice] <17
2022-12-28 16:45:52.778 [bus notice] <10
2022-12-28 16:45:52.778 [bus notice] <ff
2022-12-28 16:45:52.778 [bus notice] <a9
2022-12-28 16:45:52.813 [bus debug] ERR: read timeout during receive command, switching to skip
2022-12-28 16:45:52.817 [bus notice] <00
2022-12-28 16:45:52.817 [bus notice] <52
2022-12-28 16:45:52.817 [bus notice] <81
2022-12-28 16:45:52.818 [bus notice] <02
2022-12-28 16:45:52.818 [bus notice] <00
2022-12-28 16:45:52.818 [bus notice] <80
2022-12-28 16:45:52.818 [bus notice] <e0
2022-12-28 16:45:52.819 [bus notice] <03
2022-12-28 16:45:52.863 [bus notice] <04
2022-12-28 16:45:52.863 [bus notice] <06
2022-12-28 16:45:52.863 [bus notice] <08
2022-12-28 16:45:52.864 [bus notice] <10
2022-12-28 16:45:52.864 [bus notice] <58
2022-12-28 16:45:52.864 [bus notice] <fc
2022-12-28 16:45:52.950 [bus notice] <fe
2022-12-28 16:45:53.039 [bus notice] <aa
2022-12-28 16:45:53.127 [bus notice] <aa
2022-12-28 16:45:53.215 [bus notice] <aa
2022-12-28 16:45:53.304 [bus notice] <aa
2022-12-28 16:45:53.395 [bus notice] <ff
2022-12-28 16:45:53.480 [bus notice] <aa
2022-12-28 16:45:53.568 [bus notice] <ea
2022-12-28 16:45:53.657 [bus notice] <aa
2022-12-28 16:45:53.745 [bus notice] <aa
2022-12-28 16:45:53.835 [bus notice] <f5
2022-12-28 16:45:53.936 [bus notice] <aa
2022-12-28 16:45:53.936 [bus notice] <30
2022-12-28 16:45:53.936 [bus notice] <fe
2022-12-28 16:45:53.936 [bus notice] <50
2022-12-28 16:45:53.937 [bus notice] <22

When I enable ebusd in service mode through systemd, I do it with the following parameters (saved in /etc/default/ebusd)
--scanconfig=full --device=/dev/ttySC0 --mqtthost=10.20.0.43 --mqttport=1883 --mqttjson --pollinterval=10 --mqttuser=CaliHouse --mqttpass=MY_PASSWORD

This produces the following information

ebusctl info
version: ebusd 22.4.v22.4
device: /dev/ttySC0
signal: acquired
symbol rate: 49
max symbol rate: 77
min arbitration micros: 4
max arbitration micros: 6
reconnects: 0
masters: 1
messages: 11
conditional: 0
poll: 0
update: 4
address 31: master #8, ebusd
address 36: slave #8, ebusd, scanning

And the system pretty much stays in this state. This is an excerpt of the log since service startup:

2022-12-28 16:49:03.723 [main notice] ebusd 22.4.v22.4 started with full scan on device /dev/ttySC0
2022-12-28 16:49:04.563 [bus notice] bus started with own address 31/36
2022-12-28 16:49:04.567 [mqtt notice] connection established
2022-12-28 16:49:04.587 [bus notice] signal acquired
2022-12-28 16:49:14.566 [main notice] starting initial full scan
2022-12-28 16:51:10.342 [main notice] update check: OK

After some time, it may eventually find other masters, but it cannot scan them and use their information (maybe because I don't have the right CSVs?). For instance, it finds master #30 (which should be the BM-2 module), but it doesn't know what to do with it.

I am pretty puzzled right now, but I don't want to give up because my Wolf heatpump provides a lot of useful data through its BM2 module and I want to be able to read it and include it in my home automation system.

Any idea to go further?
Thank you all for your time.

Andrea

[eh-gh]

Hi,
I have similar problem with Wolf.
PI3, Wolf CGB-2, BM-2, MM2, ebus RPI v3.1, MixerCycle1, DHW

My first goal would be to detect the status change of MixerCycle1 using the BM-2
If I use the grab commands:
ebusctl grab ; sleep 20; ebusctl grab result ; ebusctl grab stop
I can see a lot of messages going around, but no message can be identified for the status change.

I'm also interested in a solution
tnx
eh-gh

[AndreaRicci94]

Hi @eh-gh

How did you manage the right CSV files for Wolf data conversion?

I tried your commands because I wanted to check if I was able to intercept some data (even raw). But, in my case, no luck. This is what ebusctl i shows

pi@mercury:~ $ ebusctl i
version: ebusd 22.4.v22.4
update check: OK
device: /dev/ttySC0
signal: acquired
symbol rate: 59
max symbol rate: 95
min arbitration micros: 4
max arbitration micros: 6
reconnects: 0
masters: 1
messages: 11
conditional: 0
poll: 0
update: 4
address 31: master #8, ebusd
address 36: slave #8, ebusd, scanning

As you can see, no devices have been found (the two addresses are the ones used by ebusd). Because of that (?), no messages can be grabbed.

pi@mercury:~ $  ebusctl grab ; sleep 20; ebusctl grab result ; ebusctl grab stop
grab started

done

grab stopped

pi@mercury:~ $

[eh-gh]

hi

you can clone the repo https://github.com/john30/ebusd-configuration to you
The directory
.../ebusd-configuration/ebusd-2.x.x/de/
contains a basic setup for wolf systems, you can address this directory to -c option accordingly

maybe this helps to you

[AndreaRicci94]

Hi,

Yes, that is what I've done a few minutes ago expecting better results. My startup arguments now read
--configpath=/home/pi/ebusd-configuration/ebusd-2.x.x/de/ --device=/dev/ttySC0 --mqtthost=10.20.0.43 --mqttport=1883 --mqttjson --pollinterval=10 --mqttuser=CaliHouse --mqttpass=MYPASSWORD
This is what the aforementioned folder contains

-rw-r--r-- 1 pi pi 1202 28 dic 11.05 broadcast.csv
lrwxrwxrwx 1 pi pi    4 28 dic 11.05 kromschroeder -> wolf
-rw-r--r-- 1 pi pi  754 28 dic 11.05 memory.csv
-rw-r--r-- 1 pi pi 1228 28 dic 11.05 _templates.csv
drwxr-xr-x 2 pi pi 4096 28 dic 11.05 vaillant
drwxr-xr-x 2 pi pi 4096 28 dic 11.05 wolf

Now ebusctl i detects 555 messages, I think because it parsed some information from the CSV files. Altough, no new devices are found (other than the two address occupied by ebusd).
I will look at this in the morning (it's 9pm here now), and we will see if it at least picked up new information...

For now, thank you for your time. :)

[AndreaRicci94]

After the night I went to check again if the situation improved. It found another two devices with addresses #30 and #f0 but without identification.

At this time I am beginning to think there is not enough information on the CSV files to detect the BM2 and the SM1 inside the eBUS network.

Also, is it normal that new masters begin to appear after several minutes from service startup?

[AndreaRicci94]

Hi everyone,

Little update about the situation which, unfortunately, it is still sad.

I took out of the system the RS232 hat and now I connect the Raspberry Pi directly to the ESERA Serial Coupler via a RS232/USB cable equipped with a FTDI chip.

Ebusd correctly recognizes the ttyUSB0 device and this is the output of info

pi@mercury:~ $ ebusctl i
version: ebusd 23.1.23.1
update check: OK, broadcast.csv: different version available, memory.csv: different version a vailable, vaillant/05.vl9.csv: different version available, vaillant/15.360.csv: different ve rsion available, vaillant/3c.rcc.5.csv: different version available, vaillant/e0.omu.csv: dif ferent version available, vaillant/ec.sol.sc.csv: different version available
device: /dev/ttyUSB0
signal: acquired
symbol rate: 27
max symbol rate: 65
reconnects: 0
masters: 1
messages: 555
conditional: 55
poll: 0
update: 4
address 31: master #8, ebusd
address 36: slave #8, ebusd

Unfortunately, no masters are recognized in this state or, even if they are, they cannot be scanned as the ones I have in the system (Wolf BM-2 controller and SM-1 solar module).

Could anyone think about what is wrong in my system? Is the adapter faulty? Is my wiring from the system to the RasPi not good enough? How can I understand using "ebusctl raw bytes" if the output represents valid ebus messages and not just plain garbage?

Thank you all,
Andrea

[rtm-soft]

Hi Andrea, this thread is a few years old, not sure if you got any further, the files in ebusd config have no info about SM1 and BM-2 but I reversed engineered the data and I decoded a lot of broadcast packages. Let me know if this is useful to you. I am still tweaking the data.

``# type (r;w;u;1-9),class,name,comment,QQ,ZZ,PBSB,ID,field1,part (m;s),type / templates,divider / values,unit,comment,field2,part (m;s),type / templates,divider / values,unit,comment,field3,part (m;s),type / templates,divider / values,unit,comment,field4,part (m;s),type / templates,divider / values,unit,comment,field5,part (m;s),type / templates,divider / values,unit,comment,field6,part (m;s),type / templates,divider / values,unit,comment,field7,part (m;s),type / templates,divider / values,unit,comment
*b,broadcast,,,,FE,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
b,,circuittemp,,,,5017,,pump,,pumpstatus,,,SolarPump,,,IGN:1,,,,collectortemp,,temp,,,Collector Temperature,wwboilertemp,,temp,,,WW Boiler Temperature,,,,,,,,,,,,,,,,,,
b,,yield,Collector Yield,,,5018,,power,,UIN,10,kW,Solar Power,dailysumfraction,,FLT,,,Daily Fraction,dailysum,,UIN,,,Daily Sum,totalsumfraction,,FLT,,,Total Sum Fraction,totalsumkwh,,UIN,,,Total Sum kWh,totalsummwh,,UIN,,,Total Sum MWh,,,,,,
b,,tempsensors,Temperature Sensors,,,0301,,outsidetemp,,SIN,10,°C,Outside Temperature,insidetemp,,SIN,10,°C,Inside Temperature,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
b,,sensors,Control Values,,,0800,,boilerwanttemp,,temp2,,,Boiler Requested Temperature,outsidetemp,,temp2,,,Outside Temperature,,,,,
b,,time,Date/Time,,,0700,,,,IGN:2,,,,time,,btime,,,,date,,bdate,,,,,,,,,
b,,returntemp,Return Temperature,,76,5022,CC2B0A,return,,SIN,10,°C,Return Temperature
b,,runtime,Run Time,,76,5022,CCF902,run,,UIN,,,Run Time
b,,counter,Counter,,76,5022,CC484E,count,,UIN,,,Counter
b,,counter2,Counter2,,76,5022,CC2503,count2,,UIN,,,Counter2
b,,counter3,Counter3,,76,5022,CC7709,count3,,UIN,,,Counter3
b,,counter4,Counter4,,76,5022,CC7B09,count4,,UIN,,,Counter4
b,,error,Error message,,,FE01,,error,,STR:10,,,,,,,,,,,,,,,,,,,,,

Cheers Rene

[AndreaRicci94]

Hi Andrea,

Hi to you and thank you for your reply!
Actually I went a little bit further a long time ago mainly thanks to this #950 and then because of work I had to abort this matter.

Anyway, I will make up some time in the next weekend (I hope) and try your data, as well as the newest development they had in the previous link.

I will let you now, thanks again in the meantime! :)

[Sethach]

when I look to your first post with the hex dump i assume that you ebus adapter is not adapted correctly to the level. If I compare it with my log, I have clear and only “aa”, and no f5, 30 and fe in between.
I adjusted my adapter with the windows hterm, which has the ability to show errors on each received byte in red.
It was quite tricky to adjust it, but finally a got only aa between the messages.

never the less I still have sometimes bus receiving problems, so i think the potentiometer adjustment may an environment temperature dependence

[AndreaRicci94]

Hi @Sethach and thank you for your insight.
So in your raw log you ONLY have "aa" entries? Every one of them?

Well then, no luck for me. I already did three times the full round of the potentiometer, slowly each time with the raw log running. The log is similar to the one above, every time with every position.

A few weeks ago I put in a request for the ebus adapter made by john30, it should (presumably) be ready by end of Q1 2023, so we'll see if the doubt I have (the Esera serial adapter is at fault) is real or not.

[Sethach]

I am also fighting with an older esera adapter.
I have also tried an adapter from Daniel Kucera. That adapter lets my Vaillant sensotherm crash.

in the wiki I found this:

Adjusting the potentiometer For all but the recommended eBUS Adapter Version 3.0 and eBUS Adapter Version 2.0/2.1/2.2 interfaces, a potentiometer on the adapter has to be adjusted to the current environment (i.e. voltage, cable length, etc.) in order for the hardware interface to work correctly. ebusd can be used to support this adjustment by starting it without any CSVs in raw mode in foreground, e.g. like this (after stopping ebusd if it is already running as daemon, i.e. service ebusd stop): ebusd -f -c /tmp —logareas bus —loglevel info —lograwdata=bytes -d $DEVICE The parameter $DEVICE needs to be replaced by the corresponding /dev/ttyUSB0 or whatever device is used. Starting with the potentiometer turned to the maximum left position (counter-clockwise), it has to be turned slowly to the right (clockwise) until ebusd reports “signal acquired” without toggling between signal and no signal, and shows lines like

[AndreaRicci94]

I am also fighting with an older esera adapter. I have also tried an adapter from Daniel Kucera. That adapter lets my Vaillant sensotherm crash.

I am beginning to think that Esera adapters are not suitable for this usage, as I've seen others complaining about them not working correctly. Let's hope that john's adapter will be ready on time...

in the wiki I found this:

Yes, that is actually the procedure I've followed to get the log you've seen.

[AndreaRicci94]

I have just received version 5 of John's adapter.
As soon as i connected it to my system it began collecting messages, although still unknown.

The only thing we learn from all of this discussion is that I need to trash the Esera adapter.
I am inclined to suggest to others thinking to buy an Esera adapter to stay clear of it.

Now a new journey begins...