RecoVAIR questions about connection and write BypassPosition + PreferedTemp

[rICTx-T1D]

Description

Hi! The problem was reported some years ago. When you have a heating pump on 08 and a recoVAIR on same, it is not possible to scan recoVAIR.

Heat pump, recoVAIR and Vrc720 are on same ebus and connected to ebus adapter shield 5 with last ebusd software.

Please review the problem an looking for a solution to discover on 38 or both under 08.

Have many thanks rict

Actual behavior

On scan full

Expected behavior

RecoVAIR was not discovered 08;Vaillant;HMU00;0901;5103;21;23;12;0010021110;1610;006115;N3 15;Vaillant;CTLV2;0514;1104;21;22;49;0020260914;0953;071526;N7 38;Vaillant;V32;0106;6004 76;Vaillant;VWZIO;0902;5103;21;23;17;0010023494;3110;005412;N0 ec;Vaillant;SOL00;0514;1104;21;22;49;0020260914;0953;071526;N7

ebusd version

23.3

ebusd arguments

.

Operating system

Debian 12 (Bookworm) / Ubuntu 22-23 / Raspberry Pi OS 12 (including lite)

CPU architecture

x64

Dockerized

devel

Hardware interface

Adapter Shield v5 via Ethernet

Related integration

TCP (cmdline client like ebusctl or netcat), HTTP

Logs

.

[JonesGW-MGD]

Hi there,

as you can imagine, it's not possible to have two heat sources (or indeed any two devices) on the same bus address. What Valliant implements in such cases is a VR32 Bus Coupler. This 'fronts' one of your heat sources, in your case the recoVAIR and provides it with a different address - in your case 38.

Of course, there is no way for ebusd to 'know' what type of device sits behind the bus coupler - it could equally be another heat pump in cascade mode, a back-up gas boiler - in your case it just happens to be the recoVAIR.

So there can never be a VR32 configuration file that will work in all these circumstances. (also the VR32 can present on different addresses to 38 too.)

There are actually a number of posts in the discussion forum on how to address this (and I've posted or commented on a few). You may wish to start here and follow some of the referenced links too:

https://github.com/john30/ebusd/discussions/1223#discussioncomment-8749250

But in broad terms - you need to i) host the configuration files locally, ii) 'fool' ebusd by renaming in your case 08.recov.csv to 38.v32.csv, iii) adjust the latency parameter on daemon start-up since the VR32 doesn't play well with some of the bus standards.

Good luck

[rICTx-T1D]

Thanks for your detailed answer. I will try it as in your summary describe. Give me some days for feedback pls.

[rICTx-T1D]

Hi @JonesGW-MGD, have many thank for your last posting. Now my ebusd is founding some values from "recov"

# ebusctl f -c recov
recov BypassPosition = 100.0
recov FlowActual = 171
recov FrostProtection = off
recov HumiWasteAir = 46.94
recov PreferredTemp = 23.00
recov TempInletAir = 24.88;ok
recov TempOutgoingAir = 27.75;ok
recov TempOutsideAir = 24.25;ok
recov TempWasteAir = 27.69;ok
recov VentHeatRecovery = auto
recov VentIntensityDay = 3
recov VentIntensityNight = 6

But when I try to write / change on this element, ebusd answer with "ERR: element not found"

# ebusctl w -c recov BypassPosition 70
ERR: element not found

# ebusctl w -c recov PreferredTemp 21
ERR: element not found

Other properties, e.g. activate boost mode I use the setter describe here. # ebusctl w -c recov SetVentBoost on # ebusctl w -c recov SetVentHeatRecoveryAuto on

But why now setter is existing for BypassPosition or PreferredTemp?

Did you have an idea how I con fix it?

[JonesGW-MGD]

Both of those two messages you are trying to write to are defined in the configuration file as read messages:

r9 | recov | BypassPosition | Position of Bypass Flap |   |   |   | 290b0e |   |   | UIN | 10 |   -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | --

r | recov | PreferredTemp | Desired Temperature |   |   |   | 29140e |   |   | temp |   |  -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | --

I don't know enough about the recoVAIR as to whether you could amend these to be writable - i.e. r;w, ....... or whether those messages are simply not-writable.

This comment from the configuration file ticket that was the original pull request for the 08.recov.csv file suggests that at least PreferredTemp is not writable: https://github.com/john30/ebusd-configuration/pull/102#discussion_r219670184

It's possible for example that these are designed to be read-only and that some other message is used to change the values, from perhaps the controller rather than the device. Again, apologies I don't know enough about how recoVAIRs are controlled!

What you can perhaps do is use ebusd to monitor traffic on the bus while you make changes manually to the values you wish to control. That may help you determine which message(s) drives the change event. (If the device is controlled from the controller then you are likely to see some telegrams that start 1538........, if the device is controlled stand-alone you may still see new telegrams - there is a whole section on the wiki on grabbing and decoding traffic).

You may cause issues with your devices if you simply try writing things randomly, so I suggest you open a new thread on the discussion forum (rather than an 'issue') about writing RecoVAIR messages and you may find other users can advise you better?

I also suggest that, since your original post wasn't really an issue with the ebusd software, you change this issue into a discussion item. I believe you should have an option to convert it. It might also be helpful to others if you re-title it too - something like 'RecoVAIR - accessing data behind a VR32'. as it may contribute to the knowledge pool.

[john30]

closed as not an issue in the first place