Community
OpenEnergyMonitor

Community

Advice on air-source heatpump/thermostat settings?

Tags: #<Tag:0x00007fedd214fc40> #<Tag:0x00007fedd214f9c0> #<Tag:0x00007fedd214f5d8>

Afternoon All,

I recently had a Grant ASHP installed here in west Wales, providing DHW and CH through (large) rads. Even more recently, I’ve started monitoring its operation, and have some concerns that it’s not running as efficiently as it could do:

DHW cycles happen only once every couple days, so I’m not so concerned about these (although higher flow temps obviously reduce CoP), but it seems to be cycling for CH quite often.

Thanks to the monitoring, I can see that it’s cycling due to the thermostat demand - each CH ‘cycle’ lasts ~6mins, with ~3 cycles per hour. I appreciate it’s reasonably warm at the moment, but this seems a bit short to me?

Is this ‘ok’, or should I be attempting to make these cycles longer, by adjusting the weather compensation curve to lower temperatures?

System info:
1800 built thick stone wall house (no wall or floor insulation)
Grant Aerona ASHP
Large rads, all with TRVs (except 2x bathroom towel rads) fed through a 50l buffer
Honeywell DT90 room stat (18degC) and programmer (CH continuous, DHW set for twice a day, but with a cylinder stat)
Commissioned weather curve: Te1 = 5, Te2 = 20, Tm1 = 50, Tm2 = 40 (seems high?)

Any advice/requests for more info gratefully received :slight_smile:

Hi Matthew,

Welcome to Emoncms!

I found that my heat pump was cycling too often as well. Yours doesn’t seem excessive at three per hour. Our house is also 1800 stone with little insulation. We don’t have a buffer, but we do have large rads with TRVs.

In this post you can see I got benefits from running the heat pump for longer runs. Notably with mine it took a few minutes to start working efficiently so I wanted runs of 10 or more minutes to amortize the start up costs.

Note that our desired flow temp for the space heating has also been around 40 °C because it’s been kicking in when the effective outside temperature was around 0 °C. Our weather compensation is:

compCurveValue = int(38 - 2 * effectiveOutdoorTemperature / 3)

So for your Te’s the Tm’s would be 35 and 25. If you’ve only had it installed recently it might be worth just letting it run as the installer set it for now and seeing how it goes. Notably those temps are for our rads because we don’t have a buffer. Is your system applying that curve to the flow temps or the buffer tank water temp?

I’d also expect yours to do less cycling than ours because you have a buffer tank. Perhaps your buffer isn’t really getting terribly cold so the heat pump only has a tiny amount of work to do to bring it back up to temp. In that case your intuition that it can run longer but less often would seem well-founded.

I’m a little surprised it’s got enough demand to cause cycling though. In the last few days our has only come on a few times.

1 Like

Afternoon,

Thanks for the welcome and reply :slight_smile:

Yes, >10min cycles, less often, would be preferable I think. Your experience, and the DECC heatpump reports (for example, https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/65695/7389-effects-cycling-heat-pump-performance.pdf) push me in this direction!

Thanks for sharing your weather compensation settings, they seem like better numbers, but yes, will see how it goes and experiment later perhaps :slight_smile: We don’t have a sensor in the buffer (there’s a pocket for one though), and the heatpump’s set to work off flow temperatures, although it can use buffer temp.

Monitoring indicates that CH demand is cycling on and off (and when CH demand is on, the system and heatpump circulating pumps run), but the compressor doesn’t always run as flow temps are still reasonable (there’s a hysteresis of 10K on this, this is adjustable). It was on quite a lot last night (OATs down to 0.5degC), but has been off most of today.

As the demand is on and off, but the compressor isn’t running every time, I think this indicates that the heatpump is running happily, but that the room stat is ‘at fault’? I’d like to make it less sensitive, but I can’t see a setting for this. It’s been indicating 18.0degC all day today (displays to the nearest 0.5degC). I’ve got an sdr, so I’ll try keep an eye on what it’s sending to the programmer…

1 Like

This may sounds like madness, but we don’t have a room stat creating demand.

We just use a cron job for timing and then various temp sensors on the air temp and return temp. If it’s cold we turn on the ASHP and pump water round until the return temp gets high enough. That let’s the TRVs act as an upper-bound but they can’t call-for-heat.

