the inlet (return) is not far off either
Really good stuff guys - thanks for all the effort you are putting in!
My system is currently running and I’m seeing a 2C difference between R2T and R1T. I’ll try the off/constant flow experiment later when I don’t have guests
It’s one thing to calibrate and offset the values for our monitoring, but what if one of the thermistors misread? Presumably that would affect the heat pump trying to hit a specific delta T?
I wonder if there would be any merit in lowering delta T to 4C?
Eventually, my heat pump does get to a delta T of 5C, but I think I am going to turn down or switch off the Madoka modulation. I’ve got a 2C setback from 10pm to 5:30am and I think the Madoka pushes quite hard first thing to bring the system up, then as the thermostat target temperature approaches it lowers the LWT target, which means the pump hits minimum output and I get poor COP until it stabilises.
PS: I was awake early and applied some LWT offsets in ONECTA to see what affect they had…
That’s a good question! Without any supporting documentation (thanks Daikin!) and no access to the code (!), we can’t know exactly what the HP is doing and why, but from observation:
- it clearly uses R2T as the LWT value in the internal BUH case (my R1T/R2T are sufficiently different to see this in the MMI)
- it uses R4T as the return value
Three things occur to me in respect of the calculation of dT and HP output into the building:
- My R2T/R4T appear to have a 0.5C difference when at the same temperature… so yes, it would affect the resulting actual dT anyway. If target dT is 5C, then that’s quite a difference!
- I’m not convinced it uses R2T in the BUH case as the value from which it calculates dT, although the picture is muddied by my 4C overshoot setting and the fact that my system doesn’t absorb enough heat at the current flow temps for the return to drop to the right value. It’s not unlikely that the BUH/no BUH cases are not handled correctly in the firmware though
- If the thermistors were sufficiently inaccurate, then although the dT could be right, the actual flow temp would be quite different from the intended flow temp, with a resulting different rad/room dT and thus output - given the bigger values, I think this would be unlikely, as the sensors would have to be wildly out of spec, together, a matched sh*t pair if you like
I guess the manufacturer has a target specification/performance, and presumably can achieve that with sensors of a certain %age variation. I guess. I’m still waiting for my reply from Daikin on these questions!
@tiger_cook I took a slightly different approach of clamping the delta T to zero, to avoid negative heat flow readings.
I’m curious about your 80W threshold.
I see my pump draw up to ~190W when not heating but pumping at 27-30 litres per minute.
Have you got the pump speed restricted? Or just really low resistance pipe work?!
Edit: to be clear, I see the negative heat / COP when the circulation pump is running, but the compressor is not
Hi @squarepeg77
This post over here might be useful. I covered the pump limitation when sampling - 60 % parameter and value in these threads:
And here:
Hi @squarepeg77 I have an 8kW unit, no restrictions, but great flow with little resistance, when the HP is idle it consumes 10-14W, when the circulation pump is operating it uses ~45-60W (25+l/min), so I set a value above this ‘80’ to determine that the unit was actually heating, hope this helps?
I still get a negative COP value during initial startup but no huge peaks of uber efficiency, trying to figure out a way to ignore negative values within the HA template
before I changed the template >100 COP
after, still small negative values, also looking into setting a peak max calculation…
I have an 8kW unit, no restrictions, but great flow with little resistance, when the HP is idle it consumes 10-14W, when the circulation pump is operating it uses ~45-60W (25+l/min), so I set a value above this ‘80’ to determine that the unit was actually heating, hope this helps?
Yes, thank you.
Lucky you with the 8kW! I was initially offered 9kW, then the Octopus design team downgraded it to 8kW, then a re-survey “found” a gas fire / chimney that tipped the heat loss over the threshold and we were back to a 9kW unit. If I knew then what I know now, I’d have pushed for the 8kW unit. C’est la vie.
I think, I nailed it, it’s a bit crude -
I created another template that listens to the original COP sensor template,
If the new ‘cop_true’ template value is in between 0 and 8 that listens to the original COP sensor, log value, otherwise log 0 (no negative or uber efficiency values).
I hope this makes sense. Thoughts on my cowboy approach welcome
- name: "cop_true"
unique_id: "cop_true"
unit_of_measurement: 'COP'
state: >
{% set cop_true = (states('sensor.cop_power') | float ) | int %}
{% if cop_true >= 0.001 and cop_true <= 9 %}
{{ states('sensor.cop_power') }}
{% else %}
{{ 0 }}
{% endif %}
attributes:
minute_counter: "{{ now().minute }}"
I’ve got my ESPAltherma uploading to emoncms via Home Assitant and worked through the MyHeatPump app configuration.
Thanks for the instructions @Stephen_Crown!
One gotcha I had: I needed to restart Home Assistant after changing configuration.yaml to get more data to appear as inputs on emoncms, a quick YAML reload was not sufficient.
It’s published on heatpumpmonitor as the Daikin 9kW in Hertfordshire:
https://heatpumpmonitor.org/system/view?id=120
@Stephen_Crown do we need two separate feeds indicate heating and hot water? I’m getting hot water marked okay, but my “Heat output” is zero
Don’t want to be too much of a downer here but are you noticing the heat pump turning off and on regularly (blue light in hall will be on and off intermittently instead of just on all day).
From your data you may want to try reducing the temperature on the weather compensation curve or like a good few of us here with Octopus installs you may have an oversized pump.
Oh yeah, the heat pump is probably oversized and/or my radiators aren’t big enough. The reason I’m on this forum is to learn and to try and debug and improve it!
Today has been a bit of a mess and the performance shows it. I’ve been fiddling with radiator lock shields and adjusting modulation and the WD curve.
I’m using room thermostat (Madoka) control and have previously seen the heat pump more than 1C above the room target temperature. Today when I switched the modulation off, I saw shut downs before the room temperature had been reached and I don’t think the overshoot target of 4C had been reached. I’ve restored some settings and will try and leave things alone tomorrow
Edit: with my current observations, I actually think that I need a slightly higher WD curve. I think the heat pump spends too long trying to drive down the return temperature, before eventually settling and achieving 5C dT. My system doesn’t seem to (like to) produce return water less than about 32C - it’s radiators with a volumiser. I’ve been wondering if some radiators are open too much and letting some warm water return.
If you are on Facebook you may want to join heat pumps UK and look up Paul Spence, the attached is his guide to calculating DT based on room and radiator size (but you need an accurate heat loss for it to work). If you have not already try using heatpunk to estimate your heat loss.
If you need any advice on this I have a spreadsheet I can share
Hi @Stephen_Crown I have modified the templates to correct the log errors I was seeing -
Entity sensor.water_pressure (<class ‘homeassistant.components.template.sensor.SensorTemplate’>) is using native unit of measurement ‘None’ which is not a valid unit for the device class (‘temperature’) it is using; expected one of [‘°C’, ‘°F’, ‘K’]; Please update your configuration if your entity is manually configured, otherwise create a bug report at Issues · home-assistant/core · GitHub
- name: "Pressure"
unique_id: "Pressure"
unit_of_measurement: 'bar'
device_class: pressure
state_class: measurement
state: >
{{ state_attr('sensor.esp_altherma', 'Pressure')/10 }}
- name: "Water Pressure"
unique_id: "Water Pressure"
device_class: pressure
unit_of_measurement: 'bar'
state_class: measurement
state: >
{{ state_attr('sensor.esp_altherma', 'Water pressure') }}
hi @squarepeg77 I started this thread to dial in the daikin system, could you post your configurations to compare and build on the knowledge base? Hope it helps…
ps i changed the modulation from 2 to 4 last night, and that appears to help a little, however its been tricky lately as the outside temps have not really dropped enough to see any differences and I think I am at a point of diminishing returns.
@tiger_cook Noted. I have added a note in my post for now about this, and will update the files and post properly when I get a chance. Cheers!
@squarepeg77 No problem.
I’ve added two short notes in the post regarding the need to restart Home Assistant.
I have another improvement to record and log COP within HA, if you take the COP sensor previously created and reference within a statistics sensor you can take an average over 5 mins (configurable), this smooths out the values when the Heat Pump goes in to a stable state ie ticking over, the Daikin fluctuates the input power in our case from ~250W to ~450W as a result the COP fluctuates from 3 to 8 as a result of ESPAltherma and the Shelly measuring at different intervals, so the average/mean COP is around 5 and this sensor would be good to log in Grafana and on your in-home display. Hope this helps and makes sense?
sensor:
- platform: statistics
name: "Average COP"
unique_id: average_cop
entity_id: sensor.cop_true
state_characteristic: mean
max_age:
minutes: 5
** update **
Here are the results from last night a much nicer graph in Grafana, Blue original template/sensor, and green the average per 5 mins sensor
** update 2 **
needed to add the following to the seed template so this sensor displays ‘0’ vs ‘unknown’ when the HP is idle, ie a COP of 0 -
attributes:
minute_counter: "{{ now().minute }}"
There is a new Repo (forked as there were problems with 2024.1 and the original integration) that is cloud dependant that exposes more control (on/off function and set temp), I use this as well as the ESPAlterma (local monitor only), it’s not in HACS but WIP, installed manually.
Yeah I use this to set offset temp and on/off more flexibly than the standard schedule.
Hi @John can you share your automation (or manual) logic for offset? TBH I have not changed any offsets yet manually.
eg
if outside temp is <2
set offset +1
else
0
and the reverse
if outside temp is >8
set offset -1
else
0