Devices fail to start after power outage

1

I am running HA on a Raspberry Pi 4
OS version: Home Assistant OS 10.1
HA Core: 2023.5.3

After any power failure several of my devices fail to work. Two of which are my main household power monitor and my Smoke detector. I think the problem has something to do with the LAN not yet available to the PI when it boots, as it boots way faster than my ISP’s modem. If I reboot the PI after the modem is available those devices then appear to be found.

I have been looking for a way to force my Pi to wait until it gets an IP address before it boots and can’t seem to locate a simple way using the current OS version.
Is there an easy way to make this happen so I can see if it resolves my issue? Searching on line I can find a lot of complex ways to accomplish this but I would have thought that there would be a simple way.

There is a tool raspi-config which appears to do want I want (network at boot?) but I am not sure if it is compatible with my current OS and I would rather ask before going ahead and installing.

I believe the devices that do not connect are using MQTT so maybe there is something that has to do with the MQTT setup that is the issue? There are other devices that are using MQTT that do work so I am at a loss to explain why this is happening. If I reboot the PI manually after the connections are all made the disconnected devices connect as expected.

Has anyone else run into this and if so how did you solve the problem? Thanks for any insights you can provide.

2

Power your critical devices (router, wifi AP, and Home Assistant) from a UPS.

3

Thanks for the reply.
I would use a UPS if I knew that it could provide enough power to maintain all the devices for the time the power is down. Generally our outages are a few hours to a day or so. The UPS would need to maintain the ISP’s modem as well as my router and at least the raspberry Pi. What size UPS am I looking at? I can get a 1500VA/1000W unit for about $300. how long would that last?
For the few times a year it does happen I am not sure its worth the $300 when I can just reboot the pi when I get up. I am probably more likely to spend the money on a generator for power failures since living without water is more of an issue than worrying about rebooting the Pi.

Isn’t there some way to delay the Pi from booting till it has a network connection using the Home Assistant OS or do I need to install using a different OS?

4

Look at the compliance plate/stickers on the equipment. How much power do they draw.

1 Like
5

You could set up a ping to the router and set a Boolean helper based on that.
Once the ping goes from no reply to reply, then make an automated reboot of HA.

Or if it is the ethernet/WiFi that isthe issue here, then a sensor running on another network, like ZigBee, to detect the change.

6

Thanks for the idea. Can you provide me with a simple example or some links so I can read up on this?

Edit: Okay I have made an entitiy that pings the Router and it returns if there is a connection or not. Now I guess I just need to create something that will reset HomeAssistant if there is not a connection? I’ll have to play around with that one and just do the minimum change to get the devices to connect. Maybe I don’t actually need to reboot the Pi.

7

Just for additional information. We just had another power failure (tree across the lines.)
Here is the entity graph of the Electricity Consumption from my power meter
image
Red : Power out
Blue: Power restored
Green: After reboot of Pi

Once the power was restored and HomeAssistant started again I checked the electricity consumption entities and started trying to reload and restart components, each time checking back to see if the consumption would begin to display. I began by reloading YAML configurations and progressed up to restarting HomeAssistant . The final try was to reboot the Pi. The gap between the blue and green markers is during that time. The green mark displays my final try of rebooting the Pi. From my test it appears that a full reboot is required in order to regain access to the consumption data which is accessed using MQTT.

I have a feeling this is because the modem and router are not yet available when the Pi boots but I have not checked this. All I know is that they are available when the Pi is rebooted.

Currently my easiest remedy is to just reboot the Pi manually after a power outage.

8

MQTT?
Have you tried rebooting the broker only?

9

I’m pretty sure I did that during my tests but I will test it again when I get the chance just in case.

10

Finally got back to dealing with this and just when I do we have another power failure.
This time I was more careful with my observations and figured out 2 things that I believe may have helped me solve the problem.

  1. No I did not reboot the MQTT broker, I only reloaded it. Rebooting it does indeed solve part of the problem.
  2. I checked the errors more carefully and noted I was getting a non-numeric error on startup.

I assume that since this happens after a power failure it is due to an improper shutdown and that the initial startup then errors out because there is some missing data.
I therefore added the following to my YAML

last_reset_value_template: “{{ now().fromtimestamp(value_json.time / 1000).replace(tzinfo=now().tzinfo) }}”

and hope that will resolve the issue.

I did a couple of tests just unplugging the pi and so far it has restarted properly. I’ll have to see if it continues to work and if it recovers properly after the next power failure.

11

This looks like it might have been a MQTT broker issue that has since been fixed.
It appears to be working properly for me now after a couple of MQQT updates.

So the power failure issue was not the problem. The Pi was rebooting and starting properly. The Mqtt broker appeared to be working properly but it wasn’t. Once it was restarted manually everything would then begin to work. Tried a variety of things to get it to work properly on a reboot but nothing worked. Then it just started working properly. Pretty sure it was after a mqtt update. Found some other posts on the web that had the same issue.