Yes, I think that will work. Good thinking. I’m not sure if unplugging it would leave it unassigned and cause it to fail a transmit, but it’s worth a shot if you can’t reassign its IP.
I’m re-evaluating the boot-loop section and the startup delay section right now. I’m so sorry about this, @Angus_M.
I hope it works for @Angus_M.
I retract the suggestion made earlier about using the loopback address. Murphy's law suggests it is good to have a cut-off switch as a backup; using the loopback address would remove that cut-off switch.
@Angus_M here’s another thought. If you can get into the driver, copy and paste the original in, and save it before it reboots (you might be able to get to it and paste it in within a few seconds), it would remove the ability for it to send a reboot command. I’ll stay awake here until I hear things have returned to normal on your hub.
Once it’s back up, it would be useful to see what your past logs say, although, I also understand this is a stressful situation, and you shouldn’t feel any obligation to need to share them.
@aaiyar: I was thinking it might make more sense for it to be declared globally instead of in the individual methods. Unfortunately that’s going to take a back seat as I’ll be investigating this.
Just got back from shopping. Will take another look and see what I can do to interrupt it. It literally reboots almost instantly so there is no time to intervene. I will try the ip address change at the router and see if that stops it. I even cycled the power (I know this is not ideal) and still it kept rebooting when it powered back up, which was a bit of a surprise. Please go to bed. No need to stay up for this. I'm sure we can find a solution eventually. I can always use a hammer if necessary lol.
Ok, managed to interrupt it by unplugging the network cable while rebooting, waiting for a few minutes, then replugging in the LAN cable and quickly removing the app. I also changed the dhcp reservation to another address temporarily so maybe that helped. But I didn't reboot the router. Anyway, will reinstall the app and try again. I'm a sucker for punishment and really want my hub to reboot automatically when it's slow, so I will persist 
I noticed I'd also commented out line 74 along with line 75 (I don't have my hub logged in with a username/password). Not sure if that's correct or would have caused any issue...
Fyi, just in case it's relevant, the other setting I also had activated was the modes. I'd selected all my modes because I wasn't sure if it was necessary to have them selected for the app to work under that mode.
Adam - did you manage to replicate my issue of reboot cycling when rebooted manually? Or you think it was a one-off? Also, were my edits to the driver correct (eg. I had commented out both line 75 and 74 as per the screen shot). Let me know your thoughts please. Thanks and sorry to cause you more work/time.
@adamkempenich apparently this app isn't working with a 500 error.
app:40062020-02-10 01:21:09.676 pm error Something went wrong when trying to send a reboot packet.
app:40062020-02-10 01:21:09.676 pm debug Response Status: {408
app:40062020-02-10 01:21:09.486 pm error An error occured. Hub is unreachable or has taken too long to respond. Rebooting now.
app:40062020-02-10 01:21:09.458 pm info Checking hub for DB readability...Firmware >2.18?
Missed this—haven’t had time to take a look yet — I’ll get on it 
yup 3.x
Oh! That’s not what I expected. That’s a cookie issue. Hmm.
2.18+ has an issue where it will kill cron tasks and not reboot. I’ll take a look at the cookies.
Actually wrong v.. its 2.1.8.117
I had to reboot from the port 8081 using the MAC address
Wouldn't that be a "safer" location to run the reboot against at all times? That is supposed to be the failsafe method anyway, right?
I think that's technically firing the same command. I've never investigated how the MAC reboot works, though ... I should look into that. I'll see to figuring out what the cookie issue is, in the meantime.
Internally it is probably the same, but maybe the login is implemented differently? The login with username and password and subsequent cookie, do you know if that is using the DB at all? I would suspect the MAC address "login" does not use the DB in order to be more fault tolerant, but these are just speculations, it would be nice to know for sure...
I believe the way the 8081 reboot works is using the standard linux reboot command which essentially is probably the same as the regular one except the auth is strictly via the mac address which I am assuming is checked by using grep and sed on the eth0 interface.
I might be wrong but I am pretty sure I am right seeing I have used linux for 30 years.
Yes, this sounds likely, a rather normal approach I'd say. It is very likely the most robust access to reboot we can get on this system. Getting an official answer is probably too much to hope for.
Download the Hubitat app
