Howto shutoff heat pump when LWT<30 using Onecta integration

This is somewhat complex so I am hoping we have a guru on the community !

Question: How might I automate turning off a heat pump when leaving water temperature minus the leaving water offset demand is less than 30?

Issue
I am using HA to modulate heating because the madoka room thermostat is not as responsive as my custom room sensors and also because there are limitations on the number of API calls the Oneta app can invoke over a 24 hour period (so updating the madoka values from cloud interface). The Daikin system obtains a Leaving Water Temperature (LWT) from the weather curve set in the MMI, then my HA automation applies an offset value (range -10 to +10) to the LWT value, to modulate the system as a complex but now fully working hysteresis that is not available in HA generic thermostat etc. Indeed there are 5 different thresholds that increase or decrease the offset in different time frames , to maintain the house temp - which is does perfectly, around 20C. So I do not want to change any of this - thank you for understanding.

Help needed
Put simply, I need to ensure the pump is only running when the target lwt is >= 30C however and crucially, there is no sensor value that yields what the target lwt will be.

A ‘fudge’ is perhaps the best I can do , well certainly myself which is…
As I throttle the LWT My Daikin Air Heat Pump cycles rapidly causing wear & tear and increased maintenance costs when the LWT is less than 30C. I need some way to ensure that for negative offset values, when deducted from the current LWT, the resultant value is >= 30. Similarly for positive offsets, when added to the current LWT, the resultant value is => 30.
Is there a better way?

Setup:
I use the Onecta integration downloaded today, I have a number of sensors and climate devices.
What I really need is the LWT value from the weather curve that the system is using, if that is >=30 then turn pump on, if on the other hand deducting -ve offsets takes it below 30 then turn off the pump. But that curve value (the target lwt) is not available - I note on Github users are requesting it but Daikin do not currently provide an API wrapper for this so it cannot be made available.

The only two useful exposed entities are:

climate.heating_leaving_water_offset which has state HEATING or OFF, and its associated attribute target_temperature which is a integer value from -10 to +10 (for simplicity here lets call this offset)

and

sensor.heating_climatecontrol_leaving_water_temperature which has a numeric state of 0 to 50. (for simplicity here lets call this lwt)
… but lwt isnt helping me as that is the current leaving water temperature and not the target lwt.
Ideally as above, if we had the weather curve value then (the target lwt) rather than actual lwt, and we could just simply do:

IF target-lwt + offset < 30 # check if target lwt with offset applied is < 30
THEN
    # lwt with negative offset would be less than 30
    # or
    # lwt with positive offset would be less than 30
    << turn off pump >>
ENDIF

I want to turn off the pump (climate.heating_leaving_water_offset HVAC mode set to OFF) when negative offsets applied to lwt is < 30. Lwt will always reduce for negative offsets. So this side of automation seems doable.

However the upward increasing side is more complex. If LWT + positive offset is < 30 then pump should stay off but then of course the pump will not run so LWT will never increase and so the pump will always be off once LWT has gone below 30. Mmmm.

Maybe my logic/algorithm is wrong here, but I don’t know what more I can do with the limited entities exposed through the Daikin Onecta integration.

This is complicated - is anyone understanding this and if so can you suggest a solution.

I do not own any part of your system, but through logical process a lot of people on here should be able to help you.

However, I don’t have a solution for you off the bat as I don’t truly understand what you’re trying to do (you seem to be in an XY Problem). But maybe if we hash it out, it will become more apparent to me, and others, as to what you’re trying to do. For simplicity, I’ll ignore your overall scenario and focus and the root problem and goal, numerically anyways.

  • you have lwt with a value range of 0 to 50
  • you have offset with a value range of -10 to 10
  • If lwt + offset <= 30; turn OFF pump
  • If lwt + offset > 30; turn ON pump

Example scenario 1a:
lwt = 35
offset= (-7)
lwt + offset = 28; pump OFF

Example scenario 1b:
lwt = 28
offset= 8
lwt + offset = 36; pump ON

This equation seemingly oscillates successfully on both sides of 30, turning the pump on and off. Given this recap, I don’t quite understand the problem yet.

this adds to my confusion, because from this you’re basically saying you never want the value to dip below 30, but then your pump will never turn off…OR you always want the value with a -ve offset to be <30 (assuming signage error in post?) and a +ve offset will always return >30 (even if its 18 + 10 ; your floor resultant value would be 30)?

Hi again, ok, so does this reword , graphic, and algorithmic steps help ??

Problem:
The pump cycles rapidly when target lwt is less than 30C because the pump cannot attain a low temperature so all it “sees” is the need to reset, power down/up, and try to attain that temp again - which is never will do. This is a design flaw in the pump and well known in industry and user community.

