Automation not triggering automatically, but does in dev tools

Hi, new HA user here. I’ve created several automations that worked one day, not the next… when I test the conditions, they seem to be working, but when an automation should be triggered, it’s failing on input_number.bedroom_ac_input comparison… it’s evaluating/showing as FALSE, but it’s actually true when I test it in the debugger.

The YAML code is:

alias: >-
  B4-Set bedroom A/C at 75 when outside temp between 40 and 55 degrees (with AC
  setting check)
description: ""
triggers:
  - trigger: state
    entity_id:
      - sensor.openweathermap_apparent_temperature
    from: null
    enabled: true
  - trigger: numeric_state
    entity_id:
      - sensor.openweathermap_apparent_temperature
    above: 40
    below: 55
    enabled: true
conditions:
  - condition: time
    after: "07:00:00"
    before: "21:00:00"
    weekday:
      - sun
      - mon
      - tue
      - wed
      - thu
      - fri
      - sat
  - condition: template
    value_template: |-
      {% set temp = states('input_number.bedroom_ac_temp') | int(0) %}

      Current value = {{ temp }} → 
      {% if temp != 75 %}True (does not equal 75)
      {% else %}False (same){% endif %}
actions:
  - action: input_number.set_value
    data:
      value: 75
    target:
      entity_id: input_number.bedroom_ac_temp
  - action: alexa_devices.send_text_command
    metadata: {}
    data:
      device_id: 6ce7d0964da5034a1f99550aec661525
      text_command: Turn on bedroom air conditioner
  - action: alexa_devices.send_text_command
    metadata: {}
    data:
      device_id: 6ce7d0964da5034a1f99550aec661525
      text_command: |-
        {% set temp = states('input_number.livingroom_ac_temp') | int(0) %}
        set bedroom air conditioner at {{ temp }} degrees
  - action: notify.mobile_app_ray_phone_sma64
    metadata: {}
    data:
      message: >-
        B4-Bedroom A/C set to {{ states('input_number.bedroom_ac_temp') }}°,
        25‑40 °F mode
mode: single

The automation tried to run just after 7am (in the time range), and the input_number.bedroom_ac_temp was at 69.

The automation condition for temp returned false, but when I tested it with the same setting, it returned true… so SHOULD have run.

I then ran an automation.trigger with that same automation and it ran.

Can anyone shed some light on why this would do this?

Thanks.

It’s the classic issue of the trigger already being in the range and therefore not triggering.
A trigger needs to be false then switch to true in order to trigger an automation

Sorry, I don’t understand what you’re saying… the test on input_number.bedroom_ac_temp was that 69 != 75, which should evaluate to TRUE and pass that condition. As I understood a template condition, it passed as TRUE, failed as FALSE. Am I not understanding that correctly? I did not know them to have a previous state…

The triggers ARE firing and passing… the condition is not.

Not sure why you have the state trigger - it doesn’t seem to do anything. Have you read the bit in the docs about numeric state triggers?

Yes but that is your condition, not the trigger

Could you explain what you are trying to do with this automation? Your comment say set the ac to 75 when it’s in a specific temp range outside. Is it a heat pump that only works in that range so you don’t want it on otherwise?

Or do you want it on at 75 degrees just during those hours?

Is that the actual template you are using… If so, you need to remove all the nonsense that makes it not resolve to plain true or false.

  - condition: template
    value_template: |-
      {% set temp = states('input_number.bedroom_ac_temp') | int(0) %}
      {{ temp != 75 }}

It does do something… I set the state trigger when I adjust the A/C (heat) up or down, to match the setting of the unit. Then I check in the automations to see if the one triggered by outside temp matches the SAVED temp in the state. If it matches, it does not run, but if it does NOT match 69<>75, it should run. Then I set the state to 75 for reference later. It worked fine for a few days, then just seemed to stop working.

The ‘triggers’ are working… the condition is causing it to not ‘trigger’ or run… maybe my terms don’t match, but that’s the issue. The condition works when I test it, but not when the automation runs automatically and it’s set to the same value as the test.

So it will only fire when it changes (is it actually ever null as a literal value?)

or if it changes from outside this range to a value within this range:

After that is has to pass the conditions as well to get to the action statement.

My suggestion, trigger on any change of that apparent temperature and use the condition that Drew posted, as the one you posted in your code looks like an AI having a bad day wrote it and I doubt that it would work.

