WTH is there no easy date automation trigger

[123 (Taras)]

If you’re interested, there are more date-oriented examples in a related WTH post:

WTH Why isn’t there a date range or month condition?

I agree the Time Condition should support dates and months in addition to its current support for time and day of the week. Until it’s enhanced (if ever), is there a particular template you require? For example, if you need the month of October. {{ now().month == 10 }} For a numerically continuous range of months, May to August: {{ 5 <= now().month <= 8 }} For a numerically non-continuous range of months, October to February {{ now().month in [10, 11, 12, 1, 2] }} For a specific date {…

[baghtal (Travis)]

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

[123 (Taras)]

@baghtal

Choose the entity ‘Numeric State’ then ‘DateTime’ entity. Then the GUI will let you choose a (numeric) day.

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.

[baghtal (Travis)]

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.

[123 (Taras)]

@baghtal

My full YAML to toggle a light once a week is

        attribute: day

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

[tom_l]

We have recurring calendar events now.

[RockDuster]

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?

[Hellis81]

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.

[petro]

@RockDuster

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”.

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.

[123 (Taras)]

@RockDuster

fire on as simple a condition as “on the 23rd of july”.

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.

[RockDuster]

@Hellis81

If it’s a date then it will only trigger once then never again.

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.

@Hellis81

It quickly becomes a big pile of extra addons to this simple date.

Both of the allegedly broken use cases you listed are solved by a simple recurrence option.

@petro

123 is showing a way to do it at that time before calendar entities had triggers.

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.

@petro

Now all you need to do is create a calendar, select your date. Then use the calendar in a calendar trigger.

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.

@123

The 23rd of July starts at 00:00:00 so that’s when your proposed simple date trigger would trigger.

That’s how I would expect it to work.

@123

• Time Trigger with conditions.

Which requires writing templating code, or flat out doesn’t work for recurrence if you use the DateTime helper option.

@123

• Calendar Trigger using Local, Google, or CalDAV integrations.

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.

[petro]

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.

[RockDuster]

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.

@petro

If you are interested in a different way to handle this, please create a Feature Requests

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?

[petro]

@RockDuster

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 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.

@RockDuster

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?

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.

[RockDuster]

@petro

If you aren’t willing to get the conversation rolling, why are we even here?

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?

@petro

The entire point of Feature Requests is to get core or volunteer developer attention to a user need/want.

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?

@petro

I welcome work-arounds.

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.

[petro]

@RockDuster

The conversation is already rolling my dude.

The “month of WTH” ended 1 year and 11 months ago. Please create a Feature Requests, thank you.

[RockDuster]

@petro

The “month of WTH” ended 1 year and 11 months ago.

Don’t be obtuse, please. You told me I should put in a Feature Request, and when I explained that there are already several that nobody cared about and why I felt it was pointless to create another, you accused me of “not being willing to get the conversation rolling”. The conversation is already rolling, there are years worth of asks about this.

@petro

Please create a Feature Requests, thank you.

There already is one. Nobody cared, it died almost immediately, and the replies were all bad and dismissive. What is the point of creating another?

[petro]

If there’s already a Feature Requests for what you want, then go and vote for it. You can even add your counter-points on that post to bolster the efforts. Yes, people will reply to you. Yes, they will reply to you with work arounds that will not satisfy your need right this moment. But, make your case and then wait for someone to implement the changes.

Lastly, please ton down your anger.