No ebus data from WRSOL 1.1

[fatz]

Hi

I'm trying to get the adapter to work with Weishaupt WRSol 1.1

I've adjusted PWM value until the LED starts blinking ( also checked -/+ 1 which lead to steady off or steady on ). But when I for example check port 3334 I do not receive any data.

Other things I've tried so far are ( I'm using HW ver. 6.1 ):

update firmware to 7.1
downgrade firmware to 6.3

I also tried to iterate PWM values and then check ebusctl info for signal. After changing PWM i've added a sleep for 10sec until doing the check. So I'm not completely certain if that is an appropriate check.

1. is there a better way to debug the data received?
2. so when the rx LED is blinking could I consider data on ebus? ( just gaining first ebus experience )
3. when rx is blinking but ESP does not receive any data could there maybe a communication issue on the PCB itself?

Any other debugging I could try?

Thanks for the help and this great project!

[danielkucera]

Hello @fatz ,
do you have some other device connected and communicating on the eBus?
Can you check if you have eBUS Speisung in settings enabled?
What is the PWM value?
Can you post a picture of your wiring?

[fatz]

Hey!,

just realised I do own a WRSol 1.1 not 2.1...

However a photo a bit weird to take, still temp cable ( 2meters long or so, the ESP is additionally powered by the usb-c port ) . I do have a usual data cable ( 4 wire ) connect to "e" and ground while "e" connects to "+" on the esp-ebus side and ground to "-"

eBUS Speisung is not avail in the Options... I could change the ebus address which is still in the default of 2

My PWM value is 48 which leads to blinking D1 LED. 47 turns it off, 49 leads to constant on.

I can try to tap with with an oscilloscope if nothing else helps. But my main thought was that blinking D1 already means that its receiving data.

some more details

async mode: true
software serial mode: true
uptime: 155792 ms
last_connect_time: 1430 ms
reconnect_count: 1
rssi: -76 dBm
free_heap: 157800 B
reset_code: 3
loop_duration: 60 us
max_loop_duration: 1341 us
version: v6.3
nbr arbitrations: 0
nbr restarts1: 0
nbr restarts2: 0
nbr lost1: 0
nbr lost2: 0
nbr won1: 0
nbr won2: 0
nbr late: 0
nbr errors: 0
pwm_value: 48

[danielkucera]

When there are not at least 2 devices communicating on the bus, there is no way to adjust the PWM.
That's why I was asking if there are multiple devices.

Making a capture with oscilloscope would be best.

[fatz]

Ok this is weird... i got constant 5v with a little bit of noise on bus clamps. That actaully explains why the adapter does not see any data.

According to the WRSol 1.1 docs ebus is always active. I also tried to change the address with no success. But I think we can close this issue as it does not seem to relate to the esp-ebus software or hardware...

Thanks for the help i'll ask the Weishaupt support

[danielkucera]

We can keep this open for now. Please let me know when you get some response form the support. I am interested in this.

[fatz]

I'm getting closer to solve it...

So after restarting wrsol without being connected I realised it up to 20v...
So I changed the cable. But everytime I connect the adapter again its dropping to 4.9...v

Without the adapter I could see the pulses on the oscilloscope. So I took another look at the adapter. While I was using usb-cable to power the esp I didn't realize that the jumper connects ebus to vcc. So I removed the adapter which now leads to the point that ebusd detects wrSol.

Still ebusctl scan 02 leads to timeout but this is definitely making progress

[danielkucera]

Hi @fatz , does it work at the end?

[fatz]

Well sadly not...

So the bus itself seems to work. But the device is only answering on one single command

which is

docker exec -ti ebusd ebusctl hex 15070400
0a105752534f4c01200110

which looks in the logs like this

2024-04-11 12:19:57.035 [bus info] send message: 3115070400
2024-04-11 12:19:57.067 [bus debug] start request 31
2024-04-11 12:19:57.067 [bus debug] arbitration start with 31
2024-04-11 12:19:57.131 [bus debug] arbitration won
2024-04-11 12:19:57.131 [bus debug] arbitration delay 9 micros
2024-04-11 12:19:57.131 [bus debug] switching from ready to send command
2024-04-11 12:19:57.141 [bus debug] send/receive symbol latency 10 ms
2024-04-11 12:19:57.157 [bus debug] send/receive symbol latency 13 ms
2024-04-11 12:19:57.170 [bus debug] send/receive symbol latency 12 ms
2024-04-11 12:19:57.181 [bus debug] send/receive symbol latency 10 ms
2024-04-11 12:19:57.181 [bus debug] switching from send command to send command CRC
2024-04-11 12:19:57.202 [bus debug] send/receive symbol latency 21 ms
2024-04-11 12:19:57.202 [bus info] send/receive symbol latency 8 - 21 ms
2024-04-11 12:19:57.202 [bus debug] switching from send command CRC to receive command ACK
2024-04-11 12:19:57.207 [bus debug] switching from receive command ACK to receive response
2024-04-11 12:19:57.251 [bus debug] switching from receive response to receive response CRC
2024-04-11 12:19:57.253 [bus debug] switching from receive response CRC to send response ACK
2024-04-11 12:19:57.263 [bus debug] send/receive symbol latency 9 ms
2024-04-11 12:19:57.263 [bus debug] notify request: done
2024-04-11 12:19:57.263 [bus debug] read res: 0a105752534f4c01200110
2024-04-11 12:19:57.263 [bus debug] switching from send response ACK to send SYN
2024-04-11 12:19:57.263 [bus notice] >31150704008b<000a105752534f4c0120011031>00
2024-04-11 12:19:57.276 [bus debug] send/receive symbol latency 12 ms
2024-04-11 12:19:57.276 [bus debug] switching from send SYN to ready

