Writing data to a Wolf BM-2 controller

[Ces1254]

Description

Unless I am doing something substantially wrong, it appears that for a master/slave message ebusd (master) always expects an answer from the slave. This creates a problem while writing data to a BM-2 controller by Wolf, because for a write command (0x5023) BM-2 does not responds with any acknowledgement other than the low level bus ack.

Actual behavior

Here below a snapshot of the bus traffic and log:

-------- From raw log

2026-02-20 12:19:32.260 >318550220300b52758<0002050076>00

2026-02-20 12:19:39.454 >3185502309ccb52700005d010000f6<00
2026-02-20 12:19:39.804 >3185502309ccb52700005d010000f6<00
2026-02-20 12:19:40.242 >3185502309ccb52700005d010000f6<00

2026-02-20 12:19:40.995 >318550220300b52758<000200002c>00

2026-02-20 12:19:41.231 >318550220300b52758<000200002c>00

--------- From stdout

2026-02-20 12:19:32.260 [update notice] sent read bm SetValCorrection QQ=31: 0.5

2026-02-20 12:19:39.414 [bus error] send to 85: ERR: read timeout, retry
2026-02-20 12:19:39.804 [bus error] send to 85: ERR: read timeout, retry
2026-02-20 12:19:40.243 [bus error] send to 85: ERR: read timeout
2026-02-20 12:19:40.243 [bus error] send message part 0: ERR: read timeout
2026-02-20 12:19:40.243 [main error] write bm SetValCorrection: ERR: read timeout

2026-02-20 12:19:40.995 [update notice] sent read bm SetValCorrection QQ=31: 0.0

2026-02-20 12:19:41.231 [update notice] sent read bm SetValCorrection QQ=31: 0.0

For comparison, here the messages to implement the same change (0.5 to 0.0)

• from Wolfnet to BM-2 (through Wolf web app)

2026-02-19 22:32:27.644 <ff 85 5023 09 cc b527 0000 5d01 0000 e3 00

• from ebusd to BM-2 (through TCP socket)

2026-02-20 12:19:39.454 >31 85 5023 09 cc b527 0000 5d01 0000 f6<00

The messages are identical and the command works as expected in both cases, confirmed by the read back of the value. However, an ERR is raised when ebusd executed the write.

Expected behavior

While an option is to ignore the 'ERR: read timeout', a clean solution would be to implement a 'write w/o response' in the message description, to support this type of exchanges.

ebusd version

current source from git

ebusd arguments

--device=ens:192.168.31.113:9999 --configpath=/xxx/xxx/Projects/wolf_ebus/ebusd_conf/wolf --lograwdata --lograwdatafile=/xxx/xxx/ebuslograw.txt

Operating system

Debian 13 (Trixie) / Ubuntu 24-25 / Raspberry Pi OS 13

CPU architecture

x64

Dockerized

None

Hardware interface

Adapter Shield v5/C6/Stick via WiFi

Related integration

No response

Logs

See description above

[Ces1254]

Further to my description, the expected behavior for these MS messages should be the same as for a MM message. Unfortunately, in Wolf system architecture, writing to the master address of the BM-2 controller does not work: the BM-2 controller provides many slave logical addresses, one for each system it is controlling, because multiple heaters might be working in parallel on the same bus. So most parameters' values need to be changed for a specific slave address. At least, these are the conclusions I reached with some reverse engineering of the communication flow on eBus. The option might also be introduced as a qualifier for the write command, although a more architectural-wise approach (like adding a new message specifier 'c' - command) might be a preferred solution.

[nowi967]

Hi Ces1254, I have the same Wolf BM-2 setup and I'm
also trying to read values from it. Could you share
your ebusd config files from your wolf/ directory?
That would help a lot!

[Ces1254]

Hi Ces1254, I have the same Wolf BM-2 setup and I'm also trying to read values from it. Could you share your ebusd config files from your wolf/ directory? That would help a lot!

Please check my Wolf ebusd config

[aghulas]

Hi,

Weishaupt is using the same 5022 / 5023 messages as wolf to access registers. But the 5022 is a read to a slave address while the 5023 is a write to the corresponding master address. in other word 5022 is a MS message and 5023 is a MM message.
On Weishaupt the master is always the address of the slave minus 5. Ie for 0x85 as slave, the master would be 0x80.
maybe you can try.
Also I have had issue with write command on my weishaupt when the ebusd is using address 0x31. Using 0xff works better.

[Ces1254]

@aghulas :
Hi, thanks for the message. Unfortunately I doubt that your tip may work because 0x80 is not a master address in eBus architecture. Therefore a message with destination 0x80 will be treated still as a MS message, that is, awaiting a response. Besides will not be received by any device listening at that address. As indicated in my original post, the problem is that the slave at address 85 does not produce a response, the command is always successfully executed (the register value is changed as expected).

[aghulas]

If you run "ebusctl i" command you will see the list of slave/master addresses that are on your bus and pick the matching ones for you.

Maybe another tip you could try is to change the ebusd address to 0xff. On some weishaupt devices, writing would fail if not coming from 0xff address... I'm not sure why it is so.

[Ces1254]

@aghulas:
Hi, again thank you for spending time looking at the issue reported. However, I was probably not clear enough. I have no problem in writing to the controller. My write commands are correctly executed. The problem is that ebusd implementation expects always that a telegram from a master to a slave is answered by the slave with N bytes to the master. This is not the case in Wolf systems where the slave answers back only with the bus ACK (0x00) and no payload, producing a read timeout error in ebusd. It is not a problem of addresses of the devices. It is a problem of ebusd architecture. Unfortunately, there is to my knowledge no published specification for eBus application layer protocol, so any manufacturer uses it as best fits its needs. That's why I am requesting a new feature in ebusd. I would have appreciated getting confirmation of what I am experiencing by other users of Wolf systems. As for your master at address 0xff, this address in eBus systems is usually reserved for remote connections, PC, web interfaces, and similar. That's why you may experience a different behavior in your Weishaupt system. That's not the case for Wolf.

[Ces1254]

Hi everyone,

a short update on this topic.

I implemented a quick proof-of-concept patch to validate the idea of handling write commands where no slave response is expected, but only the bus level ack, as observed in my Wolf system.

The approach is currently based on a simple input qualifier:

• if the data field starts with a special character (!), the write command is treated as “no response required”
• the ! is stripped before normal parsing, so existing message definitions remain unchanged

Example:

w -c bm SetValCorrection "!0.0"

In this case, the write is executed without waiting for a slave response, exactly as if it were a message addressed to a master.

Implementation-wise, the patch is minimal (~15 lines across 3 files). It introduces a flag in the bus request handling so that the state machine skips the response phase when required. All other behavior remains unchanged.

This was intended as a quick validation rather than a final design. A more canonical approach would likely be:

• adding an explicit option to the w command (alternatively, creating a new message definition 'c', as discussed in previous comments)
• handling it during command parsing instead of encoding it in the data field

If this direction is considered useful, I can clean this up and propose a proper PR.

Feedback welcome.