Every HA reboot triggers power state above value x in automation since 2024.4.

[Soulfly999]

The problem

So after every reboot of HA it's triggering if power above/below value x watts automations since v2024.4. So after the reboot, the power plugs showing unavailable for about 90 seconds. In the versions before 2024.4 i had no problems with that?

Integration: Zigbee2MQTT Hardware: Nous A1Z Plug with Power-Monitoring https://www.zigbee2mqtt.io/devices/A1Z.html#nous-a1z

Automation Numeric_State: - platform: numeric_state entity_id: - sensor.waschmaschine_power for: hours: 0 minutes: 2 seconds: 0 id: aus below: 1

Also - type: Power: - type: power platform: device device_id: 39a384617cc1aee59dba8787d0245339 entity_id: sensor.trockner_power domain: sensor id: aus below: 145 for: hours: 0 minutes: 2 seconds: 0

What version of Home Assistant Core has the issue?

core-2024.4.4

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

Automation

Link to integration documentation on our website

No response

Diagnostics information

No response

Example YAML snippet

alias: Waschmaschine eingeschaltet
description: ""
trigger:
  - platform: numeric_state
    entity_id:
      - sensor.waschmaschine_power
    for:
      hours: 0
      minutes: 0
      seconds: 30
    above: 100
    id: an
  - platform: numeric_state
    entity_id:
      - sensor.waschmaschine_power
    for:
      hours: 0
      minutes: 2
      seconds: 0
    id: aus
    below: 1
condition: []
action:
  - if:
      - condition: trigger
        id: an
    then:
      - service: input_boolean.turn_on
        data: {}
        target:
          entity_id: input_boolean.waschmaschine_lauft
      - delay:
          hours: 0
          minutes: 0
          seconds: 5
          milliseconds: 0
      - service: input_datetime.set_datetime
        metadata: {}
        data:
          datetime: "{{ now() }}"
        target:
          entity_id: input_datetime.waschmaschine_startzeit
      - delay:
          hours: 0
          minutes: 0
          seconds: 5
          milliseconds: 0
  - if:
      - condition: trigger
        id: aus
    then:
      - service: input_boolean.turn_off
        data: {}
        target:
          entity_id: input_boolean.waschmaschine_lauft
      - service: input_datetime.set_datetime
        metadata: {}
        data:
          datetime: "{{ now() }}"
        target:
          entity_id: input_datetime.waschmaschine_fertig
      - delay:
          hours: 0
          minutes: 0
          seconds: 5
          milliseconds: 0
      - service: notify.notify
        data:
          message: Hey, Wäsche ist fertig! 👕
          title: Waschmaschine
mode: single

Anything in the logs that might be useful for us?

No response

Additional information

No response

[BIGede]

I have the same issue with Nous plugs (Zigbee2MQTT). I don't have this issue with other WLAN plugs from Shelly or Meross.

We are currently trying to solve the problem by leaving the plugs sockets switched off. The problem only occurs when they are on.

2024.4.4 and the same automation.

[erkr]

Maybe you can add a condition to catch a trigger after a restart. Check the value of trigger.from_state.state. If that is unavailable, it is easy to ignore the trigger with a condition

[Soulfly999]

Maybe you can add a condition to catch a trigger after a restart. Check the value of trigger.from_state.state. If that is unavailable, it is easy to ignore the trigger with a condition

Thank you for your reply, yeah you're right, just want to say something has changed with 2024.4.!? Otherwise, could it be a Zigbee Problem?

- condition: template value_template: >- {{ as_timestamp(now(), default=0) >= as_timestamp(states('sensor.last_boot'), default=0) + 300 }}

[erkr]

@bdraco did improve the HA start up time several releases in a row. Side effect is that more templates, scripts and automations can address entities that are not yet available. I think your example is a result of that as well.

Side note: a delay of 5 minutes will probably work, but is kind of a last resort. In your case, check the content of the trigger in your automation (changed variables in the first step):

I expect the offending trigger during startup has a from_state.state that is unavailable in stead of a valid state. A condition checking on that value is without a timeout and will never block a valid trigger during the timeout period! Because the entity changes from state unavailable to a valid number, I think you receive a number trigger at startup where the from_state is unavailable

[bdraco]

Automations don't start until the start event is fired. Its up to the individual integration to make the state available before the start event fires. They can choose to do that or not as integrations can choose to create tracked or untracked tasks (untracked tasks are not waited for)

[amelchio]

While it is possible that the integration could be improved to provide a valid intial value, the problem here is a bit more fundamental.

These phantom triggers might also fire when a sensor returns from a legitimate unavailable state, for example after connection issues or battery replacements.

I believe that numeric_state should never fire when coming from unavailable but I have failed to convince anybody about that. Thus, everyone that wants predictable triggers has to create a condition by hand and filter out the invalid ones like @erkr suggested above.

[issue-triage-workflows[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.