Unfortunately, my mini-splits run constantly, just the fan if no heat or cool is requested… so I want to turn them off completely when not needed. The company gave a suggestion to turn off the fan when I got them, but it does not work and they don’t know why. I spent days on that. So now, I set them at a temp, save the temp setting to the input_number.xxx_ac_temp (I have 3 different ones), and if that setting does NOT match (in the condition) when one of my automations is triggered, it runs and resets the state variable. If it’s already AT that setting, it does not run the actions. I do this because I cannot ask what the current temp on the A/C is at on mine. The range of hours is because I set it at a certain temp overnight, cooler. and don’t want that reset from 10pm to 7am.

Yes, that’s the template. The extra stuff was there for debugging, per online suggestions, and I just left it there because in TESTING, it works 100% of the time… just not in automatic operation when triggered… I will try removing some to see what it does. I have these in MANY of my automations that work fine so far…

Thanks for the info… to answer your questions…

It’s never null (unless I made a mistake in one automation and did not set one, but so far, I have not seen that case), but I set it in the actions of each one when it performs the actions.

Yes, I saw Drew’s post and will try removing them… yes, it was a suggestion for debugging and since it worked 100% of the time when testing, I left the comments in there. Figured it should work all the time.

By default, the automation.trigger action skips all trigger and condition logic. It always runs the actions unless you set the skip_condition variable to false.

That would account for the discrepancy you are describing between “testing” and “natural” automation triggers.

Is this for both heating and cooling?

  1. You want to turn off the unit (to power down the fans) when not needed. How do you know when you need heat or cool if you don’t know the room temp?

  2. You want to set different temps based on time of day?

Do you understand that first trigger says trigger on any change of state, so the second trigger doesn’t really do anything?

triggers:
  - trigger: state
    entity_id:
      - sensor.openweathermap_apparent_temperature
    from: null
    enabled: true
  - trigger: numeric_state
    entity_id:
      - sensor.openweathermap_apparent_temperature
    above: 40
    below: 55
    enabled: true

Is there no integraton for your system? Using Alexa to control it seems not ideal.

I did set the skip_condition to false when testing.

I’m using the current “apparent temperatur” outside and determining what setting I want them at from that. Seems to work fine and I can adjust the automations as I go, to perfect them. I’m working on replacing my thermostats in the home to WiFi smart t-stats to hopefully be able to use them maybe.

I do have different automations based on the outside temps, for example, below 25 degrees outside, 25 to 40 outside, 40 to 55, 55 to 65 and over 70… subject to change.

I am new to this, so no, I JUST realized that not BOTH triggers had to be true to trigger it, so I’ve since moved the RANGE temps to a condition.

There is no integration right now that I have, but I hear that I can purchase a different/new dongle for $100 each… I don’t want to spend $300 for that if this works. Yes, it’s kind of a PITA, but I’ll deal… I’m retired and having fun learning this… my son also has it set up in his home, so we’re kind of working on them at the same time.

That’s not true. It’s any trigger that will, eh, trigger it.

What’s the point of that first trigger.

I’m a bit baffled by how the outside temp would be a good measure to know what to set the thermostat at.

What’s the make/model of your mini-split? (The fan running all the time is something the installer needs to fix. That’s doesn’t make sense.)

They were not triggering when testing because the temp was already in the range it was testing for, so I put the 2nd one in to get it to trigger on any change. I’ve since moved the range down to a condition to see what that does.

Outside temp is all I have to work with… and it’s completely relative. If it goes down outside, it gets colder and we need to run them higher to keep a suitable temp inside. We run them year-round and when it gets down to -15 here, we set them up around 77 to 79 and they keep up quite well, but at 72, not so much. Why is that a big deal? I don’t want to run my boiler if possible. I am down from 3+ tanks of oil to about 1 per year now. Paid for the splits in about two years or less.

Self installed, Senville, but when I installed them three years ago, went back and forth with them on instructions they gave me to “turn off” the fans when they’re not “running”, and it never worked, no matter what I did. Installer who checked them all out for warranty per Senville said they were all fine and that he’s seen that on them, too. Then offered me a job. They stop cooling, but fans on all three run constantly… just slow down and speed up as called for more/less.

Thanks to all the replies. I’ve got it working and assume it was the extraneous text that was in the code that was the issue. They’re all triggering properly and so far, I think all my conditions on all the automations are working correctly.