Used Hubitat Hub. Delete all links to previous owner seemingly not possible

🛎️ Get Help
1

Long story short, I have been a Hubitat user on and off since the C4. I upgraded to C7s and then ended up switching all my home automation to Node Red and Zigbee2MQTT on Raspis.

Recently though, for a couple of reasons, I wanted to try Hubitat again and ended up buying a used C4.

I have it up and running fine and have registered it to my account, but I have noticed in the logs I keep getting these type of entry:

Received cloud request for App 8 that does not exist, path: /webhook from 52.20.75.241

I found a few other threads about this and it seems to be cloud apps from the previous user still trying to connect to the Hub via the Hubitat cloud. I believe that IP range is Amazon.

I did contact the seller, but he had "bought it from a friend and never used it himself". He spoke to his friend who said he had "cleared everything down", but presumably he hasn't. Either that or someone in the chain isn't being completely honest. But I am not going to get any further down that road by the sound of it.

Whatever the true history of my C4, I think there really should be a way of completely factory resetting a hub that also includes invalidating any cloud webhooks set up by previous owners.

As Hubitat has been around a while now, there must be quite a few changing hands as users upgrade and it seems unreasonable to put the onus on the previous owner(s) to remember to completely shut down any cloud access. It's like buying a used car and finding that the previous owners kids still expect you to run errands for them!

Anyway, in the absence of any other solution, I decided that as I don't need any cloud access for this hub I would de-register it and solve the problem that way. I did that yesterday evening, but this morning I am still getting the same error messages in the log. If I have read the other threads correctly that shouldn't be possible on an un-registered hub? Does it take a while for a hub to be de-registered from the Hubitat servers?

Any other thoughts about how to stop these messages?

2

The issue is that the Hub ID doesn’t change when you unregister and/or reset the hub. Thus any request coming in with that hub ID gets routed to its last known location even after a reset.

3

Yes, I thought that was the reason for the initial issue.

What I wasn't expecting was that unregistering the hub completely would still allow these webhooks to come through. I thought that if the Hubitat Cloud didn't know where the hub was it couldn't route any spurious webhook messages to it.

Regardless of the mechanism for these messages coming through from old apps etc, I still think Hubitat should have some facility to cancel all pre-existing cloud connections when a new user takes over. I don't pretend to understand how it all works, but it seems a worrying situation for both previous and new owner that some fingerprint of the previous ownership lives on forever.

4

Was an oversight in the original design and will take a major rework of their cloud connection strategy to correct. Given that HE is local first this issue may be around a long time before it receives attention.

1 Like
5

So just to clarify, you would still expect these messages to come through even though I've now de-registered the hub?

6

Doesn’t this all make the hubs no good for resale? Since the C8 was released, there have be a number of posts asking what to do with the ‘old’ hub prior to selling it on. I’d be a little annoyed myself if I bought a used one from eBay that was described as having been reset, only to start seeing spurious error messages in the logs. I realise they’re just messages and won’t affect the working of the hub but still…..Let’s face it log space is at a premium!

2 Likes
7

Yes. As @thebearmay indicated, hubs are identified based on their UID, which doesn't change. So for "proper" de-registration, the original owner has to remove all cloud integrations at both ends. This was a design oversight; I don't know what it would take to correct it, but doing so is desirable.

8

I'd say it was more than a design oversight and needs sorting out. As @johnwill1 says this "oversight" effectively makes hubs no good for resale.

I am only using my hub for the excellent Samsung Hubitat TV integration community driver so the vast majority of my logs on it are now taken up by these spurious webhook messages.

It doesn't seem to effect the running of the hub, but IMO it reflects very badly on Hubitat that there is no way to stop them.

9

But it was an apparent oversight?

It probably wasn’t a deliberate attempt to prevent users from reselling hubs by causing harmless-yet-irritating log entries for those that decide to do so.

And resolving the issue (a largely cosmetic one) for those affected (probably a small proportion of the total hub user base), without disrupting the rest of the platform might be difficult, impossible, or just not worth the effort.

Perhaps it is something they can fix quickly, easily, and with little risk. I’m not an expert or anything, but that seems less likely.

10

Although it does appear to be a "cosmetic" issue, I am still uneasy that someone else's cloud set up is still trying to communicate with my Hub and would be much happier if they was a way to stop it.

As I found threads on similar issues going back nearly 2 years, I'm guessing it is not an easy fix or it would have been done already. But as this traffic must be coming via the Hubitat cloud, I do find it hard to understand why it can't be stopped. Why can't users see what access has been granted to a hub from the Hubitat cloud and delete any they no longer need/want?

11

