VRC 720 configuration: understanding and managing Heating Circuit (HC) basic parameters

[stadid]

Goal of the PR

To check and confirm basic set of registers in the ebusd configuration associated with the Heating Circuit (HC)

EBUSD regulator config (15.CTLV2.csv) implementation: see JonesPD repository

The only register to be found is External heat demand contact status at external module.
(Hc*ExtHeatDemand (RO) - should be 0/1)

[chrizzzp]

@stadid
Trying to understand the right part of your table: what do the black dots in the columns (mixer, fixed, dhw, return inc) mean? Do they mean the corresponding register has been confirmed already for these cases?

* especially check mixer `Hc*MixerMovement ` as in 720 it should report not movement but mixing valve position in %

Correct, I think it reports mixer position. In my system the values vary in steps of 5 (%), from -20 to 20.

Target flow set-back temperature desired - I believe it could be r;w,,Hc1Unknown0D,(konstant 65),,,,0D00,,,HEX:*,,,

I'm wondering how to confirm this: so this register should contain the value of e.g. r;w,,z1SetBackTemp,,,,,0900,,,tempv,,, when the setback time slot is active (time-controlled opmode)?
Currently (manual opmode) Hc1Unknown0D is 0.

[stadid]

@chrizzzp

Trying to understand the right part of your table: what do the black dots in the columns (mixer, fixed, dhw, return inc) mean? Do they mean the corresponding register has been confirmed already for these cases?

Based on the 720 simulator I've picked regulator parameters set (not EBUSD registers) corresponding to each heating circuit type. Black dot means that this parameter is used for specific circuit type. Afterwards I've linked each parameter with corresponding ebusd register.

Correct, I think it reports mixer position. In my system the values vary in steps of 5 (%), from -20 to 20.

Could you check that value read from ebusd is the same as shown in the regulator menu for mixer position?

I'm wondering how to confirm this: so this register should contain the value of e.g. r;w,,z1SetBackTemp,,,,,0900,,,tempv,,, when the setback time slot is active (time-controlled opmode)?
Currently (manual opmode) Hc1Unknown0D is 0.

Two things to consider:

1. zone temps are showing room air temperatures while hc temps are showing water temperature inside heating circuits and they should not be mixed.
2. As far as I understand in order to correctly identify this register(s) we need to set corresponding type to heating circuit. While your heating circuit has another type those registers could contain irrelevant values.

[chrizzzp]

1. zone temps are showing room air temperatures while hc temps are showing water temperature inside heating circuits and they should not be mixed.

Yes, of course, my mistake. Thanks for pointing this out again.

In order to understand all circuit types could you quickly explain the type 4 (returnincr)? Why should e.g. the 'pump status' not apply here?

I would also like to add observations I made when switching heat circuits on and off (I use a "virtual" fixed hc2 to generate additional "heat demand" when there is excess energy from photovoltaics to start the heat pump and charge the heating storage cyclinder. This will not affect heat circuit 1, the regular heating of the house).

Observations:

When switching hc type from 'inactive' to 'fixed' some default values stored elsewhere are used e.g.

• HcxDesiredTemp defaults to 65°C
• HcxMaxHeatingFlowTempDesired defaults to 95°C
• HcxHeatcurve defaults to 1.2

So these parameters have to be set manually everytime the 'fixed' hc type is activated. As soon as the hc type is switched back to 'inactive' these parameters reset to the defaults. I think we should also try to find them (if they are not hard-coded).

This (reset to defaults) could be a general behaviour also for the other hc types, as I guess heating circuits normally remain active.

[stadid]

@chrizzzp

In order to understand all circuit types could you quickly explain the type 4 (returnincr)? Why should e.g. the 'pump status' not apply here?

As far as I understand, this circuit type is fully named "increase return temperature" and used in order to increase the return temperature of the heat generator with cast iron heat exchanger, as low value of the return temp will lead to condensation of water vapor on the outside surfaces of the heat exchanger. It's acting like a "bypass" directing flow directly from heat exchanger output to its input. It seems that for this particular set-up pump is used from another "normal" heating circuit (which should be present in the system), so for this circuit only mixing valve is needed.

[stadid]

@chrizzzp

When switching hc type from 'inactive' to 'fixed' some default values stored elsewhere are used e.g.

My guess is that all HC related registers (for all HC types) got reset to defaults while changing HC type.
(i.e. If Hc1 type is changed all Hc1 registers are reset to defaults, no matter what type is chosen)

[chrizzzp]

@stadid

Could you check that value read from ebusd is the same as shown in the regulator menu for mixer position?

Yes, the regulator shows the same values. I suggest it should be renamed to HcxMixingValvePosition.

Target flow set-back temperature desired - I believe it could be r;w,,Hc1Unknown0D,(konstant 65),,,,0D00,,,HEX:*,,,

Yes, you're right. I could confirm this. If the circuit is set to inactive the setting resets to the default 0.0 (not 65 as written in the current CSV).

r;w,,Hc1DesiredSetbackTemp,,,,,0D00,,,tempv,,,target setback temperatur Hc1 (fixed circuit type)
r;w,,Hc2DesiredSetbackTemp,,,,,0D00,,,tempv,,,target setback temperatur Hc2 (fixed circuit type)
r;w,,Hc3DesiredSetbackTemp,,,,,0D00,,,tempv,,,target setback temperatur Hc3 (fixed circuit type)

We now have the following unknown registers (default values in parentheses):

r;w,,Hc1Unknown04,(konstant 30),,,,0400,,,EXP,,,target return temp?
r;w,,Hc1Unknown09,(konstant 60),,,,0900,,,tempv,,,
r;w,,Hc1Unknown13,(konstant 1),,,,1300,,,SIN,,,
r;w,,Hc1Unknown16,(konstant 0),,,,1600,,,SIN,,,
r;w,,Hc1Unknown17,(konstant 0.0 EXP?),,,,1700,,,EXP,,,
r;w,,Hc1Unknown18,(konstant off),,,,1800,,,onoff,,,
r;w,,Hc1Unknown19,(konstant on),,,,1900,,,onoff,,,
r;w,,Hc1Unknown1D,(konstant off),,,,1D00,,,onoff,,,
r;w,,Hc1Unknown1F,(konstant 4),,,,1F00,,,EXP,,,

So far I have observed no changes in these registers when the Hc was set to inactive.

BTW: What is the basis for the assumption of a register Ext. heat demand? I did not find such an entry for this in the regulator menu.

[stadid]

@chrizzzp

BTW: What is the basis for the assumption of a register Ext. heat demand? I did not find such an entry for this in the regulator menu.

It seems to be system configuration specific (config of the VR70 / VR71 modules).

It seems to be just the contact to turn heating for specific zone on/off, so ebusd register type most likely be on/off

[stadid]

@chrizzzp

r;w,,Hc1Unknown04,(konstant 30),,,,0400,,,EXP,,,target return temp?
shouldn't this be tempv instead of EXP?

Could you please check.

[chrizzzp]

@stadid

r;w,,Hc1Unknown04,(konstant 30),,,,0400,,,EXP,,,target return temp?
shouldn't this be tempv instead of EXP?

Yes, if it is the target return temp, then it should be tempv (which translates to EXP). I did not check this register yet.

