Decontaminating inline pool temperature sensor

I have a pool with a pump located in my basement, and an inline temperature probe. The pump is not running all the time, which causes the temperature probe to adjust to the room temperature instead of the actual pool temperature.

What I would like, is to have a sensor representing the last known temperature of the pool water or perhaps just not update the value unless it can be considered “good”.

I have a switch on my pool pump, so I can make a condition on when the probe can be assumed to show the proper temperature. One problem with my current implementation, is that it would update the value immediately when switching on the pump, which would represent a temperature from my basement, and not the water from the pool.

  - platform: template
    sensors:
      temp_pool_corrected:
        value_template: >-
          {% set x = states('sensor.temp_pool')|float %}
          {% if is_state('switch.pool_pump', 'on') and states('sensor.temp_pool') != 'unknown' %}
            {{ x }}
          {% endif %}

How can I improve my code, to get a better representation of the actual pool water temperature?

Move your sensor?

If you don’t have anything to say, why do you need to reply?

You could use a statistics sensor to return the minimum temperature in a certain period of time.

… and if you don’t have anything nice to say … :no_mouth:

I agree with tom_I. Moving the temperature sensor is the optimal solution. Sometimes the best fix is a redesign, not a patch.

What you’re attempting to do is to use a complex software solution to compensate for the sensor’s problematic location. Basically, a patch to cover a flaw.

Are you familiar with the MCAS system on the Boeing 737 Max? That’s a complex software solution to compensate for the aircraft’s problematic location of its new, larger engines. Their attempt to make the MAX’s new flight dynamics be the same as the previous model, using software, hasn’t been a great success (to say the least).

In your case, relocating the sensor isn’t nearly as complicated as Boeing’s situation. Moving the sensor out of the house will provide better data over the long-term.

And sometimes you don’t understand the application. There are several reasons why an inline temperature sensor is useful.

But, to keep up with your rock solid arguments, my response is: Why automate anything?

Now, stay on topic, or find somewhere else to spam.

That assumes that the pool temperature would always be below the basement temperature. I thought of that myself, but quickly realised, that this may not always be true.

I never disputed that. The suggestion we made was to relocate it outside your home so it avoids being influenced by indoor ambient temperature.

to keep up with your rock solid arguments, my response is: Why automate anything?

Again, I didn’t dispute justifying automation. The core issue here is that the sensor’s location is problematic because it is influenced by indoor temperature. Compensating for this via software isn’t the only way to solve it, it’s not even the best way.

Now, stay on topic, or find somewhere else to spam.

If you check the forum’s membership, you’ll see there are currently over 40 thousand members. However, the number of people who regularly provide assistance is a tiny fraction of the membership. It’s counter-productive to reply in a way that alienates those who come to your aid.
https://community.home-assistant.io/u

2 Likes

Yes, that is the best and proper way to do that. Why are we using software in the first place, if we don’t intend to use it? My topic asked for suggestions on how to use Home Assistant magic (that I can learn and help others with). If I wanted something inflexible that I couldn’t do anything with, I would not even be using Home Assistant, but HomeKit or something else.

Now the reason that the inline temperature probe is the best way, are several:

  1. My pool is outdoors and quite far away. Getting a probe out there involves, either getting an electrician to install outlets nearby, or working hard to get a piece of hardware (perhaps a NodeMCU) to work long-term on battery. Also a pool is wet, which means that everything needs to be carefully installed in waterproof boxes.
  2. I already have a probe available connected to a Sonoff providing the data.
  3. In near future, I will have both a heatpump and solar mats to heat up water. This means that I would need more probes, located the same place, with the same problem.
  4. It’s not even a complicated problem. All I’m asking, is basically if there is a way to have a sensor template not updating its value, or repeating it’s last value.

Ok, I can see how my comment might be construed as flippant. However It was a serious question. Can you move the sensor?

This would seem to be the simplest solution to your problem.

If you had simply said it’s not possible to move the sensor, then we could have worked from there.

Also your if statement needs an else for the case when the if is not true. The way it is at the moment is malformed.

The following template reports the temperature sensor’s value only when the pump is on and the sensor’s value is not unknown.

If the pump is off or the sensor’s value is unknown, it reports the current value of sensor.temp_pool_corrected. However, the first time you use this template, the initial value of temp_pool_corrected will be unknown. In this very rare situation, the template returns a fixed temperature value (I used 21 but it can be whatever you want).

  - platform: template
    sensors:
      temp_pool_corrected:
        value_template: >-
          {% set x = states('sensor.temp_pool')|float %}
          {% if is_state('switch.pool_pump', 'on') and x > 0 %}
            {{ x }}
          {% else %}
            {% set x = states('sensor.temp_pool_corrected')|float %}
            {{ x if x > 0 else 21 }}
          {% endif %}
  • In the template’s first line, if the sensor’s state is unknown, filtering it with float will generate a value of 0.
  • If the pump is on and temperature is greater than zero, the template reports the sensor’s temperature.
  • Otherwise, it gets the current value of sensor.temp_pool_corrected. If the value is unknown, the float filter will return 0.
  • If the value is greater than zero, it reports it. If it’s zero, then it reports 21 (use whatever value you prefer to represent the initial state of temp_pool_corrected).

There is still this issue to resolve:

it would update the value immediately when switching on the pump, which would represent a temperature from my basement, and not the water from the pool

I think I know how to solve it but I have to experiment with it first.

1 Like

Don’t sample temp values when pump is off?

The following addresses the need to delay reporting new temperature measurements for the first few minutes after the pump starts. I used 5 minutes but you can adjust it to suit your needs.

The key difference is we now use an input_boolean to represent the pump’s power-state. Two automations control the input_boolean’s state. The input_boolean is set to on only after the pump is on for more than 5 minutes. The template sensor checks the pump’s input_boolean, not the pump’s switch.

Inputs

input_boolean:
  pool_pump:
    name: Delayed Pool Pump

Automations

- alias: 'delayed pump on'
  trigger:
    platform: state
    entity_id: switch.pool_pump
    to: 'on'
    for: '00:05:00'
  action:
  - service: input_boolean.turn_on
    entity_id: input_boolean.pool_pump

- alias: 'delayed pump off'
  trigger:
    platform: state
    entity_id: switch.pool_pump
    to: 'off'
  action:
  - service: input_boolean.turn_off
    entity_id: input_boolean.pool_pump

Template Sensor

  - platform: template
    sensors:
      temp_pool_corrected:
        value_template: >-
          {% set x = states('sensor.temp_pool')|float %}
          {% if is_state('input_boolean.pool_pump', 'on') and x > 0 %}
            {{ x }}
          {% else %}
            {% set x = states('sensor.temp_pool_corrected')|float %}
            {{ x if x > 0 else 21 }}
          {% endif %}