Since this automation is running when the system is shutting down, it seems a bit of a hit-and-miss if I read some topics on the forum.
One thing I’m thinking about; is there an initial value configured for your input_boolean that would cause to overwrite the value set by the automation?
No, I haven’t done that. I just created a helper from the interface, that’s all.
My conclusion is backed up by the fact that I tried to reverse the usage of the helper (so set it off, but then it remains on).
So either way this is a buggy situation. The notification does work, but setting an input boolean does not. Or, maybe, the state preservation is in the way of this? Runs and saves to database before this automation somehow?
What I’d recommend is to consider solving a different problem first, which is the PC does an uncontrolled shutdown when you lose power. Eventually, this will cause disk corruption, history corruption, etc. Likewise, if you lose power when you are not home, it’d be nice to get notified.
Get an UPS with a USB port, put your PC and router / modem on it, plug the USB port into the PC and get a NUT server setup. In HA run the NUT client. You will then get notified when power is lost. Also if it’s a short power fault, the system won’t shutdown and your zigbee stick won’t reboot also.
I have several of these, to keep camera systems, networks, etc. online
APC UPS Battery Backup Surge Protector, BE650G1 Surge Protector with Battery Backup, Dataline Protection, Backup Battery Power Supply
Thanks @PeteRage. Lately we are facing serious power outages due to an old electricity network somehow. Most of the times (4 times in the last 2 weeks) they last for 2-4 hours. As I can’t do anything about it, I don’t care about being notified.
Your recommendation is another way of solving the same problem. Indeed a UPS helps in shutting down HA in the proper way. Otherwise I don’t need one, so for me that feels like buying a truck to deliver a letter to my neighbor . And it’s another power consuming device.
Most browsers these days have a mechanism of detecting an unclean close down, so they let you restore your open tabs after power loss. In my opinion HA could offer the same thing or at least let me automate it myself. Apparently the way I thought of doing it, is not working as I think it should.
If this indeed is a bug, I think many people would benefit from a solution.
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.