Trend sensor too brittle on HA restart because it has no minimum duration option

The problem

The Trend sensor’s sample_duration and max_samples options let you track “long-term” trends (meaning anything trend involving more than 2 sample points). However, all samples are deleted upon HA restart, and the sensor starts trying to fit trends the first 2 samples it gets and often “detects” a trend, which defeats the whole purpose of setting these options.

A min_duration attribute is required on the Trend sensor to make the existing options make sense. In fact, the current options are not very useful. It’s certain that most people using the Trend sensor with multiple samples want the trend to be over a certain amount of time, nothing more and nothing less. Otherwise, the findings would be quite useless. A “trend” involving multiple samples that meets a required change gradient tells you nothing unless you know over how long of a period that trend is happening.

The ideal solution: The sample_duration and max_samples options should be removed entirely because a binary sensor tracking trend just doesn’t make sense over a variable amount of time. They should be replaced with a single, optional duration. If it’s not set, then the Trend will just track trends between the current state and the immediately preceding state, as is already the case. If it is set, then the Trend will track the trend over the set duration, and will not falsely fire when the required length of samples is unavailable (like when HA restarts).

The temporary, non-breaking solution: Add a min_duration option that will add to the effect of the existing sample_duration and max_samples options by simply mandating that the binary sensor not fire when the collected data does not span the minimum duration specified (like when HA restarts). This is a stopgap solution and a no-brainer.

Environment

• Home Assistant Core release with the issue: 0.114
• Last working Home Assistant Core release (if known): N/A
• Operating environment (OS/Container/Supervised/Core): Container
• Integration causing this issue: Trend
• Link to integration documentation on our website: https://www.home-assistant.io/integrations/trend

Problem-relevant configuration.yaml

  - platform: trend
    sensors:
      outside_suddenly_cool:
        entity_id: sensor.outside_temperature
        friendly_name: "Outside Suddenly Cool"
        device_class: cold
        sample_duration: 1200
        max_samples: 20
        min_gradient: -0.00241

[melyux]

I use this Statistics sensor to find the trend for outside temperature:

  - platform: statistics
    name: "Outside Temperature Trend"
    entity_id: sensor.outside_temperature
    state_characteristic: change_second
    sampling_size: 50
    max_age:
      minutes: 26 # 25 minutes, but upped to avoid situation where the immediately preceding 25-minute period has only 49 samples (which is always the case b/w any two measurements)
    precision: 6

I then use this Threshold sensor based upon it to replace the trend for outside temperature suddenly becoming cold:

  - platform: threshold
    name: "Outside Suddenly Cool"
    entity_id: "sensor.outside_temperature_trend"
    lower: -0.001705 # -0.00241 is the lower-than threshold
    hysteresis: 0.000705
    device_class: cold

[slovdahl]

I’m also having a similar issue. As it stands, I can’t set min_gradient as low as I would like to, because a restart combined with a tiny bump in the value of the source sensor would trigger the trend sensor. Instead, it means the sensor won’t trigger every time it should (which in my case is still better than the opposite, triggering when it shouldn’t, but still not ideal).

The simple solution to my problem would be a “minimum samples” setting. Alternatively, read history from the recorder and backfill the samples according to sample_duration and max_samples before evaluating it the first time after a restart.