Bus coupler/bridge latency

[john30]

When using e.g. VR32 for connecting one eBUS to another and providing access to a single device in the second bus on a dedicated address on the first bus, the communication timing is no longer specification conformant.

For this special use case, when sending a message to the bridge device, it will initiate sending the translated message on the second bus, wait for the answer, and finally forward the answer on the first bus. This is a delay of up to (10+NNm+NNs)*SYMBOL_DURATION and might be up to 50 ms when assuming 16 bytes for master length NNm and slave length NNs.

For now, ebusd can handle this by using the device-related latency setting (i.e. --latency=100000), but it would be good to have that on a by-circuit basis.

[MatthiasKunze]

Hello, I have a Recovair 260/4 which is connected via a VR32 bus coupler to the eBus. The eBus also has a VR70, a VRC700/4, a VC146/4-7 and a VR920 connected to it. With the app of VR920 I can control the Recovair. Consequently, it would also be possible with the ebusd to control devices behind the VR32.

[tlc76]

My understanding is that ebus adapter is able to communicate with heaters behind VR32 if the --latency=100000 parameter is given to ebusd.

@MatthiasKunze : so you have 2 heaters (1 Recovair via VR32 and 1 Vaillant VC146 direct connection) and other VR* control devices all wired on a single ebus line. This is very close to my setup (2 x Ecotec heaters, 1 x VRC630, 1 x VR32 installed in 2nd heater --> all wired on the same ebus line in "cascade" mode). Have you been able to control your heaters with ebusd ? How many ebus adapter devices are you using? Do you still have the cascade function available on your Calormatic controller?

Thanks in advance Cristian

[john30]

if someone wants to read an arbitrary message from a device behind a VR32, here is how to do that:

1. determine the hex message to be sent (e.g. 08b5090d0000 for reading the first register value at address 0x0000)
2. append this hex sequence to this message after adding the length byte: 33b517 (assuming VR32 is on address 0x33)
3. send the message with ebusctl hex
4. wait for a message to arrive adressed to ebusd as master: e.g. 3331b518 (assuming VR32 is on address 0x33 and ebusd on address 0x31)
5. the payload will then be behind the received length byte

For a recovair scan message, this might look like this:

1. ebusctl hex 33b5170408070400
2. later asynchronous answer, master part only: 3331b5180ab57265636f5602170203