'Midnight' Automation Only Sometimes Triggering

[pnbruckner (Phil)]

You could enable logging for some core stuff. E.g., in configuration.yaml you could add:

logger:
  default: info
  logs:
    homeassistant.components.automation: debug
    homeassistant.core: debug
    homeassitatnt.helpers.event: debug
    homeassitatnt.helpers.script: debug

This will add a bunch of DEBUG messages to the log that might help shed some light. But honestly, to really “see” what’s happening, you might need to instrument the code some more.

FWIW, here is where the time trigger is implemented:

core/homeassistant/components/homeassistant/triggers/time.py at dev · home-assistant/core (github.com)

Basically, in your case, if the processing of sensor.sun_next_midnight changing state happens before the trigger processing, the previously set trigger “arming” will be removed and a new one (for the next midnight) will take its place, causing the previous one to be “missed.”

Based on the times you posted earlier from the database, there’s only about 8 milliseconds or so between when the trigger should fire and when the state of the sensor changes. I’m not saying it’s definitely happening, but I think it’s possible, especially if you’re running HA on a less powerful system, and you have it doing a lot, that the trigger callback is being delayed by other stuff, including the processing of the sensor’s state change, which will cause the trigger callback to be removed before it gets a chance to actually run.

Again, I doubt what you’re experiencing can be classified as a bug, although, of course, it might be. I really think that depending on a time trigger to fire at the time a sensor’s value indicates, when the sensor also changes at that same time, is not a robust design.

[c0nsumer (Steve Vigneau)]

Thank you very much. This is really helpful.

And yeah, I think that’s likely what’s happening… If I get a bit of time in the next few days I’ll do a little digging to see if I can prove it out. (Balanced with is-it-really-worth-it…)

In the mean time I’ll change the actual automation to something… else… and leave the debugging one for troubleshooting.

I really appreciate it.

[pnbruckner (Phil)]

@paddy0174

That’s why I suggested your integration! It’s much more reliable than the default one from HA.

I wouldn’t say it’s more reliable, but I suppose it could be said, the way it works, is more useful in some situations. Which, after all, was kind of why I wrote it in the first place.

@paddy0174

To prevent such a race condition, I’m working with the attribute from your sensor for tomorrow. As soon as the sensor changes, I update an input_datetime helper with that value, and use the helper as trigger.

In an essence, I’m setting the time a day before it actually is used.

I see what you’re saying, but isn’t it really the same thing? I.e., the main state, as well as the yesterday, today & tomorrow attributes, all change at the same time, around 00:00:00. Then your automation would immediately change the input_datetime helper. The only real difference is a bit more delay between 00:00:00 and when the trigger’s input changes (as opposed to using the sensor directly), right? Given your overall configuration and system performance, maybe that’s enough to make it work all the time. Or maybe the sensor you’re using (indirectly) sets a trigger time that’s nowhere near 00:00:00, and it wouldn’t matter if you used the sensor directly???

[Didgeridrew]

@c0nsumer

In the mean time I’ll change the actual automation to something… else…

I made a blueprint a while back that essentially just adds the ability to use and offset to a Time trigger based on an entity like your sensor. Maybe, triggering a couple minutes before the sensor rolls over will solve the issue.

Entity-based "Time" trigger with Offset

Trigger automations prior to the value of an Input datetime helper or Sensor with device class timestamp with a user-defined offset. [Open your Home Assistant instance and show the blueprint import dialog with a specific blueprint pre-filled.] The Automation: Trigger: You can choose either an Input datetime or a Sensor whose device class is timestamp to provide the initial time. When using Input datetime entities the trigger will follow the same general rules as Time triggers based on Inpu…

[c0nsumer (Steve Vigneau)]

@Didgeridrew

I made a blueprint a while back that essentially just adds the ability to use and offset to a Time trigger based on an entity like your sensor. Maybe, triggering a couple minutes before the sensor rolls over will solve the issue.

That’s kinda what I did. For now I’m simply using 7 hours before dawn for turning the lights off. The goal is a simple turn lights on and off at a not-exactly-specific time when we’re not home thing.

Initially ‘midnight’ sounded good because it’d vary, but since that’s not reliable… This should suffice.

I don’t want to get into any sort of occupancy simulation or anything that complicated, just some basic lights that are on when we aren’t home, which also get shut off at not-always-the-exact-same-time.

So, I think this’ll suffice.

(My HA setup heavily leans towards simple with as few additions to the base as possible.)