2hr state automation trigger doesn't work

Configuration
1

Hi,

I’m trying to create an automation to send a notification when the AC has been left on for 2 hours.

For some reason the following:

for:
  hours: 2

doesn’t work, but:

for:
  seconds: 10

works as expected.

AFAIK, there is no known limit with hours so I can’t think of a reason this won’t work.
The automation does not even trigger at all (so it is not a problem with the action).
I could theoretically use minutes: 120 or seconds: 7200 but obviously this would be very inconvenient.

Attached is the full automation:

- alias: 'AC On Reminder'
  initial_state: 'on'
  trigger:
    - platform: state
      entity_id: climate.living_room_ac
      from: 'idle'
      to: 'cool'
      for:
        hours: 2
  action:
    - service: notify.notify
      data_template:
        message: "The Living Room AC is on for {{ (trigger.for.seconds/3600) | int }} hours."

Am I missing something?

Thanks in advance!

2

Are you sure that your device isn’t going from ‘cool’ to ‘cool’ with in that time period? That would drop that timer I believe. You should look at your events in the log over that time period and verify that another event isn’t occurring.

3

Hi @petro, so I thought about it and it makes sense! Since climate is tied to a temperature sensor, every time that sensor updates it triggers a state change. Since my sensors updates every 1 hour, a 2hr trigger is quite impossible. Wondering if there’s an alternative? I could use an input_datetime to automate it but I am wondering whether there is a simpler solution?

4

You could start a timer the old fashion way. It requires 2 scripts though. Here is an example of my ‘door light’ timer:

Main script:

alias: Entry Door is Open
sequence:
  # Cancel ev. old timers
  - service: script.turn_off
    data:
      entity_id: script.entry_light_timer
  - service: switch.turn_on
    data:
      entity_id: switch.entry_s_switch_17_0
  # Set new timer
  - service: script.turn_on
    data:
      entity_id: script.entry_light_timer

timer script:

alias: Entry Light Timer
sequence:
  - delay:
      minutes: 2
  - service: switch.turn_off
    data:
      entity_id: switch.entry_s_switch_17_0

in the automation that fires it:

- alias: Entry light trigger on entry door 
  trigger:
    - platform: state
      entity_id: sensor.entry_door_hindge
      to: 'open'
  condition:
    - condition: state
      entity_id: sun.sun
      state: "below_horizon"
  action:
    - service: homeassistant.turn_on
      entity_id: script.entry_door_is_open

So your automations would be close but you’d remove your for: hours:2 and then call your script that starts a timer.

How it works:

When the door opens, it turns on the light and starts the timer. If the door closes and reopens, the timer is cleared and starts again. When the timer ends, it turns off the light.

You would just send your notification instead of turning anything on or off. Just make sure you put the notification after the delay in the main script.

5

There’s a timer component now that might be more flexible/dependable.

Start the timer when AC goes to “cool”. Watch for the “timer finished” event to turn it off.

1 Like
6

What are the actual states you’ve seen for climate.living_room_ac?

Each climate platform is different, so it depends on what yours is. (E.g., I have a Nest thermostat, and the corresponding climate’s possible states are off, heat, cool, auto, & eco. Note that there is no idle state for this climate platform.) Hint: If you look at your climate entity on the States page, you might see an attribute named operation_list. If so, then that attribute lists all the possible values for the operation_mode attribute, which is reported as the climate entity’s state (with the possible addition of ‘off’ and ‘on’.)

If your climate entity never has a state of idle, then your trigger would not work, because it would never go from idle to cool. I would suggest simplifying the trigger and just specify the ‘to’ state.

Regarding when the state changes, and when that would affect your automation’s trigger, even if the entity’s attributes change, by specifying a ‘to’ value, the trigger is only then affected when the state actually changes (i.e., not just when an attribute, e.g., the temperature, changes.)

So, basically, I think you should simply change your original automation’s trigger by deleting the “from: ‘idle’” line.