[chrizzzp]

It seems to be just the contact to turn heating for specific zone on/off, so ebusd register type most likely be on/off

OK, this is an optional input to signal 'external heat demand' to the heat circuits. It is not available in my current VR71 config (2). In the VR71 config 1,3 or 6 it should be visible.

[stadid]

@chrizzzp

OK, this is an optional input to signal 'external heat demand' to the heat circuits. It is not available in my current VR71 config (2). In the VR71 config 1,3 or 6 it should be visible.

Unfortunately, also not available for me. We could only ask someone with this specific config to check, but I think this kind of config is rare. We could ask @jonesPD if his config fits.

I suggest it should be renamed to HcxMixingValvePosition.

Maybe we'll follow tradition of naming and shorten it just to MixerPosition (as in VRC700 it was called MixerMovement) . i.e.:

r,,Hc1MixerPosition,Mixer Position Heating Circuit 1,,,,1A00,,,EXP,,,"position of mixer for Hc1 (<0 closing, >0 opening)"
r,,Hc2MixerPosition,Mixer Position Heating Circuit 2,,,,1A00,,,EXP,,,"position of mixer for Hc2 (<0 closing, >0 opening)"
r,,Hc3MixerPosition,Mixer Position Heating Circuit 3,,,,1A00,,,EXP,,,"position of mixer for Hc3 (<0 closing, >0 opening)"

[chrizzzp]

OK, this is an optional input to signal 'external heat demand' to the heat circuits. It is not available in my current VR71 config (2). In the VR71 config 1,3 or 6 it should be visible.

Unfortunately, also not available for me. We could only ask someone with this specific config to check, but I think this kind of config is rare. We could ask @jonesPD if his config fits.

If not, I will temporarily change my config later this year (after heatings season) and check, because I think the register is interesting for heat pump owners as the externel heat demand can be used to start the heat generator upon external relay actuation. This is e.g. part of Vaillants way to comply to the SmartGrid standard to control heat pumps externally (state 4, heat pump is started).
See: https://www.heizungsforum.de/attachments/1670440394455-png.32597/

r,,Hc1MixerPosition,Mixer Position Heating Circuit 1,,,,1A00,,,EXP,,,"position of mixer for Hc1 (<0 closing, >0 opening)"
r,,Hc2MixerPosition,Mixer Position Heating Circuit 2,,,,1A00,,,EXP,,,"position of mixer for Hc2 (<0 closing, >0 opening)"
r,,Hc3MixerPosition,Mixer Position Heating Circuit 3,,,,1A00,,,EXP,,,"position of mixer for Hc3 (<0 closing, >0 opening)"

I agree.

[jonesPD]

@chrizzzp

OK, this is an optional input to signal 'external heat demand' to the heat circuits. It is not available in my current VR71 config (2). In the VR71 config 1,3 or 6 it should be visible.

Unfortunately, also not available for me. We could only ask someone with this specific config to check, but I think this kind of config is rare. We could ask @jonesPD if his config fits.

I suggest it should be renamed to HcxMixingValvePosition.

Maybe we'll follow tradition of naming and shorten it just to MixerPosition (as in VRC700 it was called MixerMovement) . i.e.:

r,,Hc1MixerPosition,Mixer Position Heating Circuit 1,,,,1A00,,,EXP,,,"position of mixer for Hc1 (<0 closing, >0 opening)"
r,,Hc2MixerPosition,Mixer Position Heating Circuit 2,,,,1A00,,,EXP,,,"position of mixer for Hc2 (<0 closing, >0 opening)"
r,,Hc3MixerPosition,Mixer Position Heating Circuit 3,,,,1A00,,,EXP,,,"position of mixer for Hc3 (<0 closing, >0 opening)"

I also don't have an additional heat source connected to my system. It is a very simple full electric split unit system.

I can update the mixer names to position instead of movement.

[chrizzzp]

I can update the mixer names to position instead of movement.

And there is also the finding of the HcxDesiredSetbackTemp, see #5 (comment)

[jonesPD]

I can update the mixer names to position instead of movement.

And there is also the finding of the HcxDesiredSetbackTemp, see #5 (comment)

Indeed, I'll add that too. However, with my system Hc1DesiredSetbackTemp reads as 0C. Or should I not expect 65C?

Both are now updated in the online repository

[chrizzzp]

@jonesPD

Indeed, I'll add that too. However, with my system Hc1DesiredSetbackTemp reads as 0C. Or should I not expect 65C?

0°C default is correct. It's only used in Hc 'fixed' mode anyway.

[stadid]

@chrizzzp

Could you please help me with "quickveto" mode?
Please check this message #2 (comment)

[stadid]

@chrizzzp @jonesPD,
Sorry for long silence - was busy with my software.

@chrizzzp
Have you time to check ExtHeatDemand contact HC register?

@jonesPD
could you update your config with target return temp:

replace

r,,Hc1Unknown04,(konstant 30),,,,0400,,,HEX:*,,,
r,,Hc2Unknown04,(konstant 30),,,,0400,,,HEX:*,,,
r,,Hc3Unknown04,(konstant 30),,,,0400,,,HEX:*,,,

with

r;w,,Hc1DesiredReturnTemp,target return temperature Hc1,,,,0400,,,tempv,,,temperature for the increase in return circuit (default 30)
r;w,,Hc2DesiredReturnTemp,target return temperature Hc2,,,,0400,,,tempv,,,temperature for the increase in return circuit (default 30)
r;w,,Hc3DesiredReturnTemp,target return temperature Hc3,,,,0400,,,tempv,,,temperature for the increase in return circuit (default 30)

[chrizzzp]

@stadid

@chrizzzp Have you time to check ExtHeatDemand contact HC register?

Not yet, thanks for the reminder. ;-)

[jonesPD]

@jonesPD could you update your config with target return temp:
done!

[chrizzzp]

@stadid @jonesPD

Finally found some time to look at the Hc*ExtHeatDemand settings.

I had to change the FM5 configuration vom '2' to '1' (3 or 6 would also be possible but are incompatible with my setup). I also identified the register for the FM5 configuration for the general section of the 15.ctlv2.csv:

*r,,,,,,B524,02000000,,,IGN:4,,,
*w,,,,,,B524,02010000,,,,,,
r;w,,FM5Config,,,,,2F00,,,UIN,,,FM5 VR71 configuration

Valid settings are: 1,2,3 and 6 (according to VRC720/2 manual).

The flag indicating an external heat demand is found in the respective Hc* sections:

*r,,,,,,B524,02000200,,,IGN:4,,,
*w,,,,,,B524,02010200,,,,,,
r,,Hc1ExtHeatDemand,,,,,1900,,,onoff,,,indicator of external heat demand for Hc1

*r,,,,,,B524,02000201,,,IGN:4,,,
*w,,,,,,B524,02010201,,,,,,
r,,Hc2ExtHeatDemand,,,,,1900,,,onoff,,,indicator of external heat demand for Hc2

*r,,,,,,B524,02000202,,,IGN:4,,,
*w,,,,,,B524,02010202,,,,,,
r,,Hc3ExtHeatDemand,,,,,1900,,,onoff,,,indicator of external heat demand for Hc3

