I Thought My Automations Were Unreliable, but It Was Only My Incorrect Understanding

Hey all,

I’ve been using HA for a while, currently on 0.100, and since around 0.70 I’ve found some of my automations to be unreliable. I’m not sure how to troubleshoot as I haven’t found any relevant logs.

Some automations just stop working. They do work at first, then stop. I’ve confirmed that the required thresholds are met, but the automation isn’t triggered… Or maybe it is triggered but is stopped due to a condition. I haven’t found any logs that show the automation process. But all the criteria are being met.

The thing is, if I go in to the HA web interface, go to automations, and turn the broken automation off and on, it start working again… For a while…

This doesn’t seem to happen with all automations, it’s mostly ones that have numeric triggers or conditions that are referencing temperatures, and conditions based on climate states. Not sure if any of those are relevant.

Is this something other people have run in to? Are there some logs somewhere that might show some details of what’s going wrong?

If you post one of the automations you’re having trouble with we may be able to comment on why it might not be working as you expect.

Regarding logs, have you looked in home-assistant.log? There should be enough detail there to give you some clues. If not, you can try enabling some additional debug information with:

  default: info
    homeassistant.core: debug

Automations with numeric_state in the trigger will only trigger if the state goes below or above the threshold you’ve defined. If it’s already above or below, it won’t trigger. That might be relevant to the issue.

But yes, as Phil said, please post one of the automations.

Thanks Phil,

I have checked home-assistant.log but it doesn’t include any events related to these automations. I’ll add the config to enable debug logging and see if that changes.

This is an example of an automation that breaks, I have a suspicion that the more conditions I add the more likely it is to break, but that’s hard to confirm as I can’t reproduce it intentionally.

- id: '1519218765208'
  alias: Bedroom AC Off
  - below: '21'
    entity_id: sensor.bom_brisbane_feels_like_c
    platform: numeric_state
  - below: '23'
    condition: numeric_state
    entity_id: sensor.inside_temperature_bed_room_inside_temperature
  - condition: or
    - condition: state
      entity_id: climate.bed_room
      state: cool
    - condition: state
      entity_id: climate.bed_room
      state: heat_cool
  - data:
      entity_id: climate.bed_room
      hvac_mode: 'off'
    service: climate.set_hvac_mode
  - data:
      message: ' Outside feels like under 21 and inside is under 23, turning off aircon
        at {{now()}}'
      title: 'AC Off: Bedroom room'
    service: persistent_notification.create

Are you sure your automations are always on? Do you have intitial state set? I don’t recall what version this change was made in.

Looks like data: in the last service call needs to be data_template:.

Thanks Tediore,

That might be something actually. I’m not sure it’d explain all the cases I’m seeing but it could definitely explain some.

Is there a way to work around that? I guess I could just trigger every minute and put all the numeric_states in conditions?

The service call for the notification? I’m happy to change it, but when it does trigger, the notification does work.

First, are you sure the states of climate.bed_room are still cool and heat_cool? The climate component went through a significant change recently and I’m not sure heat_cool is a valid state. Something to check.

Next, if you enable core debugging, then you may find a script I wrote useful. It will search home-assistant.log for entity state changes and list them out (optionally outputting attributes as well.) I found it a bit easier to use than SQL (not a database guy. :slight_smile:) Let me know if you’re interested.

Interesting. Maybe that service call is different.

What used to be just auto is now auto and heat_cool. Although, despite reading the changelog for 0.96 several times, I can’t quite figure out what auto is supposed to be now.

Thanks silvrr,

I don’t have initial_state set, I thought it defaulted to on, but I’ll add it in to see if it helps.

CRINGE!!! :nauseated_face:

1 Like

Some notification services (maybe all???) accept templates and process the templates themselves. Which can work fine, unless you want to use the trigger variable, then…

Huh. TIL. I’ve always had to use data_template for Pushbullet.

Yeah I’d prefer not to trigger every minute, I’m open to suggestions :wink:

I’ve added initial_state: true and changed data to data_template on the persistent notification. Manual trigger worked fine, but I won’t know for a while whether its fixed the issue.

As @Tediore pointed out, the automation will only trigger when sensor.bom_brisbane_feels_like_c changes from a value of 21 or above to below 21, and if at that point the other conditions are met.

Do you want it to trigger whenever all those conditions are met? If so, you could do it with a template trigger:

    platform: template
    value_template: >
      {{ states('sensor.bom_brisbane_feels_like_c')|float < 21 and
         states('sensor.inside_temperature_bed_room_inside_temperature')|float < 23 and
         states('climate.bed_room') in ('cool', 'heat_cool') }}

This will trigger whenever the template evaluation changes from False to True.

Now that is a sexy template if I’ve ever seen one. I prefer float() over using the pipe, but that’s just me. :wink:

Learn to love the pipe (aka filter):


1 Like

Oh no.

That’s good to know, thanks.

Although, I suppose there could be some instances where I prefer Unknown over 0.0. Maybe.