However I’m trying to isolate and prove - in principal... which part of the heating cycle is most efficient and how to possibly only use the most efficient part of it. This might not suit a large family who use a lot of hot water but it would make sense to smaller HW consumption like our family is on occasion.
The other advantage of what I’m working on is that there’s nothing to stop a second reheat say in the evening to take the remaining HW temperature up to the upper limit as and when it’s needed.
With our system we can manually start a DHW heat up WITH JUST TWO presses of a button on our controller. so it’s very convenient to only heat enough for say 2 showers in a 30 minute DHW cycle. And I’m convinced the most inefficient heating period is the last 20 minutes of a typical full reheat to, as an example;50C.
So here is a full cycle DHW Reheat Andy as you can see - even though we have a proper HP ready cylinder with 3 mitre coil heat exchanger the deltaT between 5 and 8 at a recommended flow rate of 18 lpm. Now let’s be clear we are not changing the cylinder James. There are thousands of this type so I’m looking at this characteristic energy signature.
-- Attachment is not available --
So my assertions are:
The first 30 minutes is the fastest heat exchange period
The widest deltaT (gap between blue and black lines) is a visual indication of the fastest heat exchange period.
the longer the heating period is in the high temperature (55c plus) the more inefficient the hearing process will be so by removing the back end of the heating process the more efficient the process will be.
-- Attachment is not available --
I realise I am attempting to interpret energy consumption from a standard graph which lacks actual kWh consumption but a graph which does show clearly deltaT, flow temp minus return temp which with the usual calc which you probably know (Lpm/60 x 4.2X DT) the general efficiency can I believe be seen.
So ive done a new reheat with a truncated heating period and we achieved a happy 43c in 30 minutes with a much lower Flow temperature in the process.
-- Attachment is not available --
As you can see I have not lowered the target temperature but simply reduced the period of DHW cycle. This allows for a second reheat later in the day if a higher store of water is needed. This to me is simple and quite elegant.
I am not quite sure how’s to represent the inefficiency of a high flow temperature and perhaps James you might see a way of illustating this base day on the image s you can see. But it’s something that would be nice to illustrate numerically.
what do you think
addd...
we can activate a DHW cycle from all room controllers, or the wireless thermostats and also from a phone anywhere while we are out and about so this is a very convenient thing to do.
I can't see a way to get efficiency from the data. If you had flow rate and power in it could be calculated, but not what you have presented.
However as a general rule, rooted firmly in thermodynamics, efficiency drops as ft rises. So, in the absence of data to contradict (which could occur if something is happening that we cant see) your conclusions and proposed operating mode are very likely sensible. Also if the dhw tank is at a lower temp, it loses less heat so you get a double gain.
This post was modified 4 months ago 2 times by JamesPa
On a positive note, something of a breakthrough on the energy in calculations, and the need for a 1.18 correction factor. Against expectations based on my past experience, Freedom Heat Pumps have replied to my email (credit very much due where credit is due, and a very welcome change) and it turns out the 'amps_in' (modbus register address 118) variable is indeed just the compressor current.
18% is a lot particularly if it's actually a fixed ish load thus more significant at low power outputs.
Do you happen to know what happens if you run your regression method of estimating saving on the raw data before the 18% uplift is applied? It might just tell us something as the compressor power is the actual power in to the heat engine.
If I remember correctly, I used the V x I without the 1.18 correction factor when I produced the recent predictions, which is why I questioned the need for the correction factor.
I checked the V x I values against the power in values derived from the Midea data tables and found that there was a close match. I think that the average variation was something like 26W in a 1kW and above power in value, with the data tables being slightly higher than the V x I values.
Initially I thought that the 26W may be to accommodate a water pump, which obviously would be required during the testing at the testing facility, but after the recent discussions I think that it may be the power used by the fan motor and the circuit boards, which would mean that the power in values within the data tables are only for the outdoor unit and do not include any of the ancillary equipment within the complete heating system. That obviously would make sense, since only yesterday, a new forum member posted stating he has a heating system with 5 water pumps at the moment.
As you correctly state, the V x I value is the true power in value, from the point of view of heat pump COP calculation and produced thermal energy output, but obviously the ancillary power also needs to be taken into account in the overall efficiency calculations. Another can of worms. 🙄
A further thing to consider is does any of the power produced by ancillary equipment produce thermal energy within the building's thermal envelope, but obviously at a COP of 1 or less.
I started putting some of Kev's data into the spreadsheet before the holidays, which I must get completed in the near future. I have added a Other Heat Source (OHS) parameter to the spreadsheet to accommodate human infestation 😋 as I jokingly termed it, both in body, and all the electric and electronic gadgets that produce thermal energy within the home. I think that I assessed that the 'infestation' could produce a thermal energy supply in the order of 8kWh to 12kWh over a 24 hour period, which could be 10% or more of the required thermal energy input to keep the home at the desired temperature. A further unknown to throw into the equation. 🙄
Since you seem reluctant to release the actual data, could you please clarify the source and detail of the non-setback data in item (1).
Will you please stop making insinuations that have no basis in fact. I have released all the all the raw/actual data for December in the zip file I posted recently. There are enough non-setback days to do the regression. You will get a slightly different result, because I included days from October and November, but that's fine, in effect we are doing a sort of sensitivity analysis (how sensitive are the results to the data used for the regression). It's all grist to the mill.
18% is a lot particularly if it's actually a fixed ish load thus more significant at low power outputs.
Do you happen to know what happens if you run your regression method of estimating saving on the raw data before the 18% uplift is applied? It might just tell us something as the compressor power is the actual power in to the heat engine.
Beware the relative vs absolute trap! 18% of a small number is a small number! If the compressor is using 1 kWh, then the 18% is only 180W, and that has to cover two circulating pumps, the fan, and all the other current used by the heat pump ancillaries and circuitry etc.
If it is the standing load, the absolute amount should relatively fixed, meaning the relative (%) amount will change, as the compressor use changes. I haven't looked for that detail. Don't forget the history of all this (most if not all posted here at some point): I had a V x I value that did not match the external kWh value, so what did I do? I tabulated the two alongside each other, and looked at the individual and summed differences. The variation was clearly neither fixed nor linear, as far as I could tell it was random. As usual, I applied a heavy dose of pragmatism, calculated the average difference and applied that. Bear in mind I can only get data from the external kWh meter manually, which definitely rules out minute data, and frankly, my dear, life is too short to to collect enough reliable hour data to be useful. The data is already summed over longer periods (days, weeks), so all I really have in the first place is averages. As I said before, this correction was and is far from perfect, but it was better than not using a correction, because it meant I used values closer to the presumed accurate external kWh meter values. I also assumed, not unreasonably, but not in any way I can easily verify, that any variations either way would cancel out over longer time frames.
I haven't done it, but I suspect if I did the regression on the data without the uplift, everything would come out about 18% less.
I am now sure, given what FHP have said, that the V x I value is only the compressor draw, not, as the Midea wired controller manual has it, the outdoor unit current. I am equally sure that the external kWh meter reads the total draw. From those certainties, we can draw what conclusions we will. I myself am not sure how it helps to consider only the draw used by the compressor. What matters from both an energy use and bills to be paid point of view is the total draw.
If I remember correctly, I used the V x I without the 1.18 correction factor when I produced the recent predictions, which is why I questioned the need for the correction factor [et seq].
I think you are over-complicating things. The modbus amps times volts value is the compressor draw. The external kWh meter value is the total system draw. The difference between the two is about 18%, on average. All of the values are either spot readings on fluctuating parameters (the compressor current for example changes every few seconds) or sums/averages (depending on how they are presented). I don't have, and am unlikely to have, detailed enough data to be able to see how the difference varies with compressor use (that needs minute data from the external kWh meter, which I don't have, and am not going to have unless and until I get a modbus enabled external kWh meter, and that isn't going to happen any time soon).
Let's face it, the raw data I do have, and have published, isn't that bad. As far as I know, it is probably the most complete and detailed raw data available in the public domain. Do we reject it because it isn't perfect? You can if you want to. But I do think it is better than nothing (which is what you are left with if you reject it, and all other similar data, which for consistency you will have to do). It is both all we have, and it is by my test 'good enough', a notion that has within it an implicit understanding that it is not perfect; it is just good enough. As that In England Now piece concluded, I too take the view it is better to have a live problem than a dead certainty.
Beware the relative vs absolute trap! 18% of a small number is a small number! If the compressor is using 1 kWh, then the 18% is only 180W, and that has to cover two circulating pumps, the fan, and all the other current used by the heat pump ancillaries and circuitry etc.
Of course Im aware of that, I come across it every day. I presume that as the average is 18%, its rather more than 18% of the smaller values, and rather less than 18% of the larger values.
Do you happen to know what happens if you run your regression method of estimating saving on the raw data before the 18% uplift is applied? It might just tell us something as the compressor power is the actual power in to the heat engine.
From those certainties, we can draw what conclusions we will. I myself am not sure how it helps to consider only the draw used by the compressor. What matters from both an energy use and bills to be paid point of view is the total draw.
In terms of answering the question I agree with you. However as a means to understand whats going on (which is certainly my aim), being able to isolate the compressor power is actually very useful If you dont have the information then that fine, but if you did it would be interesting to see. Sometimes you have to look beyond the question to answer the underlying question!
This post was modified 4 months ago 2 times by JamesPa
I presume that as the average is 18%, its rather more than 18% of the smaller values, and rather less than 18% of the larger values.
Covered in my recent post (I'm not sure, don't have enough detailed data, but on balance, it looks random, but I don't know for certain). If/when I have time I will have another look. I suspect I will come up against the not detailed enough data problem, it (the external kWh meter data) is already sums and averages by the time it is collected (eg if it was 11,000 yesterday morning and is 11,048 this morning, then all I know is I used a sum of 48 kWh or an average of 2 kWh per hour over the last 24 hours - not detailed enough to do a minute by minute or hour by hour analysis).
That said, I might get something by looking at longer periods when OATs were consistently high, and, as they are now, low. When I have a chance...
I do, it's in the zip file I posted recently (all data for Dec 2023), which you can have if you download it, and then use for your own analysis. The 1.18 correction is applied by the python script that collects the modbus data, ie it is already in the data in the csv files. You will, of course, need to divide the 'amps_in' column by 1.18, and recalculate anything you use that is derived from 'amps_in'.
Midea 14kW (for now...) ASHP heating both building and DHW
However I’m trying to isolate and prove - in principal... which part of the heating cycle is most efficient and how to possibly only use the most efficient part of it. This might not suit a large family who use a lot of hot water but it would make sense to smaller HW consumption like our family is on occasion.
The other advantage of what I’m working on is that there’s nothing to stop a second reheat say in the evening to take the remaining HW temperature up to the upper limit as and when it’s needed.
With our system we can manually start a DHW heat up WITH JUST TWO presses of a button on our controller. so it’s very convenient to only heat enough for say 2 showers in a 30 minute DHW cycle. And I’m convinced the most inefficient heating period is the last 20 minutes of a typical full reheat to, as an example;50C.
So here is a full cycle DHW Reheat Andy as you can see - even though we have a proper HP ready cylinder with 3 mitre coil heat exchanger the deltaT between 5 and 8 at a recommended flow rate of 18 lpm. Now let’s be clear we are not changing the cylinder James. There are thousands of this type so I’m looking at this characteristic energy signature.
So my assertions are:
The first 30 minutes is the fastest heat exchange period
The widest deltaT (gap between blue and black lines) is a visual indication of the fastest heat exchange period.
the longer the heating period is in the high temperature (55c plus) the more inefficient the hearing process will be so by removing the back end of the heating process the more efficient the process will be.
I realise I am attempting to interpret energy consumption from a standard graph which lacks actual kWh consumption but a graph which does show clearly deltaT, flow temp minus return temp which with the usual calc which you probably know (Lpm/60 x 4.2X DT) the general efficiency can I believe be seen.
So ive done a new reheat with a truncated heating period and we achieved a happy 43c in 30 minutes with a much lower Flow temperature in the process.
As you can see I have not lowered the target temperature but simply reduced the period of DHW cycle. This allows for a second reheat later in the day if a higher store of water is needed. This to me is simple and quite elegant.
I am not quite sure how’s to represent the inefficiency of a high flow temperature and perhaps James you might see a way of illustating this base day on the image s you can see. But it’s something that would be nice to illustrate numerically.
what do you think
addd...
we can activate a DHW cycle from all room controllers, or the wireless thermostats and also from a phone anywhere while we are out and about so this is a very convenient thing to do.
Thanks for your reply @jamespa I can add more data as per your comments.
“I can't see a way to get efficiency from the data. If you had flow rate and power in it could be calculated, but not what you have presented.”
our flow rate for DHW is 18 lpm (it’s 16 lpm for the open heating loop)
At the moment I can only get consumed energy for the whole day, so not ideal.
However I also know the OAT when the DHW was done was approx 3c.
“However as a general rule, rooted firmly in thermodynamics, efficiency drops as ft rises. So, in the absence of data to contradict (which could occur if something is happening that we cant see) your conclusions and proposed operating mode are very likely sensible. Also if the dhw tank is at a lower temp, it loses less heat so you get a double gain.”
Yes I am seeing more and more unknown variables the closer I look and not only in the DHW cycle. I'm seeing OAT has a huge influence in converting colder air into heat made worse by 1. defrosting, 2. Protective reheats of pipe circuits, 3. antifreeze circulation at nights. Not withstanding the actual system being set up correctly in the first place.
But through all this, knowing what works in simple ways and minimal tech cost and being able to explain it is all I am trying to achieve. And hopefully that’s all that most HP users need.
Thank for comment s so far
PS as background in case anyone is interested - our flow rate for DHW cycle is 18 lpm which is 2 lpm faster than our open loop heating circuit. There is no circulation pump speed variation. The lower flow rate of the heating loop is a bi-product of the increased resistance through the bends and lockshields of the radiator system. We have set the flow rate to optimise heating at 16 lpm as recommended by Mitsubishi for our model size. The slight increase in flow for the DHW is still well within the flow range and is a bi-product of the bigger pipe size of the Primary Pipes. Our HP is the Ecodan 8.5kw.
@derek-m (and anyone else who wants it) - here is my December 2023 hour and minute data in csv format:
-- Attachment is not available --
So I did a quick model in R on the hourly data, and I found that the setback period used 1% less electricity than the model suggests would have been used if no setback was employed. I modelled htg_kWh_in as a function of (IAT-OAT)^2. The physics reasoning is as follows:
Heat_Out ~ (IAT-OAT)
Heat_In = Heat_Out / COP
COP ~ 1/(IAT-OAT)
=> Heat_In ~ Heat_Out * (IAT-OAT)
=> Heat_In ~ (IAT-OAT)^2
hence I modelled Heat_In ~ (IAT-OAT)^2
I corroborated this (manually, not included in the code below) by plotting and modelling the above variables - they do indeed all look linear, and the data supports the underlying physics reasoning. It also gave a reasonable R-squared during the "no setback" period of 0.89, which is good enough for me.
I removed the periods where the heat pump was doing hot water, then used the model trained on the "no setback" period and applied it to the (IAT-OAT) during the setback period. Then I compared the actual htg_kWh_in with the modelled htg_kWh_in. The actual usage was 1% lower than the modelled usage.
This is well within margin of error and frankly backs up the conclusion that it makes no meaningful difference whether you use a setback or not.
I don't know (as I haven't been following closely) whether I've used the right columns, but I looked at the data and made an educated guess. If I have not used the right columns let me know and I'll rerun it.
I also don't know whether it makes sense to remove the hours where the DHW was on, but I think it's fair either way as I'm removing it from both sides. In any event, including those periods makes no difference: it simply means that the actual usage is 0.5% HIGHER than the modelled usage. A 1.5% swing the other way.
Here is the R code if you want to replicate:
# midea hourly modelling
library(tidyverse)
midea_data_raw <- read_csv("midea_hr_data_dec_2023.csv")
# only include data from before setback enabled, and isn't doing DHW
# also add a column for IAT-OAT
midea_data_clean_nosetback <- midea_data_raw %>%
filter(dhw_kWh_out == 0,
datetime < "2023-12-16T00:01:01") %>%
mutate(IATmOAT = MD02_tmp - ambient)
# fit the model
lm_htg_in_quadratic <- lm(htg_kWh_in ~ I(IATmOAT^2), data = midea_data_clean_nosetback)
summary(lm_htg_in_quadratic)
# now let's look at the setback days
midea_data_clean_yessetback <- midea_data_raw %>%
filter(dhw_kWh_out == 0,
datetime >= "2023-12-16T00:01:01",
datetime < "2023-12-24T00:01:01") %>%
mutate(IATmOAT = MD02_tmp - ambient)
# apply the model to the setback period
modelled_htg_kWh_in_yessetback <- data.frame(
midea_data_clean_yessetback,
modelled_kWh_in_quadratic = predict(lm_htg_in_quadratic,
midea_data_clean_yessetback)
)
# compare actual with modelled kWh usage
modelled_htg_kWh_in_yessetback %>%
summarise(htg_kWh_in = sum(htg_kWh_in),
modelled_kWh_in = sum(modelled_kWh_in_quadratic)) %>%
mutate(setback_saving_percent = modelled_kWh_in / htg_kWh_in - 1)
Yes I am seeing more and more unknown variables the closer I look and not only in the DHW cycle. I'm seeing OAT has a huge influence in converting colder air into heat made worse by 1. defrosting, 2. Protective reheats of pipe circuits, 3. antifreeze circulation at nights. Not withstanding the actual system being set up correctly in the first place.
Heat pump efficiency declines quite markedly with low OAT, thats just the thermodynamics at work. The datasheets set it all out if you are interested (Mitsubishi is very good at this). But at moderate or higher OATs they do much better than average. If you want compare a few points with Mitsubishis graphs, if you are way out your system needs looking at, if you are in the right ballpark then it should average out over the season.
Defrost makes it worse (but is generally included in the COP plots provided. This is of course humidity dependent.
Most heating systems, whether fossil fuel or Heat Pump, do protective circulation when its cold. This can either be controlled by the boiler/heatpump or separately wired. It makes sense given that heat pumps (and many boilers) are outside the heated envelope, freezing up is expensive and disruptive, and if its that cold you want to be heating anyway! In most cases heat pumps should be running 24x7 anyway when its cold enough for freezing to be a concern.
@scrchngwsl - very interesting, and very useful, to have an analysis done using a different approach that still nonetheless starts with the observed data, which as is well know is my preferred starting point.
I only have a very sketchy knowledge of R but I do have it installed (use it mostly for high quality charting) and will try running your code.
In the meantime, three quick comments:
(a) your basic idea, that energy in is a function of (IAT-OAT)^2 is interesting, and if correct, is extremely elegant! @jamespa is far better qualified than I to comment on this, and hopefully he will have something to say before too long
(b) I think you have decoded all the column headings correctly (will be able to double check when I run the code)
(c) I also exclude the hours that have DHW activity, as the python code allocates the the energy in in such a way that the DHW heating hours also get a space heating entry for the time during the hour when system has gone back to space heating, but of course it isn't a full hours worth of space heating (typically 30 mins or less) and it skews the data (and can be seen as outliers if you plot the data with those hours included). The DHW heating hours are infrequent, typically one a day, meaning excluding them shouldn't skew the data.
If your model does indeed show no meaningful saving with setbacks (and please do bear in mind I am perfectly happy to accept that conclusion if the method of getting to that conclusion makes sense. I am not, despite possible appearances, wedded to the idea that setbacks must save money, I just have the inconvenience of an analysis that suggests they do) then I hope we can reconcile the two different conclusions, ie explain the different results, and just as importantly, say why we accept the one that we do accept.
Midea 14kW (for now...) ASHP heating both building and DHW
@derek-m (and anyone else who wants it) - here is my December 2023 hour and minute data in csv format:
-- Attachment is not available --
So I did a quick model in R on the hourly data, and I found that the setback period used 1% less electricity than the model suggests would have been used if no setback was employed. I modelled htg_kWh_in as a function of (IAT-OAT)^2. The physics reasoning is as follows:
Heat_Out ~ (IAT-OAT)
Heat_In = Heat_Out / COP
COP ~ 1/(IAT-OAT)
=> Heat_In ~ Heat_Out * (IAT-OAT)
=> Heat_In ~ (IAT-OAT)^2
hence I modelled Heat_In ~ (IAT-OAT)^2
I corroborated this (manually, not included in the code below) by plotting and modelling the above variables - they do indeed all look linear, and the data supports the underlying physics reasoning. It also gave a reasonable R-squared during the "no setback" period of 0.89, which is good enough for me.
I removed the periods where the heat pump was doing hot water, then used the model trained on the "no setback" period and applied it to the (IAT-OAT) during the setback period. Then I compared the actual htg_kWh_in with the modelled htg_kWh_in. The actual usage was 1% lower than the modelled usage.
This is well within margin of error and frankly backs up the conclusion that it makes no meaningful difference whether you use a setback or not.
I don't know (as I haven't been following closely) whether I've used the right columns, but I looked at the data and made an educated guess. If I have not used the right columns let me know and I'll rerun it.
I also don't know whether it makes sense to remove the hours where the DHW was on, but I think it's fair either way as I'm removing it from both sides. In any event, including those periods makes no difference: it simply means that the actual usage is 0.5% HIGHER than the modelled usage. A 1.5% swing the other way.
Here is the R code if you want to replicate:
# midea hourly modelling
library(tidyverse)
midea_data_raw <- read_csv("midea_hr_data_dec_2023.csv")
# only include data from before setback enabled, and isn't doing DHW
# also add a column for IAT-OAT
midea_data_clean_nosetback <- midea_data_raw %>%
filter(dhw_kWh_out == 0,
datetime < "2023-12-16T00:01:01") %>%
mutate(IATmOAT = MD02_tmp - ambient)
# fit the model
lm_htg_in_quadratic <- lm(htg_kWh_in ~ I(IATmOAT^2), data = midea_data_clean_nosetback)
summary(lm_htg_in_quadratic)
# now let's look at the setback days
midea_data_clean_yessetback <- midea_data_raw %>%
filter(dhw_kWh_out == 0,
datetime >= "2023-12-16T00:01:01",
datetime < "2023-12-24T00:01:01") %>%
mutate(IATmOAT = MD02_tmp - ambient)
# apply the model to the setback period
modelled_htg_kWh_in_yessetback <- data.frame(
midea_data_clean_yessetback,
modelled_kWh_in_quadratic = predict(lm_htg_in_quadratic,
midea_data_clean_yessetback)
)
# compare actual with modelled kWh usage
modelled_htg_kWh_in_yessetback %>%
summarise(htg_kWh_in = sum(htg_kWh_in),
modelled_kWh_in = sum(modelled_kWh_in_quadratic)) %>%
mutate(setback_saving_percent = modelled_kWh_in / htg_kWh_in - 1)
I have not had time to look in detail at your calculations, but if I understand correctly, you could not achieve a 22.9% reduction in electrical energy in consumption, just a 1% reduction.
You issued philosophies and data for peer review, also indicating that quite large reductions in energy consumption can be achieved by utilising an overnight setback operating regime.
When I try to review your philosophies and data I find that to do so correctly I need further information, which I politely request. Rather than provide the missing information, you suggest I perform the same calculations that you performed to test your methodology, but to do so I find that I now need clarification of the data upon which you performed your calculations, which I again politely request.
Rather than provide the requested detail so that the necessary peer review can be performed, you suggest I use some unspecified data, with the caveat that any results I obtain would probably not be the same as your previous results.
I fail to see how this is peer review.
I also don't understand your reluctance to respond to perfectly valid requests for further information and/or clarification of information already supplied.
I think that if the data under the volts and amps columns are integers in the file provided by CR, it will be raw data without the 1.18 correction factor having been applied. I merely added an additional column and performed the V x I calculation.
