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