Actual lwt
This is simply the temperature of the water leaving the pump at any given time and can be increasing or decreasing, or static, when reading taken compared to a previous reading.

Target lwt
The Daikin system is configured with a 2 point weather dependent curve, where A=ambient temp and LWT=target leaving water temp from the pump into the home that is required in order to attain a desired room temp at the given ambient temp. The system reads of target lwt for the current outside ambient temp.
This is displayed on the home screen of the MMI (control panel for Daikin heat pump system) however the Onecta integration in HA does not provide this target lwt because Daikin do not provide an API for it , although the system clearly “knows” it.

Here is a weather curve displayed on the MMI.

What we need to do
It’s ok for the pump to operate sub 30 provided it is increasing lwt, it is not okay if the pump is expected to maintain lwt below 30 or operate to decrease lwt below 30. Again, this is a Daikin design issue that cannot be fixed by “us”.

  • I have actuallwt with a value range of 0 to 50
  • I have offset with a value range of -10 to 10
  • If target lwt + offset < 30; turn OFF pump # not <= 30, but < 30
  • If target lwt + offset >= 30; turn ON pump # not >30 but >= 30
    BUT we do not have target lwt because it is not provided by the Onecta integration
  • The downward trend of a reducing actual lwt + negative offset can be handled because the result, if < 30 means, means turn off the pump but we need to ensure that lwt is reducing not increasing (or static).

What we cannot do with the above and this is the problem
The downward trend of a reducing actual lwt + positive offset cannot be handled easily because for example if the actual lwt is 20C and positive offset is +2 then result is 22 in which case we turn off the pump (i.e. <30) BUT we actually want the pump ON so that the actual lwt rises as water is heated. Then when the offset changes to zero because the desired room temp is met, if the actual lwt is still below 30 then we want the pump off.

Does this help?
I have no idea if this is possible in automation - and crucially - how to do it.

Okay slowly piecing this together…

Without knowing all the nitty gritty ins and outs, it sounds like your problem comes down to knowing if actual_lwt is increasing or decreasing; with this I would look at a Trend Helper. Point the Trend Helper to you actual_lwt sensor.

image

Once you create the Trend sensor, go back in and configure the settings to see the additional configurations you can do.

Once you get the Trend Helper, lets call it actual_lwt_trend, confirmed working, you can add it into your automation to help look for increase/decreasing values how you want it.

Thank you @MikeScottCAD , excellent training (!) however this does not help sadly albeit a handy tool for future ref.

To summarise: I see your intent; we want to interrogate actual_lwt_trend to confirm an upward trend then turn on the pump however the pump is already off and the trend is going down not up as actual_lwt decreases toward zero. A trend doesnt work for the following reason:

As I stated above in the “nitty gritty”, the logic: IF actual_lwt + offset < 30 THEN turn off pump
…can be implemented with some confidence as to function: for -ve offsets, when actual_lwt is less than 30, the result is going to be less than 30, so pump off and everyone is happy !

However the pump is now off and the room temp starts to fall from 20C, as does actual_lwt, and actual_lwt_trend moves down. At a predefined point in my triggers, say 18C, a heat_demand is set to on with offset set to zero , it could actually be 0 to +10 but for the purpose of this exercise that is irrelevant because actual_lwt will be close to zero . So, this requests that the pump be turned on but then the above logic kicks in, lets use that +10 offset…

IF actual_lwt + offset < 30 THEN turn off pump which resolves to IF zero + 10 < 30 THEN turn pump off

Any actual_lwt value of < 20 even with max offset of 10 isn’t going to turn the pump on so there is going to be no rise in actual_lwt and therefore no upward movement in actual_lwt_trend. This algorithm and proposed ‘trend’ thus is ineffective.

I am feeling that what I seek isn’t possible given the available inputs and that I will have to turn the pump on for any actual_lwt and offset pair which means the pump could reach 20C in mild ambient conditions without raising the actual_lwt to more than 30 , and , according to Daikin this can/will damage the pump. Bhooooo. In reality, a 30C LWT doesnt warm the house anyway - it’s just not enough to meet the thermal heat loss of most properties bar all the most insulated and modern dwellings.

I’m too invested now, I need this to work for you haha. I still think the trend might be helpful here (unless I’m mistaken), or actually a Derivative sensor might be better still, but the concept of trend tracking applies. Lets focus on the logical execution before tackling what exact sensors need to be made.

Okay so, re-reading your posts a couple times, and using some newly defined (hypothetical) variables, are the below logical statements correct?

The offset is tied to your desired room temp. A warmer room temperature will make the offset -ve, and colder room temp will make the offset +ve. Reaching the desired room temp, the offset is 0

