Automation state and "last triggered" not persisting across reboots suddenly

I’ve been running HA as a VM on Unraid for years. I noticed earlier this week that sometimes when I disabled any automation with the slider/toggle on the Automations page (“/config/automation/dashboard” in a browser), the toggle would slide back to enabled within a second or two. (And vice versa when enabling an integration.) Other times, I would slide the toggle and it seemed to stay put, but then it would revert to its previous state after restarting Home Assistant.

This is very frustrating, since it means some automations will trigger / not trigger as expected when (for example) Home Assistant restarts following a VM backup while I’m asleep.

When i check the “History” tab for the automation, i typically see my manual action (e.g.) turning an automation off (which persists across reboots as well), but the history doesn’t show it turning itself back on, even though the automation shows as enabled in the GUI and a template like states(“automation.name”) shows it as enabled. And the automation will trigger again, so it is clearly enabled in those cases. In other cases, I may enable an automation with the slider but its History tab doesn’t show me doing that at first, though it will show my enabling action after refreshing the browser page, perhaps since my system is just slow. The enabling doesn’t persist after a reboot in these cases either.

As for the “last triggered” column on /config/automation/dashboard, those seem to update in the moment, and automations are indeed triggering actions, but when I restart HA, the “last triggered” datetime reverts back to whatever it said upon initially booting HA last time.

For both of these issues, I get the same results when accessing HA from a browser window and from the HA app on Mac. Notably, everything else in Home Assistant seems to work. Like I said, automations trigger if they’re enabled (or don’t trigger if they’re disabled), the dashboard works, I’m able to create and delete files in the /config folder, I can create new automations and have those persist across reboots, make edits to my config YAML, etc. My logs show errors but nothing out of the ordinary, since they’re mostly errors about maybe a shell script failing since I haven’t updated it for a while, etc.; nothing really new or obviously relevant.

It’s probably a simple issue, but I’ve been unable to solve it, even with pretty extreme steps like:

  • restoring HA from various backups over the past week and month.
  • making a new VM on unraid and restoring from a backup.

Would appreciate any help, thanks!

Automation state and “last triggered” not persisting across reboots

Yes, you are correct. Don’t understand the term suddenly, but they are not supposed to persist and never have.

There have been a lot of clean up[ fixing broken things, perhaps you ran into that here?

Enabling and disabling automations is a thing meant more for seasonal changes, not regular changes. If you want to disable an automation the more controllable way to do so is using the conditions: key right after Triggers: and before Actions:.

Maybe I didn’t explain my issue clearly, because I would doubt that the issues I’m seeing are intentional. For example, I am unable to keep one of my automations enabled permanently. It is set to disabled (the blue slider is in the “off” position on the Automations page), and when I enable it, the slider will eventually turn itself off again – usually after a reboot. I want to keep my automation enabled but can’t, which is never how HA has worked.

And by “last triggered” not persisting, I mean that when I launch HA I see an automation might say “2 days ago” in its last triggered column. Then when it triggers, it says 1 second ago, 5 minutes ago, etc, as expected. Then when I reboot HA on the same day, the “last triggered” for that automation goes back to saying “2 days ago” when in fact it was last triggered today, before the reboot.

1 Like

When this happens, are there any associated errors in the Log?

An automation will disable itself if there’s an error in the automation so 123 is asking because that’s the most likely reason for an automation automatically disabling. So look for errors related specifically to the automations that are disabling.

I never found any, BUT I’m happy to report that cleaning up a million unrelated issues in my logs seemingly solved the problem I was having earlier. HA was apparently drowning on its own massive logs in the background, mostly due to the hundreds if not thousands of template sensors that worked fine when needed but went unavailable when not needed. (A simple example is a template that relied on a media_duration attribute that would disappear when a media player stopped playing media.) In other words, the errors were benign for the multiple years I’ve used HA.

Even though my initial automation state and “last triggered” issues affected every automation and not just ones with template sensors, adding fallbacks to a boatload of template sensors has made HA much more responsive, and now it saves automation states correctly! (Yes, it even fixed automations with no template sensors). I’m amazed the rest of HA was usable despite these log errors, but it was.

If the issues were truly “unrelated”, fixing them would not have solved the problem.

Therefore at least one of those logged errors was related to the problem.

Anyways, from your description it sounds like your system was plagued with many problems. Glad to hear you got it sorted.

1 Like