Will try. I have found a potential other cause: I disable the automation for a certain period of time between the 24hrs, then enable it again before the 24hrs are over (at least in the tested case).
I will check
for: “24:00:00”
as well as
for:
days: 1
Thanks for checking - this helps already.
regards!
I found the issue:
What happens is the following (example):
In this situation, the automation doesnt fire when reaching 7am the next day. I am able to fix this, but for me this is interesting as the trigger should look into the past.
@petro: You are the person I know who knows most of automations 
- sorry to involve you directly. Can you let me know if the case above is a bug or by design? I would file a bug if correct.
Summary: I do have a time based trigger in an automation to be in a specific state for x amount of time. The according automation is enabled AFTER the state is “reached”, but before the amount of time is reached.
I assume it is by design, but I am not sure … Thanks!
Thanks for the update!
So it does not matter whether you specify 24h or 1day?
Will provide an update tonight. Had to trigger another 24hrs cycle for testing :-).
So, now another 24hours passed by, I tested the following:
- platform: state
entity_id: input_select.presence_andre_preset
to: Abwesend
for:
hours: 23
-> this worked (hours: 23)
- platform: state
entity_id: input_select.presence_andre_preset
to: Abwesend
for:
days: 1
-> DIDN’T work
- platform: state
entity_id: input_select.presence_andre_preset
to: Abwesend
for: "24:00:00"
-> DIDN’T work
Not sure, if it was the full day, as accidently in the first attempt I put 23 hours… I will check again with 24 hours. I am a bit concerned, that 'for: “24:00:00” ’ didnt work though…
After doing some research, can I add one more test to the lot from here and try it with the history statistics sensor? An example is further down.
Also that 23h works and 24h doesn’t is very intriguing… could you also try 23:59:59?
The issue you are running into is that the way the for option in the state trigger works is, once the entity changes to the specified state, it must stay in that state for the period specified in the for option, AND while HA continues to run AND while the automation continues to be enabled. If HA restarts, or the automation is turned off and back on, the trigger is “reset”, meaning it starts over looking for the entity to change to the specified state, and then starts the time-based monitoring again. The trigger does not look back into the “history” of the entity. It only monitors the entity’s state changes while it is enabled.
It would seem that a History Stats entity would help here. If you configured it to indicate how long the given entity was in the desired state, then you could use a numeric_state trigger to trigger the automation once that value went above 24 hours.
I was about to tag you, but didn’t dare to and simply referred to the thread… but since you are here already 
do you have any guess why 23h works (which is also a pretty long time) and everything resembling a day does not? Is there some kind of overflow? A recorder issue?
Just to clarify: I didnt test 24hours - accidently only 23 (using the “hours” option). Testing “hours: 24” currently.
No, there’s nothing wrong with specifying 24 hours. I haven’t tried to understand the previous posts entirely, but I suspect the problem was the trigger was getting reset (because the automation was being turned off and back on) before it could possibly reach 24 hours, hence it never got the chance to trigger.
Hi Phil,
this was the first issue, you are right - and I got it confirmed. Nevertheless, I tried to specify the 24hours in different ways as written above, and only one of the automations triggered…, the one with
for:
hours: 23
this didnt trigger:
for:
days: 1
or
for: "24:00:00"
I tested now again with
for:
hours: 24
and it DIDN’T work. I can live with 23 hours though (as tested above), but somehow 24hours doesnt work.
If anybody can help, woudl be great. I am happy to test or deliver debug data
I tested as well now without a condition to narrow the issue down as Phil said.
I’ve tested
for:
minutes: 1
-> worked, was the control group to see if my automations work 
for: "23:59:59"
-> worked
for: "24:00:00"
-> worked
for:
days: 1
-> worked
for:
hours: 24
-> somehow didn’t work, but I have to recheck the automation if there is no copy paste error tomorrow
Weird. I used 4 automations, which I simply copied and changed the “for” part. Now 24 hours didnt work, but 23 did… Something is happening here. Most likely on my side, seeing your results.
Not sure why it doesnt work for me. I didnt update to the latest build as I am on 104.3 at the moment.
I created a simple environment with one input_select to monitor, which is only taking manual input. The automations have not been switched off either… Big “?”… Will investigate further. Thanks for the help!
Found one issue in my test today -testing again…
I can’t imagine how “for: {hours: 24}” doesn’t work. But just in case there is something unexpected I just set up a test. It has two automations. Each uses a state trigger watching for an input_select to change to a certain value. Each has a for option with hours, with one set to 23 and the other to 24. When they trigger they send a persistent notification. I’ll let you know what happens (in about 24 hours. 
)
And, FWIW, I just used the state trigger’s schema with “days: 1” and “hours: 24”, and not surprisingly they resulted in the same timedelta object:
>>> from homeassistant.components.automation.state import TRIGGER_SCHEMA
>>> TRIGGER_SCHEMA({"platform": "state", "entity_id": "input_select.test", "to": "B", "for": {"days": 1}})
{'platform': 'state', 'entity_id': ['input_select.test'], 'to': 'B', 'for': datetime.timedelta(days=1)}
>>> TRIGGER_SCHEMA({"platform": "state", "entity_id": "input_select.test", "to": "B", "for": {"hours": 24}})
{'platform': 'state', 'entity_id': ['input_select.test'], 'to': 'B', 'for': datetime.timedelta(days=1)}
So there really doesn’t seem to be any way if “days: 1” works for “hours: 24” not to work.
I wrote it on another input_boolean for the 24h one, but it works as well
My point being is simply that it has to be the condition not staying in “Automatik” for a whole 24h which causes the problem as Phil pointed out
According to the history (db) it does - it is a manual setting. But in the last test I made a mistake, so those dont provide correct results. I will now further debug my setting.
For the tests, I am only using input_selects with manual input to avoid any other mistake.
I am wondering as I simply copy and pasted the same automation 4 times, renamed them and changed the “for”-line. At the end one automation fired.
At the end I must have made a mistake - so thanks for your testing. It give me the confidence to find the bug in my coding/setup
I just recently changed the automation again and added the condition with the same testcases as above to look like this
- id: 'test_24h'
alias: 'test_24h'
trigger:
platform: state
entity_id: input_boolean.dummybool
to: "on"
for:
hours: 24
condition:
condition: and
conditions:
- condition: state
entity_id: 'input_select.automation_presence'
state: 'Automatik'
action:
service: input_boolean.turn_on
data:
entity_id: input_boolean.test24h
I’ve changed the input_select from Manuell to Automatik and then triggered the dummybool, I’ll report tomorrow my findings
Just want to note that I am not doinga nything else with the input_select - do you have some automation that includes it in an action?
The condition does not have to stay true for the entire for period because the automation’s conditions are only evaluated when a trigger fires, and in this case, that’s not until input_select.presence_andre_preset changes to Abwesend, and stays that way for 24 hours while the trigger is not reset (i.e., the automation stays on and HA continues to run without restarting.)
So the condition only has to be true for when the trigger occurs? That’s even more of a question then why 24h would not work…
Which basically leaves the only option for 23h working and 24h not, that the trigger condition is not being met within that timeframe? does the input_select refresh at some point which causes this phenomena?