I’ll open some more topics to chat about what’s actually happening with the heat pump.
I’m not ignoring you all but I’d like to keep this topic to be about adding the new app rather than what I’ve been doing with the heat pump.
Hope you don’t mind.
1 Like
Good point, I have the same on my heat bank - should have thought of that one! 
1 Like
I’ll bite on this topic. Too juicy not to 
I am impressed with the level of experimentation and monitoring that David has carried out so far. I personally don’t think enough work is carried out exploring heat pump control strategies but I know the reasons why though.
- Most people only care about heating if it’s not working, or if it’s costing them a fortune to run.
- Manufacturers’ want their ASHP box of tricks that performs as reliably as possible for as many types of installation as possible. It might not be the most efficient strategy they use, but it is often the most reliable.
With that in mind, and based on my day job as a tech support guy for a heating manufacturer, I’ll throw in my 5p worth 
(All opinions my own). Whilst this may come across as negative, it is not meant to be. I just want to remind anyone wanting to experiment, to bear some important things in mind.
Now I did speak to @TrystanLea about this last year at the Fully Charged show where OEM had a stall. He mentioned how good it would be to be able to adjust the compressor running frequency / speed based on available excess solar PV energy, or to have an influence over the defrost cycle of an ASHP.
Whilst that would be great to be able to do this as an experimenter, no manufacturer would be happy doing this from a warranty point of view. Priority 1 of the software on a heat pump is to look after the heat pump. Priority 2 is to provide heat to the customer!
Every manufacturer has a different strategy around defrost cycles - it is their “secret sauce”, whether it be a time calculation around the time it took to complete the previous defrost, or based on ambient temp, evaporator temp and suction pressure or perhaps around CoP.
One thing for sure with a reverse cycle Air to Water heat pump, is that when the heat pump needs to do a defrost, it needs 2 things. Good water flow rates & sufficient thermal energy from the heating circuit & buffer tank. A lack of flow or insufficient thermal energy during a defrost cycle can cause water freezing & crystalisation in the condenser. Freezing water expands, potentially splitting the plate heat exchanger condenser. The software built into the machine will do everything it can to prevent this from happening. That might be faulting out with an error code if needed, or switching on a flow boiler / buffer tank immersion element to assist the defrost. Just be mindful of this if you are controlling a circulation pump controlling flow through the heat pump with your own on/off durations and pump speed. If the heat pump was expecting to control that pump, but in reality you are, it could cause trouble. A split condenser = a water filled refrigerant system. Not fun is an understatement!
Now I can see David has been experimenting by switching the heat pump demand on/off and slowly ramping up the water return set temperature rather than allowing the heat pump to do this quickly. I would imagine this results in the heat pump running the compressor at a lower RPM speed for longer and having a reduced cooling effect to the evaporator, potentially prolonging times inbetween defrosts & increasing CoP. What effect toggling demand on/off signals or altering the return temp set point on the fly to the heat pump makes to the defrost algorithm I don’t know (Never worked on Mitsi). One to perhaps think about.
On the topic of compressor running speeds and run times. The compressor manufacturer will specify a minimum and maximum running speed for inverter driven compressors as well as minumum run times. This is to ensure compressor longevity. Compressors contain oil and the compressor RPM and run time makes all the difference in making sure that oil gets to where it needs to go within the compressor. Generally speaking, compressor longevity is increased by reducing the number of starts per hour they have to perform. There is also a rule in the UK that should be followed to prevent upsetting the local DNO - no more than 3 compressor starts per hour. Most heat pumps have this inbuilt. Trying to override this may shorten the compressor lifespan and upset the DNO if they catch you (unlikely but still!)
Nevertheless, my inner heating geek rather likes seeing stuff like this. Would the gains in CoP efficiency be worth the time & effort spent seeking them? I would question it, but if you’re enjoying it and it doesn’t leave you with a broken heat pump, then I will enjoy seeing the fruits of your labour.
2 Likes
Thanks for the kind words @moojuiceuk
There’s a lot of important points you mention there. You’ll see I’ve expanded on most of them over in the heat pump category:
For control I’m exclusively using commands their phone app can send. That way I can’t do anything they didn’t design for (and continue to support in the future). As a result my program just looks like a very very involved app user.
It would be nice to have finer-grain control, but (as someone who also supports other tech) I’m fine just using what they feel comfortable with.
Thanks again for taking time to think about these things and for sharing.
1 Like
I never realised you were using an API which is part of their app. Fair play 
For DHW prep, have you looked at taking an external weather forecast dataset for your area, then adjusting when DHW can be performed based on anticipated peak ambient temperatures that day? That might increase CoP figures a little bit for DHW prep. Of course this depends on when you have a demand for hot water, tank and pipe losses etc.
Also, are you heating your DHW tank to 60C every so often (say once a week)? I know of two different heating engineers who caught legionnaires and they wouldn’t wish it on their worst enemy. That hygiene cycle could be scheduled around the next highest forecast air temperature to aid efficiency perhaps?
I also wonder, from a CO2 national grid point of view what the merits would be to using a much larger thermal store and to heat that up based on when electricity is greener, by taking data from https://carbonintensity.org.uk/ or charging the thermal store during periods of off-peak electricity. Yes, the air temperatures will likely be lower overnight when prices are lower = lower CoP, but would the CO2 output be reduced by using electricity that was greener to produce at those times? Just a thought 
Here you go @moojuiceuk
Notably the demand shaper app in Emoncms should allow me to do that agile tariff/ CO2 bit. That’s part of the reason I’m doing all this work to integrate, such as this app
See
1 Like
For an indirect tank (i.e. the DHW is heated via a coil the potable water flows through within the tank), this is not really necessary as you never come into contact with the water in the tank. It could impact a heating engineer if they come into contact with the water in the tank, but is that not their risk they should take precautions against?
https://www.hse.gov.uk/legionnaires/legionella-landlords-responsibilities.htm
If the HSE state landlords have a responsibility, I would say that any private owner would want the same level of precaution taken. Regardless of the tank being an indirect coil heated tank, Legionella can grow in the tank (ie the stored hot water side), in the outlet pipework to the taps and in dead legs of the system. The primary way legionella infects people is when water droplets containing legionella become airborne (ie via a shower head).
Given legionella bacteria are killed at 60C, it is generally accepted that doing this once a week would cover the risk well. For the sake of a few extra pence of 'leccy, its worth doing IMO.
Agree - in indirect systems this is unnecessary but heating engineers beware!!
Nope, there is no HSE requirements on a private individual.
Never said there was. But, if a regulation forces a landlord to do something - it is generally worth doing yourself too. Bit like making your home has smoke alarms. Not a legal requirement for private owners but mandatory for landlords.
You are conflating two issues. There is no risk to a householder from legionella when using an indirect tank except from dead legs in the DHW supply pipework.
The legislation is an HSE requirement on Landlords to Tennants not heating engineers (or any other trade). It is up to the engineers to make a relevant risk assessment if they are likely to come into contact with such water.
Hi David,
Sorry to keep on about this but I’d like to really understand how the useful heat can be that much higher. Your comment about it being a feature of the way you’re controlling the heat pump makes me think the very high COP reading might be simply be due to the timing of the measurements you are taking.
For example on our gas boiler, the pump keeps running for some time after the boiler has stopped firing to prevent the fluid in the heat exchanger from boiling die to the residual heat, i.e. it runs to cool things down.
So I can imagine that in a HP you have exactly the same problem. Which means that if your temperature reading is just after the pump has turned off it will be very high giving a false COP ratio. Would it be possible to do the readings in a different order, or are you taking this data from the interface with the HP?
I’m not physicist, but surely thermodynamics would tell us that the ratio is impossible. Any physics PhDs out there? If this is the case then the software should be making sure that such an impossible ratio is impossible to generate from the data.
Hi @Bramco
You’re right about all the things you say. It is physically impossible and it is a result of the system measuring things with a bit of a delay.
As you say, I’m getting the values from the vendor’s system so can’t alter how that works. Notably it’s a bog standard MMSP system so you’ll see lots of people with behaviours like this as heat pumps get fitted in more properties.
There is another slightly unusual situation that is occurring as I type this. When the hot water is finished it’s hot and I pump that round the radiators which gives me some space heating in the way this vendor’s system measures it. That gives insanely an high instantaneous CoP because it’s just pump electricity being used. I’ve described it with examples in this post.
I’m not troubled by it because I tend to look at the CoP over the time of an event rather than the instantaneous CoP. That’s partly why I want this type of application in Emoncms, it allows you to look at the experiment’s outcome more easily by reviewing what makes sense to the experimenter.
BTW I should mention that Emoncms’ ability to return data “at intervals” is incredibly useful. My home-grown web-app tries to load all the data from every minute since October. As time goes by it’s getting harder and harder to do that. Of course Emoncms using PHPFINA can show an “all time” view relatively easily which is rather wonderful.
1 Like
I guess from my perspective if it isn’t physically possible, it would be better not to register that reading - if it is a single reading - and to replace it with an average of the one before and the one after. If it’s more, then lose the ‘impossible’ ones and again replace with an average.
Simon
1 Like
@TrystanLea I’ve uploaded the app and a relevant device file to MyForest/mmspheatpump on github so you can take a look.
1 Like
Thanks @MyForest this looks great, nice work! I will see if I can get your app running with my heatpump data here. Interesting wider discussion too!
1 Like
Thanks for the kind words @TrystanLea
I’m not going to say it’s bullet-proof, but I think I coded it fairly well to cope with missing feeds so it should just take advantage of what you can give it.
Come to think of it, I suspect there might be some bits that might try and divide by “undefined” if things aren’t set. I’ll go see. You can of course just be sure to assign pairs of feeds ( used + produced) to stop that.
Feel free to nudge me if it’s tripping you up. You know far more about this than me anyway
[edit] Fixed the bug that I thought might be in there.
Nice work, got it running! I don’t have all the feeds, so it’s not all showing as you have it of course. Here’s a heating run from yesterday with a nice efficiency of 433% just look at that stable run, no cycling at all
It’s doing the DHW at the moment hence higher flow temp.
Im wondering if for the time being it would be better for you to keep this under your own repository, users can just drop it in to use it and you can keep pushing new developments as you work on them without having to wait for my review and pull request merges?
I’m planning on overhauling the heat pump monitoring documentation soon and I would be happy to feature this app as part of the documentation.
It might be worth adding installation instructions to your readme, in particular the installation path needing to be MyForest/mmspheatpump which tripped me up for a bit:
cd /var/www/emoncms/Modules/app/apps
mkdir MyForest
cd MyForest
git clone https://github.com/MyForest/mmspheatpump
I see that you have used a different naming convention to the ‘My Heatpump’ app. Would you object to changing the expected feeds to:
- heatpump_elec (electricity consumption in watts)
- heatpump_elec_kwh
- heatpump_heat (heat output in watts)
- heatpump_heat_kwh
- heatpump_flowT
- heatpump_returnT
Thanks again for sharing this and your wider experimentation, really interesting.
1 Like