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

I have an event where I do intermittent fasting and a special health regiment of supplementscalled 11 day jumpstart.

I agree, date range would be nice.

I have an event that is 11 days and happens every single month except Decmber.

I’d like to set up automations during this time to remind me to get up and move every 45 minutes, a schedule of drinking water every hour, and taking my supplements in the morning and before I go to bed. And everything stops after 6pm. I’m going to re-read this thread and see if I can at least come up with a flowsheet…Thanks for the solid examples…

Just use a schedule entity

The OP makes a good point. It’s all possible with templates but a UI method would be way better for many people. I’m using a condition where I need to check if the time is before or after a time and date gotten from a frontend input, which really is more complicated than I think is pleasant for users who aren’t used to writing code.

Use a schedule entity……

Maybe I am missing something, but do you mean a schedule helper? A schedule helper knows about days of the week but not date, right? Or is there another thing called a schedule entity? If I want to do the following thing:
a) Select a specific time and date from the frontend, in a method that can be adjusted by users that do not have access to the ‘settings’ menu
b) Check in an automation whether it is before or after this specific time and date

And do all this without going into Yaml code, but purely from the UI, is this possible currently? I tried but it didn’t work, which is expected because according to the documentation, the ‘time’ condition ignores the date. So I made a template for it, which required some re-casting of the datetime because of time zone not being included in the selector.
I thought about possibly creating a local calendar specifically for this purpose. It might work but it seemed like overkill so I didn’t. But for non-coding people it might be the better option?

Correct. But if you need a month to month range, local calendar entity.

My use case here is a temporary override of my thermostat heating schedule, so certainly not month to month. A calendar might be OK here, I don’t use that atm so would have to look in to it.
Nevertheless, it seems quite limited to me that the ‘time’ condition cannot include date. Is this the result of a decision made in the past that isn’t going to be revisited, or would it make sense to put in a feature request to make this possible? Either through a ‘date’ condition to be added to the script syntax, or an optional ‘include date’ flag on the ‘time’ condition (which would default to off and therefore not break existing code). It sounds quite simple, I might even be able to contribute to that myself. :grimacing:

Well, time is not a date. A date is a date, which is why time doesn’t support it. If you want a date condition, then make a FR. I’m sure there’s already one.

99.9999999% of the time, a missing feature is just because no one added it.

All the complaining you see on the forum about missing features or lack of features is people who don’t understand this. Please do not lower yourself into that group.

2 Likes

Well, time to me is a number that has a randomly chosen zero and just keeps increasing, the shorthand notation we use modulo 24hrs is not the only way to represent time.
Anyway, I did once search for the FR to include date and didn’t find it then, but that was a very quick search. I’m not complaining here, just asking questions. I’ve only been using Home Assistant for a bit more than a year so I am not aware of heated discussions that took place before that time.
I wouldn’t even mind putting in some effort to make a PR instead of FR, but it would be a waste of time if that is going to be ignored because of earlier decisions.

I doubt a PR for a new condition would be rejected. I could see it get rejected if you tried to add it to the existing Time condition. It would be best as a separate condition, similar to numeric state.

“Use a schedule entity…”

Are all the current entities and how to use them listed in the documentation or even better somewhere else? I’ve never found the documentation of features particularily insightful because it tends to explain things in an over-complicated way that makes it extra hard for people like myself who have difficulties reading… (brain injury)

There are a bunch of WTH entries I can find that are related to this but no issues on Github in the core repository AFAICT.
Somehow this doesn’t sound like a good idea for a first contribution by a relative noob (I’ve done quite some coding but not in large projects and Python isn’t my forte and I’ve never bothered to look at the Ha source code)
Am I too naive for thinking this doesn’t require more than finding where the time condition is defined, copy-pasting that code and replacing the time part with a full timestamp or date? If the list of possible conditions has to be written explicitly somewhere that would have to be adjusted too of course, and some documentation writing. Really, I don’t have a clue at this point.

Github core is for issues only. There won’t be any Feature Requests there.

That code only uses time, it omits date. And it’s rather extensive.

But that wouldn’t be a bad place to start.

Interesting to see this topic come to life again. When I originally posted it last year, I then set a load of template conditions for my lighting automations based on months of the year. Now that time of year has come round again, I’m noticing the conditions kicking in (auto triggering Christmas presets from 1st December, for example). For what it’s worth, schedule helper or calendar are not sensible solutions for this use case.

I’m really pleased with the results and although it is totally possible to achieve this without a native date condition, I still think it feels like an easy thing to add into core functionality. It’s frustrating to be short of the knowledge required to give it a bash myself!

1 Like

I would not call that ‘rather extensive’. Less than 100 lines including some blank lines and comments.
Looks doable*. It looks like it would be most simple if you would want to the condition to test for a specific timepoint (is it before or after 15 December 2023, 11:14), or test for a date returning every year (is it between 15 december and 31 January?) or month (is it before or after the 15th?). Slightly more complex if you would want to have all those in the same condition but not impossible. I guess you could have entries for ‘time of day’, ‘day of month’, ‘month’ and ‘year’, which could all be ‘None’, you’d need some if-then logic to handle that.
This part doesn’t have the GUI bits in it that create the inputs to the condition (the datetime to test for), right? Are those created automatically based on the types of inputs to the function or is there separate code for that.

*I’m an optimist, perhaps you can tell :sweat_smile:

I get that, but if someone had already made a PR for this feature I assume it would be visible there somehow?

There are of course:

Use sensors with timestamps for time condition for automations (sort of related)
And I also found a LOT of questions related to this, that aren’t feature requests but in my opinion would not have been asked if some form of a date condition was available from the UI.

1 Like

For this use case could you just use the sun.sun attribute of elevation as a condition, rather than going for date ranges?

For example I have entrance lights based on sensors that function when the sun is below 10° elevation.

1 Like

definetly related: Automation During Date Range - #102 by nwithan8

Hello everyone, I had the same needs, and took your insights to create a pull request to add two new conditions: date and datetime.
This way, we would be able to choose to compare “only the date”, “only the time” or the “date and time” !