In FM5 config 1 there is only one external trigger for Hc2 (signalled via S7 of the FM5 module, default is 'on', see below).
In FM5 config 2 there is no external trigger.
In FM5 config 3 there are external triggers for all three Hc (signalled via S6, S7, S8, respectively).
In FM5 config 6 there are external triggers for all three Hc (signalled via S9, S10, S11, respectively).
In the VRC720/2 the Ext. heat demand indicator is only shown for the Hc that allow external triggering (according to FM5 config).

In my system the default values of Hc*HeatDemand were always 'on'. I could trigger Hc2HeatDemand to 'off' by closing S7 of the FM5 module.

The default trigger behaviour is defined by a VRC720/2 setting which ebus register still has to be identified. In the regulator it can be found in the 'Installation Configuration', the option is called Conf.ext.input: Bridge, deact.. This setting is not available in FM5 config 2, but in configs 1,3 and 6. If it's set to Bridge,deact. then closing the trigger (e.g. S7) will deactivate the external heat demand (and vice versa).

I know this can be a bit confusing, but I hope my descriptions are clear...

[stadid]

@chrizzzp
Great work!

I know this can be a bit confusing, but I hope my descriptions are clear...

For me your explanations are absolutely clear, and I can imagine the amount of analysis involved in order to get the result.
Conf.ext.input: in my understanding just inverts control contact open/close logic (just defining which contact state (open or closed) represents ext. heat demand request).

[chrizzzp]

@stadid

Conf.ext.input: in my understanding just inverts control contact open/close logic (just defining which contact state (open or closed) represents ext. heat demand request).

Correct.

[stadid]

@chrizzzp

due to the extra commas in the string which prevents config from loading, I suggest to change

*r,,,,,,B524,02000000,,,IGN:4,,,
*w,,,,,,B524,02010000,,,,,,
r;w,,FM5Config,,,,,2F00,,,UIN,,,FM5 VR71 configuration, configuration of FM5 function module

to

*r,,,,,,B524,02000000,,,IGN:4,,,
*w,,,,,,B524,02010000,,,,,,
r;w,,FM5Config,,,,,2F00,,,UIN,,,FM5 VR71 module configuration (valid settings are 1-11)

[chrizzzp]

@stadud

due to the extra commas in the string which prevents config from loading, I suggest to change

Yes, of course, my mistake. I also changed it in my original post.

r;w,,FM5Config,,,,,2F00,,,UIN,,,FM5 VR71 module configuration (valid settings are 1-11)

Are you sure about the valid FM5 settings 1-11? Do they all make sense? According to the manual there are only configs 1,2,3 and 6.

[stadid]

@chrizzzp

Are you sure about the valid FM5 settings 1-11? Do they all make sense? According to the manual there are only configs 1,2,3 and 6.

Vaillant simulation for 720/2 shows 11 possible settings (from 1 to 11), that's why I concluded that other values are not restricted.
It seems that I was wrong. Could you set any other config number out of 1,2,3 and 6 on your regulator through menu?
If not, for sure comment should be altered to reflect only 1,2,3 and 6

[chrizzzp]

@stadid

Vaillant simulation for 720/2 shows 11 possible settings (from 1 to 11), that's why I concluded that other values are not restricted. It seems that I was wrong. Could you set any other config number out of 1,2,3 and 6 on your regulator through menu? If not, for sure comment should be altered to reflect only 1,2,3 and 6

Also on the regulator selection 1 to 11 is possible.
I also noticed in the simulator, depending on the heat generator selected (no heat pump) and using the corresponding function module (e.g. FM3) configuration 1-12 is possible.

[stadid]

@chrizzzp

Maybe it is some sort of "frost protection" for not permantly used houses? However, it's wrongly documented in the VRC720/2 manual.

I think that your guess is correct and observed behavior differs from the manual.

There is another parameter that controls switching HC on during low temperatures: OT constant heating

[chrizzzp]

@stadid

There is another parameter that controls switching HC on during low temperatures: OT constant heating

Yes, it should be this one:

r;w,,ContinuousHeating,continous heating,,,,0200,,,tempv,,,-26=off when the outside temperature falls below this threshold temperature the continuous heating function is started (off <=> function is disabled)

Description in the english manual is quite cryptic. I think it works like this: if the outside temperature falls below ContinuousHeating temperature it will continously heat to (probably) z1HeatingRoomTempDesiredManualControlled (remains to be tested which setpoint temperature is actually used) and not go to setback temperature/turn heating off (depending on HcxSetBackMode).

[jonesPD]

@chrizzzp : I have some domotica scripts running that with certain conditions switch off the HP heating circuit entirely. So it is automatic, but not automatic by means of the regulator. I call this 'summer' mode, when temperatures rise further, the script will switch to 'tropical' mode, allowing for cooling by the heatpump. In the colder seaons, I use it to switch between 'expanded' and 'active'. In summer mode it is indeed set on 'expanded'.

[chrizzzp]

@stadid @jonesPD

We now have the following unknown registers (default values in parentheses):

r;w,,Hc1Unknown09,(konstant 60),,,,0900,,,tempv,,,
r;w,,Hc1Unknown13,(konstant 1),,,,1300,,,SIN,,,
r;w,,Hc1Unknown16,(konstant 0),,,,1600,,,SIN,,,
r;w,,Hc1Unknown17,(konstant 0.0 EXP?),,,,1700,,,EXP,,,
r;w,,Hc1Unknown18,(konstant off),,,,1800,,,onoff,,,
r;w,,Hc1Unknown19,(konstant on),,,,1900,,,onoff,,,
r;w,,Hc1Unknown1D,(konstant off),,,,1D00,,,onoff,,,
r;w,,Hc1Unknown1F,(konstant 4),,,,1F00,,,EXP,,,

I think I identified the 'HcxUnknown09' register: if 'HcxCircuitType' is set to 'hwc' (hc acts as external DHW circuit) this register defines the desired DHW temperature of the external DHW circuit. I suggest to rename the register to 'HcxExtHwcTempDesired'.

So the definitions would be:

*r,,,,,,B524,02000200,,,IGN:4,,,
*w,,,,,,B524,02010200,,,,,,
r;w,,Hc1ExtHwcTempDesired,Hc1 desired external HWC temperature,,,,0900,,,tempv,,,Hc1 desired external HWC temperature

*r,,,,,,B524,02000201,,,IGN:4,,,
*w,,,,,,B524,02010201,,,,,,
r;w,,Hc2ExtHwcTempDesired,Hc2 desired external HWC temperature,,,,0900,,,tempv,,,Hc2 desired external HWC temperature

*r,,,,,,B524,02000202,,,IGN:4,,,
*w,,,,,,B524,02010202,,,,,,
r;w,,Hc3ExtHwcTempDesired,Hc3 desired external HWC temperature,,,,0900,,,tempv,,,Hc3 desired external HWC temperature

I will try to see if more ExtHwc registers exist.

[chrizzzp]

@stadid @jonesPD

I will try to see if more ExtHwc registers exist.

They do... ;-) I'm not sure to which PR we should put this. It is actually also an HWC topic...

