@PjH vaillant ASHP data can be collected via ebus. There is big ebus community out there that’s developed software and hardware to read from this. Google ebusd on GitHub.
Here is some of the data I read. I’m able to calculate the CoP using a combination of emon power consumption monitoring (emontx3) and yield data via ebus. It’s all logged into emon via MQTT.
3 Likes
Nice one @Zarch Pretty good experience here (in a Passivhaus) of a 3.5kW Arotherm+ system, other than the controls and reporting. Waiting on emontx reappearing in the shop to try and get better monitoring for next heating season. I just wish Vaillant would open up their API to users, as much of the information is captured and could be made available without additional CT clamps, flow temp monitors etc. There are modbus/ebus possibilities (thanks @modeller ), but it is hard work for non-techs like me. At least you were sensible and got a heat meter included in the specification!
2 Likes
Thanks for the example @MyForest and for raising this with a bit more prominence.
Yes a good point.
Definitely a complex question!
1 Like
That’s my concern with Smart Meters. OK, so all the data securely encrypted. Unfortunately, a lot of organisations have believed that to be the case with their customers’ data, and found to their and their customers’ cost that they were wrong.
1 Like
That’s great @modeller, what kind of resolution is the data via ebus? can you poll every 10s and receive new data?
Thanks for raising the privacy issue @MyForest, it’s a tricky one. Do you think the privacy concerns are at all reduced for heat pump data relative to solar PV/electricity consumption, or pretty much exactly the same? Occupancy is (or can be) less directly obvious if heating is on fairly continuously, although it’s still clear when you’re having a two week holiday.
Different people will have different comfort levels of course but a platform would need to either offer different options or have some (probably relatively conservative) policy.
@TrystanLea’s profile explorer potentially gets around this, but that may also indicate if you are always out at a certain time of day!
1 Like
On the bright side, heating is pretty coarse.
I know from friends who do electricity consumption analysis that they can tell if you are using a toaster or a hoover from the power profile.
For heating it’s pretty going to be just “the occupants are there”, or in the worst case “we can tell the kids are back from Uni because the heating is on more at night”.
I’m torn between the drive to share as much as possible to allow others to do their own analysis and the inevitable problem of sharing so much that random people can tell what you are doing (or worse yet, they simply run a bot against all shared data and ask “who isn’t at home tonight?”)
Setting permissions on the data does seem to make sense, but then I have to try and guess if I can trust you and that is hard with the looseness of this forum for example.
1 Like
Without the context the data is almost useless. With a gas boiler everything is effectively just blasted with power and the only real variable is is it on or off. but a heat pump has to be used in a more subtle way if it is to be beneficial. Context is vital but security is also important. It must be possible to de-localise a system description to keep security intact while keeping an amount of localisation to enable local weather effects to be considered. probably a role for this forum here in enabling checks for authenticity. eg is this data from a trusted source. once out in the known world there will be a queue of people wanting to submit bad data to suit their own agenda or just because they can.
Note this is not a reason to can the project. its a good useful idea which I will be happy to contribute to. (circa 1935 solid wall house with air source heat pump solar PV and Tesla power wall in the midlands)
2 Likes
I feel that as long as the data is sufficiently anonymised, then most people will be happy for their data to be shared. By this I mean included in a comparitive set of “similar heating systems near to your location”, or a broader analysis of heat pump performance.
We need to consider why we’d collect data about heat pumps. If we’re simplying sharing our own experiences, then curated / annotated screenshots with accompanying context are probably more useful. There are many examples of these on this forum, which have been great talking points.
IMHO, the real benefit of collecting data from many systems is to provide an overall picture of heat pumps: how well do they perform in general? how about certain types of property? underfloor vs. radiators? Seeing individual systems by themselves (without context) doesn’t seem nearly as useful.
I remember listening to a @BetaTeach podcast titled “How Well do Heat Pumps Perform - looking at the OFGEM data” discussing the results from this report [PDF] ← this episode / report seems somewhat relevant to this discussion.
What really struck me is that the researchers had “a dataset containing anonymised information from over 2,200 domestic heat pump installations was obtained from Ofgem”, yet they had to discard about 3/4 of that dataset, analysing the performance just 598 ASHP installs.
So, one question to ask is: what would an ‘open heat pump dataset’ driven by the community be able to show that other, official datasets (e.g. MMSP) haven’t? What data analysis / pruning would be needed to be done in order to extract something useful from it? How can this be done automatically?
1 Like
Just getting to this, apologies - thank you @TrystanLea for initiating and for the work on public dashboards. Timely for me as a few villagers will be showcasing heatpump installs at a local energy fair in Buckinghamshire at the end of the month, so this will serve as a nice real-time demonstration.
I would support @Timbones latest comments - and I would be very happy to contribute to a detailed public dataset assuming location/identity is sufficiently fuzzed (had wanted to contribute to the MMSP, but our installer declined to participate sadly). That said, would be keen to explore how/what/why this could be contributed effectively and what aspects we would want to build in to maintain a reasonable level of data quality. Weather Underground springs to mind.
I’m very happy with the OEM data coming off our Midea system and Sontex meter installed in January - which has proven essential in optimising and diagnosing some early teething issues. I’m not particularly confident in my COP calculations but will continue to work on this!
1 Like
They threw out alot of data, but its not surprising considering some of the installs included in the larger dataset.
Heat pumps with compensation forced OFF and a static flow temp set so installers don’t get callbacks… @BetaTeach will be spinning in his chair.
Heat pump performance monitoring becomes alot more valuable when we have measured heat loss data from the place where its installed, either before or after!
That’s exactly what my installer did! I’d turned on weather compensation before they’d commissioned it.
Yes, in a way, more useful perhaps than a lot of detailed data might be a series of written case study type documents in a searchable format. Each document or case study web page might have the following details:
- Heat loss rate of the building in W/K
- Space heating demand in kWh/m2.year
- Approximate location
- Heat requirement of each room at design temp and heat output of heat emitters at design flow temp.
- Type of emitters, under floor heating, radiators, fan assisted radiators .
- Number of zones
- How zones are used in the control strategy
- Type of controls, thermostats, locations etc.
- With or without buffer or low loss header
- Central heating pump models
- Hot water control strategy
- Legionella protection settings
- Heat pump model
Then in terms of data it could be in increasing levels of detail.
Level 1: Annual electric consumption and heat output if available
Level 2: Monthly electric consumption and heat output, (outside temperature available via weather underground perhaps).
Level 3: Monthly disaggregated into Space heating, Water heating and standby
Level 4: As level 3 but with internal temperatures (that would match my analysis here Trystan Lea)
Level 5: Average daily profiles
Level 6: Detailed data with or without data restrictions
Perhaps the way to prototype this would be to build this as a series of forum posts to start with rather than spend time trying to make a nice website? I should try to make a single contextual page for my heat pump…
Here’s a quick go at a one page format that could perhaps be built into some kind of searchable and sortable database?
An EcoDan ASHP case study
- Building heat loss rate: 205 W/K (SAP assessment), 173 - 192 W/K based on monitoring.
- Space heating demand: 111 kWh/m2 (SAP assessment)
- Space heating demand: 8558 kWh (SAP assessment)
- Floor area: 77m2
- Approximate location: North Wales, UK
- Heat loss at design temp: 4.5kW (8866 kWh) (revised down since first assessment)
- Design temp: -3C
- Heat output of radiators: 4.5kW (@40C Mean Water Temperature)
- Type of emitters: Standard K2 radiators
- Number of zones: 1
- Type of controls: Single thermostat and manual flow temperature control, typically flow temp set to 32C but increased to 34C or 36C if house is not warming up fast enough. Thermostat turns heat pump off at target temperature.
- Buffer or low loss header: No
- Central heating pump model: Wilo Pico
- Hot water control strategy: Two daily heat up cycles one at 4am, the other at 2pm, heating typically to 42C tank temperature.
- Legionella protection frequency: 2 weeks (>50C, sometimes 60C).
- Heat pump model: Mitsubushi EcoDan 5kW (heat) r410a
Room by room heat loss detail:
| Room | Heat loss | Heat output | Configuration |
|---|---|---|---|
| Livingroom & Diningroom | 1179W | 1956W | 3x 1200x600 K2’s |
| Hall | 370W | 652W | 1x 1200x600 K2’s |
| Kitchen | 771W | 0W | heat from livingroom |
| Bed 1 | 473W | 557W | 1x 1200x500 K2 |
| Bed 2 | 515W | 557W | 1x 1200x500 K2 |
| Bed 3 | 274W | 387W | 1x 1000x400 K2 |
| Landing | 158W | 0W | heat from hall drifts upstairs |
| Bathroom | 773W | 435W | heat from hall and other rooms drifts upstairs |
| Total | 4513W | 4544W |
Full calculation example: https://openenergymonitor.org/heatlossjs/
Monitoring: Class 1 electricity metering of outside unit, inside controller, central heating pump and 3 way valve with an SDM120, Class 2 heat metering with Sontex 440. CT sensor on the immersion heater.
Level 1:
| Year | Electric consumption | Heat output | COP |
|---|---|---|---|
| 2020 | 1946 kWh | 7615 kWh | 3.91 |
| 2021 | 2378 kWh | 9643 kWh | 4.04 |
Level 2,3 4:
Profiles shared above & detailed data Emoncms - app view dashboard
System diagram:
Is there anything else that would be good to add?
1 Like
That seems to be pretty comprehensive. I think you need both the
overview and have the possibility of drilling down into the details.
Personally i am pretty relaxed about usage as I am here all the time but
it could be an issue for some.
perhaps we need a way to completely anonymise inputs in a way that
protects the user supplying the data. after all from a data viewpoint
what is needed is a way to weed out spurious inputs from bad actors
trying to game the system.
Regards
Nigel
1 Like
Thanks, @TrystanLea, the draft outline looks very solid - we could easily contribute in line with this format.
Few questions/thoughts:
-
Number of Zones: Under Type of Emitter, assume this could be per Zone, in cases with two or more Zones with multiple emitter types i.e. UFH and Radiators
-
Buffer/Low Loss Header: Could we indicate whether there is hydraulic separation and if so type, e.g. None, Buffer, Low Loss Header, Plate Heat Exchanger, Other etc? (With more installers putting plate heat exchangers in (in our case, upside down!), it might be helpful to understand these characteristics given the heat loss between the types of devices used.
-
Age Installation/Commissioning month? Although the consumption data by year also gives an approximation. Not sure if participants would want this fuzzed. It would be interesting to track performance against system age.
-
DHW & Plumbing characteristics: Not sure to what extent the details in the diagram would also be represented in this taxonomy (nice diagram btw) - the Cylinder and Plumbing characteristics would be interesting (we inherited a system that was plumbed with 50% combination of unlagged Polypipe
and new lagged copper - or would this be superfluous due to overall heat loss values already stated?
I’ll throw my data into the ring too then - here’s my EcoDan 11kW ASHP heating a 1960s house somewhere in Yorkshire. Mediocre insulation with radiators.
That sounds like a useful option to have, yeah.
2 Likes
Great thanks @Timbones! good to see! Can you remind me what your using for electric and heat monitoring?
Glyn has uploaded his yesterday too: https://emoncms.org/samsung5kw
I have the official MMSP package from Mitsubishi (includes Sontex 440) which is reporting directly to the EcoDan FTC. I then scrape the energy values from MELCloud every minute into emoncms. Didn’t buy an emonPi, sorry.
1 Like