Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bus coupler/bridge latency #109

Open
john30 opened this issue Sep 26, 2017 · 7 comments
Open

Bus coupler/bridge latency #109

john30 opened this issue Sep 26, 2017 · 7 comments

Comments

@john30
Copy link
Owner

john30 commented Sep 26, 2017

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
Copy link

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
Copy link

tlc76 commented Jan 26, 2021

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
Copy link
Owner Author

john30 commented Feb 20, 2021

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

@ojundt
Copy link

ojundt commented Nov 10, 2023

Hi @john30, I'm using your ebus adapter v5 connected to a Vaillant flexoCompact 58/4 and it works nicely. Now I'm trying to follow your instructions to read some additional data from a recoVAIR 260/4 which is connected to the flexoCompact behind a VR32 but without any success so far :(

In my case VR32 is located at address 18 and ebusd master at 31:

address 18: slave #12, scanned "MF=Vaillant;ID=V32;SW=0106;HW=6004"
address 31: master #8, ebusd

I tried to get some response from the recoVAIR by scanning through the VR32 like this:

ebusctl hex 18b5170401070400
ebusctl hex 18b5170402070400
ebusctl hex 18b5170403070400
(... incrementing target address by 1...)
ebusctl hex 18b5170497070400
ebusctl hex 18b5170498070400
ebusctl hex 18b5170499070400

All of the commands returning 00 as immediate response. Checking with ebusctl grab result all I don't see any other async response.

Ebusd is running with --latency=100000 and --receivetimeout=100000.

What am I missing? Is the b517 correct? How do you know it's b517 as the PBSB?

@john30
Copy link
Owner Author

john30 commented Dec 25, 2023

@ojundt you need to wait for the asynchronous MM response with PBSB b518 in this case

@derMeister21
Copy link

Hallo @john30 ich muss das Thema nochmal aufgreifen und zwar habe ich auch die Konstellation, dass ich eine Vaillant Wärmepumpe, einen MultiMATIC VRC700 Regler an einem ebus hängen habe und eine Recovair Lüftung über eine VR32 mit diesem ebus verbunden ist. Als ebus Adapter habe ich deine Adapter V5 und der ebusd läuft auf einem Loxberry.

Folgendes wird mir angezeigt. Also ich sehe, dass er die Wärmepumpe erkennt (08.hmu.csv) und den VRC 700 (15.700.csv) . V32 müsste der VR32 sein wo die Recovair dran hängt. Was VWZ00 ist weiß ich selbst nicht.

address 03 master #11
address 08 slave #11, scanned "MF=Vaillant;ID=HMU00;SW=0307;HW=0403", loaded "vaillant/08.hmu.csv"
address 15 slave #2, scanned "MF=Vaillant;ID=70000;SW=0510;HW=6403", loaded "vaillant/15.700.csv"
address 33 master #13
address 38 slave #13, scanned "MF=Vaillant;ID=V32;SW=0117;HW=9802"
address 76 slave #9, scanned "MF=Vaillant;ID=VWZ00;SW=0307;HW=0403"

Hier meine args:
--scanconfig -d ens:xx.xx.xx.xx:9999 --initsend --latency=100000 --accesslevel=*

wie muss ich jetzt genau vorgehen um Werte übers VR32 zur Recovair zu bringen?

Vielen Dank für die Unterstützung.

@john30
Copy link
Owner Author

john30 commented Jul 13, 2024

@derMeister21 pack the message you'd like to send to recovair into the b517 frame as shown above @derMeister21 and then wait for the response as b518

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants