Another carrot, which I had hoped to include in yesterday's post, but ran out of time, having lost four hours in the morning to the power cut.

One of the things I like is pleasing charts. Interactive charts that have scrolling, zooming, getting a data point value on mouse-over, and even better, live charts that update in real time as the data changes, are even better. HA's History Explorer card does most of this, and you have some control over formatting, but it is all rather proprietary. Maybe there are ways to do similar charts outside HA?

Indeed there are. Using something called Highcharts JS, free for personal use, I can plot any data I want to chart from my csv files. Highcharts JS has a lot of charting options, and the formatting is done using CSS (the standard web page formatting code) meaning I can change the appearance of anything in the chart at will. Again just as proof of concept, here is the minute by minute ambient temperature collected over modbus for the last ten days or so. That's over 15,000 data points, and most charting software would struggle to render that amount of data, but HighchartsJS has a way of knocking such large quantities of data into shape. The step-wise appearance is an artefact caused by the fact the Midea wired controller reports ambient temperature as a whole number, with no decimal places:  

Although this is running on the HA operating system (because I can't be bothered to change it to something else at the moment), getting that chart has not made any use of HA at all. Instead, it relies on the python scripts to get the data over modbus from the wired controller and into the csv files, and then uses Highcharts JS to plot the data from those csv files. It is simple, efficient and robust, not words that normally spring to mind when working with HA.   

Hi, this is very interesting. Im just putting in my Samsung Heat Pump and saw that there was a module I could add to the PCB to give modbus communication. I havent come across it before but my Python is pretty reasonable. I havent gone with the module yet as reports said it was pretty inaccurate for COP, so I have added a heat meter to use with my emonpi system, which incidentally is very good.

Ive also just have a Huawei solar and battery system installed and again the inverter has a modbus com port so i can see I will need to get into this pretty soon.

I think I may have tried HA in the past but cant really remember it, the last home automation system I used was Domotictz in my last house.

Thanks Mark

@bontwoody I put in the samsung modbus on day 1.  my objective is to be able to take control of LWT, once I've got the system where I want it - the modbus has Write as well as Read capability. not done that yet though. From day 1 I've used the modbus to monitor flow rate, LWT and RWT, and compressor frequency. they give very good clues about when the system isn't working right (they told me I had a not-enough-emitters-open issue straight away for example). I only have 1 week of data so not enough long term data yet to say if the COP calculated from the modbus meter's numbers are fully accurate or not, but they don't seem too far out so far.  the temps appear accurate compared to my DS18B20 probes. where did you here that it was inaccurate? although I have been wrestling with finding a suitable statistical approach to how to reliably calculate COP, I had no issues getting modbus working with an ESPHOME though HA. 

@iancalderbank Hi Ian, Ive been reading a lot of the work of Glyn Hudson at Open Energy Monitor. He has done quite a lot with monitoring his Samsung using modbus and the OEM system and is very approachable. He thinks the Samsung is as much as 30% out due largely to its poor temperature sensing. Here are some of his articles. Worth a read.

https://community.openenergymonitor.org/t/samsung-air-source-heat-pump-installation-with-monitoring/21254

https://github.com/glynhudson/samsung-modbus-mim-b19n

Posted by: @iancalderbank

↑

I had no issues getting modbus working with an ESPHOME though HA

Probably because you are already an expert in these things! Remember, this is a beginner's guide. Beginner doesn't mean stupid, obviously, but it does mean lack of familiarity. What is obvious to a doctor might not be at all obvious to an engineer, and vice versa. Neither are stupid, and both have a scientific background, they are just not familiar with the other field. My premise is that I am not stupid, but I am a beginner in this monitoring game, and I found HA over-complex, more possessed of jargon than medicine itself, poorly documented and held back by a zombie forum where the un-dead unanswered threads vastly outnumber the useful ones. That doesn't mean a non-beginner can't do excellent things with HA, but hand on heart, I can't recommend it to beginners when there are other far simpler more reliable ways of achieving the same result, and more. Using Highcharts JS charting for example is vastly superior to HA's rather feeble native charting, and is even an improvement on the very good third party History Explorer card that can be added to HA.

Another big problem with HA is that although it tries to keep historical data previously collected in real time, it will not accept historical data at a later date. When your database goes tits up, its tits up forever. Even if you manage to recover the data, HA will not allow you to add it to its new database. Doing so just corrupts the database yet again. [technical note: I stuck with the sqlite database, normally a perfectly reliable yet lightweight database, the other database options, which get increasingly complicated and decidedly too complicated for beginners, might by some sql voodoo manage it, but such voodoo is not for beginners, as in put beginners and voodoo together - what could possibly go wrong?]    

Posted by: @iancalderbank

↑

I have been wrestling with finding a suitable statistical approach to how to reliably calculate COP

I don't think that particular bit of the whole is that difficult. The basic statistic is energy out divided by energy in over a period of time. There are two ways of getting energy in and energy out, at least there are on Midea units and I wouldn't be surprised if the same applies to other heat pumps. The first is to calculate each from fundamentals, energy in is amps x volts, energy out is flow rate x specific heat of circulating fluid x (LWT - RWT). The second, simpler way is to have a tally of total lifetime energy in and out readings, and subtract the reading a period ago from the current reading to get energy in/out over that period. In each case, the from fundamentals method and from the lifetime totals method, the actual data can come from either the manufacturer's inbuilt sensors (subject to compressorgate/marking their own homework errors) or independent added sensors (much better data, but expensive and in some cases tricky to set up).

Once you have the data, however obtained, all you need to do is decide what period you want to use (hour, day, week, month, year) and the divide the energy out for that period by the energy in for that period, and that is it. It is almost back of the envelope maths. Whatever period you choose, the value you get will I think I can say reasonably confidently will be the mean for that period. I don't think it (COP) needs any more complicated statistics. The problems are not with the sums, but the sensors, which may or may not provide valid and reliable data.  

The problem I have at the moment is that the energy in figures from the different sources/methods don't agree with each other. Sometimes the variation is trivial (say 1-2%) sometimes it is not (>10%). I will go into greater detail when I have more data.        

Posted by: @bontwoody

↑

He thinks the Samsung is as much as 30% out due largely to its poor temperature sensing. Here are some of his articles.

Ho hum. Interesting. Here's a quote from one of his posts:

However, Samsung does a very poor job of measuring heat output. At least on my system, the heat output displayed by Samsung is 30% less than my heat meter. I think this is party down to Samsung assuming glycol is used (I’m not using glycol) and party due to the Samsung temperature underreporting the temperature of the flow/return. Samsung’s temperature measurements are about 1° C below what my MID approved heat meter and my own digital DS18B20 sensors report. 1° C equates to about 1kW difference at a flow rate of 16.5L/min e.g yesterday Samsung reported 33kWh of heat while the heat meter reported 50.7kWh.

The result of this is that in December Samsung reported a COP of 2.9 while my MID approved heat and electricity meters reported a COP of 3.9.

Interestingly, this is the opposite of compressorgate. Here it seems Samsung are down-marking their own homework, a rather curious thing to do. 

I do have an external third party energy in meter for my Midea heat pump, and can use that as a check against Midea's own energy in estimates, but I don't have third party energy out sensors at present. I can, and may well, add LWT and RWT temp sensors, but the much trickier and more expensive problem is how to get flow rate. Even if I get a sensor, it is not obvious where to put it. The accessible pipe runs are short and complicated by multiple bends.      

I can see how (rather surprisingly, because it seems a small difference) "1° C equates to about 1kW difference at a flow rate of 16.5L/min" works:

16.5/60 (to get L/s) x 4.2 (Sp ht water) x 5 (delta t) = 5.775kWh

16.5/60 (to get L/s) x 4.2 (Sp ht water) x 4 (delta t with LWT 1 degree lower) = 4.62kWh

but Hudson reports that both sensors are under-read ("Samsung temperature underreporting the temperature of the flow/return"), in which case, the delta t will remain the same - but it doesn't, according to a chart later in the post, which shows the Samsung delta t to be varably around 0.5 degrees lower than the third party monitor delta t values.

Glycol assumptions may indeed also be important, but less so: 

16.5/60 (to get L/s) x 4.2 (Sp ht water) x 5 (delta t) = 5.775kWh

16.5/60 (to get L/s) x 3.9 (Sp ht water + 20% glycol) x 5 (delta t) = 5.363kWh

The main anomaly I have at the moment is that the calculated (using Midea reported amps x volts) energy in is significantly less than that derived from lifetime energy in now minus previous value subtraction, giving higher (and not very credible) COPs in the 4 plus range. Perhaps I should just bin them. 

I don't think any of us have definitely got to the bottom of this yet.

@cathoderay I hadnt actually looked in depth at the graph you mention when I read the article and comments

https://community.openenergymonitor.org/t/samsung-air-source-heat-pump-installation-with-monitoring/21254/6

The heat meter and additional DS18B20 temperature sensors look to agree very well, so I would certainly tend to believe them over the integral samsung ones. There is also a curious 5 minute time shift in the data, with the samsung lagging behind the other two. I cant think of an explanation for that.

It would be nice to see the actual input and output temperatures rather than just the DT.

@bontwoody

I very much doubt that the information provided by any heat pump system will be 100% accurate, and even additional equipment installed to measure the various parameters, may be more accurate, but will not be 100% accurate.

The above is still true of industrial measurement systems costing thousands of pounds.

Measuring instruments were developed because humans wished to know what was happening within a process, both at that instant in time, but also over a period of time. Years ago measurements would be recorded in tables, that would be kept for analysis, or even just for reference should a problem arise. With the advent of digital computers this process has been automated when necessary.

There are occasions when accuracy is required, since I don't now of many people who would be too happy if they received a speeding fine, for travelling at 35 mph in a 30 mph zone, but there speedometer clearly stated that they were only travelling at 30 mph. I believe that car speedometers are set to read high, to avoid the above from happening.

Accurately measuring the COP of a heat pump system involves overcoming quite an number of problems. Installing sufficiently accurate sensors, in the correct location, and in the correct manner, to measure the variable in a consistent and reliable manner. Sensors installed at one end of a long pipe run could provide different readings if installed at the other end, because mixing is taking place within the pipe. Sensors in actual contact with the liquid, or in suitable packets, are likely to provide more accurate and more responsive readings, than those attached externally to the pipework, particularly if they are not adequately insulated if this is necessary.

The electronics measuring the sensor may not have been adequately calibrated, and may be susceptible to ambient temperature variations, particularly if located outdoors.

How the measurements are converted and presented can also affect the accuracy of the displayed reading. If the data is only displayed as integers, then there will already be a rounding error, which could be quite high in percentage terms. Consider the following:-

The true LWT is 47.49C, but is rounded down to 47C. The true RWT is 41.5C, but is rounded up to 42C. The indicated DT is 5C, but the actual DT is 5.99C, the calculated DT is therefore over 16.5% lower than the true value.

But all is not lost.

Whilst accuracy is important, repeatability and precision are more important. If it is known that a particular measurement always reads 1% high, then that error can be accommodated within any calculations. Readings, if available, to at least one decimal place should be used in preference to integers.

Trends obtained from the above can therefore be used in the optimisation of a system, by making an adjustment and monitoring the effect, it should be possible to improve the overall system efficiency. The fact that the indicated values are not 100% accurate is not of prime importance.

A further benefit of monitoring trends, is that they may highlight a deterioration in performance over time, which could indicate the need for some form of maintenance being required.

@cathoderay can we please just agree to disagree over HA? I was purely responding to @bontwoody  query regarding future use of modbus and previous use of HA. 

yes, COP is simply energy out/energy in. yes, energy out is simply flow rate * DT * heat capacity. But what are flow rate and DT and how do you measure them and how often do you calculate energy out? On my system, measuring the flow and return temp and flow rate for a week with modbus, what is noticeable is that they are not steady.  the reported temps frequently vary by .1 or .2C within the space of a minute , when the system is in theory in a steady state., if they move in opposite directions, that affects DT by 10 or 20% and thus the energy out by the same.  Also, the flow rate is measured at a point in my system that (at typical flow rates) is about 60 seconds behind / 120 seconds ahead of where the temps are measured. If I calculate energy out every (say) 30 seconds, using the flow rate and DT values measured during that interval,  I get a lot of spikiness in that value. But the flow rate and DT do need to be measured for "the same" time interval (for some suitable definition of "the same")  - you can't simply do "average DT over 30 mins times average flow rate over 30 mins" that result isn't valid either as the power output almost certainly will have varied during that time. running the 30second-sampled numbers through is giving me a very spiky and pointless COP. here's an example from a period of running when the temps look completely stable if you look at it zoomed out, but when zoomed in , with power out calculated on the 30s temp and flow values, power out appears to be varying by 20% - which I doubt it is - all due to those tiny .1C variations in the temperature that are e reported  

So my point about a statistical approach is that I think some averaging or other type of smoothing of the data is needed and how best to do that - most importantly, over what time period - is my question mark.

 @bontwoody I haven't yet put DS18B20's in a place where they can check on the F+R temps reported by the samsung outdoor unit over modbus. I won't be able to  replicate as install inside the unit is unlikely to be feasible (but I'll have a look)- but will try to get them somewhere close. I suspect what I will do next is try to really accurately calibrate 2 or even 4 or 6 DS18B20's (using ice and boiling water) and then put them on the F+R pipes just inside the house. I may go out and get a couple of in-flow temperature pockets. So I don't have enough numbers to firmly agree or disagree yet with glen's comments about samsung reading low.

