Soft alternative to prohibit for short cycling and pump overrun

[JHAvB]

Hi everyone,

I have a question about the current implementation of the short cycle protection.
At the moment, prohibit is used to stop the heat pump during short cycling. This has the following side effects:
• The circulation pump stops immediately.
• The heating zone is disabled, causing the zone valves to close.
Using prohibit is quite an aggressive way of handling this. Would it be possible to introduce a "soft" alternative instead?

My idea would be to temporarily set the flow temperature well above the feed temperature for a configurable period. As far as I understand, this should keep the heat pump and the zone valves active while preventing the compressor from starting. This could avoid short cycling without completely shutting down the system.

I have a similar question regarding the pump overrun time. On the FTC7, the circulation pump stops immediately when IN1 is deactivated. In many installations, it would be beneficial if the pump continued running for, for example, another 15 minutes to dissipate any residual heat.

Could this perhaps be implemented using the same approach, by temporarily keeping the flow temperature above the feed temperature instead of immediately deactivating IN1?
I'm interested to hear what others think about this idea and whether there are any technical reasons why this approach would or would not work.

[gekkekoe]

My idea would be to temporarily set the flow temperature well above the feed temperature for a configurable period. As far as I understand, this should keep the heat pump and the zone valves active while preventing the compressor from starting. This could >avoid short cycling without completely shutting down the system.

