Is my Vaillant ecoTEC working properly?

[PiMike]

 

2 hours ago, Radian said:

 

Good stuff - ebusd on a Raspberry Pi? If so you should be able to get the operational modulation value "ModulationTempDesired" which despite the name is the calculated value that's controlling the gas valve and fan. If you range rated a 24kW boiler to 12kW, for example, then this would max out at 50 (%) and if the boiler has a 4:1 modulation ratio then would go no lower than 25 (%). My Glowworm boiler is monitored via ebusd and I get this kind of spaghetti plot which shows the actual modulation bottoming out at 33% as it's only got a crappy 3:1 range:

 

 

 

Which component is "turning off"? Do you mean the boiler is cycling off as in "hit the lowest modulation" and still too little delta?

 

Yes it's a RPi4. I've played with the ModulationTempDesired but converted it to kW as in this earlier plot:

 

 

I'm not sure what's telling the boiler to turn off yet. I need to go deeper into the rabbit hole ...

 

Mike

 

Edited March 15, 2023 by PiMike
Replaced poor graphic

[PiMike]

53 minutes ago, JohnMo said:

You will have a max temperature set in the control system, so the boiler slowly increases power and therefore heat output, once it hits the max temperature setting it cuts out.  It will continue circulation and when it sees the return temperature drop by a given temperature, it will kick back in to life.

 

Well that's what's happening now, but in the graph I posted in reply to Radian (above) it doesn't shut off when it reaches the desired flow temperature (65C in that instance).

 

Mike

[JohnMo]

Looks to hitting max kW of 12 ish then it trips?

[Radian]

2 hours ago, PiMike said:

I've played with the ModulationTempDesired but converted it to kW as in this earlier plot:

2 hours ago, PiMike said:

I'm not sure what's telling the boiler to turn off yet. I need to go deeper into the rabbit hole ...

 

Right, so the modulation is swinging between 12kW and 6kW by the look of it, corresponding to your max range rating and boiler doing 4:1 minimum modulation.

I'd therefore say it's not the boiler cycling, as it wouldn't cut out while it still had some modulation authority available, yet each short-cycle seems to start with close to full modulation.

Can you capture and plot the control inputs for

 bai SetMode

 

 

[PiMike]

3 hours ago, JohnMo said:

Looks to hitting max kW of 12 ish then it trips?

Yes because the part load was set to 12kW and the minimum for this boiler is 5kW.

 

Mike

[PiMike]

33 minutes ago, Radian said:

Can you capture and plot the control inputs for

 bai SetMode

 

Yes I can, but with what values for FlowTempDesired and PartloadHcKW?

Mike

[PiMike]

Hi Radian, how's your Python? Mine's pretty poor and I'm struggling to come up with the code to capture the SetMode string.

 

This is how I capture FlowTemp:

 

bai = ['/usr/bin/ebusctl', 'read', '-c', 'bai', '-f']
flow_temp = float(check_output(bai+['FlowTemp', 'temp']))

 

Mike

[PiMike]

54 minutes ago, PiMike said:

Hi Radian, how's your Python? Mine's pretty poor and I'm struggling to come up with the code to capture the SetMode string.

 

This is how I capture FlowTemp:

 

bai = ['/usr/bin/ebusctl', 'read', '-c', 'bai', '-f']
flow_temp = float(check_output(bai+['FlowTemp', 'temp']))

 

Mike

 

OK I've sorted it with Popen 😇. Which of the SetMode parameters are you interested in?

 

Mike

[Radian]

I've set up ebusd to communicate over MQTT which I find to be more flexible than using subprocess commands on the Pi running the daemon.

However, now I'm wondering about what you get back from SetMode because from the command line:

 

ebusctl read -f -c bai SetMode
ERR: element not found

 

the -f (force reading the bai register directly rather than the stored value) results in this error whereas without -f:

 

ebusctl read -c bai SetMode
auto;54.0;-;-;0;0;0;0;0;0

 

I get back the flow temperature set by my 'controller'. I use this term loosely because my controller isn't actually a physical one like the Vaillant VR65 with a roomstat, but my code running on another Pi doing all my home control stuff. This writes SetModeOverride which was cobbled into the ebusd config file by someone in order to emulate  a vaillant controller. So at the command line, to set the flow temp to 54 (as read back using SetMode above), I would issue:

 

ebusctl write -c bai SetModeOverride '0;54;0;-;-;0;0;0;-;0;0;0'

 

I have a "heat only" boiler so no additional HW stuff, I just alter the flow temp when I'm charging the store, so it's always 0 (auto) in the first parameter, and the flow temp required in the second. The rest of the parameters seem to have no effect so I set them to 0. If this command isn't received after a few minutes the boiler falls back to the flow temperature set on its physical interface.

 

