[Release] [500 Error Self-Healing] Rootin' Tootin' Self-Rebootin' (0.96)

Wot in tarnation


For use in the Wild West of home automation development.

This app will reboot your hub when a 500 error occurs

Installation Instructions

>>>Read this<<<

You MUST edit the section between lines 41 and 45 before you use this. I can't make these settings, because it takes away the reliability of the app.

If your app goes beyond the limit set in your bootLoop settings, you must uninstall and reinstall the app to make it work again. >0.95 resets this counter after a successful boot, so this is more of a last-ditch fix than anything.



I'd noticed that certain events would still fire, even when my hub DB was unreachable. This app (ab)uses that feature and adds onto it.

This is the one-hub version I hypothesized in this post.


  1. Your hub must be on a locally static IP/Address.
  2. You cannot use this as a permanent fix for your hub. If you can fix it, you should fix it.

That's it! If it works for you, let me know. If it doesn't work for you, let me know (as always). Share this with others who are getting 500 errors.

:cowboy_hat_face: Yeehaw!

v0.96 Changes:

Thanks to

@codahq for the bigger changes in this version:

  • Fixed an issue with cookie refresh
  • Changed a potential issue with CRON
  • Allows multiple maintenance windows
  • Fixes the hard-coded IP glitch

Crap... this only works if you don't have a login set.

@aaiyar — Am I remembering correctly that you have a way to send a reboot command to a protected hub?

Yup. I'm at my annual physical (yuck!), but will email you the script when I'm back.


The way he does it may not be compatible with doing it inside of HE apps... Just FYI.


That's probably correct. Unless a login cookie can be stored in the driver for a virtual device, or in an app.

Edit - And not being a developer, I don't know if that's possible.

Just updated the version to 0.91. This limits the number of boot loops that can occur to (default) 5.

To reset the counter, go into the app's settings and toggle the reset switch to its opposite value, then hit done.

I'd have to look into it. In the meantime, you could just have a server relay the POST command to @aaiyar's CURL method.

The cookie itself is tiny - it's just about 80 bytes. You can get a cookie as such:

curl -c cookie -d username=he_login -d password=he_passwd http://hubitat.ip/login

Once a cookie is obtained then the hub can rebooted using an HTTP POST with a command such as:

curl -sb $cookiefile -X POST http://hubitat.ip:8080/hub/reboot

So if there is a means to store the cookie file in an app or driver, the method can be used in Rootin' Tootin' Self-Rebootin' for hubs with login/password

1 Like

You know? I might know of a way to do that locally...

Here’s a success story—a couple hours ago I told @chuck.schwer I wouldn’t be able to test if the limiter was working. Sure enough, I just had one of my hubs 500 twice in a row, and it self-healed/added to the limiter no problem :cowboy_hat_face:

The hub crashed about a minute after booting up, the logs say.

1 Like

I’m very glad to have this app running. Otherwise I would have arrived at the office to find out holiday lights all off :frowning:

Well I don't know what's going on with my Hub, but I installed this app as per the instructions and it just send the Hub into a boot loop.

I have to remove the app in a small window when the Hub is rebooted and before the next reboot command is sent.

Not sure why it is doing that, but everything seems to be working fine without the app. So may be the app is picking up an error somewhere it's not meant to be?

1 Like

I think you got the Rootin' Tootin' Loopin' Self-Rebootin' App . . .



Yeah, that shouldn’t happen :crazy_face: I think whats happening is the rule can’t keep up with the app on boot. I’ll add a 5 minute delay or something to the startup process and I think that’ll fix it.

But why would the hub be rebooting in the first place? There is no error that I could see and everything was working fine.

Once I installed the app, it just decided a rebooted is necessary.

1 Like

The app works on two separate exploits:

  1. A hub refuses to respond in a timely manner
  2. A rule refuses to execute.

The situation you’re experiencing is that the hub doesn’t respond to the first request right away, so it falsely reads it as an error.

I’m still testing for better ways to detect this, but a delay on startup will fix that issue.

I’m also seeing an error in some of the logic in the boot loop preventer. I’ll fix that at the same time.

0.92 is out. It adds a startup delay (2min 30s) and fixes the boot loop limiter (defaults to 5)

Edit: just to confirm—you’ve made the rule listed in the first steps, and it’s triggering?

@adamkempenich are you still working towards making this work with a login? Or is this unfortunately a current limitation of the HE platform? Also Nice work on creating this app.

1 Like

I am. The latest release fixed the startup issue. Haven’t had time to test the login version though :frowning:

If anyone wants to see if they can grab a login cookie and write that part for me, shoot me a DM :slight_smile:

1 Like

I forgot to post here and say that I added a startup delay. You may want to make it longer than the default 5 minutes.