please safely discard my messages, you are free to do, nothing enforces other way around.
The “danger” is that people will stumble across your recommendations and waste time trying to get them to work. If I ever suggest something that turns out to be wrong (not unknown 
) I go back and edit the post to clarify my error (recent example).
1 Like
You are also free to delete/correct your original post to prevent misleading other people from believing your proposal works.
1 Like
i can definitely agree on this, you are right
If you agree then delete/correct your original two posts to prevent misleading other users.
all other people, I will continue to post with good intentions and propose possible solutions. I do not have any enforcement to update/delete any historical messages. Enjoy your Friday and relax.
This might have issues when there is downtime happening like updating hass or electric outage. Rather than taking mod, i would go with greater comparison.
Hopefully you will do research and read what others wrote (like amelchio’s post) before proposing “solutions” that are known to not work. As the saying goes, the road to hell is paved with “good intentions”.
3 Likes
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