Although the circuit type 'ExtHwc' is probably a rarely used function of the VR71/FM5 module, it will put the heat generator into HWC heating mode, but does not swith the internal three-way-valve ("priorityswitchingvalve") to HWC, so it will operate the heating circuit. The usual application (I think) could be to heat up a second (external DHW) cylinder, but of course it is not limited to this. It will actuate an external loading pump (or switch an external valve) connected to the respective actuator outlet of the VR71/FM5. It will stay active until a dedicated sensor (connected also to VR71/FM5) reaches the value 'HcxExtHwcTempDesired'. Through the separate OpMode-setting it can be bound to the HWC time schedule (time-controlled) or run permanently (manual). I haven't tested yet wether all general HWC settings apply (e.g. HwcLockTime), but e.g. HwcMaxChargeTime does.

Here's the summary:

*r,,,,,,B524,02000200,,,IGN:4,,,
*w,,,,,,B524,02010200,,,,,,
r;w,,Hc1ExtHwcTempDesired,Hc1 desired external HWC temperature,,,,0900,,,tempv,,,Hc1 desired external HWC temperature
r;w,,Hc1ExtHwcOpMode,ExtHwcOpMode,,,,1300,,,opmode2,,,operation mode of external Hwc circuit
r,,Hc1ExtHwcActive,,,,,1800,,,onoff,,,

*r,,,,,,B524,02000201,,,IGN:4,,,
*w,,,,,,B524,02010201,,,,,,
r;w,,Hc2ExtHwcTempDesired,Hc2 desired external HWC temperature,,,,0900,,,tempv,,,Hc2 desired external HWC temperature
r;w,,Hc2ExtHwcOpMode,ExtHwcOpMode,,,,1300,,,opmode2,,,operation mode of external Hwc circuit
r,,Hc2ExtHwcActive,,,,,1800,,,onoff,,,

*r,,,,,,B524,02000202,,,IGN:4,,,
*w,,,,,,B524,02010202,,,,,,
r;w,,Hc3ExtHwcTempDesired,Hc3 desired external HWC temperature,,,,0900,,,tempv,,,Hc3 desired external HWC temperature
r;w,,Hc3ExtHwcOpMode,ExtHwcOpMode,,,,1300,,,opmode2,,,operation mode of external Hwc circuit
r,,Hc3ExtHwcActive,,,,,1800,,,onoff,,,

Interestingly, I also observed that when an 'external hwc' heating circuit is active (i.e. heating), the respective register 'HcxPumpStatus' reads the value '3' instead of 1 ('on'). So obviously this register is not of the 'onoff' type as currently defined in the ctlv2.csv. So I created a new template (hcpumpstate) and changed the definitions to:

_templates.csv:

hcpumpstate,UCH,0=off;1=on;3=exthwc

15.ctlv2.csv:

r,,Hc1PumpStatus,PumpStatus Hc1,,,,1E00,,,hcpumpstate,,,pump status of Hc1
...
r,,Hc2PumpStatus,PumpStatus Hc2,,,,1E00,,,hcpumpstate,,,pump status of Hc2
...
r,,Hc3PumpStatus,PumpStatus Hc3,,,,1E00,,,hcpumpstate,,,pump status of Hc3

I'm not quite sure why they implemented a different 'hcpumpstate' for this hc mode, because it seems the same actuators of the VR71/FM5 are triggered.

[jonesPD]

@chrizzzp Adding your new proposals to my repository, I found that the HcxPumpStatus are indeed not of onoff type. I found in the notes the following: Pump status of zone 1 (0=off, 1=heating, 2=cooling)

Therefore, I propose the following definition to _templates.csv:
hcpumpstate,UCH,0=off;1=heating;2=cooling;3=exthwc

[chrizzzp]

@jonesPD

@chrizzzp Adding your new proposals to my repository, I found that the HcxPumpStatus are indeed not of onoff type. I found in the notes the following: Pump status of zone 1 (0=off, 1=heating, 2=cooling)

Therefore, I propose the following definition to _templates.csv: hcpumpstate,UCH,0=off;1=heating;2=cooling;3=exthwc

Agree. Just noticed in john30's repo the datatype of HcxPumpStatus is UIN, which would evaluate also the next byte and allow values from 0...65534. I wonder if there is more to the 'hcx pump state'.

[chrizzzp]

@stadid @jonesPD

I could resolve two more Hc registers related to floor screed drying (although rarely used I guess). Floor screed drying works by operating the Hc as a fixed circuit (independent of outside temperature) and activates heat pump and immersion heater (backup boiler!) at the same time. The screed drying schedule comprises up to 29 days with an individual fixed temperature for the whole day, e.g. :

day1 - 25°C
day2 - 30 °C
day3 - 35°C
...
day27 - 35°C
day28 - 30°C
day29 - 25°C
etc.

(I'm just wondering whether this can be used also for something else...)

The registers are:

*r,,,,,,B524,02000200,,,IGN:4,,,
*w,,,,,,B524,02010200,,,,,,
r;w,,Hc1ScreedDryingDay,,,,,1600,,,UIN,,,current day of screed Hc1 drying schedule (1 to 29 0=screed drying off) 
r,,Hc1ScreedDryingDesiredTemp,,,,,1700,,,tempv,,,current Hc1 screed drying desired temp

*r,,,,,,B524,02000201,,,IGN:4,,,
*w,,,,,,B524,02010201,,,,,,
r;w,,Hc2ScreedDryingDay,,,,,1600,,,UIN,,,current day of Hc2 screed drying schedule (1 to 29 0=screed drying off) 
r,,Hc2ScreedDryingDesiredTemp,,,,,1700,,,tempv,,,current Hc2 screed drying desired temp

*r,,,,,,B524,02000202,,,IGN:4,,,
*w,,,,,,B524,02010202,,,,,,
r;w,,Hc3ScreedDryingDay,,,,,1600,,,UIN,,,current day of Hc3 screed drying schedule (1 to 29 0=screed drying off) 
r,,Hc3ScreedDryingDesiredTemp,,,,,1700,,,tempv,,,current Hc3 screed drying desired temp

Normally HcxScreedDryingDay is set to 0, so screed drying is off. Setting this register to values between 1 and 29 will immediatly start screed drying with HcxScreedDryingDesiredTemp as the fixed target temperature defined for this day in the schedule. HcxScreedDryingDesiredTemp is read-only and has to be set in the VRC720 regulator (Screed drying) until the respective schedule registers have been found... ;-)

BTW: @stadid are you still working on your MyVaillant app replacement?

[stadid]

@chrizzzp
Thank you for your GREAT contribution to the project. You with @jonesPD are among not so many participants here really helping moving development forward. I am short of time last months, but regularly see your updates on HP and regulator config.

As to the app, I've finished VRC720 branch and added it to the app. As of today my app supports VRC700 all generations and VRC720 (all 3 generations). If you are interested I could upload Clonezilla install image (~1Gb) and provide you with the link to evaluate app in VM.

@chrizzzp @jonesPD
I have a question - do you think my application will be helpful for Vaillant users?
The main difference with HA approach is that it's "regulator-centric" - it's focused on system management through regulator.
So in short words it's self-hosted "advanced" version of the native app, with additional features.

The main problem is that initially app is not multi-lingual and huge amount of translation should be performed in order to provide English version. Currently there are 200 html interface templates including huge qty of in-program messages.

