The only “result” that’s important here is that a Time Pattern Trigger cannot be configured to trigger every 90 minutes.
The closest approximation is what Troon proposed, to trigger on each half-hour and then calculate if it’s a multiple of 90.
So, you became the committee leader to pick what is the most important and what is the best solution. You are not helping at all yourself. 
and yes, you are totally right that your findings, 
for you. I just tried to close the topic nicely without making any hard feelings and you will want to continue, why? I am not able to understand your reasoning. You can be the last responder after this message and enjoy being the last
1 Like
I never said it was the “best solution” I said it was the closest approximation (for using a Time Pattern Trigger to execute every 90 minutes) and that’s based on what has been suggested in this thread (so far).
I can think of another way to trigger every 90 minutes, involving an input_datetime plus a service call, but it wouldn’t be anywhere near as concise as either of Troon’s two suggestions.
Based on what I have learned over the past two and a half years, it would be challenging to devise a more compact technique. So I feel it’s fair to say that, for the easiest way to trigger an automation every 90 minutes, Troon’s suggestion definitely falls in the ‘best of breed’ category and deserves a Solution tag.
Although not exactly “easy”, as requested in the topic’s title, pyscript supports cron triggers so having it execute every 90 minutes would be straightforward (assuming one is already invested in pyscript).
1 Like
this looks simplest, agree. i would concern about downtime cases but it should not matter in this specific context a lot.
just for the sake of experiment:
template:
- binary_sensor:
name: Per 90 minutes
state: >
{{(now().hour*60+now().minute)%90==0}}
and:
automation:
- alias: excute per 90 minutes
id: excute per 90 minutes
trigger:
platform: state
entity_id: binary_sensor.per_90_minutes
to: 'on'
mode: restart
action:
- service:
would that work?
btw, the difference between the way @troon 's automation works and my suggestion, is that with Troon, the automation follows the clock, and my automation follows the automation, no matter the clock.
That difference could make the difference 
Yours would trigger at 90 and 91 minutes. You need a to: 'on' in the trigger.
1 Like
of course… sorry adjusted in the post above
I often create these helpers, to make for easier automations… just an old habit I guess, plus, often I can reuse these helpers in other places in the config.
troons would be less resource intensive though. His firing every 30 minutes vs yours firing every minute (on the template thread). Granted it’s still better than a template trigger.
If the point is actually to run an automation every 90 minutes, wouldn’t
- id: e6aeb207-e42f-492d-b7f6-2b8d0f7dde62
alias: The Automation
trigger:
- platform: time_pattern
minutes: "/1"
condition:
- condition: template
value_template: >-
{% set sinceLastTriggerMinutes = ((now().timestamp() - as_timestamp(states.automation.the_automation.attributes.last_triggered)) / 60) | int %}
{{ sinceLastTriggerMinutes %90 == 0 }}
action:
- service: sprinkler.run
be better (assuming the automation ran at least once)?
It also survives restarts.
Would work with one caveat, if the automation is brand new, last triggered value is None, so it will throw an error. Either run automation once manually and get rid of initializing part or fallback to last updated if it is None. I shared an example above.
Yeah, hence the “assuming the automation ran at least once”.
As it is a one time initialisation, better to run it manually once, or you would test for years for a condition that will never happen anymore after the 1st run.
The advantage of Troon’s version is that it evaluates its condition every 30 minutes versus every minute. That’s 30 times less “work” to do. In addition the template doesn’t rely on the automation’s last_triggered attribute so it’s unaffected by initial conditions (when the attribute has no value).
Earlier I called it ‘best of breed’ because I feel it is challenging to devise something that is more concise and efficient. Many months ago I mused that this would be easy to do if there was something like a Time Cron Trigger but there has never been much interest in adding such a feature. I base that opinion on my 2.5 year-old Feature Request which has collected a mere 21 votes.
I think it’s because a total of 21 people on this forums knows cron. If others are like myself, most people came from windows or mac and linux functions are a mystery. It would be nice to have, but getting people who don’t know what it is to vote for it would be hard and your feature request title doesn’t really spell it out.
I thought the “Full-featured scheduling” would be the draw but a grand total of 21 votes over 2.5 years says “Nope!” 
FWIW, cron-style scheduling is available in Pyscript’s @time_trigger but using Pyscript is probably a bridge too far for most users (especially if this is the only use-case they have).
No question it’s better if you want to run an automation precisely on the hours and a half.
My suggestion is, e.g., if you run an automation first on sunrise (or any trigger), then want it very 90 minutes, like the OP suggested.
EDIT: There are now 22 persons on the forum knowing about cron 
You’re right; the original request was to start the first 90-minute interval at sunrise (not midnight). Your suggestion satisfies that requirement.
What’s interesting is that this topic’s author never replied to any of the posts when it was first created almost a year ago. Perhaps they simply created a repeating 90-minute timer that is started at sunrise and cancelled at sunset. Meanwhile, world+dog continues to perfect the ‘all in one’ 90-minute trigger.
2 Likes
My first version could test the modulo operation for any value, not just zero. OP could evaluate that number at sunrise as a trigger-based template sensor, then plug that into the template in place of the zero.
template:
- trigger:
- platform: state
entity_id: sun.sun
state: "above_horizon"
sensor:
- name: Sunrise minutes offset
state: "{{ (now().hour*60+now().minute)%90 }}"
and the automation:
trigger:
- platform: template
value_template: >-
{{ (now().hour*60 + now().minute)%90 ==
states('sensor.sunrise_minutes_offset') }}"
condition:
- condition: state
entity_id: sun.sun
state: "above_horizon"
Should trigger at sunrise (when the sensor gets updated) and every 90 mins thereafter until the sun goes down. This wouldn’t survive restarts, but would be easy to drop the number into an input_number instead of the sensor if that’s important:
alias: Record the sunrise offset
trigger:
- platform: state
entity_id: sun.sun
to: "above_horizon"
action:
- service: input_number.set_value
data:
entity_id: input_number.sun_offset
value: "{{ (now().hour*60+now().minute)%90 }}"
alias: Run every 90 mins from sunrise
trigger:
- platform: template
value_template: >-
{{ (now().hour*60 + now().minute)%90 ==
states('input_number.sun_offset') }}"
condition:
- condition: state
entity_id: sun.sun
state: "above_horizon"
fork me… i love this forum… everyone so passionate… and all this so that I could get alexa to tell my 3 years old that it is toilet time (for potty training)… needless to say that he nailed it in a week so we no longer needed it… as a side… my wife told me… after trying to figure this out for around 3 hours… that it was better to notify every 2 hours… go figure… problem solved!!
Anyway… thanks for all the comments… .I love you guys…
4 Likes
Hi, someone find a solution? i am interested too.
Regards
Read the thread. My solution above will work for you:
1 Like