HeatpumpMonitor.org

HeatpumpMonitor.org is a great initiative to counter the view from some quarters that ‘heat pumps don’t work in normal buildings’ with research and facts. It shows a dashboard of real-world performance data from a modest but ever-increasing list of heat pump installations.

Currently, all the systems listed are in the United Kingdom and most are Air Source Heat Pumps in Retrofit (rather than New-Build) installations – but a recent addition is a certain new-build with a Ground Source Heat Pump.

HeatmpumpMonitor is built on top of emoncms (which I’d be using for internal temperature and humidity monitoring if I hadn’t already gone down the OregonScientific route) and links out to emoncms.org for further detail on each of the installations.

HeatpumpMonitor.org dashboard as of 2022-12-17, sorted by “30 Day COP”

For people already capturing data using a local emoncms installation (such as might run on an emonPi) it’s a simple configuration process to forward that to emoncms.org and publish to the dashboard. Since I’m not using a local emoncms, I run a script (every 2 minutes) to extract the relevant updates from my local InfluxDB database and push those to the emoncms.org API.

Normally, emoncms.org is a chargeable service but the nice folks who run that very kindly waived the fee for inclusion in this dashboard.

Revised immerSUN Monitoring

I have re-worked the monitoring solution for the immerSUN solar PV diverter which is responsible for measuring the house’s electricity consumption, the import of electricity from the grid, the solar PV generation and any diversion of excess solar generation to the domestic hot water cylinder’s immersion heater.

Previously the monitoring was done by extracting data from the live.myimmersun.com webpage every minute and storing it in InfluxDB for visualization using Grafana. This worked OK but missed a lot of the details of how the readings change on a more dynamic basis. The immerSUN unit actually sends data in the form of a 56-byte UDP Datagram every 5 seconds and since this data is traversing the local network anyway it seems a shame not to extract the readings “on the way past”. While not trivial, since the format of the 56-byte Datagram is not published, it’s not that hard to reverse engineer where the different readings are.

There’s a (draft) write-up of the solution under the Technical Articles here.