bold silo
Hi everyone,
I would like to trigger an automation every weekday at 06:30 and every Sat&Sun at 09:00.
But the time trigger does not support weekdays.
The time condition supports weekdays but not at. It only knows before and after.
Maybe I am just particulary thick today, but I am not seeing a way to join these two simple or cases together in that one automation (no, I do not want to create a second automation for something this basic^^).
vast bear
Schedule Helper - trigger the automation when its state turns 'on' and then set events to occur at 6.30 on weekdays and 9.00 on weekends?
If you want to avoid an additional helper
Triggers
Time: 06:30, 09:00
Conditions:
OR
Time: Before 07:00, Weekday
Time: After 07:00, Weekend
bold silo
An additional helper would be as cumbersome as creating an additional automation.
I am surprised that such a simple automation is not possible given all the updates automations received this year.
Your workaround should theoretically work but it is very "unelegant" 😄
vast bear
i disagree, a convenient helper to contain all the trigger logic is very useful and tidy
but different strokes for different folks
bold silo
Well, automations have triggers and conditions. Needing a helper to do what the automation should do is not tidy.
An automation that cannot be triggered cleanly without a helper seems like suboptimal automation functionality.
It is acatually a bit surprising that time: has different options depending on whether it is a trigger or condition. IMHO, a trigger should also allow for weekday selection.
vast bear
Make a PR and add it then but generally they seem to want to trigger often and cut back with conditions, rather than build condition logic into the triggers themselves - which makes sense given triggers are checked much more frequently than conditions
outer vine
at would make no sense for a condition; times are accurate down to microseconds. A time with an at condition would never be met
If you want to pass the condition you need to use after
bold silo
`at` would make no sense for a condition; times are accurate down to microsecond...
Sure it would. Makes no difference whether it is a trigger or a condition. At is a specified time.
A time with an at condition would be met exactly once per day.
Anyway, the bigger issue is the lack of weekdays for the trigger.
outer vine
My point is that trigger will fire at (or as close as possible) to a specific time. If you set a trigger for 6am, and then look at the trace for the automation after it fires, you will see it fires some number of microseconds after 6, for example 00:06:00.001538. If you set a condition for “at 6am” it will never be met because there is a one in a million chance that that condition will be checked at the exact microsecond that you set it to.
In other words, a time with an at condition can be met for literally 0.00000000115% of a day. Which is not useful.
You can use conditions to qualify the triggers to ensure the automation only runs on weekends.
bold silo
My point is that trigger will fire at (or as close as possible) to a specific ti...
Okay, yes, that makes sense but obviously the solution would be to simply round the condition, i.e. not check to the ms but simply to the s. That way the problem would not exists.
So the code itself could be after 6:00:00.000 and before 6:00:01.000 and it would work and for the user it would be identical to at.
outer vine
Defining at: to be within the specified second is completely arbitrary. It would make just as much sense to be within the specified minute. Or within the specified hour, or 0.1 seconds, or anything else. And I would argue each option is equally as useful/useless/confusing as any other option. If you want it to be within a second, simply specify the above and below values to be a second apart.
Your argument, if I'm summarizing this correctly, is that this condition with an arbitrary fixed accuracy of 1 second that is not adjustable:
- condition: time
at: "06:00:00"
is superior (and less confusing) compared to the current method specified by this code, where the accuracy is explicitly defined by the user:
- condition: time
after: "06:00:00"
before: "06:00:01"
I don't think you'll get any buy-in from the devs on that argument.
novel dagger
When I've wanted to use a condition based on which time trigger fired, I just give each time a unique trigger id like time_0600, time_0930, etc.