Is it worth spending time on this?
What do you think?

Here are the app key features:
Detailed description of status codes and error codes for supported families of heat generators (turboTEC, atmoTEC, eloBLOCK, ecoTEC, ecoVIT, ecoCRAFT)
• Display of user-selected system parameters (max 10 parameters), parameters could be taken from the heat generator or regulator.
• Sending error notifications, current status reports and basic remote system management via Telegram bot.
• Built-in L2TP/IPsec VPN client for remote access to the web interface of the program.
• The ability to change all available settings of the regulator and heat generator through the application (experimental function for experienced users).
• Automatic time and date correction of the regulator.
• Automatic sending of selected system parameters to the public monitoring IoT service (max 6 parameters)
• The ability to control the system by opening/closing the control contact (5 control inputs, requires a special USB GPIO device). Only one feature implemented (switch DHW off when contact is closed, and restore last DHW state when contact is open).
• Both wired (Ethernet) and WiFi connection are supported
• Application made as a web interface, which allows remote access from any device (phone, tablet, PC).

[chrizzzp]

@stadid good to hear you're still around!

I have a question - do you think my application will be helpful for Vaillant users?

Helpful for sure, as it is more powerful than the MyVaillant App and provides independence of the Vaillant servers. But - if I understood correctly - since it's also a hardware solution (involving ebus coupler and some computer hardware, not the VR921 gateway though) there is definitely a barrier to get started or change from the App to your software. It might be different for countries where the Vaillant servers / MyVaillant App are unavailable.

BTW: can all ebus couplers be used?

Of course, if the software gets translated the barrier will certainly lower again, but would IMHO require also translations to other than English (at least for the countries with the most systems sold, do you happen to know which countries have the most systems installed?).

In my oppinion it could also be difficult as you somehow do "compete" with similar approaches using (free) home automation platforms, such as Home Assistant and others which allow implementation of many of these things, too. Although they currently still require still quite some individual effort (while your ready-to-use software is probably the most advanced solution) but the number of HA users is continously growing and this will have an impact in the future, I think.

• Automatic sending of selected system parameters to the public monitoring IoT service (max 6 parameters)

What IoT services are these?

• The ability to control the system by opening/closing the control contact (5 control inputs, requires a special USB GPIO device). Only one feature implemented (switch DHW off when contact is closed, and restore last DHW state when contact is open).

What would be the application case for this?

[stadid]

@chrizzzp

Of course, if the software gets translated the barrier will certainly lower again, but would IMHO require also translations to other than English (at least for the countries with the most systems sold, do you happen to know which countries have the most systems installed?).

Unfortunately I do not have info in which countries Vaillant sells most. I guess Europe is the target region.

In my oppinion it could also be difficult as you somehow do "compete" with similar approaches using (free) home automation platforms, such as Home Assistant and others which allow implementation of many of these things, too. Although they currently still require still quite some individual effort (while your ready-to-use software is probably the most advanced solution but the number of HA users is continously growing and this will have an impact in the future, I think.

I share your vision of the situation, I do not expect my app to be a popular replacement of the My Vaillant, nor it's a competitor for HA integration as majority HA users at least have some understanding of ebusd and adpater/config setup.

Comparing my app with HA the only advantage I see is that user do not need to make technically sophisticated settings like setting-up ebus-adapter, choosing the right ebusd config, and so on.

BTW Even evaluation version of my app is fully functional. It only has limitations on displaying zone parameters (1 zone) and heating circuits parameters (1 heating circuit).

BTW: can all ebus couplers be used?

Yes, all ebus couplers that are working with ebusd could be used in my software, but some non-critical app features (like password recovery) will not work with network connected couplers.

What IoT services are these?

Local IoT service - providing for free possibility to send values of different parameters of your home sensors and stores them on their server. Plus graphs, some basic notifications if values are out of range, etc.
You can make some sensors public (i.e. outside temp), and make some private (available only for the owner).

I've added this feature for the users who want to have nice graphs of their system performance. Hardware which I recommend for installing my app is not powerful and considering that it uses emmc as a storage, i do not what to implement this feature by myself.

What would be the application case for this?

This feature I've implemented for myself))) I have a DHW cylinder with DHW circulation pump controlled by the boiler (using vr40 "2 of 7" extension module). There are situations where pressure in my domestic water system falls to 0, in this case I want to turn off heating of DHW cylinder and switch off circulation pump in order not to run it dry.

There are relatively big amount of use case scenarios that could be implemented using this feature. For example: for old people having difficulties with changing settings of the VRC7XX regulator make it simple as turning on/off the light. Just a switch: turn it on and hot water is on, turn it off and hot water is disabled. It's just an example, and for sure those features are not required by majority of the users, so i've implemented support of adding such features in the code for the future.

[chrizzzp]

@jonesPD @stadid

Adding your new proposals to my repository, I found that the HcxPumpStatus are indeed not of onoff type. I found in the notes the following: Pump status of zone 1 (0=off, 1=heating, 2=cooling)

Therefore, I propose the following definition to _templates.csv: hcpumpstate,UCH,0=off;1=heating;2=cooling;3=exthwc

While testing the external DHW circuit (exthwc) I noticed the heat pump actually behaves almost the same as in the "regular" (internal) Hwc mode, only the internal three-way-valve is not actuated (remains in Hc position). The building circulation pump (acting as the DHW loading pump) also goes to full power and the status code also displays the 'warm water circuit' message.

In analogy to HcxPumpState I further observed a VRC720 register in the general section that seems to represent the pump state of the internal building circuit pump / hwc loading pump, which also cycles between 0 = off, 1 = heating and 3 = hwc (could not test cooling mode). I suggest:

*r,,,,,,B524,02000000,,,IGN:4,,,
r,,BuildingCircuitPumpState,PumpState building circuit pump,,,,4800,,,hcpumpstate,,,polled by VR921 every 60s from ctlv2

and changing the template hcpumpstate to:

hcpumpstate,UCH,0=off;1=heating;2=cooling;3=hwc

Maybe someone could confirm this and check this register during warm water preparation using the internal DHW circuit (which I don't have)?

One could also discuss whether 'BuildingCircuitPump' is really the best name, as this pump is also used for DHW loading. However, it's probably it's better to stick to the established name of this pump...?

[stadid]

One could also discuss whether 'BuildingCircuitPump' is really the best name, as this pump is also used for DHW loading. However, it's probably it's better to stick to the established name of this pump...?

@chrizzzp
If you don't mind, I would like to share my approach of how to name this register.
If we talking about VRC720 config we should expect some level of abstraction from the Vaillant developers.
For DHW it means that we need to read the pump status which is responsible for charging DHW cylinder, regardless of what system schema/equipment is currently used for this. In your case it is building pump. In my case it's standard internal heat generator pump, it could be even external pump manged by VR70/71. Don't focus on specific pump location. If possible stick register name with pump function. Not sure if I correctly understand your research, but this register is only for DHW? Could it happen that this register is "mirroring" some other specific register intended only for other specific purpose?

I'm not quite sure why they implemented a different 'hcpumpstate' for this hc mode, because it seems the same actuators of the VR71/FM5 are triggered.

That's the point!
Here we are using the same register using the same actuators for different circuit types.
If circuit type is heating - its HCpump
If the circuit type is DHW - it's DHW pump

Hope my explanation was not too misleading)))

