Thanks @datamonkey. That worked for me. For future searchers here are 2 automations that fire on alternate weeks using the value_template to identify the week number…
- id: '111'
alias: Email Bin Night Blue
trigger:
platform: time
at: "17:00:00"
condition:
- condition: time
weekday:
- tue
- condition: template
value_template: "{{(as_timestamp(now())|timestamp_custom ('%U') | int % 2) == 1 }}"
action:
- data:
message: Take out the bins. Tonight it is Recycling (Blue)
title: Bin Night! (blue)
service: notify.gmail
- id: '222'
alias: Email Bin Night Red
trigger:
platform: time
at: "17:00:00"
condition:
- condition: time
weekday:
- tue
- condition: template
value_template: "{{(as_timestamp(now())|timestamp_custom ('%U') | int % 2) == 0 }}"
action:
- data:
message: Take out the bins. Tonight it is Green Waste (Red)
title: Bin Night! (red)
service: notify.gmail
The problem with using week number is that if you have 53 weeks then you will get two odd weeks after each other.
| Because I'm 1 hours ahead of UTC (I disregard summertime because the int will flatten it out anyways), replace this with your timezone
{{ ((now().timestamp() | int-(86400*5)-(now().hour-1)*3600) / 604800) |int is odd}}
^ because 1970-01-01 was a Thursday
Calculates the number of weeks from UTC and thus should give you a correct every other week condition.
However, according to an online resource, there have been 13 leap years since 1970. Merely dividing the total days by 7 doesn’t take leap years into account therefore the computed result is a value that isn’t guaranteed to align with the boundaries of the current calendar week.
Nevertheless, it’s probably ‘good enough’ for this application because it performs the check on a Wednesday (i.e. at the middle of the calendar week and not at its boundaries which aren’t necessarily aligned with the formula’s concept of a week).
I think this is the correct approach anyways. Personally, I don’t care if it’s an odd or even week. I just want every other week from when I start doing it. A date input makes sense and it would fire every other week from that date.
The second template’s result is not aligned with calendar weeks (the Unix Epoch doesn’t start at the beginning of a calendar week plus there are 13 additional days due to leap years; elapsed days since the epoch divided by 7 doesn’t align with calendar weeks). As I mentioned previously, that offset can affect one’s application (it depends on the application).
Lastly, the original example I posted, of the Unix epoch calculation, used the wrong division operator. We want integer division so that’s // not %. I have corrected the original example posted above.
NOTE
If you want to experiment, copy-paste this into the Template Editor.
That is what I believe my template takes care of.
I believe if we set the template correctly now, then it will last for years before needing a calibration again since the week change is in the middle of the night.
I don’t believe too many of us get up at midnight to roll out the bins
I repeated the test I performed above using your template (adjusted for my timezone) and it starts a new ‘week’ tomorrow (i.e. the calculated value goes from odd to even on Tuesday).
Should be OK for this application because it checks on Wednesdays. However, as I explained previously, because it’s not aligned with a calendar week it may present a problem for some applications.
For example, if one application checks on a Monday and another on a Friday, the template will report odd on Monday and even on Friday despite the fact both days are within the same calendar week. That’s because its concept of a ‘week’, a period spanning 7 days, is not aligned with a calendar week.