We have time based triggers, but no date based triggers.
You can create an helper, but then that is just at one date, there is no simple way to repeat on a day of the month, or day every year. unless I am missing something?
Thank you
Template trigger?
trigger:
- platform: template # trigger on the 13th of every month
value_template: "{{ now().day = 13 }}"
yes everything can be done with code. but it is not always easy. 
3 Likes
Agree, one of the points of WTH was to ask for an easyer option, not the coding one, we know the drill. But thanks anyway for the code! Nice to see
3 Likes
If you’re interested, there are more date-oriented examples in a related WTH post:
Reviving this old thread because I was just looking for the same answer and this was a top google result. Might be new in the intervening three years but as of mid 2024 this works:
Choose the entity ‘Numeric State’ then ‘DateTime’ entity. Then the GUI will let you choose a (numeric) day.
Good luck future Automator’s!
EDIT FOR FUTURE CLARITY: This did not work. I missed the ‘Day’ Attribute, and the helper is a single date that needs to be updated using code as well. Still not a WTH simple answer
1 Like
You have provided instructions to create a Numeric State Trigger to monitor an Input Datetime.
The “numeric day” you described is the value of the Numeric State Trigger’s above property (which can be any number and has no understanding of days of the month).
Visual mode
YAML mode
You claim it works but an Input Datetime’s value is not a numeric value. It’s a string value representing date, time, or both:
2024-11-07
07:00:00
2024-08-31 16:10:00
A Numeric State Trigger cannot compare an Input Datetime’s string value like 2024-11-07 to a numeric value like 20.
A Numeric State Trigger is meant for monitoring the value of sensor entity, not an input_datetime entity.
Thanks for helping to find a better answer. I was a little incomplete in my initial thought I needed to make an above and below. My full YAML to toggle a light once a week is:
alias: Sched - Stars - Toggle Weekly
description: ""
trigger:
- platform: time
at: "04:00:00"
condition:
- condition: or
conditions:
- condition: numeric_state
entity_id: input_datetime.date
attribute: day
above: 6
below: 8
- condition: numeric_state
entity_id: input_datetime.date
attribute: day
above: 13
below: 15
- condition: numeric_state
entity_id: input_datetime.date
attribute: day
above: 20
below: 22
- condition: numeric_state
entity_id: input_datetime.date
attribute: day
above: 27
below: 29
action:
- type: toggle
device_id: ea0beb992acfdea599c6eb27f306675f
entity_id: 7b69b33975714943cb32fb6246dac57d
domain: light
mode: single
Sadly this morning, I’ve learned that that helper is getting a single static date/time and not the current date and time. I don’t think this is a viable solution after all for that reason. (until I find a helper i can update every day or something).
Edit: Please note that despite posting the YAML, I’m trying to do all the config with the GUI editor, hence not using template code.
There’s the missing detail in your original description. You have configured the Numeric State Condition to monitor the Input Datetime’s day attribute.
If you’re interested, you can use a State Condition to do the same thing (with one fewer line of code).
- condition: state
entity_id: input_datetime.date
attribute: day
state: 7
The only catch is that when you use the Automation Editor in Visual mode, it automatically changes the given integer value, 7, to a string value "7" because it doesn’t know that the day attribute’s value is an integer not a string. 
That change causes the Template Condition to fail (you have to manually edit it in YAML mode to remove the double-quotes).
FWIW, I still feel a Template Condition is the neatest way to do it. Your four Numeric State Conditions can be reduced to this:
alias: Sched - Stars - Toggle Weekly
description: ""
trigger:
- platform: time
at: "04:00:00"
condition:
- condition: template
value_template: "{{ now().day in [7, 14, 21, 28] }}"
action:
- type: toggle
device_id: ea0beb992acfdea599c6eb27f306675f
entity_id: 7b69b33975714943cb32fb6246dac57d
domain: light
mode: single
1 Like
We have recurring calendar events now.
1 Like
That isn’t a real solution. We shouldn’t have to bumble around configuring an entirely separate (poorly documented) integration in advance of creating the automation, and then figure out how to use a bunch of hidden properties that are only accessible via YAML and then only by doing roundabout nonsense with a template trigger (for which the syntax is atrocious) just to set an automation to fire on as simple a condition as “on the 23rd of july”.
How is it real that after this long there isn’t a simple “type a friggin date in and that’s it” Trigger option, or date range for Conditions?
I believe one of the reasons this does not exist yet is because in most cases it’s not a date you want.
If it’s a date then it will only trigger once then never again.
If it’s a birthday then it can’t be a date but instead a month/day.
It quickly becomes a big pile of extra addons to this simple date.
However if it really is a date then use the input_date and trigger on this.
1 Like
You don’t need templates at all for it. 123 is showing a way to do it at that time before calendar entities had triggers.
Now all you need to do is create a calendar, select your date. Then use the calendar in a calendar trigger. All from the UI without needing any templates.
1 Like
The 23rd of July starts at 00:00:00 so that’s when your proposed simple date trigger would trigger.
Is that how you want it to work or should it include a date and time?
FWIW, triggering on time and date can currently be achieved several ways:
- Time Trigger with conditions.
- Calendar Trigger using Local, Google, or CalDAV integrations.
1 Like
Only if it were deliberately implemented poorly, which wouldn’t make sense because this is functionality we already have with a Time trigger that uses a DateTime helper.
Both of the allegedly broken use cases you listed are solved by a simple recurrence option.
A way that is equally convoluted to using templates and subject to at least one dumb landmine of the value type when using the UI.
Except that the Calendar Trigger is completely unintelligent. It can’t be told which event should trigger it. If you don’t want it to trigger the automation on every single event it has, you have to either combine it with a Template condition, or create a unique Calendar for each unique event you want to use as a trigger. This is not a real solution.
That’s how I would expect it to work.
Which requires writing templating code, or flat out doesn’t work for recurrence if you use the DateTime helper option.
Which is not a real solution for the reasons I wrote above.
-
I really think all of you that replied to me are too used to doing convoluted, user-unfriendly things that you shouldn’t have to do to coerce HA into doing things that should be simple. All of these alleged solutions are methods that you have settled for because HA doesn’t provide you with the basic functionality that it should for this use case.
First, you need to rethink how you respond to people. You are 100% on attack, and you don’t need to be.
If you are interested in a different way to handle this, please create a Feature Requests detailing exactly how you’d expect it to work with various scenarios (triggers and or conditions). Then we can have a decent discussion about the future behavior.
Mate, if I’m “on attack”, it’s because it’s extremely frustrating to have a specific need and the only responses I can find over the course of years worth of threads are people talking like I’m insane for wanting it to begin with, and suggesting “solutions” that involve convoluted/roundabout workflows that I shouldn’t have to do just to achieve a very basic function.
There’s already at least one feature request for this specific functionality, and multiple feature requests that are related. There have been dozens of posts about this over the years. All of them have the same problem that I have right now - The replies are either suggesting convoluted workarounds with the implication that the feature is unnecessary, or just outright stating that it’s a bad idea and you shouldn’t be trying to make automations based on a date to begin with.
If you were me, and you read those threads, would you really want to make another knowing the most likely outcome is a bunch of people tell you how to solve your problem in a way you explicitly don’t want to solve it or that what you want to do is fundamentally wrong?
If you aren’t willing to get the conversation rolling, why are we even here? The entire point of Feature Requests is to get core or volunteer developer attention to a user need/want.
Many times, people will post work-arounds in that thread. Just remember that Feature Requests are still open until the feature is added or the thread is closed or marked with a check.
I know many people don’t want to hear this, especially from me, but I welcome work-arounds. If I have an issue, I want to solve it right this moment. I do not want to wait for a developer to add functionality. This seems to be missed by a large portion of the user base.
I personally rather spend my time fixing my problem. The last thing I want to do is go and voice displeasure about current functionality. It’s just not how I am.
The conversation is already rolling my dude. The replies to it are, at best, casually dismissive of the problem. Almost every reply to every thread about this, including the feature requests, is “Open up the hood and fiddle around with a bunch of disparate parts, then connect them all together in a convoluted way”. That is not a real solution, it is a temporary solution that became a permanent because it was “good enough”.
Do you understand why I - or anyone - would be discouraged from trying to start a new discussion about how this is a lack of functionality that should be fixed, seeing all of that?
That hasn’t happened with this in the multiple years it’s been being brought up. So again - If you were me, why would you want to create another Feature Request for the same feature that apparently nobody in the HA development sphere cares about implementing? It would just be a repeat of every other thread, with all the same replies about datetime picker this and calendar plus template that. When nearly every response to every thread I’ve found about this is just various people being directly or indirectly dismissive of there being a problem with the UI to begin with, what is there left for me to do except complain?
I don’t. I cannot tell my non-technical wife, who barely tolerates my smart home enthusiasm to begin with, that if she wants to set up holiday schedules for our newly installed lights, she has to screw around with HA’s templating system that is flat out unusable on a phone. She is just going to get annoyed that she can’t do something every other scheduling/calendar system she’s ever used lets her do, throw up her hands, and make me deal with it, which is exactly what happened and why we’re here now.
I spend 50+ hours a week, professionally, dealing about a dozen different programming and scripting languages and DSLs, none of which are Python or whatever the templating language is. I do not want to come home and have to learn or deal with another bunch of syntactical idiosyncrasies just to kick off an automation on the same date every year. I want to click some buttons and I should be able to do that.