[chrizzzp]

@stadid

For DHW it means that we need to read the pump status which is responsible for charging DHW cylinder, regardless of what system schema/equipment is currently used for this. In your case it is building pump. In my case it's standard internal heat generator pump, it could be even external pump manged by VR70/71. Don't focus on specific pump location. If possible stick register name with pump function. Not sure if I correctly understand your research, but this register is only for DHW? Could it happen that this register is "mirroring" some other specific register intended only for other specific purpose?

I agree, the setups are often very different and esp. the regulator VRC720 can control all kind of heat generators...

So the register preliminarily named BuildingCircuitPumpState indeed reflects more than just DHW loading (state=3, max. flow). It goes to state=1 (50% flow) when the pump is running in Hc mode, and to state=0 when turned off (e.g. by outside temperature cutoff) and @jonesPD reported it shows state=2 in cooling mode. (BTW in my case it's not the building circuit pump because I don't have a direct circuit, but a separate pump for Hc1 involving a mixer.)

How about naming it SystemPump or HeatGeneratorPump? Any other suggestions?

Do you have the chance to monitor this register on your setup?

[stadid]

How about naming it SystemPump or HeatGeneratorPump? Any other suggestions?

I am still trying to understand all the schematics where this pump register is used.
What this register show in complicated systems - having several pumps?
This will define the name of the register.
Correct me if I am wrong, but it could not be named HeatGeneratorPump as it also shows the status of the external pump, which could be controlled not only by heat generator, but by VR70/71 module.

Do you have the chance to monitor this register on your setup?

At the moment no - I've connected my VRC700 back.
I'll try to monitor it when VRC720 will be connected to my system, but when it happens, I don't know.

[chrizzzp]

@stadid

Correct me if I am wrong, but it could not be named HeatGeneratorPump as it also shows the status of the external pump, which could be controlled not only by heat generator, but by VR70/71 module.

No, it does not show the status of the external pump (connected e.g. to the VR71). Sorry, if I wasn't clear about this.

Let me try to explain (I'm afraid this will be a long text...). ;-)

I consider my system to have a rather "complicated" setup:

There is the'system' pump in the hydraulic station (until now termed "building circuit pump") which actually loads a relativley large storage cylinder (800 L) used for heating only (my DHW is completely separate from the heating). This cylinder is mainly there to store the (hot) water from a (fire) chimney with water pipes (so the heat generated in the chimney can be used for heating the whole house). As the water from the chimney is about 60°C, but the floor heating requires no more than 30°C, the floor heating circuit (Hc1) is connected through a mixer and an external pump (Hc1Pump, connected to VR71) to the cylinder. But also the HP can heat the cylinder (when chimney is not in use), but the hydraulics are connected in a way that only water in the upper part of the cylinder is heated by the HP (while the chimney heats heats the whole cylinder).

Now (to make it even more complicated...), since I have 8 kWp photovoltaics (PV), I wanted to make use of the PV excess energy and heat up the cylinder using the heat pump while the energy is "for free". Since I monitor solar electric yield through my home automation, I set it up like this, that if there is PV excess energy (and a certain amount of solar yield is also predicted for the day) the cylinder is heated up to e.g. 50°C by the HP (I have a rather large HP, so this does not take too long). And to start the HP without an actual heat demand from Hc1 and to load the cylinder as fast as possible I set up a "virtual" heating circuit (Hc3) using the circuit type 'External DHW' (via VR71).

In addition (you've been warned... ;-)) in this use case an external three-way-valve is actuated which allows heating of the whole cylinder (and not only the upper part as in non-PV heating mode). This external valve is also connected to the VR71 and is automatically actuated as soon as Hc3 is active. An additional temperature sensor (also connected to VR71) monitors the cylinder temperature and shuts off Hc3 as soon as the desired temperature is reached (e.g. 50°C).
With a heat demand from the 'external DHW' the HP goes into HWC mode (full power of 'system' water pump), but the internal three-way valve is NOT actuated (which would be used for normal DHW mode to switch from the heating circuit to the DHW circuit ). This is how the 'external DHW' is actually implemented by Vaillant (originally designed to heat up a second DHW cylinder, I think).
So I basically use the DHW mode of the HP to heat up the Hc cylinder, because it may be a bit faster (remains to be confirmed, this is all new...) and I can actuate the external valve via the VR71.
BTW heating the cylinder is also possible in normal Hc mode, but then the 'system' water pump will only run at 50% power and automatic shut-off of cylinder heating is only possible using the HP supply flow/desired flow temperatures (energy integral), if no external temperature sensor/ebusd is used (and I need an external relay to actuate the external valve).

Now back to BuildingCircuitPumpState:

The system' ("building circuit") water pump' of my system is in the hydraulic station. The pump flow and pump power can be monitored by reading ftom the hmu:

r,,BuildingCircuitFlow,,,,,2B03FFFF,,,UIN,,l/h,Current heating water flow rate (liter/hour),,,,,,,,,,,,,,,,,,
r,,BuildingCircuitPumpPower,,,,,0103FFFF,,,UIN,,%,Building circuit pump power (% of maximum),,,,,,,,,,,,,,,,,,

In direct heating circuits this pump is really the building circuit pump, in my case not. So the naming of these registers is probably a bit unfortunate.

However, using my system as an example we have the following different scenarios:

1. normal heating mode is on (Hc1, circuit type: mixer) and (external) DHW (Hc3, circuit type: extHwc) is inactive: BuildingCircuitPumpState and Hc1PumpState =1 (heating), Hc3PumpState = 0 (off))
2. normal heating mode is on (Hc1) and (external) DHW mode is active (Hc3): BuildingCircuitPumpState and Hc3PumpState =3 (Hwc), Hc1PumpState =1 (heating, but only when HwcParallelLoading (ctlv2) is "on", otherwise Hc1PumpState would be 0 (off))
3. normal heating mode is off (Hc1, e.g. because of outside temperature cut-off) and (external) DHW mode is active (Hc3): BuildingCircuitPumpState and Hc3PumpState =3, Hc1PumpState =0
4. normal heating mode is off (Hc1, e.g. because of outside temperature cut-off) and (external) DHW mode is incative: BuildingCircuitPumpState, Hc1PumpState and Hc3PumpState = 0

Unfortunately, I cannot generate the case where the external pump of Hc1 is active, but the 'system pump' is not. I guess this would only be possible if Hc1 would be active, but not generate a heat demand (wouldn't make sense, would it?).

In summary, I think the register BuildingCircuitPumpState indeed shows the pumpstate of the 'system' pump (in the hydraulic station in my case). It would be interesting to see how this register behaves in system where the DHW loading is performed by a separate pump.

Sorry for this long post, I hope it's not all too confusing now...

[stadid]

@chrizzzp

Sorry for this long post, I hope it's not all too confusing

Your solution is effective and it seems you've put a lot of efforts to get the desired result, as the automation is quite complicated, and some used technical solutions are elegant.

But it took me some time to figure out your system structure and main working principles. ))))