The other thing we do that’s odd is that we don’t run the pumps very much. We are essentially using the large rads as heat sinks so when they get warm we turn off the circulating pumps and the ASHP. Of course you would reasonably ask “well how do you know the return temp if the circulating pumps are off?” We actually just use the sensor on the return pipe near the ASHP which acts as a rough proxy for the actual rads because it loses heat at about the same sort of rate.

We found our 30GBP room stat was sending too many cycling events even when we dug into the menus and opened up the hystersis. It’s no longer allowed to play with the others.

Good luck making yours play nicely - we found the manuals online (sometimes for a similar make) gave us the info we needed to access the inner menus.

1 Like

That makes sense, and would certainly give much greater control. I do need to finish getting some room temp sensors set up… and buffer temp, and rad flow/return, and… and… haha

I have considered changing the programmer from continuous to timed, and perhaps very crudely emulating something like your cron arrangement, but can’t decide if it’s likely to be more or less efficient - longer runs with bigger gaps will be closer to steady state, which is good, but if the walls cool too much it’ll need higher flow temps to recover. My assumption is that (for reasonably settings) there probably isn’t a huge amount of difference, but it will need testing to be sure and to optimise.

If I can increase the hysteresis on the room stat, I think I’ll be happy. And if not, it seems worthwhile to sacrifice it for the cause :laughing:

1 Like

Very good Matthew :slight_smile:

Let us know how it works out.

I have to keep reminding myself that getting an extra 0.2 CoP isn’t worth a year of my life.

I can see that CoP chasing could become addictive haha

Ahhhh, I’m beginning to understand the room stat behaviour now…

It (or specifically, the programmer, but considering the room stat and programmer as a system) implements TPI - a crude way of reducing average flow temps for fossil fuel boilers and eliminating room temp hysteresis! The stat has a small (1.5 - 3.0K on this Honeywell kit) ‘proportional band’ where it will intentionally cycle the boiler on and off to get an average duty cycle sufficient to keep the room temp at the setpoint. So this on-off cycling three times an hour is intentional (although perhaps undesirable) behaviour.

The TPI system learns the response characteristics of the heating/building system, and adjusts the boiler duty cycle to keep to the fixed setpoint, where-as a ‘perfect’ controller would instead modulate the actual heat output to match. Of course boilers and heat pumps can’t modulate down all the way, and there are other real-world issues that get in the way…

Our Grant ASHP only accepts on/off control from the stat/programmer, and it doesn’t have a funky system like yours where we could adjust target flow temps on the fly (I’m not jealous, honest…) so I think we’re either stuck with TPI, a basic stat, or time control only.

However, I think if we get the weather compensation as close as possible to ‘perfect’, then the house will need ~100% of the heat pump output all the time. (I appreciate this will simply shift from thermostat cycling to the heatpump cycling its compressor, but as it drives its compressor with an inverter, this will be better - the inverter goes from 10Hz min to 70Hz max). Of course, in the real world, we’ll want to give ourselves some margin (lest we become unable to maintain room temps due to excessively low flow temps), but at least the TPI will ‘learn’ this and perhaps become more useful…

Here’s current behaviour: (I must admit, I adjusted the weather curve to lower temps already since yesterday)


Red is OAT, blue is CH demand on/off, yellow is heatpump power consumption. Overnight, while OAT was low, TPI was resulting in a duty cycle of ~25% (It’s currently set to 3 cycles per hour (20mins), and 5mins minimum run time - a minimum duty cycle of 25%, although I suspect any call for heat at all will result in that 5mins of run time. I set these settings, trying to reduce cycling… they were at defaults - 6 cycles per hour, 1min minimum on time).

As OAT increased, TPI duty cycle remains at ~25%, but the power consumption shows that the heatpump doesn’t run the compressor every time (this power consumption is as reported by the heatpump, so not necessarily reliable, and only to the nearest 100W, but it seems reasonably good. It shows 100W when the circulating pump is running, although I don’t imagine its actually consuming that much), indicating that the water temps aren’t cool enough to warrant the heat input. This is good - the heatpump is reducing its output based on increasing OAT, but not good enough - TPI is still only calling for its minimum heat. Reducing flow temps further will result in lower output, and at some point I’ll see the TPI increasing its duty cycle to compensate, meaning the heatpump will be closer matched to the building, and will see longer run times which should make it happier.

