My heat pump starts nearly twice an hour, so I borrowed a stranger's controller

I built my own flow temperature controller. Then I borrowed someone else's, to see which one my heat pump likes better.

Two weeks ago I asked whether I was just a heat pump perfectionist. My Mitsubishi Ecodan keeps a Dartmoor prefab warm for very little money, but it lets liquid refrigerant into its compressor at the start of many runs, and I couldn't decide whether to live with that or push for a fix.

Mitsubishi has been kind enough to acknowledge it several times since: my software update request, a hand-off to their quality team, a case opened for factory review, and more details added to it last week. I'm looking forward to hearing from them soon on what to do about the refrigerant.

In the meantime there's one part of the problem I can work on myself: how the heat pump decides how hot to run. That turns out to matter most on the days you'd think were easiest.

And, as last time, I'm not really doing it myself. The best thing about owning a heat pump in 2026 isn't the heat pump, it's the people around it: owners, engineers and hobbyists who write the software, share the data and answer strangers' questions for nothing. Almost every idea in this post started with one of them.

---

The trouble with mild days

At 8–12 °C outside, my house needs about 1 kW of heat. My 6 kW Ecodan can't turn down that far. The lowest it will run is about 3 kW, so on a mild day it makes heat three times faster than the house can use it.

A gas boiler in the same spot just turns itself down. A heat pump can only do the next best thing: run, overshoot, stop, wait, and start again. Mine has done that about 18,700 times in 9,000 hours of running, two starts for every hour on. This October its heating runs lasted a median of about eight minutes.

Every one of those stops is decided by a single number: the flow temperature target, how hot the water leaving the heat pump should be. Get it right and the heat pump runs long and gently. Get it wrong and it stops almost as soon as it has started.

Why it stops

Out of the box, the Ecodan picks its flow target from a weather curve: colder outside, hotter water. The controller then stops the compressor when the water gets about 1.5 °C hotter than that target.

On a mild day that's the problem. The curve asks for, say, 27 °C. The heat pump, making three times the heat the house needs, gets the water there in a few minutes, overshoots by a degree and a half, and stops. Nothing has gone wrong. That's just what a big heat pump does in a small load.

Two ways to choose a flow temperature

Since mid-October Home Assistant, which runs most of my house, has been setting the flow target instead of the Ecodan. That's only possible because of F1p's CN105 bridge: a small board, built and sold by one enthusiast, that plugs into a socket inside the Ecodan and speaks its private language. When I emailed to ask whether I could put different firmware on it, I had a clear, generous answer the same afternoon.

Mitsubishi never meant owners to talk to that socket. A chain of volunteers decoded it, each building on the last, and posted everything on the OpenEnergyMonitor forum and GitHub for anyone to use.

I've now tried two quite different ideas about what the flow target should be.

The same night on my Ecodan, 2–3 November. Left: the target my controller set. Right: what gekkekoe's formula would have asked for from the same readings. It wasn't in control, so the white flow line is what actually happened under mine.

Mine starts from a weather curve that learns from the house: each night it refits how much heat the house loses, how much the sun and the people in it add, and how much the radiators give out at each water temperature. Once the compressor is running, it stops treating the curve as a target and tracks the water instead: it keeps the target half a degree under the actual flow temperature. The controller only stops the compressor when the water is well above target, so as long as the target keeps moving up just ahead of that, it never does. The run ends when the room is warm enough, and Home Assistant switches the heating off.

gekkekoe's comes from their open-source esphome-ecodan-hp firmware, which runs on the same kind of bridge as mine. It's a remarkable piece of work to give away: started in 2024, improved by 19 contributors, still being updated (the latest change landed the morning I wrote this), with an online simulator so you can see what it would do before you trust it with your heating. Their "auto-adaptive" controller ignores the weather curve. It sets the target to the temperature of the water coming back from the radiators plus a gap. On my radiator profile the gap is 4 °C when the room is at target, widening up to 10 °C as the room falls below it, and a little more when it's cold outside. The return temperature is a running measure of what the house is taking, so the target follows demand right now rather than the weather. It also never lets the target fall a degree or more below the water actually leaving the heat pump, which stops the controller from cutting the compressor.

Both ideas share the same insight: stop the Ecodan seeing an overshoot, and it keeps running. Where they differ is how hot they're willing to let the water get while doing it.

Backcasting the two

I was going to buy gekkekoe's controller hardware and swap it in. Then it occurred to me that my heating already works, and the lower-risk move was to steal their logic instead. That's the beauty of open source: it isn't really stealing, it's what the code is there for. I could read exactly how it decides, and rebuild that in Home Assistant without touching anything plugged into the heat pump.

