Increased DHW targets with warmer outdoor temps

Some more findings on my experiments.

When having a large hysteresis as well as a time window, it is possible that a day goes by without a DHW cycle. This might mean that the next morning there’s not enough hot water. I now make sure to force a DHW cycle once a day even if the hysteresis value has not been reached.

This is a graph how tank temperature, hot water max temperature at the top (BThome), flow- and return temperatures (Vorlauf and Ruecklauf) behave during a recharge cycle. At the beginning when the recharge is triggered by the hysteresis (27°C) measured tank temperature I am still getting more than 39°C water out at the tap, enough for a hot shower. Ignore the drop of the max temperature at the end of the recharge cycle, the temperature is currently measured using an NCIR sensor pointed at the pipe and only yields a proper measurement when hot water is flowing as it was during the charge by having the circulation pump on.

This really goes to show that recharging at the default 7 K hysteresis is a huge waste of COP potential. I am also experimenting with leaving my hot water circulation pump running during a hot water cycle. The forced circulation between the top and approximately middle of the tank might lead to a more homogeneous water temperature distribution in the tank; but I’ll have to measure whether that makes any sense.

The shown cycle yielded a COP of 4 at 25°C outdoor temperature recharging from 27 to 47 °C.

1 Like

This is different to my own experience, whereby a large hysteresis of -20°C means it will skip a day sometimes, yet there’s always been enough hot water for the following day. (Recharging daily to 45° but only if tank drops below 25°).

I think this very much depends on the hot water demand of the household vs. size of the tank and target temperature. Given we have such low demand, I’m tempted to move the thermister into the upper pocket so I’m heating less of the volume. Maybe.

I’m now heating to a higher target on warmer days, by 0.5° for every degree above 15°C. Unfortunately the weather’s been relatively cool since, so no results yet.

1 Like

@Timbones or anyone else, am I correct that there is no way to control the offset temperature (how much higher the flow temperature will aim for above the set DWH temperature) on the Ecodan?

I don’t think so, no. In my experience, the FTC will power hard to get flow up to the tank target, and then reduce power until the tank reaches that temperature. I used to walk the target up slowly to keep it running at min power for as long as possible.

(I don’t bother with this any more)

Edit: compare to a recharge to a fixed target of 47°

1 Like

Adding an observation…

I am currently doing a single DHW reheat each afternoon to 45C, normally between 13:00 and 15:00 based on the cheapest 30min Agile price slot, and at the warmest time of day.

My installation is complicated by the presence of a 50L volumiser tank in the primary return pipework.

The DHW may typically have dropped from 45C to 30-35C when the cycle starts.

On occasion, if the system has been idle for 24h (heating is off, and the DHW cycle may have run earlier yesterday), the system automatically runs the pumps for 5 mins. This has the effect of pumping that 50L of now cold water through the DHW tank, and cools it to maybe 26C as the volume circulating in the system and the DHW tank temperatures reach equilibrium).

On days where this occurs, the subsequent DHW run has a better COP and uses less energy. Where I am able, I now manually run the pumps for 5-10mins just before the DHW cycle is due to run (unfortunately I’ve found no way to automate this). Otherwise, the system spends the first 10-15mins of the DHW cycle cooling and then reheating the tank to the temperature it started at.

Hi
Your installation sounds somewhat unconventional. I believe the more normal arrangement is like this:

image
OK this sketch shows a volumiser on the emitter flow rather than the return, but either way any flow via the DHW tank should not pass through the volumiser.
I may have misinterpreted your post, of course, and it might be worth giving us a sketch of your set-up…
Sarah

@SarahH Yes, you are correct - it is not ideal to have the volumiser fitted in the primary pipework, and thus affecting both emitter and DHW circuits. It was an ECO4 installation, so we had no input into the design.

Graham Hendra discusses such an installation here:

From my experience in the last weeks I can say that I need the DHW run every day to make sure that I have sufficiently hot water. Maybe I could optimize this further but to be honest the expected gains would be minimal. So what I’m doing now is run th DHW cycle at the forecast hottest time of day or latest 5 p.m. For this I have defined these Home Assistant template sensors that get the hourly forecast for the day every day at 6 in the morning and store the expected peak temperature & corresponding time.

template:
  - trigger:
      - platform: time_pattern
        hours: "06"
        minutes: "00"
        seconds: "00"
    action:
      - service: weather.get_forecasts
        data:
          type: hourly
        target:
          entity_id: weather.berlin_buch
        response_variable: hourly
    sensor:
      - name: DWD Forecast Hourly
        unique_id: dwd_weather_forecast_hourly
        state: "{{ states('weather.berlin_buch') }}"
        attributes:
          forecast: "{{ hourly['weather.berlin_buch'].forecast }}"
      - name: "High temperature today"
        unique_id: High_temperature_today
        device_class: temperature
        unit_of_measurement: °C
        state: >
          {% set midnight = (today_at() + timedelta(days=1)).isoformat() %}
          {{ state_attr('sensor.dwd_forecast_hourly', 'forecast')| selectattr('datetime', 'lt', midnight) | map(attribute='temperature') | list | max }}
      - name: "High temperature time today"
        unique_id: High_temperature_time_today
        device_class: timestamp
        state: >
          {% set midnight = (today_at() + timedelta(days=1)).isoformat() %}
          {% set forecast = state_attr('sensor.dwd_forecast_hourly', 'forecast') %}
          {% set max_temp = forecast | selectattr('datetime', 'lt', midnight) | map(attribute='temperature') | max %}
          {% set max_temp_time = forecast | selectattr('temperature', 'eq', max_temp) | map(attribute='datetime') | first %}
          {{ max_temp_time }}

Then I have this automation:

It triggers when the peak time is reached or at the latest at 5 pm so I have guaranteed hot water in the evening. The trigger template i this:

{% set peak_time = states('sensor.high_temperature_time_today') %}
{% set latest_time = today_at().replace(hour=17, minute=0, second=0, microsecond=0).isoformat() %}
{% if peak_time < latest_time %}
  {{ now().isoformat() >= peak_time }}
{% else %}
  {{ now().isoformat() >= latest_time }}
{% endif %}

The if condition checks whether the tank temperature is below 40°C. This will typically be the case, except for rare cases with a Legionella cycle in the previous day & very little water use.

Then the DHW mode is switched to “Eco” to be safe; this is done via a dropdown selector that is provided via the Node RED integration. Node RED sends the appropriate MQTT command to ebusd. I’m waiting a minute to make sure the change is applied.

Following this, the target temperature is briefly set to 70°C to triger the run; this is done via the MyVaillant integration, though I want to transition this to using ebus too to be cloud-independent. After one minute, the temperatue is set to my default of 47°C again, which is the temperature that terminates the DHW run.

I have implemented this strategy manually over the last couple of weeks and am reaching COPs between 3.5-4 at outside temperatures between 20-30°C.

Any unexpected hot water use that drops my tank temperature below 27°C at any time will trigger a DHW run based on the normal Vaillant built-in mechanism.

1 Like

Hi @Andre_K. I like this approach so have copied the automation to test against my hot water usage. I’ve removed the 17:00 part of the trigger and will stick with the standard drop at 28C but the rest is still the same. Thanks for sharing.

Glad you like the approach! I noticed a timezone bug in the original code, so here’s my current trigger which corrects this:

{% set peak_time = as_timestamp(states('sensor.high_temperature_time_today')) %}
{% set latest_time = as_timestamp(today_at().replace(hour=17, minute=0, second=0, microsecond=0).isoformat()) %}
{% if peak_time < latest_time %}
  {{ as_timestamp(now()) >= peak_time }}
{% else %}
  {{ as_timestamp(now()) >= latest_time }}
{% endif %}