Automation help - trigger when value stays at a certain value for too long

I have asmall pump in my whirlpool which pumps water on my roof to heat it up.

Recently I noticed that the pump got stuck. I will try to avoid that on the hardware side, but till than I want to get a notification when the pump gets stuck.

I have the temperture of the poolwater and the temperture on the roof.

IF the rooftemp (TR) is higher than the pooltemp (TP)
AND
TP doesn’t heat up
THAN no water is pushed through the tube.
If that happes I’d like to be notified.

So the automation should look something like this (pseudo code):

trigger: TP doesn't change 
condition: TR > TS
action: notification

I only need help for the trigger. TP will always flucuate a little. So there must be a threshold.

@petro I’m sure you know how to do that.

Surely you mean petro :wink:

1 Like

This part requires more information:

TP doesn’t heat up

Please explain that in greater detail. For example: the pool is considered to be not heating if it’s temperature remains less than the roof temperature for more than 45 minutes.

Alternatively, use a pressure sensor downstream of the pump to detect if there is adequate flow.

IF the pressure drops below 100 kpa for more than 30 seconds
AND the pump is on
THEN the pump has failed

I’m not sure how you’d go about doing it for a variable like that but take a look at the
for:
trigger

If you can assume that if the pump isn’t stuck then it will only take X mins to lower it add

for:
  minutes: X

Then it will only trigger if it has been that valid for X.

The pump is active if TR - TP > 2

and deactivated if TR - TP < 1

About the sensor: It’s a good idea, but I don’t want to add another sensor.

Maybe a pictures helps:

On the left you can see the green line (TP) slowly rising. This means the pump worked.

On the right side you can see that the TR is much higher than TP (because it isn’T cooled by the poolwater) AND TP stays arrount the same temperatur, so no slope.

Maybe it would be a good idea to calculate the slope, and if the slope is below a certain value for to long → trigger

EDIT: Looking at the picture again. Maybe it’s also enought to use the difference between both value.
So if the TR - TP > 10
Trigger: notification check pump

EDIT2: Forget this last idea, this won’t work if the pooltemp drops due to bad wheater. Followed by a sunny day.

Just when I was about to tell you that this can’t be correct: deactivated if TR-TP < 1 you updated your post to TR-TP > 10. Now that makes more sense! :slight_smile:

If the pump fails, the two temperatures will diverge. If it is working, the two temperatures will (ideally) converge.

If you know how long it should take to cool then you can do something like this

alias: Pump Stuck
initial_state: ‘on’
trigger:

  • platform: state
    entity_id:
    to: ‘on’
    for: “00:05:00” # 5 mins
    condition:
  • condition: template
    value_template: ‘{{ states.TR - states.TP > 10 }}’
    action:
  • service: notify.pushbullet
    data_template:
    message: ‘Hey! The Pump is stuck’

That should check if the pump has been on for 5 mins and the difference is still greater than 10

Sry I wasn’t clear about that.

The pump is active if TR - TP > 2
and deactivated if TR - TP < 1

is correct. This is how I control the pump when it’s working correctly.

Thanks @ChaoticUnreal but I don’t like my idea from above “TR - TP > 10”, because (see Edit two above).

Looking at the picture for it seems pretty simple.

 - alias: 'Pool - Pump stuck'
  initial_state: 'on'
  trigger:
    ... something that detects that TP doesn't rise
  condition:
    - condition: template # only if TR>TS+2 
      value_template: '{% if states.sensor.solartemperatur.state %}{{ (states.sensor.solartemperatur.state | float > states.sensor.pooltemperatur.state | float) + 2 }}{% endif %}'
  action:
    service: notify.ios_device
    data:
      message: "Pump stuck"

Found this

EDIT:

This is the automation I came up with, suggestions welcome:

    - alias: 'Pool - Pump stuck'
      initial_state: 'on'
      trigger:
        platform: time_pattern
        minutes: '/15'
        seconds: 00
      condition:
        - condition: state
          entity_id: binary_sensor.pool_trend
          state: 'off' # on if TP rises above 0,3°C per hour.
        - condition: template
          value_template: '{% if states.sensor.solartemperatur.state %}{{ (states.sensor.solartemperatur.state | float > states.sensor.pooltemperatur.state | float) + 2 }}{% endif %}'
      action:
        service: notify.ios_device
        data:
          message: "Pump stuck"

