I don’t think that i can go over all previous messages before posting any possible solution, there are threads with more than 500 messages, reading all of them is not scalable. I will continue what i am doing and discard your proposal.
why not trigger time_pattern every 10 minutes or so, and have a template condition for the time since the last trigger >90 minutes?
1 Like
I tried to come up similar here (What's the easiest way to run an automation every hour and a half? - #11 by fuatakgun) and it should not require to be called for every 10 minutes. It is a bit duplicated because last triggered attribute can be empty if this is a fresh new automation.
no, thats a template trigger.
using the time_pattern is much easier, and doesn’t waste resources, because if the template isn’t met, the action isn’t executed.
automation:
- alias: excute per 90 minutes
id: excute per 90 minutes
trigger:
- platform: time_pattern
minutes: /5
seconds: 00
condition:
- >
{{(now() - state_attr('automation.execute_per_90_minutes','last_triggered).total_seconds() > 5400}}
mode: restart
action:
- service:
something like that
1 Like
Amelchio’s post was the fifth one before yours. There were only two dozen posts in this thread so it wasn’t a hardship to read it and learn what you proposed wouldn’t work.
1 Like
In that case:
trigger:
- platform: time_pattern
minutes: "/30"
condition: "{{ (now().hour*60+now().minute)%90==0 }}"
I’ve no idea if that is any less resource-intensive than my prior attempt.
6 Likes
Yes, dismissed again
Well hardly, you read and replied to the post.
Fact is you didn’t bother reading this thread (you admitted that much) and then suggested something that was established ten months ago to fail.
Instead of simply admitting it was a mistake to do that (we all make mistakes) you continue to defend it and believe it is helpful to post defective proposals. Very odd.
3 Likes
Nice. Short and sweet. Every 90 minutes starting at 01:30.
First version gets evaluated every minute. Second version is evaluated on the half hour.
Theoretically the second version is less of a load. However, under the hood, the system clock still checks all time-based triggers at the same interval so it’s a bit of question as to whether resource usage is significantly different.
Nevertheless, I like the second one better.
Look, proposing a solution without bad intention is not something defective. You approached in a attacking way and I pushed back. then Troon approached in a logical way and I agreed with him. You can claim that result is identical but approach and method is as important as result.
So, the proposal is wrong, I never had any duty to fix my messages so far but Troon’s reason made sense. Your reasoning was about why you are proposing sth which you did not test which I do not agree and I cannot commit to do for each proposal. But, if fixing my proposal helps future people, I will gladly to it. If you would say that this is already suggested and not working, you can fix your comment, I would onboard it quickly.
Here we are, now trying to generalize the approach to each problem, what should be the maximum number of messages in thread before going all over it or it is our due diligence to read everything before posting a solution. I am saying that, I cannot take the first option as it might be time consuming and you disagree on this. While I respect your decision, I do not agree on this and dismissing it. This is an acceptable state to be, having disagreement and not being able to conclude it. And, there is no reason for you to analyze me , you have no gain and I have no lose here, so we can close the topic as concluded in disagreement and move forward and without any hard feelings.
2 Likes
I don’t know what you’re trying to say there but it has nothing to do with what I have been explaining to you. The fact is you proposed a solution that had already been established to not work. Had you bothered to read at least some of the thread before posting you would have known that.
I asked you a question. Read my first post to you. It’s a question. Did you see Amelchio’s post explaining why a Time Pattern Trigger cannot be used for a 90-minute interval?
If you characterize that simple question as an attack it’s because you didn’t want to admit that you didn’t read the thread or even test your proposal.
A quick and simple admission of having made a mistake, because we all make mistakes, would have been the end of it. However, your response has been, and continues to be, to deflect, make excuses, and talk circles around it. Even convincing you to amend your posts (you still haven’t corrected the second one) resulted in more excuses.
1 Like
ok, we have different understanding from each other, let’s leave it here as we will not be able to converge onto same result. thanks again for the discussion.
1 Like
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.