That all makes sense to me… can you see any glaring errors or misunderstandings?

You’ve got the right idea Matthew.

Your room stat is behaving like ours did - it only seems to do on/off.

I tried getting long runs with my system as documented here:

I never managed to get the heat pump to modulate down enough (as you mentioned) so after a while it started cycling again. I reverted to my “switch the heat pump off” strategy. It’ll be interesting to see how your buffer tank might cause yours to behave differently. I was anticipating that the buffer tank would give fewer but longer cycles as it heated up the buffer and then went back to sleep. As you say, if the ASHP flow temp is low then it’ll need to keep nudging the buffer. That wouldn’t work here because the heat pump is in the garden and it’s annoying when we’re outside and it’s on.

Given your setup I might be tempted to just use timed control and let the TRVs manage the temps. We have our bathroom TRVs wide open so they behave like yours. I would expect the ASHP will see your return is getting too hot and shut itself down when it can’t modulate down far enough so you wouldn’t need the room stat to perform that “switch off when warm enough” functionality.

The 100W from the circulating pump sounds plausible, even our pond pump is 65W. Part of the benefit of the “turn it off” strategy is that we don’t have the noise or power consumption of the circulating pump all the time - it only comes on when it’s got something to do.

I’m surprised you need the CH during the day in the UK at the moment, it’s getting to 15 Celsius and we’re having the doors open some of the time (which is inevitable when you have orphaned ducklings living in the house overnight). Moving to a timer would cut out much of your day usage. I can also see that it’s cold overnight (we had a frost a couple of days ago) but we’re finding a single 15 minute run in the morning takes the chill off and we haven’t even done that since Thursday. Perhaps you could avoid all that overnight cycling using the timer too? We’re finding the trick is to shut the doors / windows in time to conserve the heat from the day.

Don’t feel too bad about your cycling…

Good luck.

David

Interesting reading, thanks. I’d missed that thread somehow.

Yes, it’ll always get to a point at which is cycles, especially if I leave it going all summer… :slight_smile: The buffer adds system mass, so should increase running times and improve CoP, and will also mean that the flow to the rads isn’t quite as warm as flow from the ASHP, which reduces CoP… This one’s “only” a 50l buffer, so pretty small really, but was ‘required’ by the ASHP manufacturer.

I dropped the flow temp to its minimum of 23 degrees (at 18degC oat), expecting this to be too cool (plus set the lower oat temps to match yours, and a 3K hysteresis on the flow temps in the ASHP for compressor cycling). It’s taken ~24hrs for the room stat to learn this new behaviour, but although cycles are now much longer, it is still cycling, but not as much. Average running CoP since midnight has been ~4.5(!) and ASHP energy use has dropped by ~50%. I’m reasonably happy with that :slight_smile:

You are quite right - although our location and surrounding topography conspire to keep local outdoor temperatures ~2degC below nearby locations and maintain ‘breezy’ conditions (300m above sea level, and in a slight ‘wind funnel’), we don’t really need the heat at the moment and it’s not an ideal time to be trying to tune a heating system… We get a good lump of solar gain in the late afternoon/evening, so yes, a short run in the morning would probably be sufficient for room temps at the moment. I did measure the power used by the circulation pump. The one built in to the ASHP (included in the 100W figure) uses ~47W, but we also have another indoors to circulate around the rads, which consumes ~35W. So not too bad, but certainly significant if left running 24/7. The internal ASHP pump won’t run all the time actually - it’s cycled on for a couple minutes occasionally to ‘update’ the flow temperatures. But yes, better to turn off when not needed.

Our DHW is also set to run at 06:30 16:30 each day (it doesn’t, due to the cylinder stat) currently. I’ve never seen it run in the afternoon, but the morning run, which I guess makes sense it terms of matching shower times, is probably close to the worst time of day for efficiency… But to make that perfect, it needs some calculation to work out the efficiency lost due to low OATs balanced against the loss of energy from not using the hot water straight away (although loss from the tank just becomes heat into room temps). Quick rough calcs suggest we’d be better off with a run in the afternoon, but the cylinder stat also needs replacing (it has a 15K hysteresis…) and the optimum timing depends on weather/temps/etc…