@derek-m you're right, trends are very important and can sometimes be shown without getting high precision. But, if you are starting from an unknown point - you don't know if the system is running at a COP of 2.0, 3.0 or 4.0 - and the data you are getting has given you all those values at times - then precision is important.  I don't know the right answer here. 

Posted by: @iancalderbank

↑

can we please just agree to disagree over HA?

Of course we can! I even said right at the beginning that for some people HA will be 'just the thing'. It is also good that you are putting forward the case for HA. But I also want beginners to be very aware that, for the reasons given here and previously, in my opinion it is not the way to go unless you have infinite reserves of time, energy and hair to pull out.

The COP maths for calculated energy in/out may indeed turn out to be complicated. I'm still trying to get my head round it, and like you I have only got a short run of data so far. I agree about the general spikiness of much of the data, and the potential importance of the time interval between data points. We can see that crudely by, for example taking the case of hourly measurements. Let's say that at 1300 the amps in is 4, and by coincidence it is also 4 at 1400. But that misses out the fact that between 1215 and 1245 it was 8 amps for whatever reason, perhaps because it was heating the DHW over that period.  

Perhaps it'll be some sort of area under the curve type thing. Let's consider amps in again. Lets says we have the above hour's again, but this time we have data every minute, and that is enough to capture the ups and downs. For the example above, we now have 30 mins at 4 amps and 30 mins at 8 amps. Is the average, 6 amps, an accurate way of quantifying the amps in over that hour, to do hourly COP calculations? Or do we have to do the calculation for every minute?

