Open john30 opened 6 years ago
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.
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
if someone wants to read an arbitrary message from a device behind a VR32, here is how to do that:
ebusctl hex
For a recovair scan message, this might look like this:
ebusctl hex 33b5170408070400
3331b5180ab57265636f5602170203
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?
@ojundt you need to wait for the asynchronous MM response with PBSB b518 in this case
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.
@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
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.