Weird that the logs aren’t telling you anything. 
The good news last beta b5 fixed it 
Who exactly benefits from knowing what automations are running at that point in time? I don’t see the need, at least for me; the warning was informative enough for my needs.
For me, I have automations that trigger in response to electrical use and set timers/monitor usage to let me know when my laundry or dishes are done. The warning now tells me those automations are running so I know to delay a restart. Same with automations I have for running lights or making sure my doors auto lock like they should.
Write the automation to avoid long wait loops and retrigger to be restartable on HA restart and it won’t matter… My thesis is HA is an automation platform and should ALWAYS be treated as something is running. Restarts happen. If you lost power this would be the same issue.
Old behavior: generic warning about stopping any currently running scripts & automations prior to restart, regardless if you had any automations or scripts running.
New behavior: no warning if nothing is running; and if something is running you get a warning telling you specifically what is running
There’s two scenarios here, so let’s attack each one separately:
- No scripts/automations running: There’s really no valid argument for keeping the old behavior. Nobody can possibly want to be warned about something that isn’t happening. So we should be able to agree that eliminating the generic warning in this scenario is an improvement for everyone.
- One or more scripts/automations running: The argument here would be that a generic warning is better than one that specifically lists the offending scripts. And note that there’s no extra click, and nobody is forcing you to read it, so the argument is the generic warning is more aesthetically pleasing than the specific one.
This is a really weak argument, isn’t it?
Consider rebooting a windows PC (yes I understand Windows is not the best benchmark for good UI, but bear with me). It warns you if programs are running and allows you to cancel the reboot process if you don’t want to kill those programs. Now, what sort of feedback do you suppose Microsoft would receive if they replaced that dialog with “Something may or may not be running. If something is running it will be killed. Are you sure you want to reboot?” Can you honestly tell me this would be a welcome design change? And that nobody could have possibly benefitted from the detailed information that was previously provided?
Not the same thing. You have to equate it to running with the system scheduler. Not the live UI… Apples and Orangutans… Background service not MSword.
Source: I used to be a MS Tam and escalated one of these. The dev team would have said eh? That’s what background automations are for… Doesn’t meet bar.
You’d still have to make the case for the generic warning being more “pleasing” than the specific one.
I don’t think the MS comparison is as far off as you’re suggesting. Automation tasks should be able to be completed in small fractions of a second.
Maybe the appropriate feature request here is to provide scripts and automations with the option to bypass this warning. If someone has a long-running script and they’ve programmed it such that they don’t care to know if it is running and will be interrupted, then they can set that option on a per-script basis to avoid that warning.
Which of these 132 would you like to edit?
No I’m absolutely positive about the parallel analogy of background process system service. Not foreground.
NonInteractive. Meaning you don’t need to be there for it to happen that’s actually one of the differentiators from scripts which have to be instanciated not triggered. I USE this differentiation when reading context for my own scripts to determine what I should allow my assist agents to do.
If truly noninteractive (automations are) users should ASSUME they run on thier triggers (time pattern? Chron - *nix service, btw) and need to come back on somehow after restarting. Which is also the reason almost anyone on the community assisting with automation recommends to not use loops that require long waits and make your automations restartable.. If you do that (which isn’t as difficult as it first sounds) it becomes moot and we don’t need no stinkin’ badge… Er toasts for the system restarts. I’m much more interested in the result of a HA check config result and it’s clear to restart signal…
The automation says ‘Oh hay I need to restart my automation because HA restarted and my condition is met…’
Your alternative asks everyone ever (existing base) to edit something to avoid behavior… I personally haven’t used said feature so I reserve personal comments as to how that ha implementation is after I’ve used it. Yet I know what my vote is. And the lead balloon that ask would be. Sorry.
BTW… UX decision isn’t as easy as folks think it’s hard tbh. It’s easy to play armchair front-end quarterback… I don’t envy some of these decisions. That said. I ALWAYS err to current behavior unchanged unless you prove the better to the group most impacted.
My personal opinion is automations gonna automate that’s what they do. If they’re working correctly the answer to that toast is and… So? Which it then falls into unnecessary toasts… As a security wonk - - I reeeeeeeally try to eliminate noise and unnecessary messaging in general lest ‘cry wolf’ or info overload starts to apply and the users stop caring and just click it to make it go away.
I’d LOVE some sort of warning as HA updates a lot and I often miss things as I didn’t realize the script/wait was running. The more info the better. I don’t remember what’s running and isn’t. That’s why I automate things, so i don’t have to remember. An annoyance of mine with HA is I have no idea what’s running so the generic warning offers no value to me.
Aka something may or may not be running but I won’t tell you either way. Just know it could be, or might not be.
The long-running ones.
I think you’re trying to make the case that a bunch of your automations are going to get caught on each reboot? Maybe we have different methods of automating. I don’t have background auotmations/scripts running all the time on my system. I have automations waiting to trigger, not constantly running. Sure, maybe once in a hundred reboots this warning might catch one that is actually in the process of running. Is that really a good reason to not surface that information ever?
You’re still trying to make the case that the generic warning is preferred over the specific one. If your argument was that there should be no warning at all, it might hold a bit more water. But the argument that the generic warning is vastly superior to the specific warning just makes no sense. Sorry.
you totally missed my point - I have literally hundreds that run on and off ALL the time - I, NOBODY can predict what is running at any given time - so I don’t try and shouldnt try - they’re BACKGROUND - I shouldnt care except when they do not recover.
AND my point is - we dont need a new message at ALL whats there already is fine and this is an exercise in futility.
Ok but have we thought of this: I like seeing what’s running before I click restart. Call me curious/nosey. Even if it’s ultimately meaningless, it gives me insight into what’s happening before I click the button.
Plus, its really not adding any extra friction. Same amount of button presses, maybe just a bigger popup.
That’s why I brought up having an option to disable the change. I figured there were going to be people that want to see this just like there are people that find it annoying, so they could both be happy.
I also tend to like that change. Not personally for me, but for beginners.
The chance, that everyone is doing best-practice automations right after setting up HA isn’t really realistic.
If you click your first automations in the GUI, it’s very tempting to use fixed delays for timings.
Who didn’t start like that. 
If the popup would sort with longest running tasks on top (not sure how it’s implemented, I’m on vacation and skip this beta), the output might still be useful for power-users, as the important stuff should show up on top.
But yeah, maybe a „I don’t care now and at any time in the future, please don’t nag me ever again“ checkbox might be fine.
The core issue of the restart warning is that it’s useful for long-running automations (which should be avoided), but not for short-running ones.
A way to tag important automations so that only those cause the warning to be issued plus a warning to avoid them were possible could be a nice improvement.
im having an issue with every update reboot my 2 mains ZBminil2s refuse to rejoin after update and i have to remove them completely reset and rediscover them.
I think I’ll upvote for the new automation warning on restart (not that it ever matters ).
I’ve always tried to make my important automations restart tolerant (no long running automations and adding a HA restart trigger as needed) . And for the exact reason that this change addresses - because I could never know if that important automation was actually running when I restarted HA. This change makes that way less of a concern.
I don’t know about anyone else but my HA isn’t in the habit of ever restarting without me telling it to so the only time I ever have to worry about HA restarting is when I tell it to so I don’t mind that HA tells me I have an automation running so I can decide if it’s “important” or not at that moment.
The only thing that will affect me negatively with this is if I want to use this feature I’ll likely have to change my workflow now since I use an external “restart” button in my own “system” dashboard view instead of going to the yaml page of (dev-)tools and clicking restart there.
Unless someone knows a way to mimic that functionality when the HA restart service is called via a tap-action?
Thank you for pointing out how most people restart Home Assistant, and it’s not manually, whether they realize it or not. Most of the time, at least for me, Home Assistant restarts because of a call to homeassistant.restart triggered by me updating a HACS integration or the Home Assistant Core.
I almost always restart through the settings → restart button, hotkey, or the yaml page. All 3 produce the new message