I’m curious, do you know if this works if the input_number’s value is less than 10?
for: "00:{{ states('input_number.interval') | int }}:00"
For example, if it’s 5 then the time string will look like this:
for: "00:5:00"
I think that’s acceptable (it doesn’t need to be 00:05:00) but I’m not certain.
yes it works (tested with a value of ‘1’) 
Thank you! Saved me some time testing it.
How is this still not implemented after 7 years? Why I can’t use for at numeric_state condition? It works with normal state check and even with the numeric state check in the trigger! Why it does not in conditions?
I would really need this and unable to find a workaround without creating unnecessary entities just for this simple specific check.
You should really check your stuff, before complaining… 
Simply opening the documentation and read up:
PS: reviving a thread that is nearly three years from the last post…best way to get current information - NOT
That’s about triggers. I want to check if a state has been at least x in x minutes in conditions.
I tried it with templates but that also does not work because it does not know if it was below a specific state. Probably I need to add for each check an extra binary sensor like the answer of this thread is.
Not a good solution but at least it should work.
Edit: Sorry, my fault. This is about the for check in triggers. I misread that an thought it is about that it works in trigger but not in conditions because he compared the two.
All good, so what’s your actual problem? Think about opening a new thread, this is very outdated. And feel free to tag me, I’ll be happy to jump in, if I can give a quality answer.
Sorry for necroposting, but do we have a more elegant solution for the problem in the meantime?
The previous answer is an answer - but only a workaround in my eyes.
It’s neither pretty nor intuitive and the use friendliness is pretty limited as well.
You can do for on numeric_state triggers. That’s what this feature request is about. If you want this on a condition, it’s not possible at this time.
It’s actually unlikely to ever get implemented for a condition due to the limitations of the system. It would need to traverse the database and look at all values over the specified duration. The limiting factor is that it would require users to use history and recorder, which are optional integrations.
Well, triggers won’t do the job.
I do understand that it’s not trivial to do that like you explained.
What I do not get: why can’t it do what is explained above in the background? Create hidden sensor or the like that.
The point is, the data won’t always exist for all home assistant users, so it’s unlikely it would be added as a core condition.
What’s described above is an sql sensor that looks in the database. The database won’t always exist. That’s why.