That, combined with your suggestions, are certainly encouraging me to ditch the room stat, cylinder stat and programmer and build something more intelligent. I do have the beginnings of a system I started building a couple years ago to control our old oil boiler - including wiring in the ceilings for a DHT22 in each room… This was intended to run off a Pi, but I think it should be fairly do-able to install the OpenHAB integration on the EmonPi, and run it all through that… I can get forecast temperatures each day to do the DHW timings, and also influence how the ASHP runs if at all. Do you use EmonCMS to run your ASHP, or just to monitor?

This sounds like a summer job… I probably shouldn’t wait until winter bites to start fiddling with the heating haha

</wall of text>

1 Like

I’ve finally rigged up my Boiler/thermal store to be operated via relays rather than the tank stat. I’ve had the UFH controlled that way for a couple of years. I’m using Home Assistant automations and ‘schedy’ as the controller plus manual HA switches as overrides and the ‘dumb’ temperature sensors and relays using Tasmota.

In all cases though, the original controller (UFH/Tank) is still in place (albeit set low so it does not interfere), as the backup! Belt & Braces.

1 Like

Thanks, that sounds like a good arrangement. I’ll take a better look at HA.

At the moment I have a separate Python script to drive the heatpump which I use it to drive the manufacturers web app. The folks on this forum are much better informed in implementing control hardware than me.

Emoncms is acting as a central point for data from the solar panels, weather station and heat pump so the control alogrithm can get what it wants.

When we get a battery and an agile tariff I may move to the Demand Shaper plugin for Emoncms.

You might be interested in these experiments I did…

Notably, we don’t heat for when the showers are planned because there are four people in the house and showers are very random. In fact sometimes we shower when it’s a good time for the heat pump. For example we’ll shower at 13:00 when the morning sun has heated the tank and we’re creating “space” for the afternoon sun to heat the tank. Also, our tank doesn’t lose much heat so we’re free to leave it full of water.

Yep Brian, that’s been a key part of our setup too. The residents know they can just tell it what to do whenever they like if the clever stuff isn’t working for them. That makes them much more willing to let the computer take control most of the time. It’s rare they feel the need to intervene. My control algorithms have gating unit tests which stops them going live if they are going to misbehave.

It sounds crazy, but I can understand why you’d do that. We found we weren’t emitting enough heat with a room delta that low so the pump would switch off because the return was coming back too warm.

We think of the radiators as “a big warm dog lay in the corner” rather than “a furnace” so if they are only running at 28 Celsius that’s fine.

What will it take to make you very happy?

It’s not as mad as it sounds. I took the defaults on our system in October and November and only took computer control at the end of November when I had something interesting to work on and some evidence that the defaults we’re working for me.

That bumped us up from the red line to the blue line:

It was warm enough in October that it would have been OK to have been playing with the control then and people wouldn’t have noticed much. You probably want to get the hardware in place by then though.

Good luck.

David

Thanks, all good info. Yes, Emoncms makes it easy to use various bits of data in different places, so plenty of implementation options.

Thanks for those threads, I’l have another read through now I’ve a better idea of the concepts :slight_smile: Fair point on not timing DHW for showers. Ours is ‘only’ a 200litre cylinder, and seems to be losing about 80W at ~45degC, but that gives us about 24hrs of warm water from a DHW run so that should be enough to play with.

It seems the weather curve I set is ok when warm out, but only just barely enough when cold, so I’ll need to tweak the bottom end up a bit. I suspect the true ‘perfect curve’ is far from a straight line, but so long as I’m on the right side of it, we’ll be warm.

I miss-spoke… (got my maths the wrong way around) - dropping the weather curve ‘only’ dropped consumption by ~30%. But… yesterday I turned it off at noon, back on again at 5pm, and off at 10pm. This seems to have resulted in power consumption of ~40% of where we were a few days ago. (Well, ~30%, but I trying to account for the slight increase in outdoor temps) That might’ve been a bit far, as it felt a little chilly, but there’s room to tweak timings and settings :slight_smile: Perhaps ‘reasonably happy’ is a slight understatement haha (of course, this is only one day, it’d take longer to get a proper understanding)

