FR Time pattern trigger: Allow higher seconds/minutes than 59

[Mariusthvdb (Marius)]

as a direct follow up of the discussion in scan_interval being deprecated for the Ping sensor in 2023.12

the need for an easy way of triggering that ping tracker has surfaced more evidently.

(there’s no discussion on that matter here, the way forward is disabling automatic polling and use ones own trigger schedule if the built-in interval of 30 secs since 2023.12.1 does not fit ones needs.)

in Automation Trigger - Home Assistant

we can only use seconds/minutes number between 0 an 59

• Automation with ID ‘test_trigger_pattern’ failed to setup triggers and has been disabled: must be a value between 0 and 59 for dictionary value @ data[‘seconds’]. Got None

As a follow up of Time pattern trigger for every 90 seconds - #4 by 123

where this example is provided to have an automation trigger every 75 seconds

trigger:
  - platform: time_pattern
    seconds: '/15'
condition: '{{ (now().hour * 3600 + now().minute * 60 + now().second) % 75 == 0 }}'

and

@123

If you want every 90 seconds (like it says in the topic’s title), change '/15' to '/30' and change 75 to 90.

and the same would apply for minutes above 59 and hours above 24:

Taras also suggested this shorter version:

{{ now().timestamp() | int(0) % 90 == 0 }}

Use it as a condition with a 30-second Time Pattern Trigger (as explained in the linked example) or simply as a Template Trigger.

Of course, this is still a bit complex, and not as straightforward and simple as

  trigger:
    - platform: time_pattern
      seconds: /90 # same for minutes

please allow using an absolute number of seconds or minutes higher than 59 in the time_pattern trigger, and have the backend recalculate that to the correct internal requirements.

or, introduce a new trigger if the above seemingly simple change would require complete rewrite…

[mwav3 (Tim)]

+vote from me. I was surprised to see the error when i tried 90 seconds in that box.

[123 (Taras)]

I voted but everyone should be aware that this represents a departure from the Time Pattern Trigger’s currently documented behavior.

You can prefix the value with a / to match whenever the value is divisible by that number.

The “value” is the current time value. In other words, a maximum of 60 for seconds and minutes and a maximum of 24 for hours.

This example:

minutes: /20

means it should trigger whenever the time in minutes, 0 to 60, is evenly divisible by 20. That means at 0, 20, and 40.

Other than 0, you can’t evenly divide 1 through 60 by 90 so that’s why /90 fails to work.

In order to support this FR, the Time Pattern Trigger will need to handle / in a completely different way. Arguably it will be more intuitive, given that many users assume you can use any integer value, but different nonetheless.

I think the first challenge for implementing this FR will be answering this question:

Starting from when?

If /90 means “every 90 seconds”, when should it start counting? Starting at the moment the automation is saved? Starting at the beginning of the next hour/minute/second? Whoever volunteers to implement this FR will need to choose a starting point.

All this to say that this FR will cause existing Time Pattern Triggers to behave differently from the way they do now; it’s a breaking change.

[Mariusthvdb (Marius)]

It was already suggested to not change the current behavior, but maybe introduce a new.

You are absolutely right and that would be a big change to handle.

Probably a new field with new functionality would be best.

I believe Petro suggested something like

total_seconds: \90