Request for brine temperature data from ground-source HeatPumpMonitor systems

Hardware Heatpump
1

Hello everyone,

I am a doctoral researcher using public HeatPumpMonitor data to validate thermodynamic heat pump models.

I am looking for ground- or water-source heat pump datasets that include source-side measurements, particularly:

  • brine/source-fluid inlet temperature;
  • brine/source-fluid outlet temperature; and
  • corresponding timestamps.

I am especially interested in the HeatPumpMonitor systems with IDs 11, 47, 66, 204, 267, 309, 513, 560, 571, 598, 724, 762 and 944. If you own or monitor one of these systems, or have another suitable ground-source dataset, and record these temperatures in EmonCMS or another platform, would you be willing to share them for academic research?

The measurements would be aligned with the already-public HeatPumpMonitor time series and used only for research, with appropriate acknowledgement and any required anonymisation.

Thank you very much.

2

Hi @mcolahi,

System ID #11 is my NIBE F1145 Ground-Source system. That’s logging data - including Brine Inlet and Outlet temperatures - to NIBE’s myUplink Cloud database and I pull instantaneous readings back to a local InfluxDB database every 2 minutes. I then push (some of) the readings to EmonCMS - from where they get picked up by the MyHeatpump App and hence by HeatpumpMonitor. For reasons I’ll explain below, my Brine temperature data in EmonCMS is rather ‘patchy’ - but I have the raw data points stored in InfluxDB.

I’d be willing to share my data for research purposes, if it would be useful to you.

The main complication I’ve encountered with my Brine temperature readings is that the temperature sensors are installed in the GSHP’s indoor unit, which is located in my Plant Room, which tends to be rather warm. Shortly after the Brine Circulation Pump starts running - which in my case is only when the Compressor starts running - the Brine temperature sensors report plausible values for Brine temperature. As soon as the Brine Circulation Pump stops, there is no longer any brine flow and the sensors quickly start reporting implausibly high brine temperatures as the indoor unit’s pipework heats up, due to the high ambient temperature (and the close proximity of the refrigeration circuit heat exchangers too, I presume).

My GSHP installation is roughly 10 years old and the NIBE F1145 pre-dates variable-speed compressor drive motors, so its compressor is only ever On or Off. It’s heating a Passivhaus building which has a low heat demand, so there’s typically only one compressor cycle every few hours. As a consequence, the Brine temperature sensor readings only reflect the actual Brine temperature for a small proportion of the time.

For example, here are the readings for a couple of days in early January (this plot is from Grafana, pointing at my InfluxDB):

image
image2694×1398 339 KB

In an attempt to exclude the misleading readings, I apply a ‘plausibility’ test before uploading the Brine temperatures to EmonCMS - but right now that’s just a crude “<15C?” check which could definitely be improved.

I presume other GSHP installations will face similar challenges. Those which do less cycling (due to a variable-speed compressor drive and / or a higher heat demand) will probably report accurate Brine Temperature readings for a greater proportion of the time - but maybe I’m jumping ahead and I should wait for such conclusions to be reported as research findings…

David

3

Hi David,

Thank you very much; I really appreciate this. This would be very useful for my research.

The issue you describe with the sensors during periods without brine flow is understandable. For the analysis, I would retain only periods when the compressor and brine circulation pump are operating and exclude the initial transient period after startup.

If possible, could you share the raw timestamped brine inlet and outlet temperatures, together with compressor or brine-pump status? Brine flow rate would also be helpful if it is recorded. The unfiltered InfluxDB data would be preferable, as I can apply and document the operating-period and stability filters consistently.

Could you also let me know the available date range, timestamp timezone and measurement units? I would align these data with the publicly available measurements for system ID 11.

Thank you again for offering to help.

Mohammad-Reza

4

Hi Mohammad-Reza,

That all sounds good. Once I refresh my memory of how best to extract the data from InfluxDB I’ll be in a position to share it with you. (I think I have a Jupyter notebook somewhere from last time I did this…)

From a quick check it seems I’ve got data going back to May 2017 (i.e. 9.5 years’ worth!) but I propose we start with 1 year, perhaps 2025-09-01 through 2026-08-31, and extend further back as required.

Over those years I have slightly adjusted the range of parameters I’ve been storing - for example I added “Operating Mode” (which indicates ‘Heating’ versus ‘Hot Water’ and confirms compressor on/off status) relatively recently. There was also a switch from the old NIBE Uplink cloud service to the newer myUplink but I don’t believe that had much of an impact on which parameters I was storing, and how they were represented in InfluxDB.

Please send me a Personal Message with details of where I should send / upload the data. We can then take any more detailed discussion about data transfer logistics offline from this thread.

Assuming I reproduce the data export mechanism I’ve used before, I propose to share CSV files with contents like this; would that be OK?

ISO8601Timestamp,BT10 Brine Incoming Temp (C)
...
2024-01-26T00:34:01.003536582Z,30.2
2024-01-26T00:36:01.152849138Z,30.2
2024-01-26T00:38:00.969952348Z,10.7
2024-01-26T00:40:01.130864592Z,6.7
2024-01-26T00:42:01.216882423Z,6.7
2024-01-26T00:44:01.077806794Z,6.7
...
2024-01-26T01:24:01.071165765Z,6.2
2024-01-26T01:26:01.009571905Z,6.2
2024-01-26T01:28:00.964893302Z,8.2
2024-01-26T01:30:01.082429761Z,9.2
...

(I know those timestamps are ridiculously over-precise but that’s how they come out of InfluxDB. via its API.)

All timestamps will be in UTC (as indicated by the ‘Z’ suffix) and the measurement units will be stated in parentheses in the column header (as per the “(C)” example above).

The NIBE controller reports some additional temperature readings for key points around the thermodynamic cycle which are not uploaded to EmonCMS; might those be of interest to you too, to help validate your thermodynamic models?
They are listed as:

  • Condenser Supply Line Temp
  • Hot Gas Temp
  • Fluid Pipe Temp
  • Suction Gas Temp

I’m inclined to also include the Heat Pump Flow and Return temperatures. Those are already on HeatpumpMonitor but in case there’s any issue with e.g. timestamps at the start and end of Daylight Savings Time it would not hurt to have directly-comparable data sets direct from InfluxDB.

David

5

Hi David,

Thank you very much. This sounds excellent, and starting with the period from 1 September 2025 to 31 August 2026 would be sufficient for the initial analysis.

The proposed CSV format, UTC timestamps and units in the column headers are all suitable. I will send you a personal message with the data-transfer details.

Thank you again for offering to share such a valuable dataset.

Best regards,
Mohammad-Reza