How did you come to this conclusion? When there is demand (via in1 or mrc/wireless) the heatpump operates. A higher feed temp will prevent the compressor stop (it's exactly what the predictive cycle prevention is doing), but it will keep the compressor on. The zone valves are most likely controlled by your thermostat, they should be independent of the heatpump. When prohibits are turned on, the valves remains open on my install when there's demand from the thermostat.

I have a similar question regarding the pump overrun time. On the FTC7, the circulation pump stops immediately when IN1 is deactivated. In many installations, it would be beneficial if the pump continued running for, for example, another 15 minutes to dissipate any residual heat.

There's a setting for that in the FTC where you can have the water pump circulate for a certain amount of time after demand stop.

Currently there's no way to control the compressor or water pump directly. The water pump can be controlled via PWM but you probably don't want to mess with it.

[gekkekoe]

I think there was a bug in the step down a couple of releases ago that triggered this. If I remember correctly, the cooling would not start at all when the flow setpoint was way above the actual flow. I don't know if the water pump keeps running. But you can manually test it.

1. generate demand
2. set flow temp such that operations will not start and monitor water pump

What are the intentions of letting the pump run? Is it the residual heat/cool ? That is very small gain for a lot of hassle.

[JHAvB]

Yes, as soon as IN1 becomes active, the water pump starts running and the compressor waits for the flow setpoint to be reached. This therefore seems like a possible cause.

Due to the control behavior of our installation, the heat pump can start short cycling, especially in cooling mode. Temporarily blocking the compressor start helps to reduce the number of starts and stops. A waiting time of 15 to 20 minutes is not a problem in this situation.

However, because the prohibit function is used, the water pump also stops. In combination with our series-connected buffer tank installed in the return line, this creates two effects:

1. The energy stored in the buffer tank is not used during this waiting period, although the effect is limited.
2. When the water pump starts again, the return temperature in cooling mode is still “too” low due to the cold water stored in the buffer tank. As a result, the compressor does not run for very long before stopping again.

Since our cool/heat emission system consists of fan coils, I believe it would be preferable to keep the water pump running during this waiting period. The return temperature rises relatively quickly, which allows the compressor to run for a longer period after the waiting time before short cycling occurs again.

[gekkekoe]

Let me check the condition and see if we can abuse it. Probably an option to choose (server control / flow setpoint control) as lockout strategy

Did you already test it locally yourself?

[gekkekoe]

Please try https://github.com/gekkekoe/esphome-ecodan-hp/releases/tag/2026-07-22.03 (when build server is done) it has an extra option:

Select flow control, it will then try to keep the water pump running during lockout duration. You can use that duration to deplete the buffer.

@ethem @schumch @Bl4ckr4v3n You guys are probably also interested in this 'bug' / feature, try it out.

[schumch]

thy @gekkekoe: will check and test in cold situation.

[JHAvB]

First of all, thank you for the very quick response and for updating the code!

Yesterday I tested the new code. The concept works well as a "soft" version where the water pump keeps running. However, I still had to intervene manually to prevent two issues.

The attached graph shows the results of my test. As you can see, I also use DS18x20 temperature sensors. The DS18x20 Return Temp sensor is installed before the buffer tank. This allows me to measure the temperature difference before and after the buffer tank.

DS18x20 Sensor 0 measures the return temperature directly after the fan coil. The fan coil has a flow rate of 180 L/h. This means that during yesterday's test, part of the flow was passing through the bypass, which explains the temperature difference.

As soon as a short cycle is detected, the target flow temperature is increased, but not by enough. In the first example, the compressor restarts because the feed temperature rises above the target temperature. During the second test, I manually increased the target flow temperature to 20 °C, and that worked perfectly.

Another interesting observation can be seen during the second test. Apparently, my circulation pump is configured with a 10-minute overrun time. When the pump stops, the feed temperature rises sharply, causing the pump to start again immediately. I believe this is caused by the position of the built-in expansion vessel. When the pump stops, the pressure in the supply line drops. As a result, the built-in expansion vessel releases a small amount of water into the system. This happens just before the feed temperature sensor. It makes sense that this water is slightly warmer, as the expansion vessel is located directly above the boiler.

The second issue that required manual intervention is that Asgard's control interval appears to be too slow to prevent the compressor from stopping. Several times I had to manually lower the target flow temperature to the minimum value to keep the compressor running. Would it be possible to check this condition more frequently?

[gekkekoe]

Thanks for testing. Please try https://github.com/gekkekoe/esphome-ecodan-hp/releases/tag/2026-07-23.01 and see if it keeps working. I cannot test it myself since I don't have such a system.

changed

• we still do +5c from actual temp when we detect short cycle
• on feed temp change we enforce the +5c rule (if feed temp rises during lockout, it updates it). This should handle those rising feed temps during lockout.

Lockout effectively becomes a buffer discharge this way

[JHAvB]

Once again, thank you for the quick response!

The lockout works great. In the image below, you can see that the target flow temperature stays nicely 5 °C above the measured feed temperature. As you can see, I have not yet adjusted the water pump run time 😉.

At the moment, the target flow temperature is checked every time the feed temperature changes. Would it be possible to also run the function that checks whether the target flow temperature needs to be adjusted (to prevent a compressor shutdown) when the feed temperature drops below the target flow temperature (in cooling mode)?

At the moment, I am nowhere near reaching the minimum cool flow (6°C) that my system is capable of. As a result, the compressor only runs for a very short period of time.

[gekkekoe]

At the moment, the target flow temperature is checked every time the feed temperature changes. Would it be possible to also run the function that checks whether the target flow temperature needs to be adjusted (to prevent a compressor shutdown) when the feed temperature drops below the target flow temperature (in cooling mode)?

Do you have example of this happening ? There's a en force step limit that prevents this, but it's only executed on setting a flow setpoint. Try the predictive cycle prevention, it now also supports cooling, and it's designed to prevent this.

[JHAvB]

Thank you. However, for my system, the Predictive Control is not fast enough to prevent the compressor from stopping. Actual cooling only starts to be delivered below approximately 12 to 10 °C. Please also see the image below, which shows how quickly the feed temperature drops. In the end, I disabled AA and set a target flow temperature of 10 °C.

[JHAvB]

Short cycle protection only reacts once short cycling is already occurring.

Maybe we need a different approach for this.
I'm curious to hear your thoughts on it.

As I understand it, short cycle protection is only intended to be active while the system is in an unstable state. In practice, this is typically the first 15 minutes after system startup, although I don't think that is a good definition of instability.

Regardless of whether the feed temperature is close to the target temperature, I think we should define system stability based on the maximum temperature change within a given time window. For example, if we use a 5-minute time window and the feed temperature changes by no more than 2 °C during that period, the system can be considered stable. If the feed temperature changes faster or by more than that, the system should be considered unstable.

While the system is unstable, I believe the target flow temperature should always be at least 1 °C below the feed temperature when operating in cooling mode.

Only once the feed temperature has changed by no more than 2 °C within a 5-minute time window should the system be considered stable, at which point short cycle protection can be deactivated.

[gekkekoe]

The predictive short cycle is executed in the same event handler...
It cannot be done 'faster' as it react on feed temp change currently. What are your predictive cycle settings, you can set timer and delta T. Please post a log when it is going to cycle, I need to see the predictive cycle log msg to see why it fails for you

[JHAvB]

A did test some differed settings, for now I use
Time Window (min): 1.00
Delta Threshold (°C): 1.00
logs_2026-07-23T14_23_23.txt

[gekkekoe]

ok confirmed. I refactored predictive cycle prevention to basically keep flow setpoint / actual feed temp within 1.0c.
Try https://github.com/gekkekoe/esphome-ecodan-hp/releases/tag/2026-07-23.02, it's experimental so please report your results

Please be advised that only the switch remains, the parameters are not needed anymore and are dropped

[JHAvB]

"It's doing something strange with the heating now. At least, it's setting the temperature to 29°C."
logs_2026-07-23T16_42_42.txt

[gekkekoe]

it uses the wrong version of stepdown. probably multi zone byte status messing things up. Try https://github.com/gekkekoe/esphome-ecodan-hp/releases/tag/2026-07-24.02 and report back

[turin400]

Hi, I'm testing the latest version with the short-cycle improvements and I've seen this "fix incorrect multi-zone status to identify is_heating/is_cooling" message, but I've tested it and if only one zone is running, the flow temperature of the other zone also changes. I don't know if this solves the problem. I've attached a log. I have a 300L buffer, two zones, and a mixing valve. Thanks.

device_logs_2026-07-23T18-42-53.txt

[gekkekoe]

you are not hitting the new cycle prevention parts. This behavior did not change that it always calculate both zone did it?

[turin400]

That's right, the cycle protection isn't running.
I had read about the modification separating the zones and thought it would also work in this operating mode.
Having a buffer is crazy. It stays loaded. Constantly calculating the unused zone when cold is causing its target flow temperature to rise.
I'm also a bit worried about the writes to the Ecodan flash memory.
Thanks for replying so quickly, as always.

[gekkekoe]

It will be active when you enable it. The flow control lockout can be used to discharge the buffer, that might be interesting for you.

regarding ecodan flash:
Monitor how often Mitsubishi own AA changes flow setpoint...
I also don't think they use flash to store, I think its backup by a super capacitor since all settings (clocks , ...) are lost when the power is unplugged for too long. But we only write once every 5m, and only if it changed.

Do you only use z2? z1 is never used?

[turin400]

Yes, I'm using this latest version to see if it helps with the tank's discharge.

Regarding the flash writes, you're right about Ecodan's adaptive mode; it must be designed for that.

Zone 1 is the fan coil unit; I don't always use it.
When Zone 2 is active and I start Zone 1, the target water temperature is high, and when the water from the tank enters, the compressor stops.

I have sensor.ecodan_heatpump_mixing_tank_temp and I copy that temperature to the flow setpoint, but the adaptive mode sometimes overrides it.

I do this with Home Assistant, but I'm very dependent on Wi-Fi.

When I only activate Zone 2 and the tank is very cold, it takes two minutes for the mixing valve to open, and the temperatures aren't stable.

I don't know if other people are experiencing the same thing; using the mixing tank is crazy.

Thanks for everything.

[gekkekoe]

@JHAvB Did the new predictive cycle prevention worked for you?

[JHAvB]

Sorry for my late reply.

Over the past weekend, I observed several times that it works, but at certain moments it still responds too slowly, especially when the flow temperature suddenly drops by 1 to 1.5 °C. This may be related to the frequency at which Asgaard retrieves the temperature data.

Above 12 °C, the supply temperature drops extremely quickly during a compressor start. This is also because the Ecodan cannot start at its lowest frequency (Hz), resulting in an immediately higher temperature delta. See the example from last night below:

[gekkekoe]

Some SUZ unit always start at min fixed frequency, and if your circuit does not have enough capacity for it, it will do it forever. I have seen report that it does start normally after a DHW, so it seems it needs some runtime before it can modulate down.

Asgard already retrieves this within 30s, I don't think we can retrieve feed temp faster. When we detect the gap, we send a new cmd but that also can take up to 1m to be processed by the ecodan. Do you have a some logging when it happened? (not at start, but when it's too slow to react during a run)