so IMO the plain communication works.

I found this documentation https://www.mikrocontroller.net/attachment/437515/eBUS-Befehle_WRSol_x_1.pdf which seems to be related to my controller.

Every other command leads to a time out.

Example:

docker exec -ti ebusd ebusctl hex 15100100
ERR: read timeout

and these logs

2024-04-11 12:25:11.014 [bus info] send message: 3115100100
2024-04-11 12:25:11.023 [bus debug] start request 31
2024-04-11 12:25:11.023 [bus debug] arbitration start with 31
2024-04-11 12:25:11.083 [bus debug] arbitration won
2024-04-11 12:25:11.083 [bus debug] arbitration delay 3 micros
2024-04-11 12:25:11.083 [bus debug] switching from ready to send command
2024-04-11 12:25:11.093 [bus debug] send/receive symbol latency 9 ms
2024-04-11 12:25:11.105 [bus debug] send/receive symbol latency 11 ms
2024-04-11 12:25:11.114 [bus debug] send/receive symbol latency 8 ms
2024-04-11 12:25:11.123 [bus debug] send/receive symbol latency 9 ms
2024-04-11 12:25:11.123 [bus debug] switching from send command to send command CRC
2024-04-11 12:25:11.135 [bus debug] send/receive symbol latency 12 ms
2024-04-11 12:25:11.135 [bus debug] switching from send command CRC to receive command ACK
2024-04-11 12:25:11.140 [bus debug] switching from receive command ACK to receive response
2024-04-11 12:25:11.195 [bus notice] >311510010048<00
2024-04-11 12:25:11.195 [bus debug] notify request: ERR: SYN received
2024-04-11 12:25:11.195 [bus debug] ERR: SYN received during receive response, switching to ready
2024-04-11 12:25:11.195 [bus error] send to 15: ERR: read timeout, retry
2024-04-11 12:25:11.244 [bus debug] start request 31
2024-04-11 12:25:11.244 [bus debug] arbitration start with 31
2024-04-11 12:25:11.306 [bus debug] arbitration won
2024-04-11 12:25:11.306 [bus debug] arbitration delay 5 micros
2024-04-11 12:25:11.306 [bus debug] switching from ready to send command
2024-04-11 12:25:11.321 [bus debug] send/receive symbol latency 14 ms
2024-04-11 12:25:11.333 [bus debug] send/receive symbol latency 12 ms
2024-04-11 12:25:11.344 [bus debug] send/receive symbol latency 10 ms
2024-04-11 12:25:11.365 [bus debug] send/receive symbol latency 20 ms
2024-04-11 12:25:11.365 [bus debug] switching from send command to send command CRC
2024-04-11 12:25:11.376 [bus debug] send/receive symbol latency 10 ms
2024-04-11 12:25:11.376 [bus debug] switching from send command CRC to receive command ACK
2024-04-11 12:25:11.382 [bus debug] switching from receive command ACK to receive response
2024-04-11 12:25:11.436 [bus notice] >311510010048<00
2024-04-11 12:25:11.436 [bus debug] notify request: ERR: SYN received
2024-04-11 12:25:11.436 [bus debug] ERR: SYN received during receive response, switching to ready
2024-04-11 12:25:11.436 [bus error] send to 15: ERR: read timeout, retry
2024-04-11 12:25:11.485 [bus debug] start request 31
2024-04-11 12:25:11.485 [bus debug] arbitration start with 31
2024-04-11 12:25:11.544 [bus debug] arbitration won
2024-04-11 12:25:11.544 [bus debug] arbitration delay 5 micros
2024-04-11 12:25:11.544 [bus debug] switching from ready to send command
2024-04-11 12:25:11.558 [bus debug] send/receive symbol latency 13 ms
2024-04-11 12:25:11.577 [bus debug] send/receive symbol latency 19 ms
2024-04-11 12:25:11.593 [bus debug] send/receive symbol latency 15 ms
2024-04-11 12:25:11.600 [bus debug] send/receive symbol latency 7 ms
2024-04-11 12:25:11.600 [bus info] send/receive symbol latency 7 - 25 ms
2024-04-11 12:25:11.600 [bus debug] switching from send command to send command CRC
2024-04-11 12:25:11.613 [bus debug] send/receive symbol latency 12 ms
2024-04-11 12:25:11.613 [bus debug] switching from send command CRC to receive command ACK
2024-04-11 12:25:11.621 [bus debug] switching from receive command ACK to receive response
2024-04-11 12:25:11.681 [bus notice] >311510010048<00
2024-04-11 12:25:11.681 [bus debug] notify request: ERR: SYN received
2024-04-11 12:25:11.681 [bus debug] ERR: SYN received during receive response, switching to ready
2024-04-11 12:25:11.683 [bus error] send to 15: ERR: read timeout

i also tried the single ID requests but everything ends up in a timeout.

after some search I found one response in a forum from someone experiencing the same but no further answer from there and that thread was like 3 years old (forgot to save the link).

I gave up for now due to limited time working on it. However I would appreciate every possible hint.