I don’t understand. If the two temperatures are almost identical (TR-TP<1) how is that an indication that the pump has failed (deactivated)?

  • When the pump is functional, its goal is to circulate the cool pool water and heated water until there’s little difference between the two temperatures (i.e. within a degree of one another). So TR-TP<1 is not a reliable indicator of pump failure.

  • A difference of more than 2 degrees could mean the pump has just started operating (like in the morning) and there’s a significant difference between the two temperatures. It can also mean the pump has failed and now the two temperatures are diverging (heated water gets hotter, pool water gets cooler). So TR-TP>2 is not a reliable indicator of a functional pump.

You’re probably going to need to use a Trend Binary Sensor, as suggested by @h4nc, to determine if the temperatures are converging (definitely a sign the pump is doing its job) or diverging (a potential indicator of a pump failure, especially if heated water temperature is rising and pool temperature is falling).


Or just replace the faulty pump …

It is not. Deactivated and failed are too different things. I think that is the reason for the missunderstanding here.
It is deactivated on demand. So this is my regular automation to control the pump.
Turn on if solartemp is 2 deg higher than pooltemp.
Turn it off if solartemp is 1 deg higher than pooltemp (because than it would cool down the temperature (it looses some temp on the way down from the roof).
The example above should only show how I control the pump regulary, because you wanted me to explain it more detailed.

I’m the threadstarter and h4nc :wink: so I found the trendsensor myself^^

I think my automation in my last post should work. But I will change the +2 °C to 5°C.

Actually, I did not. I asked for an explanation of how you intend to determine if “TP doesn’t heat up”. It was part of your pseudo-code for handling the pump’s failure (not its normal operation):

IF the rooftemp (TR) is higher than the pooltemp (TP)
AND
TP doesn’t heat up   <------ this
THAN no water is pushed through the tube.

You replied with an example of formulas for normal pump operation, not pump failure, and that’s where I became confused.

Anyway, the question remains the same. How do you plan to detect the condition you referred to as “TP doesn’t heat up”? I suggested to check if the pool temperature remains less than the roof temperature for more than 45 minutes. If the pump runs normally for 45 minutes, the pool temperature should rise. If the pool temperature fails to rise over a period of 45 minutes, that can be an indication the pump has failed (i.e. it is on but not actually working).

It would look something like this:

- alias: 'check pump'
  trigger:
    platform: state
    entity_id: switch.pump
    to: 'on'
    for: '00:45:00'
  condition:
    condition: template  
    value_template: "{{states('sensor.solartemperatur')|float - states('sensor.pooltemperatur')|float > 5}}"
  action:
    service: notify.ios_device
    data:
      message: "Pump stuck"

Forty-five minutes after the pump is turned on, if solar - pool > 5 then send a ‘Pump Stuck’ notification.

If the pump can fail at any time, even while already running, then you’re better off using your approach where time_pattern periodically checks the situation.

Yeah, I failed to make that association! My mistake. :slight_smile:

I’m sorry I missunderstood that.

With the trendsensor. If the binary sensor is off, because TP doesn’t heat up with more than 0,3°C, than the condition gets true.

Don’t you think that should work?

I get your idea, but I think the trendsensor could react faster (than the 45min automation).

Based on the information you’ve provided, I have my doubts.

Here’s the information:

  • Let’s look at the graph when the pump is working properly, specifically the 8-hour period starting from 6/18 08:00 to 6/18 16:00. From approximately 10:00 to 15:00 there is a constant (linear) rise in pool_temperatur. However the slope during the first two hours is noticeably flatter. In fact, it looks flat during the first hour.

  • Your threshold for the Binary Trend Sensor is a rate of 0,3 °C per hour.

  • The automation’s time_pattern is every 15 minutes.

Even if the pump has not failed, the automation expects the Binary Trend Sensor to have collected sufficient data, within the first 15 minutes, to establish a rising trend of at least 0,3°C per hour. Therefore in the period of the first 15 minutes of operation, pool_temperatur must rise by at least 0,3 / 4 = 0,075 °C to establish a trend of 0,3 °C per hour.

I don’t know the accuracy of the device you’re using to measure pool_temperatur, but 0,075 is on the order of ‘noise’ for the average temperature sensor. Its measurement is likely to vary by that amount even if the actual temperature is steady. Add the fact the slope during the first hour appears to be virtually flat and it becomes difficult to imagine how this method can reliably detect either a failed or functional pump. The odds of success and reliability improve when the slope increases (from 10:00 to 15:00) but I’m skeptical of its performance within the first half-hour, especially the first 15 minutes.

That’s why I initially proposed waiting 45 minutes to allow sufficient time for the pool water to increase in order to reliably determine if pump is working or not.

That’s also why I also suggested using a pressure sensor because it will tell you within 10-15 seconds if the pump has developed a nominal pressure.

Here’s another thought: when the pump fails to work, I assume it is consuming less power (none) compared to when it is working properly (unless ‘pump fails’ means the pump’s motor continues to run but its impeller fails). You can plug the pump into a ‘smart socket’ that also reports power consumption. You can monitor the power consumed to determine the pump’s condition. This is a much simpler, faster, and more reliable detection method than monitoring the difference between pool_temperatur and solar_temperatur.

Good point, I did not think about the accurancy of the sensor. You right this will most likly be an issue.

I think it’s time to describe what “pump stuck” means.
It is a DIY Solarheater (gardena tubes) connected to a small aqarium pump (12V) controlled by a modded sonoff (tasmota) which has the the two temp sensors (DS18B20) connected.
The pump consumes a small amount of power and is good enough to heat the whirlpool. However, this worked perfect last year. But this year the inlet of the pump “sucked” on the pool walls the second time.

So the pump isn’t fixed (and can’t be fixed, because I want to be able to pull it out, when someone goes into the pool). I will probably add a small tube to the inlet. This should/could avoid the issue.

Anyway I thought a second (software) way to monitor this, would be nice.

About the power sensor. I already have a smart socket connected to this. But it tracks the whole consumption of the pool. The pool has a electrical heater too (which explains the higher rise at the end of the first day in the picture).
The stucked pump consumes a little less power than normal, but it will be hard to seperate it from the other consumers (filterpump of the pool 40W, heater arround 2000W).
It looks like normally the pump consumes 30W and stuck (25 W).
Good idea but I think not really useable in my setup.

I will use the automation you provided. Thanks for your time.

EDIT:
It can also get stuck during the day so after it was on for 45 min.
So what about this: (adding your trigger as a condition):

- alias: 'Pool - Pump stuck'
  initial_state: 'on'
  trigger:
    platform: time_pattern
    minutes: '/15'
    seconds: 00
  condition:
    - condition: state
      entity_id: switch.pump
      state: 'on'
      for: '00:45:00'  
    - condition: state
      entity_id: binary_sensor.pool_trend
      state: 'off' 
    - condition: template # nur wenn Tsolar - Tpool > 5
      value_template: '{% if states.sensor.solartemperatur.state %}{{ (states.sensor.solartemperatur.state | float - states.sensor.pooltemperatur.state | float) > 5 }}{% endif %}'
  action:
    service: notify.ios_device
    data:
      message: "Pump probably stuck"

I will add my vote to performing this simple modification.

It will take far less time and effort compared to what we’ve already spent discussing a fragile, temperature-based solution. In fact, it will take less time to add an inlet tube than for me to explain why your modified version of the automation won’t work as expected.

Well i’m way to late to this thread, looks like @123’s got u.

1 Like

You are right. I did not expect that the discussion will take so much time.

Again thank you. I’ll buy a tube that fits and the problem should hopefully be gone.

Yep, tons of time and effort invested in explaining why an overly-complicated and easily fooled software solution is not the right way to mitigate a simple hardware problem. In retrospect, I wish I had arrived late too …

Again I’m sry, this wasn’t intended.

Never thought that this takes so much time.
And during the discussion I did want to interrupt it, telling you that it isn’t that important.

At some point I was interested if we find a solution. Also wanted to use the trend sensor.

Have a nice day.