Scheduled Reboot

I have a c7 hub and I want to schedule daily unattended reboot of the hub.

I do not want to do this with some sort of power cycle Hard boot, rather a soft reboot.

If there is no way to do this through the system settings, is there a way I can run a scheduled routine that would initiate the reboot?

Thanks

See the Hubitat Hub Controller driver — it has a reboot command. Create a virtual device that uses that driver and then invoke the reboot function of that device in a rule.

The Hub Information Driver v3 also has a reboot capability, and is probably a better choice for such a driver in that it has multiple other capabilities that are useful.

1 Like

Hi John, Thanks for your helpful suggestions. This is a good learning opportunity for me to understand hub system capabilities.

-Jack.

Why? You really shouldn't have to do this.

4 Likes

I agree, I reboot my hub very rarely, I even skip updates so I don't have to deal with it. My mmWave presence sensors sometimes need to be power cycled after a reboot, so I would not want anything scheduled to cause that issue.

When the hub is working well, there should be no need for scheduled reboots.

3 Likes

I have network reliability issues that the hub does not recover from. There are always guaranteed points of failure and entropy that systems must be able to recover from: power loss, downstream and upstream components, hardware failure. This is commonplace. Especially in home networkd

If a hub cannot recover reliably from soft reboot, then that's a flawed design in either the hub resiliency architecture, implentation or protocols.

The same can be said for a hard reboot.

This is just reality of any real world systems.

I have to disagree with you on this.

From a professional standpoint (I'm in IT), most systems do not and should not require daily reboots. If configured properly, systems of all types can run for days, weeks, months or years without a reboot. The only time we reboot critical systems or devices is during scheduled maintenance windows.

From a home user standpoint, the same holds true in my opinion. I have over 150 devices of various type connected to my home network. The only time I reboot a device is when doing upgrades that I deem necessary.

It may be worth looking into why you have network reliability issues. Again, just my opinion.

5 Likes

Maybe I misunderstood but I don’t think anyone has suggested the hub will have a problem recovering from reboots, no matter how often you do them.

The issue others are pointing out is that frequently rebooting the hub is a temporary workaround, whereas identifying and fixing an underlying issue is usually possible (and in most people’s opinion, preferable).

6 Likes

Very trivial to do in Rule Machine. Just be sure to change the IP address in the "Send Post" action to that of your hub. Make sure your HUB's IP address does not change by using a DHCP reservation in your router. The ":8080" at the end of the IP address is required!

3 Likes

Or use the special IPv4 "loopback" address, 127.0.0.1

That's what my reboot rule says on each of my hubs. Doesn't really care if the DHCP address changes or even a new LAN.

As an aside, I just had a Hub become unreachable over the network last week ( vacation home). I thought I would have to do a "plug pull" once I got there, but...
My weekly reboot resolved it since the "loopback" address is handled in SW and never even touches the physical interface.

3 Likes

Good point!

1 Like

This is pretty much my scenario. Thanks for the suggestions!

Unfortunately I have no control of the environmental conditions that cause the conditions, which is a non-deterministic cascading failure, And I only have remote access.

I agree in a perfect world, I wouldn't need this and I also wouldn't need to reboot my phone right!

Thank you

i still wouldn't schedule a nightly reboot. i have remote hubs as well and put kasa wifi switches (can be controlled independent of hub) on them so i can manually hard reboot if necessary. i only rarely do a soft reboot .. ie for updates and if working on something and want to pair down all the debug crap i generated in the log during development..

if remote you also should put an ups or battery backup on the hub.. hard power outages not only can burn out power supply with very rapid on/off switches but can corrupt the databse (which is recoverable fortunately with a soft reset_).

in fact i have hubs in 4 locations so at any one time 3 are remote.

2 Likes

Thanks for the suggestions, that's an interesting configuration. Just like you, I have remote locations that I cannot access without a 3-hour drive.
Definitely the UPS, just ordered a new one in fact, the battery was at end of life.

The reason all this started...
I've been getting ISP outages as well as power outages, and pretty my network infrastructure needs to be rebooted unattended since I can't access it remotely, as a secondary location.

I have to power cycle my cable modem pretty much every night as well in an old school timer switch. They're doing "upgrades" and connectivity is super flakey.

Thanks.

1 Like

Finally got this to work after discovering the hub post command is "restart" not "reboot"

Otherwise thanks again, learned something new!

BTW is there a document describing all of the hub post commands?

"reboot" has been working for me for many years now... :thinking: Still works as written in my earlier post in this thread.

Also, appears /reboot is the preferred method

Is there a difference between restart and reboot? - :bellhop_bell: Get Help - Hubitat

2 Likes

Hey thanks, I got the reboot command working! I'm really glad you helped me find that community post, explaining the difference between "restart" and "reboot", where restart causes memory leaks due to it only restarting the JVM, not the Kernel OS. The results reported were disastrous, yikes!

There were 2 issues why "reboot" was not working for me:

  1. Network router security configuration.
  2. Not reverting from "restart" to "reboot" once I figured out how to fix the REAL issue to re-work the addressing of the command (e.g. don't code at 2AM, ugh).

The issue was NOT with the command (reboot/restart), rather the HTTP POST command being blocked by my router due to security configuration.
Perhaps others can learn from this, now given more enhanced security features in routers, which default to high security out of the box.

My router isolates iOT devices network traffic to prevent POST commands inadvertently/intentionally from any of the devices out side that group. e.g. So iOT devices network traffic is blocked/isolated from security risk to other devices on your lan, thwarting attacks. My Hub is configured as part of this isolated security group, by default.

I have my Hub configured with a static IP address, and used the post command as suggested, to the Hub's IP address, which should work.

However, the Router blocked this POST command from being set back to the hub, regardless of the fact that it was initiated from the Hub. The router security must recognize this as some spoofing attack, or is just how it's implemented... a new discovery.

Once I switched the POST command to a localhost address (127.0.0.0) since that's just a loopback command, this of course never left the device so voila, the command worked - both the restart AND as I just discovered the REBOOT command!

NOTE: Using localhost or static address was one of the options in a previous post in the thread, thanks for that getting me thinking of this work around.

Now the user error: I didn't revert the command to "reboot", having last re-wrote the command to use "restart", thinking that was the issue. and once I fixed the addressing issue, didn't update the command to "reboot". Lesson learned: don't debug at 2am, I should have learned that a long time ago :wink:

Thanks again for your help, and everyone else on this thread.

I'm super impressed with the Hubitat community knowledge, contributions, and passion - and prompt reply to get me going.

-Jack

3 Likes

Glad to hear you figured it out. Also, thank you for sharing your findings, as I am sure it will help somebody else out in the future!

1 Like