I don't see an actual answer to the question - shouldn't installed apps show their app # when listed in 'apps'? I get an error message for app 327 but get a 404 when I try the 'IP/installedapp/configure/appnumber suggestion.
I have a message that repeats every minute:
sys:12021-03-18 10:40:29.116 pm Received cloud request for App 327 that does not exist, path: /ping from 52.203.225.134
Yes, the fact that app 327 doesn't exist is precisely the problem that the warning you see in the log indicates. 
What happened is that you had an app 327 installed in the past, and it had a cloud endpoint that something outside Hubitat is still trying to use to communicate with the app--but it doesn't exist, presumably because you removed it from your hub (without removing the other piece outside of the hub).
There is a bit of a clue in your message: HubConnect is a popular community app that uses the /ping URL, though that's pretty generic name that I wouldn't be surprised if other apps use, too (this is just a common culprit). So, if you had either SmartThings or a second Hubitat (as cloud and not LAN) set up to use this community app, check there and uninstall or otherwise de-activate it. If that's not it, try to remember what you may have had in the past and see if you can figure out any clues (or you could restore a backup, if you have one from the affected time, to see for sure).
2 Likes
If it's of any use 52.203.225.134 resolves as a server in Amazon's AWS cloud. I know that doesn't narrow it down by much...
3 Likes
wow. thanks. It didn't occur to me to run a lookup on the inbound IP. While it didn't help - it does provide a small clue. Recently (last week) I blew the brain out of my Hubitat and rebuilt it carefully from scratch - using all i've learned in the last 2+ yrs about devices, useful apps, groups etc. Getting 2.1 groups for example seems like a positive, It also allowed me to really deep dive the firmware of all my smart hardware. I did not debug my logs from the previous load.
What are the ramifications to storing my current load (saving a backup) , loading the pre-update backup I made back onto the Hub in an attempt to ID the app connector?
1 Like
As long as you keep your current database as a backup to restore back to, the impact should be none. Do keep in mind that while it contains the list of devices on Hubitat, it doesn't contain the Z-Wave radio contents, which will remain unchanged with these restores (shouldn't really be an issue if you don't pair any new devices while on the old firmware and are really just going to look up an app ID quick).
But my guess is still HubConnect.
2 Likes
reloading the backup pre-rebuild didn't help. Since none of the screen tables show app numbers, my only option was the previously mentioned IP/installedapp/configure/327. This resulted in an Error 500.
Regarding Hubconnect - To the best of my knowledge, I've never tried or experimented with that module. However, it's possible something coming in from my Smartthings dev days. I'll check their site but I'm less than hopeful as I disconnected and got away from them months ago. TY for the leads.
Make sure you download that current backup before you start. Each Restore first overwrites the on-hub current backup before doing the restore, in case things go badly. Only one backup per day is stored on the hub, with least recently used backups being tossed, as needed. So, if you backup and download the current database before beginning your troubleshooting, you can always go back to that point.
2 Likes
The reload after digression was safe - I got a bit scared when the logs showed massive errors, until I realized the log files don't refresh - so I was seeing errors from the regression test. I can't even get into Smartthings as the api account I used to use is no longer. Just one of those things I guess.
I still submit it would be beneficial if the tables for app drivers/system and app page had the option to display the App ID #'s. I think of M$ Outlook or Drupal and the ability to add/remove fields in the table header as being a good model for this.
Fair enough. Although as @bertabcd1234 pointed out, the app in question has apparently been deleted - hence the log error.
2 Likes
Update: While doing windows updates on a rarely used laptop I had to open the browser, and my smartthings developer account page opened up - (edit: smartthings has TWO logins - the old and the new - in a previous post I mentioned I had deleted the old - I had forgotten the new). The account showed my old smartthings hub - listed below it was a smartapp i had originally linked my Samsung device to my HE device. I killed this app (and a second, related one) and the error 'received cloud request blah blah' stopped immediately on my HE logs. It seems the app number does not come from the HE in this case, but from the source. Anyways. 1 problem solved for me.
Sounds like a while back you deleted Hubitat app #327 (probably Hublink or Hubconnect, something to that effect) but not the corresponding smartapp on your ST hub?
1 Like
in hindsight it's most likely. What is hard to grasp is why I'd get a message in a 'fresh' hub about some external app. That leads me to believe that it is possible to fill someones log files with bogus messages potentially. I was confused by the 'app xxx' reporting a failure until I learned it was a message from the other side getting into my hub. Just glad I stopped the error - annoying as all hell. Reading a recent comment made me laugh '..annoying issues that require forum spelunkering' totally described this.
Oh I see, I think I missed where you said you were getting this on a new hub you had restored a database to?
I don't think there's any way for an outside server to "spam" your hub unless it's something you yourself initially setup and have not (yet) disconnected on the sending end.
2 Likes
To the best of my recollection - I hard reset the hub and started from 0. However, we can assume I already had my DHCP server give it the same IP, and that my login info was identical. I mean, who really changes user/pw pairs just because?? 
After that I started a reload - hand adding devices, drivers etc etc etc. The error DID show during this time, which in my mind it shouldn't have. I also, during this period ran a reload of a backup in an attempt to identify the message. This sequence implies the log is being written to unauthenticated. But other than spamming log files, I can't see a reason to be concerned.
I also changed phones and I have the same problem you had a year ago.
I can't get L360 to show up as a presence sensor since I changed phones.
Please let me know if you had any success clearing it up.
Indeed, it's difficult to get Life360 working again on a new phone.
I had to factory reset the old phone, and uninstall, then install the life360 app.
I then had to sign into the life360 app with the same id as I had previously used.
Then to reset the Hubitat app, and then sign in again.
It's somewhat of a pain, which is why I use the "combined" presence approach.
Sounds like one.
As an alternative, have you considered OwnTracks? Your data isn't stored on anyone's cloud (outside of whatever your mobile provider does with your location data). An unlimited number of waypoints can be defined - and used as automation triggers (eg. Home, Work, Grocery, Library, etc). And @brianwilson has written a Hubitat integration.
1 Like
Interesting.. On both of our iPhones, I was able to simply restore an encrypted iTunes backup of each phone to our new phones, and Life360 just worked again after it was installed. I don't recall spending any time setting it back up on either phone. Note: This happened over a year ago, so it is possible something may have changed in the meantime.
1 Like
Perhaps, as well, it's just another example of how easier it is to use an Iphone, instead of an Android phone.
2 Likes