So I ported gekkekoe's formula into Home Assistant as a "shadow": it works out what it would ask for every few seconds, from the same readings, but doesn't control anything. (I left out some parts of their controller: a "smart boost" for when the room stalls below target, special handling after defrosts, and after hot water runs. I've asked gekkekoe whether those matter for a house like mine.)

Over four days of heating at 4–11 °C outside, 1,393 minutes of compressor running, their target would have sat a median 1.9 °C above mine, and about 1.6 °C above the water actually flowing.

That's not a sign that either is wrong. It's the trade-off at the heart of mild-weather heating, and they've chosen different sides of it.

What a start actually costs

A heat pump's efficiency falls as it heats water hotter, by roughly 2–3% for each extra degree. Hotter water costs you every minute the compressor runs. So why not run as cool as possible, and let it cycle?

Because starts aren't free either. What I can measure on mine:

• The wet start. In the first few minutes of many runs my Ecodan lets liquid refrigerant reach the compressor (the subject of the last post). I only knew what I was looking at because experienced engineers on the OpenEnergyMonitor forum had been documenting the same thing on their own Ecodans for years. At the same water temperature and compressor speed, it's roughly 30% less efficient while that's happening. Restarts within ten minutes of the last run are twice as likely to go wet. Fewer starts means fewer wet starts.

• The ramp. Each start, the compressor draws power before any warm water reaches the meter. That's by design, but it's the least efficient part of a run.

• Reheating the system. Each stop lets the water and pipework cool a little, and each start has to warm them back up before any heat reaches a room.

• Wear. Compressors are rated for a finite number of starts. Nobody publishes the figure, but two for every hour of running, for four and a half years, is a lot.

So I measured it. Over ten days, I compared the first ten minutes of each long heating run with the same run once it had settled. The first minute is dreadful: power goes in before any warm water comes out, at an efficiency below 1. But it recovers within two or three minutes. Add it up and a start costs about 12 Wh of extra electricity (the middle half of starts cost 3–25 Wh).

That's tiny on its own. But on a mild day my heat pump starts 15 to 25 times, so it comes to 3–5% of its electricity, and that's before wear, or the heat the pipes lose while it's stopped.

The trade-off

So the choice on a mild day is:

• Lower flow, more cycling (mine): better efficiency every minute, but more starts, and more of them wet.

• Higher flow, fewer stops (gekkekoe's): longer, steadier runs, but a couple of degrees hotter, and a few percent less efficient while running.

Put numbers on it and it's closer than I expected. Running 1.9 °C hotter, at 2–3% a degree, costs gekkekoe's approach roughly 4–6% while the compressor runs. Starts cost mine 3–5%. The two costs are about the same size, so this isn't a solved question with an obvious answer. It depends on the house, the heat pump and the weather, and I don't know for mine yet.

Three days on gekkekoe's controller

Readers have shaped this already. After the last post, a heating engineer suggested on LinkedIn that an oversized heat pump like mine wants a minimum flow of 28–30 °C, so it has some headroom to run before it overshoots, and both controllers now start from that.

Since Tuesday evening my heat pump has been running on gekkekoe's controller, switched with one toggle in Home Assistant. Three days is far too soon for a verdict, but not too soon for first impressions.

The cycling has all but gone. In the four days before the switch my heat pump started 27 times a day, and its median heating run lasted 8 minutes. On gekkekoe's controller it has started 5 times a day, and the median run is 90 minutes. It runs for an hour and a half, the room drifts up to about 22 °C, Home Assistant switches the heating off, and it rests for three or four hours.

The water is much hotter than I predicted. The backcast said gekkekoe's target would sit 1.9 °C above mine. In practice the water has averaged about 37 °C while running, against about 27 °C on mine, and peaked at 41 °C. The shadow got this wrong because it was calculated while my controller was in charge, from the cool water mine sent back. Once gekkekoe's target is in control, hotter water going out brings hotter water back, which raises the target again. It keeps climbing until it reaches the 40 °C ceiling I gave it, and it has spent nearly half its running time there.

Efficiency held up anyway. By my own sums, 10 °C hotter water should cost 20–30% in efficiency. It hasn't. At the same outdoor temperatures, heat out over electricity in has been about the same as mine, or slightly better: about 4.4 against 4.2 on the nights I can compare. The emoncms daily figures agree. Long, steady runs seem to be worth more than my 12 Wh a start suggested, or my sums for the cost of hotter water are too pessimistic.

But it has used more electricity. On nights at 4–6 °C outside, with the room averaging 21.3 °C under both controllers, gekkekoe's used about half as much electricity again as mine did, and put about 60% more heat into the house. The room with the sensor was no warmer, so where did it go?

The bedrooms. We felt it before I saw it in the data. They have smaller radiators than the living room, so at 27 °C they barely get warm, and the rooms sit a little cool. At 37–41 °C those small radiators finally get going and the bedrooms come up to temperature. A radiator's output rises faster than its water temperature, so 10 °C hotter water makes a big difference to a radiator that was only just warm.

So the extra electricity mostly bought a warmer house, not a less efficient heat pump. That's not nothing: it's heat we hadn't asked for, in rooms the thermostat can't see, because the only sensor is downstairs. A fair comparison needs both controllers to keep the whole house at the same temperature, and for now I can't measure that. The bedrooms have no sensors yet. (Some of the extra heat may also be going into the pipes under the floor, which lose more when they're hotter.)

I could turn the bedroom radiators down. But that would shrink the radiators the heat pump has to work with, which is the opposite of what a heat pump wants, and it would change the house halfway through the test. For now they stay open. The better fix is a sensor upstairs, so the next round can judge both controllers on the whole house, not just the living room.

That's three nights a side, and my side isn't perfect either: a fault I found on Tuesday meant my controller had been running without its room thermostat for the nine days before.

Will it cope with winter?

So far it has only seen 3–7 °C. Dartmoor's winter is colder, and three things change.

The house needs more heat, so the heat pump's minimum output stops being so much too big. Cycling falls on its own, under either controller, so gekkekoe's biggest advantage shrinks while its hotter water still has a cost.

The formula wants hotter water as the outside temperature falls, and it's already at the 40 °C ceiling half the time. In a cold snap it would sit there almost permanently, which turns it into a fixed 40 °C flow switched on and off by the room thermostat. My learned curve thinks 31 °C is enough at −3 °C, but it learned that from the living room, and this week has shown the bedrooms disagree.

And wet days at 0–5 °C are defrost weather. That's when the heat pump keeps stopping to melt the ice off its outdoor coil. gekkekoe's controller has special handling after a defrost, which I left out of my port, so the first cold, damp week will test my copy harder than the original.

The forecast has 2 °C by the end of next week. Will it keep up? I'll keep it running through the first cold spell and report back: starts per day, run length, efficiency, how much of the running is wet, and whether the room holds 21 °C. Then I'll decide whether to flash gekkekoe's firmware properly, keep borrowing the logic, or go back to mine. If you want to see which one wins, subscribe and it'll land in your inbox.

Or change the radiators

There is a third option, which attacks the problem from the other end.

The reason my heat pump overshoots on a mild day is that the house can't take its minimum output at a low water temperature. Radiators only give out so much heat at 27 °C. If the rooms could absorb more heat from cooler water, the heat pump could run at its minimum for longer before the water climbed high enough to stop it.

This summer I wrote about how I regret my heat pump lacks air conditioning, and suggested fan coils: a radiator with a fan, which can also cool and dry the air in a heatwave. I'm now thinking seriously about fitting a couple in the rooms we use most.

Most people would buy them for the cooling. But a fan coil also gives out several times more heat than a radiator of the same size at the same water temperature. In winter, a couple of them in the right rooms could let my heat pump get rid of its minimum output at a lower flow temperature, with longer runs and fewer starts, without either controller having to compromise.

I've asked gekkekoe what they make of fan coils with their controller too.

---

The real lesson, again

Last time I said the heat pump community was the best thing about my heat pump. Two weeks on, I'd say it more loudly.

In a fortnight: one developer's free firmware gave me a second controller to test against my own. Another's bridge made it possible to plug either of them in. Engineers I've never met explained what my compressor was doing. A reader's comment about my flow rate set me looking at a sensor that had been set up wrong, and my Ecodan went from near the bottom of the table to mid-table. A heating engineer on LinkedIn retuned my minimum flow. And the manufacturer is taking a look.

None of them was paid. Most of them I'll never meet. If you own a heat pump and you're even slightly curious about it, go and find them: heatpumpmonitor.org, the OpenEnergyMonitor forum, and the GitHub pages of the people who build these tools. Share your data. Ask the daft question. Somebody will have the answer, and they'll be glad you asked.

And if their work helps you, buy them a coffee. I'm about to.

Thanks to gekkekoe for esphome-ecodan-hp and the auto-adaptive controller, to F1p for the CN105 bridge, to Graham Hendra and John Ewbank for the flow sensor and the data that started all this, and to everyone on the OpenEnergyMonitor forum.