Struggling with template trigger

If I use the following template in the dev panel, it works, but it doesn’t trigger my automation.

- alias: 'Salt lamp auto OFF with phones'
    trigger:
      - platform: time
        at: '21:00:00'
      - platform: template
        value_template: "{{ state_attr('sensor.daves_s7_battery_level', 'is_charging') }}"   ### Dave's S7 on charge?
    condition:
      - condition: time
        after: '21:00:00'
      - condition: template
        value_template: "{{ state_attr('sensor.daves_s7_battery_level', 'is_charging') }}"   ### Dave's S7 on charge?
    action:
      - service: light.turn_off
        entity_id: light.salt_lamp

Can someone please explain what I’m doing wrong?

I tried changing the template to:
value_template: "{{ is_state_attr('sensor.daves_s7_battery_level', 'is_charging') }}"

…based on the docs but that doesn’t work in the dev panel

Try after 20:59:59 for the condition

Can you show us the screen print of the states page for sensor.daves_s7_battery_level, with the attribute you’re looking at highlighted please?

You’re currently saying that you want to check an attribute called ‘is_charging’ but aren’t saying what you want it to be.

Yeah, I wonder if that sensor really has an attribute with that name. But if it did, as long as it is some form of true and something else, it should work.

I think my point was that if the phone is plugged into the charger at (say) 20:100:when the trigger goes at 21:00 then the condition will stop as its not technically ‘after’ 21:00
Insted it’s == 21:00
Or does after 21:00 mean => 21:00

First, the time the condition is checking against is the exact time at which the code gets to evaluating the condition. That will always be after the trigger, because no matter how fast the machine is that is running HA, it can’t get from evaluating the trigger to evaluating the condition instantaneously. Next, the way the check is done it will be true as long as the current time is >= after.

So basically:

- trigger:
  - platform: time
    at: A_TIME
- condition:
  - condition: time
    after: A_TIME

Is always guaranteed to work. And, yes, it should probably be named at_or_after. :wink:

Okay, understood (it’s a bit like knowing that the numeric triggers ‘need’ to transition)

Dave is suspiciously quiet on this subject, he’s left it a FULL day :scream_cat:

I think the main reason it’s not working is the way it’s implemented - it just looks odd to have exactly the same in trigger and condition.
I’d say change your automation to condition-less template trigger.

Also, this

is very suspicious and your “working” template might not return True/False - what does it show in template editor?

Hi all, sorry I was busy yesterday so didn’t get back on here to reply.
An update though, I plugged my phone in last night and the automation worked perfectly. So I think I had just been testing it wrong previously. The code posted above does in fact work :grinning:

What value does this return?

{{ state_attr('sensor.daves_s7_battery_level', 'is_charging') }}

Is has to return a boolean True or False to satisfy the Template Trigger’s requirements.

You also tried this:

{{is_state_attr('sensor.daves_s7_battery_level', 'is_charging') }}

You’ve only supplied two parameters but is_state_attr required three.

I know nothing about the sensor but if its state can be is_charging then you want this for the Template Trigger:

value_template: "{{states('sensor.daves_s7_battery_level') == 'is_charging')}}"

If is_charging is not of the sensor’s possible state values but the name of one of its attributes, then we need to know what values that attribute can have and which specific value you want to use for triggering the automation.

Just to close out some of the above questions, the sensor does have a attribute ‘is_charging’
image

Having the trigger and condition the same does work as this allows for the automation to trigger on either state but require them to both be true to cause the action.

OK, try this in the Template Editor:

{{ state_attr('sensor.daves_s7_battery_level', 'is_charging')  is string }}

It will report False if the attribute’s true value is a boolean (or True if it’s a string).

Hi Taras, it’s ok as the automation is in fact working as written in my initial post. It was just that for some reason my testing didn’t seem to work

Well, it just looks a bit unnecessary to me as you can do exactly the same in just one template instead of two which means a) less (and more intuitive) code, b) easier to maintain and c) to debug (and d) less room for error).
But I take it that you are pretty happy with it anyway so no worries then :wink:

my experience with templates is quite the opposite. simple triggers and conditions are less likely to cause headaches than templates.

more than happy to see your idea

yeah, but a lot of repetitive conditions/triggers is difficult to handle.
in the end of the day it’s down to how close you’re with Jinja :wink:

Here’s my suggestion - get rid of the condition and use this trigger

trigger:
  - platform: template
    value_template: >
      {{
        states('sensor.time') > '21:00' and
        state_attr('sensor.daves_s7_battery_level', 'is_charging')
      }}

I think it’s a 100% replacement to your original automation.
I’m not 100% sure but it might be that without before your automation worked only between 9pm and midnight.
If you want it to work until next morning (say, 6am), you just add another condition to your template

- platform: template
  value_template: >
    {% set time = states('sensor.time') %}
    {{
      (time > '21:00' or time < '06:00') and
      state_attr('sensor.daves_s7_battery_level', 'is_charging')
    }}

OK, that means the attribute’s value is a boolean. Glad to hear you sorted out the testing procedure.

You are wrong, this is ‘normal’ coding format to allow two triggers, but reguire BOTH conditions to be true.
Dave has been doing this a LOT longer than you or I and Taras has been doing it a LOT longer than all 3 of us combined. He thought it okay and was just testing the existence of an entity.
The alternative would be to write a long template sensor (VERY not easy to maintain but doable for Dave) or do it in Python, which seems to be your ‘goto’ solution.

I know about this approach. Just pointed out that in this particular case it’s not necessary and can be replaced by a simple template trigger. I posted it so you can examine it and tell me if it does not work, I’m more than happy to learn.

I did not say that about anyone else’s code/approach here - what’s up with you?

Oh, don’t have a ruler… So just because of that it is prohibited to question validity of code written by anyone more experienced than yourself or I misunderstood you? I’ll write it down in my book for the future reference.

I honestly give up !
It is you who have been ‘insulting’ and your less than snappy passive agressive comebacks are just wearing. Goodbye

Edit: For Review