As to the naming of the BuildingCircuitPumpState it seems to me that this register "mirrors" some HC and DHW (maybe other) pumps state depending on the system configuration and current working mode. At least for now I have such a feeling.

For sure, you are right - we need more data from other system configurations where we can correspond this register state with other existing HC, DHW, buffer cylinder pump, etc. states.
Maybe its better to rename this register to EquipmentControlledPumpState. It seems to me more general naming.

[stadid]

@chrizzzp
Could you please check if the following config entries allow to read temp and humidity directly from VRC720 sensors:

*r,,,,,,B524,06000901,,,IGN:4,,,
r,,RoomHumidity,room humidity shown by regulator,,,,0700,,,exp,,,room humidity shown by regulator
r,,RoomTemp,room temperature shown by regulator,,,,0F00,,,exp,,,room temperature shown by regulator

Currently do not have opportunity to check this on my system.
This works on 700, absolutely not sure if this will do for VRC720.

[chrizzzp]

@stadid

> *r,,,,,,B524,06000901,,,IGN:4,,,
> r,,RoomHumidity,room humidity shown by regulator,,,,0700,,,exp,,,room humidity shown by regulator
> r,,RoomTemp,room temperature shown by regulator,,,,0F00,,,exp,,,room temperature shown by regulator

Yes, they work! They give the same readings as the respective values in the regulator-associated zone section.
How did you find them? Did you also scan other registers nearby?

[stadid]

@chrizzzp

Yes, they work! They give the same readings as the respective values in the regulator-associated zone section.
How did you find them? Did you also scan other registers nearby?

It's a side effect of finding how to read humidity from VRC700 and my recent analysis of communications between VR91 and VRC700.

0700 (humidity) was found by analyzing traffic between internet gateway and VRC700
At that time I was not aware of the temp register at 0F00

Initially my goal was to read room air humidity from VR91 (MyVaillant do not show this information for zones assigned to VR91)
While analyzing traffic from VR91 to VRC700 I've discovered that VR91 "writes" every 5 min to two registers of VRC700 which base "address" alters depending on which device (not bus) address was set on VR91 (address is in range 1-8)

So based on the findings I've assumed that base address at 09 should also contain temp value, and successfully confirmed that. You could try to check the config below on 720, but you need VR92 and it should be assigned to the corresponding zone, otherwise those registers show empty values (at least that's what I assume based on VRC700 behavior).

below is extract from the VRC700 config complied from the result of my findings (just remove conditional operators)

# ##### Room humidity #####,,,,,,,,,,,,,
*r,,,,,,B524,06000901,,,IGN:4,,,
r,,RoomHumidity,room humidity shown by regulator,,,,0700,,,exp,,,room humidity shown by regulator
r,,RoomTemp,room temperature shown by regulator,,,,0F00,,,exp,,,room temperature shown by regulator
# ##### VR91 address 1 #####,,,,,,,,,,,,,
*r,,,,,,B524,06000a01,,,IGN:4,,,
r,,VR91addr1RoomHumidity,room humidity shown by VR91 address 1,,,,0700,,,exp,,,room humidity shown by VR91 address 1
r,,VR91addr1RoomTemp,room temperature shown by VR91 address 1,,,,0F00,,,exp,,,room temperature shown by VR91 address 1
# ##### VR91 address 2 #####,,,,,,,,,,,,,
*r,,,,,,B524,06000a02,,,IGN:4,,,
r,,VR91addr2RoomHumidity,room humidity shown by VR91 address 2,,,,0700,,,exp,,,room humidity shown by VR91 address 2
r,,VR91addr2RoomTemp,room temperature shown by VR91 address 2,,,,0F00,,,exp,,,room temperature shown by VR91 address 2
# ##### VR91 address 3 #####,,,,,,,,,,,,,
*r,,,,,,B524,06000a03,,,IGN:4,,,
r,,VR91addr3RoomHumidity,room humidity shown by VR91 address 3,,,,0700,,,exp,,,room humidity shown by VR91 address 3
r,,VR91addr3RoomTemp,room temperature shown by VR91 address 3,,,,0F00,,,exp,,,room temperature shown by VR91 address 3
# ##### VR91 address 4 #####,,,,,,,,,,,,,
*r,,,,,,B524,06000a04,,,IGN:4,,,
[SW>419]r,,VR91addr4RoomHumidity,room humidity shown by VR91 address 4,,,,0700,,,exp,,,room humidity shown by VR91 address 4
[SW>419]r,,VR91addr4RoomTemp,room temperature shown by VR91 address 4,,,,0F00,,,exp,,,room temperature shown by VR91 address 4
# ##### VR91 address 5 #####,,,,,,,,,,,,,
*r,,,,,,B524,06000a05,,,IGN:4,,,
[SW>419]r,,VR91addr5RoomHumidity,room humidity shown by VR91 address 5,,,,0700,,,exp,,,room humidity shown by VR91 address 5
[SW>419]r,,VR91addr5RoomTemp,room temperature shown by VR91 address 5,,,,0F00,,,exp,,,room temperature shown by VR91 address 5
# ##### VR91 address 6 #####,,,,,,,,,,,,,
*r,,,,,,B524,06000a06,,,IGN:4,,,
[SW>419]r,,VR91addr6RoomHumidity,room humidity shown by VR91 address 6,,,,0700,,,exp,,,room humidity shown by VR91 address 6
[SW>419]r,,VR91addr6RoomTemp,room temperature shown by VR91 address 6,,,,0F00,,,exp,,,room temperature shown by VR91 address 6
# ##### VR91 address 7 #####,,,,,,,,,,,,,
*r,,,,,,B524,06000a07,,,IGN:4,,,
[SW>419]r,,VR91addr7RoomHumidity,room humidity shown by VR91 address 7,,,,0700,,,exp,,,room humidity shown by VR91 address 7
[SW>419]r,,VR91addr7RoomTemp,room temperature shown by VR91 address 7,,,,0F00,,,exp,,,room temperature shown by VR91 address 7
# ##### VR91 address 8 #####,,,,,,,,,,,,,
*r,,,,,,B524,06000a08,,,IGN:4,,,
[SW>419]r,,VR91addr8RoomHumidity,room humidity shown by VR91 address 8,,,,0700,,,exp,,,room humidity shown by VR91 address 8
[SW>419]r,,VR91addr8RoomTemp,room temperature shown by VR91 address 8,,,,0F00,,,exp,,,room temperature shown by VR91 address 8

[chrizzzp]

@stadid

Nice find! What is the conditional operator [SW>419] used for?

I checked the VR91-associated registers on the VRC720 and they also work, but all yield ffffff7f (-), as I have no VR92.

But I checked the 'nearby' registers from base address 09 and got some responses (after the slash):

3115b52406060009010100 / 050109010001
3115b52406060009010200 / 050109020015
3115b52406060009010300 / 050109030000
3115b52406060009010400 / 0701090400050e00

They don't seem to change within an hour or so, though.
However, the corresponding registers for VR9x base address 0a were:

3115b5240606000a010100 / 05010a010000
3115b5240606000a010200 / 05000a020000
3115b5240606000a010300 / 05000a0300ff
3115b5240606000a010400 / 07000a0400ffffff

(all reflecting non-existent VR9x)

[stadid]

@chrizzzp

