Automation on a particular day

Configuration
21

Well,
I changed the test automation to clean in up, take less space, sort the quotes etc. and toggle every 2 minutes, ended up with : -

automation:
  - alias: Now Test Automation
    trigger:
      - platform: template
        value_template:  "{{ now().strftime('%F') == (now().strftime('%Y') | int ) ~ '-03-12' and now().strftime('%R') [4:5] | int in [0,2,4,6,8] }}"
    action:
      - service: input_boolean.toggle
        entity_id: input_boolean.ib_global_test

Without any further intervention from me this now toggles the boolean every two minutes - This Should Not Work ! But it does !

Admittedly I just hate this, I wouldn’t rely on it cos it may just be that someone will find the error and correct it so it won’t work next week !
Interestingly my processor usage and average load has not budged so It’s not even consuming much resources. WEIRD !

22

Yep which is why I said : -

It’s cgtobi 's template from the post quoted

23

Thanks for the replies I used the following code.

  condition:
    condition: time
  # At least one of the following is required.
    weekday:
      - fri

Regards
James

24

We should be thanking both you and @daveyrb, this has highlighted a potentially serious issue :+1:

25

It’s not long winded… it’s just wrong. It’s omitting a return value for false.

1 Like
26

Point Taken

I just looked at it, saw it was trying to give a True/False but had evaluated the necessary bit, didn’t see the point in the rest and discontinued reading.
My Bad - Thanks for pointing it out

27

Results of my experiment:

I created four automations, each with one of the following Template Triggers:

      value_template: "{{ now().minute % 2 == 0 }}"

      value_template: "{{ now().minute >= 0 }}"

      value_template: "{{ now().minute - 1 + 1 >= 0 }"

      value_template: "{{ now().strftime('%F') == now().strftime('%Y') ~ '-03-12' and now().minute >= 0 }}"
  • All four templates have no identifiable entities and all rely on the now() function.
  • Each automation’s action simply toggled an input_boolean.
  • Only the automation using the first template worked (i.e. it toggled the input_boolean on even minutes).

It’s an interesting result and, on the face of it, challenges the documentation’s broad assertion that the template must contain an identifiable entity and that now() cannot be used as a trigger. However, it’s a very subtle exception to the rule because 3 out of the 4 variations failed to work.

  • The second template relies on now() but doesn’t trigger the automation.
  • The third template does some simple arithmetic but doesn’t trigger the automation.
  • The fourth template adds string concatenation but also fails to trigger the automation.
  • The first one is almost the same as the second one but performs integer division and that seems to make a difference. In the case of the first template, Home Assistant appears to have assigned a listener to the automation’s trigger. :thinking:

For anyone who wishes to try this for themselves:

- alias: 'Toggle every even minute'
  trigger:
    - platform: template
      value_template: "{{ now().minute % 2 == 0 }}"
  action:
    - service: input_boolean.toggle
      entity_id: input_boolean.flash

Screenshot from 2020-03-12 12-42-01

28

I have submitted the issue on github but your tests are ‘interesting’ I’ll edit my post to add (a link) to your analysis :+1:

29

looking at your templates, they ALL seem to ALWAYS evaluate to True apart from the first

And @daveyrb 's uses the time to evaluate, not just the minute, mine takes the time and strips to the last ‘unit value’ of minute as well (so mines well less efficient aswell).

30

Only the first is capable of returning false but the template has to be evaluated in order to determine that. What’s causing the template to be evaluated? It would be a listener assigned to monitor it. That listener appears to be evaluating it when now().minute changes value. So why aren’t the other three templates being handled the same way? I don’t know the answer to that.

31

it’s does not use what’s already there (days) and therefore is slower/worse - that’s true.
but I think there is nothing wrong in not returning False - the docs say only about True and anything else (including None which is most likely what it gets) is interpreted as “not True” i.e “False”.

32

Seems that long nights are not so good :frowning:
Tried example by Taras123 in post 31- all works but how to reset the binary sensor after expire- 0:00 next day? Now it remains active despite date change.
TIA and best, JR
And another q: how to find out e.g. 3rd Sunday in May in template?

33

You’ll have to clarify which post you’re talking about, try quoting it. Post 31 is the post before yours. Not 123’s post.

34

Sorry… as I said looooong night coding :frowning:
This was Taras (123) post #15…
Can not see why binary_sensor did not reset at midnight (and the group also remained true) so it reminded me the next day too (wrong date) - with developer tools all works OK… go figure… will try again today.
And is this very primitive way to find out e.g. second Sunday in November like this:

{{ now().month == 11 and now().isoweekday() == 7 and now().day > 7 and now().day < 15 }}

Sorry for misinformation- next time will rest before coding again :slight_smile:
Best, JR

35

Did you configure the Time & Date integration? The binary_sensors are updated when sensor.date changes state which is once per day at the start of the day. You must define sensor.date using the Time & Date integration.

1 Like
36

That is really embarrassing :frowning:
How could I stupidly run HA for 3 years without it and all was neat :slight_smile:
Somehow I assumed it is included by default- so RTFM more frequently (note to myself)!
Thank You- saved my weekend …
Best, JR

37

IMO it should be included. But I believe it isn’t because of the frequent history db writes.

1 Like
38

But we can restrict writes with logbook: (recorder) and history: excludes?
Best, JR