Exactly how is it offtopic? Has it been determined which type of cloud integration (direct or Hubitat relay) is causing the OP's issue? It was mentioned that one of the source IPs was Google's.
Does Hubitat use Google Cloud Services? How would the communications be sourced by Google if not?
If this goes through Hubitat, it's their problem to fix. The OP said the registered user was changed, so Hubitat should be responsible for shutting down the service associated with the old user on that hub.
If it doesn't go through Hubitat, why all the discussion as if it did, and back to my original question - how does it know the new IP address? edit: And if Hubitat somehow allows direct services to look up public IPs associated with a hub ID, then it's again a problem for Hubitat to solve - they should shut down the connection when a hub's registration is changed.
Original topic is how to discover what is calling it.
Hubitat does not allow external services to lookup a hub's location, it maintains it's own registry of hubs and delivers messages based on what the external service provides as a hub identifier if it matches an entry in the registry.
You can't just block all Google or Amazon type messages to a hub, the account at the 3rd party must be shutdown - normally only the account owner can do this.
Pretty much all Cloud Integrated Services, where that cloud provider can generate a non-polled event back into your Hubitat hub, requires the use the Hubitat's Cloud Endpoint Server, which is hosted on AWS.
For example, your Life360 integration uses Hubitat's Cloud Endpoint Server. When Life360 on your phone detects the device has entered or left a geofence, it lets the Life360 Cloud Server know. The Life360 Cloud server then contacts the Hubitat Cloud Server, using an OAUTH2 URL that your hub generated originally when you installed the Life360 App on your Hubitat Hub. This OAUTH2 URL contains a 'token' that must match your hub's Life360 app's expected token to allow the data to transfer to it, via the Hubitat Cloud Endpoint server.
There is never any need for a 3rd party cloud server to know your hub's private LAN IP address. When your Hubitat hub reboots and connects to the Hubitat Cloud Endpoint server, it establishes a persistent TCP/IP connection. This is what is used to transmit all external requests to your Hubitat hub. Your hub's IP address really is not all that important, as long as the hub maintains its connection to the Hubitat Cloud Endpoint server.
When a user buys a used Hubitat hub, like the OP did. There is a chance that 3rd Party Cloud Services, like Amazon, Google, Life360, etc... will still try to update the hub via Hubitat's cloud endpoint server. This results in the issue reported in the first post. But, since the tokens have all changed (assuming the hub was reset!), the data will not be accepted by the hub. The hub does, however, let the user know in the Logs that an application somewhere is trying to send data to the hub.
Yes, it is... Hubitat's Cloud Endpoint server is simply acting as a relay, passing through the IP address of the Cloud Server that sent the data. This is the only way the end user will have any clue as to what system originally transmitted the data.
This is a pretty well-described warning that occurs for reasons we (as users of the platform, not staff) are pretty sure we understand the basis for.
I’ll say again, this is a digression that’s unrelated to the OP’s question/request for assistance at this point. Please start another thread if you want to have a more detailed discussion about Hubitat’s cloud endpoint.
Then Hubitat's logging sucks. If a Google address is reported as the incoming one, that's the address the HE should be responding to, which if you know anything about networking would not be appropriate for a relay/proxy.
And, assuming it is going through Hubitat's relay, this is Hubitat's problem to solve. They shouldn't be relaying services associated with an old registration to a new one.
Think of the system log as a courtesy call for the user to take action. What the log says is simply letting the user know that an external request was received looking for an app that user has removed. The hub doesn't know what it is for. For all intents and purposes this may very well be viewed as an attack. It is up to the user to take action on the warning.
That. Nobody else has control over those integrations, they are tied to someone's Amazon or Google account.
Cloud services use cloud.hubitat.com URL, which then uses messaging to forward requests to the hub. You could disable the cloud and get rid of these messages, but that will obviously stop your own cloud integrations.
That is an incorrect assumption. A Soft Reset (without restoring a backup) would remove the app, but would not have an effect on the network settings or cloud connectivity.
The user claims not to have had such an app. They bought a used unit, reset it, and re-registered it. They imply that they've never set up a cloud integration themselves on the hub.
If that's the case, and Hubitat is still relaying stuff, that's a security problem which Hubitat has created. Hubitat should not be relaying something set up for an old account, to a new one.
Perhaps the original source can't be stopped (although allowed services should be required to have either a time-out or a kill switch), but Hubitat can certainly stop relaying until/unless the service becomes associated with the new account. And, if they're not associating services to registered accounts, and letting anyone send messages to any hub ID, that's an even bigger security issue, if only because of DoS.
Resetting and re-registering a hub should make it like new. The user should not have to resolve issues such as this.
Not a security problem because the hub is correctly rejecting the request, and nothing is being sent back to the originator either verifying or denying the existence of the hub.
Hubitat didn't create the problem, the original owner did by not terminating the 3rd party accounts.
Perhaps, in this case, because the app isn't present. Are all services required/policed to use encrypted/authenticated communications (and if so, why not also require association with the current registration)? Is there the possibility for a new owner to take over control of the old user's service by identifying the app and creating a new instance, or creating a custom app to do nefarious things? If the hub is not authenticated using current registration info to the Hubitat relay, why are messages still sent? Are the communications throttled, or is this a potential DDoS mechanism (for both Hubitat and the hub)? How many messages is Hubitat handling which are destined for retired hubs because the service can't be stopped? If nothing else, it consumes bandwidth, cpu, and creates unnecessary log messages.
Really? Hubitat can't figure out how to associate creation of a new service with the registration in effect at that time, apart from oauth? Hint: Associate token with registration. Registration changes? Invalidate token.
