Issue with the "for" argument within Automation Conditions: Unexpected behavior caused by Network Interruption

Configuration
1

Hello!
I have created several automations in my home assistant already without any problems. A few weeks ago, I was creating an outdoor automation:
Lawn Mowing Robot shall return to base when it rains and shall continue when it has not rained for 2h

Issue:
This was working well for a few weeks. But today I noticed, how home assistant sends it to the base even though there was no rain, see report from Influx where the knx sensor value is also saved:
image → See, no actual rain happened today.

:bulb: I might have an idea why the “unexpected behavior” happened in home assistant: Around 1pm I had to restart the fritz box / router. Naturally, this interrups home assistant connections. It might be the cause here: See this interruption in the history:

image
image2165×332 27 KB

This “interruption” was shortly after 1pm. So when the automation was running at 3pm, you could argue, that the sensor value “was not thoroughly OFF for 2h” because it was interruped (router restart). On the other hand you could also argue, the rain was never ON in the last few days … so therefore the behaviour is somewhat questionable!?

My question therefore is: If it hasn’t rained in a few days, should the automation not work as intended even though I do router restarts? Should the implementation of the “for” argument be improved? (Luckily this does not happens often for me)

My home assistant:
Core 2023.8.3

Further infos below:

The Automation is not very simple, but simple enough:
If the lawn mower (vacuum.mackel) is not deactivated with a global boolean, then
IF
- condition: state
entity_id: binary_sensor.aussen_sensor_regen
state: “off”
for:
hours: 2
minutes: 0
seconds: 0
THEN send to base, otherwise start the robot.

See full Yaml attached below.

Full YAML:

alias: GARDEN_Automower Rain Automation
description: ""
trigger:
  - platform: time_pattern
    minutes: /15
  - platform: state
    entity_id:
      - binary_sensor.aussen_sensor_regen
    to: "on"
    for:
      hours: 0
      minutes: 1
      seconds: 0
condition: []
action:
  - if:
      - condition: state
        entity_id: input_boolean.automower_enabled
        state: "on"
        alias: Check Automower is ENABLED (This is my MANUAL OVERRIDE HELPER)
    then:
      - if:
          - condition: state
            entity_id: binary_sensor.aussen_sensor_regen
            state: "off"
            for:
              hours: 2
              minutes: 0
              seconds: 0
        then:
          - service: vacuum.start
            data: {}
            target:
              entity_id: vacuum.mackel
        else:
          - service: vacuum.return_to_base
            data: {}
            target:
              entity_id: vacuum.mackel
    else:
      - service: vacuum.return_to_base
        data: {}
        target:
          entity_id: vacuum.mackel
mode: single
2

For Home Assistant, unavailable is a state as any other state. While you know that it is next to impossible that it didn’t rain while the router was out, that is knowledge HA cannot apply. As far as HA can tell, it could be anything during that time, including rain. It was virtually blind at the time.

It would require a different construct to do what you hope, ignoring specific values. Changing this would have unwanted consequences in other situations. As it is, you’d need to use another mechanism, such as using a timestanp to identify the last rain.

At times I also run in situations where the for seems the right way, but isn’t for reasons like this. I would like there to be an easy construct for these things too.

1 Like
3

Thanks for your answer, it makes a lot of sense. I will change my automation accordingly if it becomes an issue. Usually the router it not getting restarted very often, so it should be fine. Thanks for clarification!

4

These are GroupValueResponse telegrams. They are no indication of something actively sending, but are responses to a GroupValueRead request - which HA does by default for every KNX sensor 1 hour after the last received telegram. (See “sync_state” in the KNX integration documentation).

5

Since my house it not actively using the rain sensor right now, as you said it was the home assistant itself that was requesting those GroupValueResponses from the rain sensor through the KNX integration:

Binary Sensors

binary_sensor:

  • name: “Aussen Sensor Regen”
    state_address: “0/0/40”
    (there is no reason to believe that the rain sensor is not working currently)

I know this print from the influxDB that logs the knx signals is not directly relevant for the automation, as it does not take it’s values from my influx DB, but rather from the KNX integration directly. I just used it to prove that there was really no rain. Nevertheless I’m fine with the answer from Edwin_D, topic can be closed.

1 Like
6

when I think of the famous numpy library, there is often the option how NaN values shall be treated, e.g. numpy.isclose — NumPy v1.26 Manual, argument equal_nan

To implement something like this would be the most user-friendly way: The user can decide how the “for” condition shall operate:

  1. Based on all changes including the state “unavailable” (no assumptions, as is).
  2. Or shall it ignore the unavailable states → make assumptions that it has probably not rained if it was not reported - I also forsee some difficulties implementing this version, but it’s probably feasible and should be used with caution.)