What would be helpful would be some specific instructions relating to resetting the hub prior to resale, that include any additional steps that the seller needs to do to prevent the log entries. Surely when you migrate from a C7 to a C8, any cloud apps will use the hub ID of the C8 going forward. Is it a case of someone resetting a hub that hasn't been migrated, and failing to disable/remove cloud integrations first? Is there a way to prevent this happening if the correct steps are taken by the original owner? If so, it would be good if it was documented.

12

While I agree that specific instructions would be good, what if something happens to the current user that means they are unable to perform a graceful exit? If someone is too ill, or worse, to be able to go through the exit strategy?

Surely it would be much better if there was a complete clean slate option for any new owner?

13

There isn't really any way for Hubitat to know. Any app you install on your hub can define an endpoint with an optional cloud (and optional local--you technically need just one or the other) "endpoint" URL. These aren't "registered" with Hubitat in any way; the app can just generate URLs with all the pieces needed to make these requests work. Specifically, these are an access token generated by the app, the app ID (assigned to the app by the hub upon installation of that app), and your hub ID. That last piece is how requests get routed from the Hubitat cloud endpoint to your hub (and it's only needed for cloud endpoints; local just needs the other two pieces).

So, after going to the Hubitat cloud, it will reach your hub by ID. Then, it will either find an app with that ID that can handle the endpoint, or will give you that error message. If you have something sending these cloud requests to the Hubitat's cloud for this hub ID, there's really no way to backtrack and figure out what it is--something somewhere just still has one of the pieces above (the hub ID) and is trying to do something. As you may know, the only solution is to figure out what that thing is and stop it. That would be a job for the original owner, or whoever set this up.

That may sound unfortunate, but the good news is that there are two other pieces that will stop this from actually doing anything on your hub. Most importantly is the access token: even with a matching app ID with OAuth enabled (probably unlikely on a hub set up completely differently), such requests--local or cloud, for that matter--cannot do anything once they reach the hub unless the access token matches. The log entry is just passing along the fact that something tried. This can be useful for troubleshooting (e.g., if you're setting up an external integration where you need to manually copy/paste these things and got something wrong); otherwise, it's probably at least Hubitat letting you know that their servers might be happier without this traffic, which would be true regardless of hub ID. :slight_smile:

3 Likes
14

Thanks for the very detailed information.

I cant pretend to understand all of it, but if I understand the basics, a request comes into the Hubitat cloud server from Amazon or whoever with my HubID on it and so it gets forwarded (by the Hubitat server) to my Hub? If so, isn't it at that point that if my hub has been de-registered like it has been now, it shouldn't be passed on?

15

Not sure how the Hub UID is generated exactly, but it seems like a very simple solution would be that when a hub is de-registered the UID is relinquished and a new one established when it is registered again.... but the UID might be tied to the hardware in some way making it not that easy.

16

I'm not sure of all the internals, but since the hub ID isn't tied to registration, I'm guessing the hub will still try to connect to the Hubitat cloud if it has an Internet connection so that cloud endpoints (also used for things like Hubitat Dashboard) will work, with this connection giving it a path back from there.

17

I suspect this to be the case.

18

The original owner picked an integration, got the Access Token from that hub, and gave it to the distant end. Hubitat's cloud isn't involved in any of those steps. It comes as a surprise to Hubitat's cloud when messages start appearing out of nowhere. BUT, the cloud code knows what to do, find the Hub ID and forward the message along. No part of the setup process is Hubitat cloud configured.

Hubitat's cloud doesn't know more about what site is causing the message than you do. There's no back channel to pass along "It's been deregistered, stop it." :slight_smile:

I want to confirm what @bertabcd1234 said about this being harmful. It's not. I don't think any of us here in the forum know how to fix it, but your situation is somewhat unique. We've seen the issue of the message before, more than a couple of times. The resolution has been to dredge through the owner's memory and identify the integration that was created. Login there and disable it. Obviously that can't happen in this case... you're two removed from the originator of the issue.

I think it's clear that little to nothing can be done "today" but I encourage you to keep on this and push for a solution with Hubitat. I suspect that a fix could get added to some future Platform release, but those don't come along on a predictable schedule.

2 Likes
19

It's at that point that i would have hoped the cloud code would check that the hub is actually still registered and If it isn't don't pass on the message.

I'm going to tag @bobbyD to see if we can get an official response to the issue as I do think this makes buying a used hub less desirable, which in turn might affect people's decison as to whether to upgrade or not.

20

There’s the rub.

I believe it’s an effort to maintain the privacy of the user in the first place that makes that intervention difficult in the context of these “unsolicited” messages coming from somewhere else on the internet and destined for a hub.

I think that’s one reason why a gatekeeper like you’re proposing isn’t so simple to implement.