let’s assume/create the following HA variables
adjusted_lwt = actual_lwt + offset
actual_lwt_trend is the derivative/trend sensor.

  1. IF actual_lwt_trend is decreasing AND adjusted_lwt < 30; turn off pump (I know, this part was the easy-to-handle part)
  1. IF actual_lwt_trend is decreasing AND offset > 0 (i.e. positive); turn on pump (here we ignore the adjusted_lwt formula as you said there are scenarios where it won’t resolve to >= 30, and instead simply use the presence of a decreasing trend and a +ve offset to turn the pump on)
  2. IF offset == 0 AND adjusted_lwt < 30, turn off pump
  3. IF adjusted_lwt >= 30; turn on pump (this blanket addresses any scenario where actual_lwt + offset is >= 30 where you want the pump on)

Sorry I don’t seem to understand water heating systems as well as you. As such, the above logical statements are seemingly a gross simplification (maybe even incorrect) of what you may want to achieve. But, my end point is you don’t have to only use the trend/derivative sensor…it just becomes an additional sensor in your arsenal to solve your logic problems (as seen in logic #2)

Okay so, re-reading your posts a couple times, and using some newly defined (hypothetical) variables, are the below logical statements correct?
YES :slight_smile: almost.

Perhaps I should state the requirements and tag each of these with your solution where appropriate and then what remains is that which has no solution - still (sorry) - but I will use your trend theorem (where lwt refers to actual_lwt)…

  1. When the pump is on and lwt trend is up and a +ve offset results in no action (pump remains on)
    Yes, this is accounted for due to there being no action needed.

  2. When lwt trend is down and with a -ve offset and lwt transitions below 30 then turn pump off. You suggest:

    1. IF actual_lwt_trend is decreasing AND target_lwt < 30; turn off pump (I know, this part was the easy-to-handle part)

    but the issue here is I do not have target_lwt only actual lwt ( you must forget the actual !:slight_smile: ) and furthermore this takes no account of offset

  3. And so we come to the most complex bit. Here, I do not believe your 2,3 or 4 make sense, because they are not quire what is needed and you also throw in target_lwt which is not a variable I have, recall that the only two variables are actual_lwt and offset.

It is probably best rolling up the requirements into a textual objective single statement, which I would say is:

The pump must never be “on” trying to maintain a leaving water temperature that is less than 30C. A negative offset is an attempt to reduce the lwt to cool the home, a positive offset is an attempt to increase lwt to heat the home"
…this is because doing so will cause the pump to cycle rapidly as it seeks to maintain a temperature that due to manufacturing design it is neither possible nor realistic; this rapid cycling causes premature wear and degrades performance causing premature failure and significant costs. Air Heat Pumps are designed to run 24/7 and ideally should never be turned off; however in mild climates with outdoor temps > 10C and solar gain (sunshine through windows, not turning off the pump will result in house temps that are truly uncomfortably high and sweltering.
Quite how long the pump might be able to run before being shut off I do not know because without the target lwt (which we do not have) we have no way of knowing whether the pump will reach that target lwt but I suppose we should define some arbitrary period of time after which “we give up” and turn off the pump, what that is - who knows. Is this where your trend idea comes in? I’ve never used trends in HA

remember all I have is actual(current) lwt and offset , and of course date/time and anything else we can extract from the universe !!

This is all soooo frustrating because the target_lwt - whilst not provided through the HA integration because it’s not a Daikin API - is however known by the Daikin system, because it modulates the actual_lwt around this, adjusting its power output as needed, but I’ve turned this off because the associated hysteresis is +/- 2C with overshoot of 4C which is ridiculous and means the house temp is all over the place. This hysteresis cannot be changed unless you come out of this operating mode (which is what I have done) and use basic mode which is offset-only where you can dial in a +/- offset value but this needs doing all through the day and is a PITA for sure - hence I want HA to automate it.

EDIT
there is a device called ESPHome supported by the great OpenEnergyMonitor.org site which connects to a port on the motherboard inside the outdoor monobloc unit, and has a ton of measurements, but this requires I open the sealed cabinet and break the 7 year warranty - which I am not doing.

Im glad you’re invested :slight_smile: :slight_smile:

I’ll have a more thorough read through in a bit, but for now at first glance I see some confusion.

I defined target_lwt as our own HA variable here (knowing we don’t have Target LWT anyways from your system, I thought making our own target_lwt would be fine, but I see I’ve just caused confusion labeling our own variable like that)

To avoid confusion, I will go back and change it to adjusted_lwt. Wonder if this will change the perspective as

my original targe_lwt variable that was defined is the formula that accounts for offset…I have gone back and changed to the variable name to adjusted_lwt.

Maybe a second read through now knowing adjusted_lwt = actual_lwt + offset might change your interpretation of my response.