I read all the posts twice (yes, I swear I did! ), but still don’t get, what you’re after.
Why do you want to have all this on the shutdown, and not at the next start? Let’s stay with the lights as an example. If you want to control what is really happening with your lights, it doesn’t matter what state they were in at the power outage, what matters is, what state they are in at the next start. You should have a check on the start of HA if all the things you want to control have the state you want.
Setup a list, where the states you want your lights to be in after a restart is described. After a restart you check the real states against this list and act accordingly.
Or am I totally wrong here? If so, please give me a hint why. Really, I don’t get it. I would always try to look what happens after the start, not before the shutdown.
To be short: after power loss, all my lights come up “on”. That wouldn’t be so bad, I have automations in place to set the lighting the way I want. However, most Zigbee devices don’t report the actual new state to HA after power loss, so in my dashboard and automations, lights appear to be out when they’re actually on.
I think it’s because after power loss, the lights are instantly on and HA needs a minute to start and also setup the Zigbee network.
Now you could think to switch them off in any case, but they don’t switch off because HA or Zigbee2MQTT thinks they are already off, so nothing happens. Until I reset the situation by switching switch on all lights and then switch em off again. And then to whatever state I want them to be.
The problem is, after a manual restart from the front-end (for example an update), I do not want to reset the lights al the time, but there’s no state to detect if we come from a normal restart or a power loss.
If power losses are usually > 1h, you could also do that with an input_datetime in which you set the current datetime every 5 minutes using an automation. Another automation, on homeassistant.start then checks this and knows how long you’ve been offline. If > 1h, you consider it a power loss, and do you magic.
@khenderick That’s a nice idea. However not a one size fits all. Problem is still that HA does not what I expect it do. Being able to run an automation at restart should not be a “you cannot call a service to set a value”
To be honest, I agree. I would suggest reporting this as a bug on github, so the development team can fix it, or maybe provide some insights in what will and will not work in the docs (in case it’s not something that can easily be fixed)
For now, it seems that a workaround will be the only option.
I also wanted to note that I think one of my posts above contained an error, as I think the event is actually raised on update, but my setup is up-to-date and I can’t verify.
In the mean time (assuming you have a MQTT broker) you could use an MQTT based entity with the retained flag set. This would correctly restore on startup.
Another workaround is that if you know you are going to do a manual shutdown or restart then just create a helper, or helpers, that you use to perform that operation and essentially create an automation that changes your power loss state helper and then calls the shutdown or restart service. This way you know for sure your state helper is going to get set and the appropriate action is going to happen.
I understand that this is still a workaround but is one that is manageable.
I noticed my issue has been closed and marked as “stale”. Can somebody tell me why this happens? So yes, it hasn’t been picked up, there’s no reply or review, and now it’s non-existent again?
I understand. But I don’t see any form of prioritization. It would definitely be more user friendly to respond with a MOSCOW categorization, so there’s room for improvement.
Volunteers have to “want” to fix it. Even if there was prioritization, it doesn’t mean it’ll get fixed. Also, you get notified when stale gets added to an issue. Respond in the PR and it won’t get closed.
Sure, I’m not looking for a guarantee of it being fixed. There’s only so much time and always shifting requirements. I’m a programmer myself and the backlog is always growing. From time to time we groom it and classify at least what we definitely are NOT going to do. That’s a commercial environment.
With volunteers I guess there’s more cherry picking (doing what gets their attention and what’s their strong point). Now a bot is grooming the backlog, so even if it might have been a small thing to fix with rather high value (but being unnoticed), it may be demoted to the trash bin.
I think my question is: what is the process, has at least somebody noticed the issue?
), but still don’t get, what you’re after.
Really, I don’t get it. I would always try to look what happens after the start, not before the shutdown. 
At first this was a feature request to add an extra event. As it seems however, it’s only a buggy situation.