[Solved] Template entities reload causes erroneous datapoint

Configuration
1

I have a rain gauge hooked up to a D1mini. When there is “enough” rain collected it swings over and a pin is shortly pulled high on the D1mini. Integrated with ESPhome I have a binary sensor that is called binary_sensor.rain_pulse

To calculate the amount of rain falling per minute I have the following code:

 - platform: template
    sensors:
      rain_pulse:
        friendly_name: Rain Pulse
        value_template: >-
          {% if is_state('binary_sensor.rain_pulse', 'on') %}
            1
          {% elif is_state('binary_sensor.rain_pulse', 'off') %}
            0
          {% else %}
            0
          {% endif %}

  - platform: statistics
    entity_id: sensor.rain_pulse
    precision: 0
    name: rain_gauge_pulse_1
    state_characteristic: count
    sampling_size: 120
    max_age:
      minutes: 1

  - platform: template
    sensors:
      rain_1:
        friendly_name: Rain 1 minute
        unit_of_measurement: 'mm'
        value_template: >-
          {{ (states("sensor.rain_gauge_pulse_1")) |float /2 * 0.367 }}

result: if there was rain enough to measure 0.367mm of rain in the last minute the sensor outputs 0.37 if there was enough rain to do to measure twice in the last minute it outputs 0.73 and so on and on.

My issue is however that when templates are reloaded (now via developer tools > yaml > YAML configuration reloading > template entities) or at reboot, the sensor output is 0,18. (half of the 0.367 rounded to 2 decimals.)

I understand what the issue is, going from “unavailable” to “0” is counted and calculated with /2 * 0.367

I… ehm… just don’t know how to fix it…
Does anyone have the brilliance to make me feel dumb and fix this? Much appreciated!

2

It seems I have figured it out. So for future reference:

The template sensor called rain pulse could have 3 states in the code in the post 1, 0, and unknown. When reloading template sensors (or during boot where the same happens) the sensor would be on unknown and then change to 0 again. hence half a pulse being counted.

so I changed the zeros in the template to “unknown” now the sensor output is either unknown or 1. so there will only be a change counted when the binary source actually changes to on, anything else just outputs unknown.

not pretty but it is not a sensor to be displayed, so who cares.

Solved! (is there a way to mark this post as solved?)

3

I have weird spikes, seemingly with statistics sensors as well, but hardly caused by similar effects: I have sudden temperature spikes in the -4000 or 4000 range on every reboot. Started fron 2022.5
image

4

If during reboot the source information is not available it outputs based on what it knows… Erroneously thinking that it is in hell?

What’s your code?

5

I hadn’t posted anyting yet because it is a rather complicated bit of multiple consecutive sensors (don’t know which one yet) and I first wanted to dig deeper because it is indeed possible I messed up somewhere. Also had not heard any one else about it. But I thought I’d chip in here because I may not be alone after all.
I’ll look into it myself first and let you know if I pinpointed there things mess up.

6

Yeah putting data from sensor to sensor is something that is increasing the risk of errors. And hard to dig out, especially when the error occurs in one of the first steps.

It would be awesome if these “multi-step” could be put in one sensor somehow though. (time for a what the heck month again) like that posting, the code would also be easier.

7

If you have template sensors, always make availability templates for them to avoid startup issues.

1 Like
8

can you point us to any documentation regarding availability that explains a bit more than:

availability template (optional, default: true)

Defines a template to get the available state of the entity. If the template either fails to render or returns True, "1", "true", "yes", "on", "enable", or a non-zero number, the entity will be available. If the template returns any other value, the entity will be unavailable. If not configured, the entity will always be available. Note that the string comparison not case sensitive; "TrUe" and "yEs" are allowed.

If available of course.

9

You have to create a template that looks for invalid states and return false when that happens. There isn’t much documentation because you have to figure out the code for your own use case.

10

I’ve looked into my own spikes some more. First of all I didn’t use an availibility template because my whole point was to have the sensor available as much as possible, so I checked for unavailable sensors in the value template. My assumption for now is that I caused the initial problem myself because I didn’t also check for none, missing or any other unavailable state out there. So I opted to use is_number() instead.

I still have spikes on reboot, but I guess that is another effect that may disappear over time. I use a statistics sensor that averages over time, so now it is probably picking up on old spikes from the past, as it should when averaging in that time window.

But I did see something else that may have changed as an after effect of some of the recent changes. I have a not so reliable KNMI integration that is often unavailable. But during reboot, it seems to restore an old value (not the unavailable ones) before being sent back to unavailable (which is what is was meant to be). The spikes below are reboots, seemingly picking op on the old value from the past:
SharedScreenshot.

I’m still trying to figure out if this behaviour is also at play repeating my earlier spikes on every reboot.