In your setup, I'd expect the VR65 to be activating the boiler on behalf of your HW stat and room stat - filling in more of these parameters. Not having an official control setup, I haven't any way of sniffing any data from an external controller, so I've just made do with what seems to work. I'd be interested to see all the parameters you get back when you read SetMode.

Edited March 16, 2023 by Radian

[PiMike]

Thanks for that. Yes I found the problem with -f by trial and error. A typical output from SetMode is:

 

auto;0.0;65.0;-;1;0;1;0;0;0

 

I decided that a FlowTemp of 55C was insufficient to achieve the 18C room temperature so I increased it to 60C and set the CH Part Load to 8kW. I started a new plot at midnight and the interim result is below. I only started plotting SetMode at 1pm.

 

The only SetMode parameters that vary are flowtempdesired (which swings between 90 and 0) and disablehc (the inverse of flowtempdesired and plotted on the graph).

 

I believe flowtempdesired is only relevant to return regulation and I am using flow regulation. What is driving disablehc?

 

Mike

 

[Radian]

58 minutes ago, PiMike said:

I believe flowtempdesired is only relevant to return regulation and I am using flow regulation. What is driving disablehc?

 

 

What makes you believe FlowTempDesired is only relevant to the return regulation scheme? It's the only parameter my 'controller' uses to adjust boiler output and it's working in flow temperature regulation mode (I don't know how or if it could be switched to return).

 

If I set disablehc to 1 when the boiler is running (in the fifth parameter of SetModeOverride) like so:

 

ebusctl write -c bai SetModeOverride '0;54;0;-;-;1;0;0;-;0;0;0'

 

The boiler shuts off into state S.02 (pump pre-run) so behaves the same as yours

 

I have no idea why your controller would be doing this kind of bang-bang control!

 

[PiMike]

11 minutes ago, Radian said:

 

What makes you believe FlowTempDesired is only relevant to the return regulation scheme? It's the only parameter my 'controller' uses to adjust boiler output and it's working in flow temperature regulation mode (I don't know how or if it could be switched to return).

 

Sorry you're correct, I misread the manual. d.5 is Flow or Return target depending on whether Flow or Return regulation is selected in d.17.

 

I read elsewhere that Return regulation works better with the VR392f thermostat so I will try it at some point.

 

Is SetModeOverrive persistent? I could try setting disablehc to 0.

 

Mike

Edited March 16, 2023 by PiMike

[Radian]

14 minutes ago, PiMike said:

Is SetModeOverrive persistent? I could try setting disablehc to 0.

 

 

You'll be fighting the controller which is periodically setting this so I doubt if it would be an effective work-around. Clearly the wiring center or room thermostat are sending this bizarre command - is it trying to do some sort of load compensation? 

From your first plot, It always seems to kick-in whenever the room temperature approaches the set point:

 

It certainly seems to track with the onset of the temperature peaks in the room. You could check the menus to see if load compensation is listed...

[PiMike]

8 minutes ago, Radian said:

 

You'll be fighting the controller which is periodically setting this so I doubt if it would be an effective work-around. Clearly the wiring center or room thermostat are sending this bizarre command - is it trying to do some sort of load compensation? 

From your first plot, It always seems to kick-in whenever the room temperature approaches the set point:

 

It certainly seems to track with the onset of the temperature peaks in the room. You could check the menus to see if load compensation is listed...

 

I can't see any mention of load compensation. However, the VRT392f has two operating modes. It's currently in 2-point (like a conventional thermostat) so I could try analogue mode.

 

Mike

[Radian]

Table 6.2 on Page 10 of the expert technician Installation instructions VRT 392f

Quote

 

Control strategy Determines the type of room temperature control Two point represents on/off control; Similar to a modulating control. Two-point, analogue Two-point

 

 

Hah beat me to it, yes I was posting the above when you replied!

[Radian]

BTW, next time you're at the console, could you post all the output from:

 

ebusctl info

 

I'm curious about the arbitration timing and scan results you get using your interface. Mine reports:

 

version: ebusd 22.4.v22.4
update check: version 23.1 available, broadcast.csv: different version available, memory.csv: different version available, vaillant/bai.308523.inc: different version available, vaillant/broadcast.csv: different version available, vaillant/errors.inc: different version available, vaillant/general.csv: different version available, vaillant/hcmode.inc: different version available
device: /dev/ttyebus
access: *
signal: acquired
symbol rate: 36
max symbol rate: 123
min arbitration micros: 1
max arbitration micros: 197
min symbol latency: 3
max symbol latency: 12
reconnects: 0
masters: 2
messages: 225
conditional: 3
poll: 10
update: 10
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0202;HW=8001", loaded "vaillant/bai.308523.inc", "vaillant/08.bai.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd

 

(yes I know, there's lots of updates I'm ignoring!)

[PiMike]

Sure, here it is:

 

version: ebusd 23.1.23.1
update check: OK
device: /dev/ttyUSB0
access: *
signal: acquired
symbol rate: 39
max symbol rate: 146
min arbitration micros: 302
max arbitration micros: 6435
min symbol latency: 0
max symbol latency: 16
reconnects: 0
masters: 3
messages: 371
conditional: 3
poll: 0
update: 11
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0518;HW=7401", loaded "v                                                                                                             aillant/bai.308523.inc" ([HW=7401]), "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=F3900;SW=0120;HW=2102", loaded "va                                                                                                             illant/15.f39.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address 64: slave, scanned "MF=Vaillant;ID=V6500;SW=0007;HW=8301", loaded "vaill                                                                                                             ant/64.v65.csv"

 

[Radian]

Hi PiMike, thanks for posting your info. The arbitration time is a little high but it doesn't seem to phase your boiler.

You asked about configuring for MQTT so in addition to the host IP you might want to specify the port and wildcard the topics such as:

 

--mqtthost=localhost --mqttport=1883 --mqtttopic=ebusd/%circuit/%name/%field

 

Then every time you issue an ebusctl command, you will see the response sent over MQTT. It doesn't matter how the command is sent, the daemon always echo's the response.

You also can use the same syntax as the responses to send command messages to the daemon over MQTT.

The way I use it as configured above splits individual parameter fields into separate topics for simpler decoding but I'm not sure what happens when you publish to the topic - never did look into this. If you don't mind parsing out the individual parameters on subscriptions, just leave out %field

[PiMike]

1 hour ago, Radian said:

Hi PiMike, thanks for posting your info. The arbitration time is a little high but it doesn't seem to phase your boiler.

You asked about configuring for MQTT so in addition to the host IP you might want to specify the port and wildcard the topics such as:

 

--mqtthost=localhost --mqttport=1883 --mqtttopic=ebusd/%circuit/%name/%field

 

Then every time you issue an ebusctl command, you will see the response sent over MQTT. It doesn't matter how the command is sent, the daemon always echo's the response.

You also can use the same syntax as the responses to send command messages to the daemon over MQTT.

The way I use it as configured above splits individual parameter fields into separate topics for simpler decoding but I'm not sure what happens when you publish to the topic - never did look into this. If you don't mind parsing out the individual parameters on subscriptions, just leave out %field

 

Thank you. I will give that a go once I've got the boiler's behaviour sorted.

 

Mike

[PiMike]

OK so with my room thermostat in conventional 2-point operation the modus operandi is for the boiler to run until room temperature is reached then revert to short cycling.

I have a friend with an ecoTec 428 and conventional thermostat and his behaves the same so I guess that is normal operation. I will try the room thermostat in analogue mode next.

 

Mike

 

[Radian]

The only plot you posted that shows the actual modulation level was this one labelled Output kW:

 

 

You said the ecoTec 428 minimum modulation was 5kW yet it doesn't quite seem to get down to that level so it really has to be the external control that initiates the cycling. I hope you will be plotting the modulation again when you switch to analogue control so we can see how it goes about it...

[PiMike]

My boiler is a 418 (my friend has the 428) but yes 5kW is the minimum and yes I am logging modulation 😀.

 

It gets down to 33.3% which is 5kW.

 

Mike

 

 

[PiMike]

15 hours ago, Radian said:

You asked about configuring for MQTT so in addition to the host IP you might want to specify the port and wildcard the topics such as:

 

--mqtthost=localhost --mqttport=1883 --mqtttopic=ebusd/%circuit/%name/%field

 

I still need some help on this please. I have made the changes above but I'm not sure what commands to send. Do I do this:

 

mosquitto_sub -t ebusd/%circuit/%name/%field

 

Or this:

 

mosquitto_sub -t ebusd/bai/FlowTemp/temp

 

Then what do I send to read the bus?

 

Mike

[Radian]

1 hour ago, PiMike said:

Or this:

 

mosquitto_sub -t ebusd/bai/FlowTemp/temp

 

Then what do I send to read the bus?

 

Just publish:

ebusd/bai/FlowTemp/get

 

and

ebusd/bai/FlowTemp/set

 

with data you wish to write.

[PiMike]

Yes that works! Thank you Sir 😀.

 

Mike