Here’s some of this morning’s run:


Those short spikes are from the system circulating water (to monitor flow/return temps), but not running the compressor. The graphs also highlight the very poor resolution of the heat metering…

Yes, so long as the hardware’s in and the system is nominally working, colder weather is probably an ideal time to be ‘optimising’ haha.

Thanks for all your help :slight_smile:
Matt

1 Like

A few things are interesting in that graph.

Firstly the bars seem surprisingly wide on your efficiency graph. On my browser they don’t overlap each other. I’m on Firefox on Linux.

Did you change it to do that because you wanted to, or did it just behave like that for you?

I found I didn’t need the runs to determine the return temp. I just use the temperature from the sensor on the heat pump which is on a vaguely lagged pipe. It gets cool at about the same speed as the radiators so is a reasonable proxy for them.

I like how it’s showing the CoP for the time range. The instantaneous CoPs are always pretty inaccurate, even though the shape is pretty useful. I hope the time navigation is helping you review different experiments. I can see from a sliver of green that you have “Show Latest” turned on which I personally find very useful as I sit watching things unfold.

I’m also pleased to see some of the un-mapped feeds are hidden in the graph (e.g. “solar”) which keeps your analysis and screenshots crisper.

You’re very welcome. I’m pleased to see someone benefiting from my heatpump-experimentation app in Emoncms.

Keep up the good work.

David

Hmm, no, I haven’t changed anything regarding bar widths. I’ll try other devices/browsers, (this is chromium/linux) although it may be due to me having a 5s period on the feeds instead of the default 10s.

Yeah, the periodic circ pump runs are just a default setting on this ashp. They can be adjusted, or set to ‘always running’ or based on thermal store temp (which I don’t currently have). The return water temp sensor seems to drop much quicker than flow, although I’m not sure how this correlates to the rads. The flow temp sensor is fitted above the PHX, so is likely to be warmed slightly, and the return sensor is right at the bottom, so may be cooled a touch. I could wire in a temp sensor on the buffer and set the ASHP to use that, but I’m not too worried about it at the moment - although I’ll probably adjust the circ runs to be shorter and longer apart at some point. Edit: Actually, this isn’t particularly useful, as it will only ever be able to measure the temps in the buffer, and not the rads, unless the second rad circ pump is also running. They should all be fairly close, but not guaranteed. Although the rad pump will be running all the time while the stat calls for heat… hmmm more thinking required here.

Yes, your app has been very useful, both watching current behaviour, and comparing with historical data :slight_smile: I keep meaning to ask - how is your ‘effective’ outside temp calculated/detected? (I assume it includes some function of solar gain/extra infiltration losses on windy days etc?)

1 Like

Glad to hear it. Feel free to discuss things you might also want to see.

That came about during the really stormy week when it was feeling much colder in the house than was being reported. It hadn’t been terribly important until then. I just followed this strategy:

https://pywws.readthedocs.io/en/latest/api/pywws.conversions.html#pywws.conversions.apparent_temp

I have a cheap and cheerful weather station that pushes to Emoncms. I don’t include solar gain, even though that might be useful. I’ve just put in a binary behaviour that says “is it getting warmer and are the solar panels generating something interesting” - if that kicks in it suppresses the heat pump. It’s saved it coming on about 8-10 am where the house will soon be warm, but has a bit of a chill on it.

The period shouldn’t be a problem, I have a mix of 6s, 1 minute and 5 minutes all on the same graph :slight_smile:

I’ve just tried on Chromium on Linux and it looks pretty happy even when I tried zooming in and out and things like that. For example:

I’m using the normal flot charting tools from Emoncms but I do have a few of their plugins loaded and I hack about with the style quite a bit:

If it’s OK with you, I’m going to gloss over your exciting UI for now because I expect Emoncms might get a new charting library in the next year or so.

Thanks for sharing your progress.

David

Gotcha, that makes sense. Thanks for the link.

Yeah of course, not a problem. It’s definitely something to do with my particular setup, but it causes no usability issues! I hadn’t noticed until you pointed it out haha.

1 Like