Received cloud request for App 35 that does not exist, path: /intf/location/updated from 174.243.149.217

The cloud request is coming through with a hub identifier that is tied to the physical hub. Doesn't matter if you reset the hub or not, the identifier will remain the same.

1 Like

Oh poo.. I’ll try restoring older point and do a soft reset then. But anything else if this doesn’t work?

Could try blocking the IP at your router, but that may have other consequences if you use Verizon for anything legitimate.

It does feel like a small utility to keep a record of app id's and names, both current and pass apps, may provide useful in situations like this....

1 Like

I feel something may appear in HPM in the not too distant future?

1 Like

That would be great. Along with users just doing good house keeping and properly backing up systems — which I am guilty of not since I barely just started last month.

1 Like

I did start to try and parse the App page to get the list, I think I got close from memory, it's been a while....

Many of us rely completely on the built-in backup service and the subscription cloud backup but the retention period is only a couple of days so I'm pretty sure you're not alone in this.

Am I just restoring a backup or using Diagnostic Tools to go back to a previous version? Seems to be two different functions.

Yes.

No.

Right you are! Restore to previous version rolls back platform upgrades but will not restore apps etc. Restoring from a backup restores the hub's database. It will not cause the platform to revert to a previous version.

Now that I think about it... a great custom app would be one that automatically saves each night's backup to a network-accessible (from the hub) file share. It is beyond my capabilities (and perhaps not technically possible) but I do know people :slight_smile: @sburke781 @thebearmay

There's a simple script out there that I used to run on a rPi to do that (adapted it to run on my Synology a year or so back).

1 Like

That may convince me to invest in Synology. I have stayed away from NAS up until now.

Uhh. That didn’t go well.

Well crap. At what point did you get this message?

After I did the restore from backup

Hmmm. Well... since it suggests a reboot why don't you give that a whirl. If not I'm a little puzzled, but maybe try another backup to restore? Or do a soft reset followed by a restore, but I am pretty sure the recent platform versions do that for y ou.

Here's a snippet from my script, I just repeat this for each hub. Looking at it now there's probably a few things I could improve, but it does the job. I also hope I can use it for downloading a file manager backup.

#!/bin/bash
# Script to download hubitat backup

heName='HERULES01'
heAddr='XXXX'
backupdir='/data/backups/hubitat/HERULES01'
cd $backupdir
ls -1tr | head -n -14 | xargs -d '\n' rm -f --

curl http://$heAddr/hub/backup | grep download | awk -F"=" '{ print $4}' | awk -F'"' '{print $2}' | sed '/^$/d' | tail -1 | xargs -I @ curl http://$heAddr/hub//backupDB?fileName=@ -o $backupdir/HERULES01_$(date +%Y-%m-%d-%H%M).lzf

But, back to the task at hand, getting @GHN1013 back up and running...

1 Like

Tried Rebooting from Diagnostic Tools but reverts back to same page. And Cannot do a soft reset. Button is grayed out. Says Hub unreachable. :frowning:

Update: trying a soft reset now. Apparently “soft reset” is case sensitive. Sorry. Was able to do a soft reset and the asks me to restore from backup. Tried that and I reverts back to “corrupt database.”

Try pressing Control+F5 on your browser, just to make sure that display is not a cached view of the page. Alternatively try a different browser.