But that is a simple case, our data is more irregular. I think the right time interval will probably be the interval that captures the peaks and troughs. We can probably determine this empirically, by setting different time intervals for the data collection (single number change in my python script) and finding the longest interval that doesn't miss the peaks and troughs.

Meanwhile, here is another Highcharts JS chart showing hourly ambient outdoor and indoor temperature over the last six months (heating turned on 1st Oct 2022). The target indoor kitchen temp is 19 degrees, and the chart shows that most of the time the heat pump can achieve this, but in colder spells it can't quite cope (CQC). These are the times when I may need to program in a 'load balancing' adjustment into my weather comp curve. The good thing about  Highcharts JS is that once you have got your head around the code used, mostly javascript but also some CSS, the charts are easily edited to display almost anything. 

PS for AOC (area under the curve) calculations, I have a worrying suspicion I might be talking about this sort of mumbo jumbo:

https://en.wikipedia.org/wiki/Riemann_sum         

Hopefully though we won't have to deal with periods of negative energy input suggested by the wikipedia image that gets pulled in for the link.

@derek-m lol, no measuring system is 100% accurate, quite apart from the limits of the equipment we could talk about quantum effects too 😆.

I guess accurately calibrated sensors, positioned appropriately with best contact to the medium possible and short measurement periods is the best we will manage. I think at the end of the day all most people are worried about is, is the system working efficiently?