How can I use an automation to reboot my HA? Every now and then (very infrequently) it will lock up and requires a hard reboot to get everything running again. I travel quite a bit from work and when this happens I’m unable to access remotely.
I’d like to use an automation or a Node Red flow to reboot HA once a week or so.
Thanks
In node red, with a scheduler of your choice (I use light-scheduler), you can do a simple call service…
In addition to the hassio.host_reboot service shown above you can also specifically restart HA using homeassistant.restart or restart a particular addon using hassio.addon_restart. All can be automated via HA automations or Node RED flows.
Can you clarify a bit more what “locked up” means though? Do you just lose external access or is the software actually frozen/crashed? If it is frozen/crashed what is in that state? Everything or just HomeAssistant?
I’m just wondering because you can’t make an HA service call if HA itself is frozen/crashed. If it’s just a problem with HA but Node RED always runs fine then you might want to look into a way to restart the host that doesn’t involve HA at all. Like if you exposed an HTTP In node from Node RED that lead into a node capable of telling the host to reboot without going through HA then you could unfreeze yourself anytime this happened.
But it all depends on what exactly is locked up. If its the whole system then there’s not much that can be done to get out of it when a lock up occurs besides pressing the physical restart button. In that case I could see why you’d want to increase the frequency of restarts but at some point you’ll probably have to dig into that more.
Home Assistant is non-responsive. I can’t connect to it via mobile or laptop and none of my automations work. It doesn’t happen often but when it does all I have to do is cycle power on my Raspberry Pi. I’m not sure how to determine if it’s a HA issue or Raspberry issue but am assuming it’s caused by HA.
I’m hoping to preemp future lockups by regular reboots.
Gotcha. So just a thought then, I searched the Node RED pallette and found node-red-contrib-rpi-shutdown. Seems like it would allow you to create a flow that could reboot your raspberry pi directly from Node RED. I think if you dropped an HTTP In node and connected it to the restart node in that package you could give yourself a way to reboot the host machine even when HA was completely locked up.
Or if you don’t like having a REST endpoint for that could pick something else that Node RED can integrate with to use as a trigger. Anything besides the HA nodes would work (since HA may be locked up).
Even if you do go with a regular restart schedule just seems it might be useful to have a way to get out of a lockup in a pinch.
Quick follow up. I think I may have found out why my HA was locking up. I think it may have been overheating. Prior to installing the Z-Wave controller board I had a fan on my Raspberry PI, but the Z-Wave board installs in the 5V pins on the GPIO. The fan can run off of 3.3-5 volts so was able to power the fan from another GPIO pin. Since I’ve added the fan back on about a week ago, I haven’t had a lock up.
Same here. But it’s about the RAM Usage.
I use a 1 GB Version of a R Pi wich is not recommendet and not supportet as fas as I know. But the otheres are hard to find at the moment.
However - I will upgrade asap. But in the meantime, a reboot each night fix the problem.
Thx!
Rakete
Several subjects covered in the topic “Reboot Automation”. Overheating on Raspberry PI, memory, etc.
I couldn’t get an answer if a reboot automation is possible or not? It’s possible? Does anyone have a script to exemplify?
I am looking for the same. I have heard from several very technically savy senior folks across forums that this is typical for Raspberry PI’s (what is happening in my case), all the logs show nothing but the unit just stopping functioning - as though it just decided to go on vacation - and it gets really cool then as well, like the CPU has nothing to do, so it isn’t a kernal panic or multithreaded race condition etc. This happens to people that even tweak their setup to death so everything is running within very safe parameters. I have an RPI 4b w/8Gig of RAM running completely off a 1TB SSD, network connectivity is only through ethernet - no other hardware connected (Healthy and Supported HA Supervised) - voltage is fine, I don’t even have an SD card in the slot - and like clockwork it completely freezes once every 7 or 8 days. I also several times a week even, make sure the host OS is fully up to date with all patches and also update every single available update to any and all parts of HA (including addons, HACS items, etc.). It is typically only at 106 degrees F (with a spike to 115 once every 5 minutes or so) consistently all the time, and I have never seen memory usage go higher than 30% (usually at 20%). I have reformatted and installed from scratch everything several times, even have a daemon running on the unit’s host to power on the fans if more than 60 degrees C and then power them back off when it falls below 50 degrees C (and never have seen the fans on unless I am forcing it to have a maxed out CPU to check my logic for the FAN daemon) as the case I have is like a huge heat sink and I am running it as 64 bit (32 bit runs much hotter). I had a cron job on the host which would stop HA properly and then reboot the RPI every night but for some reason when it comes back up, it will not connect to the network - but only on exactly every other reboot. That was resolved only by weeks of work re-testing and reconfiguring and ultimately re-installing HA Supervised from scratch a couple of times until I had it down to a science. The only way I can get everything on the unit to come back up consistently on a reboot every single time (I mean testing it by doing the reboot 20 times in a row even to make sure it is bulletproof) is if I do the reboot within the menu on HA itself. Every time the systenm would lock up after 7 or 8 days, when this happens there is no error message in any of the logs except they all have at the time of it freezing, one line of binary characters in the log (and then more lines which are normal from me doing the reboot) - that one line I do have to remove in order for command-line sesnsors that do a grep in different logs to be able to return valid values (yes, I have replaced the SSD with a brand new one as well, and consistently would shut it down, reboot from an sd card, then reconnect the ssd, telnet into a linux command line, unmount the SSD and do as sudo a full linux file system check as well as commands to remove file fragmentation). All that has made no difference, consistently it will ‘go out to lunch’ every 7 or 8 days. I have even tested throwing all kinds of weird situations at the RPI such as powering down and rebooting various other devices (the router, the ONT, switches, other devices that may flood the network with gobbledigook messages, etc.) on my network to see how it handles connection errors and/or network reconnects, it always handles those like a champ.
I was going to get an intel NUC or the like but it almost seems like a waste of money with this little champ of mine running so cool with so much extra memory left and the CPU % running so low.
Purists always say ideally one should find the root of an issue rather than a band-aid reboot approach but in this case I have gone down that route in a logical manner until it does end up becoming a rabbit hole, so am stuck with the issue unless I try re-institute regular reboots - but only from within HA itself.
Therefore I am going to just set up an automation witrh a time-based trigger every 4 days or so to use “hassio.host_reboot” only at 3am or the like, and will slowly lengthen the time between reboots until I run into the issue again and then will back down on the length of time for that. What a bummer.
I’ll add an update here after that has been running for a while to let everyone know if I have experienced an outages after a while with this approach…
Thoughts anyone?
(FYI Current setup is below)
| version | core-2023.4.6 |
|---|---|
| installation_type | Home Assistant Supervised |
| dev | false |
| hassio | true |
| docker | true |
| user | root |
| virtualenv | false |
| python_version | 3.10.10 |
| os_name | Linux |
| os_version | 5.10.0-21-arm64 |
| arch | aarch64 |
| timezone | America/New_York |
| config_dir | /config |
| GitHub API | ok |
|---|---|
| GitHub Content | ok |
| GitHub Web | ok |
| GitHub API Calls Remaining | 4842 |
| Installed Version | 1.32.1 |
| Stage | running |
| Available Repositories | 1338 |
| Downloaded Repositories | 24 |
| can_reach_server | ok |
|---|---|
| remaining_requests | 26 |
| logged_in | false |
|---|---|
| can_reach_cert_server | ok |
| can_reach_cloud_auth | ok |
| can_reach_cloud | ok |
| host_os | Debian GNU/Linux 11 (bullseye) |
|---|---|
| update_channel | stable |
| supervisor_version | supervisor-2023.04.0 |
| agent_version | 1.4.1 |
| docker_version | 23.0.4 |
| disk_total | 915.4 GB |
| disk_used | 15.8 GB |
| healthy | true |
| supported | true |
| supervisor_api | ok |
| version_api | ok |
| installed_addons | AppDaemon (0.12.2), Core DNS Override (0.1.1), Duck DNS (1.15.0), File editor (5.5.0), Home Assistant Google Drive Backup (0.110.3), Log Viewer (0.15.0), Mosquitto broker (6.2.0), Samba share (10.0.0), Terminal & SSH (9.7.0), AdGuard Home (4.8.6) |
| dashboards | 5 |
|---|---|
| resources | 15 |
| views | 29 |
| mode | storage |
| oldest_recorder_run | March 23, 2023 at 2:41 PM |
|---|---|
| current_recorder_run | April 22, 2023 at 12:43 PM |
| estimated_db_size | 1147.45 MiB |
| database_engine | sqlite |
| database_version | 3.38.5 |
Hope this helps for other people, I’ve set up a drop down with the days of the week for the dashboard and a time picker, both of which are used by the automation and I’ve supplied the yaml for that as well. (I have them named 1 of 2 and 2 of 2 because I want to set two times a week for reboots as needed). Below screenshots and the code for the first one and the second one are the same (so only showing the details for the first).
Here’s a new HA blueptrint for a weekly reboot at the specified day and time:
To use:
What is just found, but still don’t really understand is on a hotel wifi, sometime, I cannot get remotely to HA. however when getting to the cloud flare HA link the remote access is working.
Probably, the wifi definition of the hotel is closing the direct tunnel used by the App.
Maybe this will help someone.
can i make this to reboot everyday?
For rebooting every day at a specific time, you can use this automation:
alias: Daily Home Assistant Host reboot
description: "Reboot Home Assistant Server every day at specific time"
trigger:
- platform: time
at: "01:30"
condition: []
action:
- service: hassio.host_reboot
data: {}
mode: single
Adjust the time to your needs.
Sorry, this particular blueprint doesn’t support daily reboots.
I would say, if daily reboots are required, too many things are going wrong, and it’s better to address those to be able to reboot just once a week. A weekly or a monthly reboot can clear up issues rare and random enough that are both hard and low priority to resolve, but nightly indicates more urgent issues.
Have the same issue! Going a way for several weeks and wife is not happy when HA has stoped working.
I habe my raspi powered wie a Shelly plugs that I can tun of/on via the Shelly cloud if I have to hard reset.
Also I can’t understand why it happens. R4 with 8GB and SSD on the USB port. (Using apr. 13% GB and 2-3% CPU)
I will try to analyse the power consumption on the Shelly and see if something is show up there!
Hello, I am following, this disusssion to automate an addon dayly restart.
The scheduler can be" inject" at specific hour, “call service”, now “action” will runs hassio.addon_restart.
My difficult is how to target the action to the specific addon.
I think I understood it is necessary to insert the “slug name” in the “J: expression”, but what is the “slug name”?
Furthermore, what is the exact syntax to use in the “J: expression” to target the specific addon?
Do I am totally along from the solution? In Case please explain to me.
Thanks for your reply.