You are actually lucky to have made it so far. I have a RPI4 (8Gig of RAM) running supervised on a USB SSD (Samsung T7 1TB). It works great except almost every 7 days it just dies. I mean - the CPU decides to go on vacation. No high temperatures, CPU at 0%, memory usage very low, nothing in ANY of the logs except the last line in each log is some kind of binary gobbledigook - so if you have any command line sensors that run a tail on the syslog for example and the like would not be able to properly interpret what is in the file. I got sick of rebooting and then truncating the log files by opening them with “sudo nano” and then using alt-t to clear out the contents before doing ctrl-x to close out each file as empty. (I know I sound like a linux noob because I am to some extent).
Anyway, it is not talked about often, but I have heard from other very senior people on this forum, evidently this is a known issue with the RPIs in general with HA but an ‘open secret’ (?). I believe this has never been resolved because there are no logs to show what the problem was - there are no error messages in ANY log files even if you have extremely verbose logging for all of them turned on (believe me, I have gone down that road as well, there is nothing to be found). It is just running normally - and then decides it is bored and wants to go on strike, so it spits some garbage obscenities onto the log files and goes on vacation (still powered up, but ‘out to lunch’ so to speak). No CPU race conditions, thread locks, hardware issues or anything like that is shown… For this reason alone others have decided against using an RPI but I did this workaround which resolved the issue permanently in an elegant manner - and it can be set/adjusted from the dashboard with no further coding needed once it is set up.
As I do it twice a week I could duplicate the below twice to show you everything I have but that is not needed to get my point across so I’ll just show the first. The day of the week selection is just an input_select with every day of the week available in the selection:
and the time is an input_datetime set to only pay attention to the time:
Here is the automation utilizing the above - it is triggered every day at the time specified and the condition is only met if the three letter representation of the day of the week matches what is selected -
alias: "Host Reboot (Per Day and Time #1 of 2)"
description: ""
trigger:
- platform: time
at: input_datetime.time_for_weekly_reboot_1_of_2
condition:
- condition: template
value_template: >-
{{ states('input_select.day_of_weekly_reboot_1_of_2') ==
now().strftime('%a') }}
action:
- service: hassio.host_reboot
data: {}
mode: single
This has worked flawlessly ever since I put it into place. the “hassio.host_reboot” is the perfect and safest way to do it as it first gracefully shuts down HA and then gracefully also shuts down all the other processes running on the RPI - which includes properly closing all open files such as log files etc. - for absolutely everything on the hardware, even software that is unrelated that might be running on it - and then reboots it (so the reboot takes a few minutes - it’s the safest and best way to avoid any issues). You just have to have everything that is running on your RPI be set to start on bootup.
I have never had the weird problem since.
Yes, I was thinking of using the calendar for this (I know some people would ask), as they also do have a ‘repeating’ feature - but when I set this up I did not know about the calendar (I have used it since for other items though). I am one who goes back and redoes things when I learn they could be done better (as it is a hobby/obsession as well), buit in this case the calendar is not better… I would rather keep it this way - this is simpler, you can just update the date and time with a couple of gui items on the dashboard even on your cell phone easily, when you are nowhere near a keyboard, once it is built, no reason to bother with any coding to adjust it… 
I guess you could also add input_select/s with “Enabled” and “Disabled” values which are then shown on the dashboard that you can then use in the automation code as a condition to not bother with the reboot if set as “Disabled”… (I do that with a bunch of other stuff, it is convenient…)
Hope that helps