What is the conditional operator [SW>419] used for?

This removes unsupported zones and associated registers for earlier generations of VRC700:
700/2 and 700/4 supports only 3 zones/heating circuits max
700/5 and 700/6 supports 9 zones/heating circuits max

I checked the VR91-associated registers on the VRC720 and they also work, but all yield ffffff7f (-), as I have no VR92.

The same result i observe on VRC700 without VR91, i.e.: ffffff7f (-)

There is another linked register in VRC700 which I believe tells VR91 to which zone which VR91 address is assigned

below is just my guess
vr 91 address 1 requesting assignment from VRC700 - receiving reply that address1 assigned to zone 1
3015b5240108 / 08000001010c012e30

vr91 address 2 requesting zone assignment - no zone assigned to any of VR91 units
7015b5240108 / 08ff00000000000000

just to check if somebody could perform:

VR91 address = ebus slave address | ebus master address
1 = 35 | 30
2 = 75 | 70
3 = f5 | f0
4 = 1c | 17
5 = 3c | 37
6 = 7c | 77
7 = fc | f7
8 = 06 | 01

[jonesPD]

@chrizzzp

What is the conditional operator [SW>419] used for?

This removes unsupported zones and associated registers for earlier generations of VRC700: 700/2 and 700/4 supports only 3 zones/heating circuits max 700/5 and 700/6 supports 9 zones/heating circuits max

@stadid : RoomHumidity and RoomTemp also work in my set up with a CTLV2. However, with [SW>419] in the 15.ctlv2.csv file, I get an error "condition SW>419 not defined". Probably because I just copied the register definition and the condition definition is missing. How to get it to work?

[jonesPD]

Ah...I managed already by adding the definition:

*[SW>419],scan,,,SW,,>419

in the same file with the RoomHumidity and RoomTemp definitions.

This is the simple use of the conditions I guess. Using it to select a device specific scode template for the hcmode.inc and/or the device specific files is more complicated I assume. Or do we already know how to connect it to the various examples @stadid mentioned here ?

[stadid]

@jonesPD

Ah...I managed already by adding the definition:

*[SW>419],scan,,,SW,,>419

in the same file with the RoomHumidity and RoomTemp definitions.

This is the simple use of the conditions I guess.

Yes, exact.
It was done to limit number of addresses for 700/4 and 700/2 (they support only VR91 addresses 1-3), while 700/5 and 700/6 are using the whole range 1-8

If condition not met those config strings are ignored.

BTW, we do not need them for CTLV2 as all 720 series support addresses 1-8 as I understand

so for the VRC720 config should look like this

# ##### Room humidity #####,,,,,,,,,,,,,
*r,,,,,,B524,06000901,,,IGN:4,,,
r,,RoomHumidity,room humidity shown by regulator,,,,0700,,,exp,,,room humidity shown by regulator
r,,RoomTemp,room temperature shown by regulator,,,,0F00,,,exp,,,room temperature shown by regulator
# ##### VR92 address 1 #####,,,,,,,,,,,,,
*r,,,,,,B524,06000a01,,,IGN:4,,,
r,,VR92addr1RoomHumidity,room humidity shown by VR92 address 1,,,,0700,,,exp,,,room humidity shown by VR92 address 1
r,,VR92addr1RoomTemp,room temperature shown by VR92 address 1,,,,0F00,,,exp,,,room temperature shown by VR92 address 1
# ##### VR92 address 2 #####,,,,,,,,,,,,,
*r,,,,,,B524,06000a02,,,IGN:4,,,
r,,VR92addr2RoomHumidity,room humidity shown by VR92 address 2,,,,0700,,,exp,,,room humidity shown by VR92 address 2
r,,VR92addr2RoomTemp,room temperature shown by VR92 address 2,,,,0F00,,,exp,,,room temperature shown by VR92 address 2
# ##### VR92 address 3 #####,,,,,,,,,,,,,
*r,,,,,,B524,06000a03,,,IGN:4,,,
r,,VR92addr3RoomHumidity,room humidity shown by VR92 address 3,,,,0700,,,exp,,,room humidity shown by VR92 address 3
r,,VR92addr3RoomTemp,room temperature shown by VR92 address 3,,,,0F00,,,exp,,,room temperature shown by VR92 address 3
# ##### VR92 address 4 #####,,,,,,,,,,,,,
*r,,,,,,B524,06000a04,,,IGN:4,,,
r,,VR92addr4RoomHumidity,room humidity shown by VR92 address 4,,,,0700,,,exp,,,room humidity shown by VR92 address 4
r,,VR92addr4RoomTemp,room temperature shown by VR92 address 4,,,,0F00,,,exp,,,room temperature shown by VR92 address 4
# ##### VR92 address 5 #####,,,,,,,,,,,,,
*r,,,,,,B524,06000a05,,,IGN:4,,,
r,,VR92addr5RoomHumidity,room humidity shown by VR92 address 5,,,,0700,,,exp,,,room humidity shown by VR92 address 5
r,,VR92addr5RoomTemp,room temperature shown by VR92 address 5,,,,0F00,,,exp,,,room temperature shown by VR92 address 5
# ##### VR92 address 6 #####,,,,,,,,,,,,,
*r,,,,,,B524,06000a06,,,IGN:4,,,
r,,VR92addr6RoomHumidity,room humidity shown by VR92 address 6,,,,0700,,,exp,,,room humidity shown by VR92 address 6
r,,VR92addr6RoomTemp,room temperature shown by VR92 address 6,,,,0F00,,,exp,,,room temperature shown by VR92 address 6
# ##### VR92 address 7 #####,,,,,,,,,,,,,
*r,,,,,,B524,06000a07,,,IGN:4,,,
r,,VR92addr7RoomHumidity,room humidity shown by VR92 address 7,,,,0700,,,exp,,,room humidity shown by VR92 address 7
r,,VR92addr7RoomTemp,room temperature shown by VR92 address 7,,,,0F00,,,exp,,,room temperature shown by VR92 address 7
# ##### VR92 address 8 #####,,,,,,,,,,,,,
*r,,,,,,B524,06000a08,,,IGN:4,,,
r,,VR92addr8RoomHumidity,room humidity shown by VR92 address 8,,,,0700,,,exp,,,room humidity shown by VR92 address 8
r,,VR92addr8RoomTemp,room temperature shown by VR92 address 8,,,,0F00,,,exp,,,room temperature shown by VR92 address 8

[jonesPD]

@chrizzzp Sorry this message is out of place for this PR...

Can you have a look at this PR posted by someone on my repository? It is adding some new RunData registers. I believe the ones are there now originated from you. There seems to duplication of measurements, and inconsistent naming. Thanks.

Rundata registers by JGJ156

[chrizzzp]

@chrizzzp Sorry this message is out of place for this PR...

Can you have a look at this PR posted by someone on my repository? It is adding some new RunData registers. I believe the ones are there now originated from you. There seems to duplication of measurements, and inconsistent naming. Thanks.

Rundata registers by JGJ156

@jonesPD I left some comments there. I could not confirm all suggested registers, maybe due to different setups (split/monoblock).

[jonesPD]

Thank you. Good feedback, I'll let the original submitter respond before deciding to include these registeres in my repo