Hubitat OAuth Connection Issues

I have 4 Hubitat Hubs connected to Sharptools. One of them I shut down a long time ago but it still shows in the Sharptools list. I tried to disconnect it tonight. This didn’t work, I think because it was not powered on? However it did delete two of the other three hubs. Now when I try to connect them I get the “Oops Hub is not responding message”. I tried rebooting the hubs, still the same message.

So I am now running with 1 active hub connected, 1 connection to a hub that is not running, and missing my two primary hubs. So I have a lot of placeholders right now.

I searched through the related posts but they all seem to point to something on habitat cloud side being down. But I don’t see any posts or anything over there. Any suggestions? Thanks.

:information_source: This post has been updated to summarize the issue. The original reply to Simon is included at the bottom of this reply for posterity.

We have added a warning to the authorization flow that will show up if the Hubitat OAuth servers are slow to respond. That warning links to this thread.

As alluded to in that warning, the Hubitat OAuth servers have been experiencing significant performance issues. We created a post in the Hubitat community and have been tracking the issue with the Hubitat team:

Unfortunately, this issue impacts any service which similarly authenticates with Hubitat including Google Home, Alexa, IFTTT, and more.

We significantly increased the request timeout on our side to try to give the OAuth servers more time to respond, but if they don’t respond within 60 seconds (which is an exceptionally long time to wait in the modern internet), the process will timeout.

:bulb: If you already have your Hubitat location authorized, you can update your device selections from the SharpTools ‘app’ settings on your Hubitat hub. This bypasses the Hubitat OAuth servers.

Some people have found that if they wait 5 minutes and then try again, sometimes they can get things to go through. The performance of the Hubitat OAuth servers seems to degrade more and more over time, so sometimes this requires retrying several times over a long period of time before it works.

Background device sync improvements (tap to expand)

We’ve also update our background device sync process to workaround this issue for users with existing Hubitat connections. This will not fix things for the primary authorization for as that fundamentally relies on the Hubitat OAuth servers, but will workaround things for background device syncs that may occur as you edit your dashboards or rules.

Previously, the background device sync process needed to ask the Hubitat OAuth servers for a list of locations – unfortunately, because the OAuth servers were experiencing significant issues, this could cause the locations to become deauthorized from SharpTools. We’ve added logic that will fallback to querying our internal location snapshot if the Hubitat OAuth servers don’t respond in time.

Original reply to simon (tap to expand)

I’m seeing the same thing when I try to reauthorize as well… it’s interesting as that message does in fact come from Hubitat’s servers directly. So it’s weird that they thing the hub is offline when I’m able to use Cloud URLs from other ‘apps’ like the Hubitat Maker API. :thinking:

I get the same error message when trying to authorize other Hubitat OAuth apps like IFTTT, Alexa, and Google Home, so it seems like there’s something funky going on at the HE side of things…

Edit: Here’s a link to the post I created in the HE Community:

[RECURRING] OAuth Connections Down / Performance Issues - 🚧 Developers - Hubitat

I see that you posted over there so will wait and see.

Will my hubs reconnect or will I have to connect them manually?

Also, do I have to power the old hub back on to disconnect it? I think I asked this in the past but I can’t find the thread. Thanks.

If they are disconnected, you may have to reconnect them.

I suppose that depends on what’s going on with the HE side of things. I suspect it’s something with their OAuth servers and when they fix it, then reauthorizing should get things back online, but we’ll have to see what the HE team comes back with.

Lost connection to my Hubitat hub on Sharptools as well. All the tiles just show placeholders. Will I need to reconfigure my tiles again after they fix the issue and I have to reauthorize it. I hope not cause I just spend a lot of time customizing them.

No, the tiles are keyed on the Hub ID + Device ID and should rehydrate when the hub is reauthorized.

Just an update that the Hubitat team indicated that the OAuth issues should be resolved. I’m still seeing some intermittent performance issues with the Hubitat OAuth servers, so if it doesn’t reauthorize right away you might try again (or try again later).

@josh It doesn’t appear to be working for me again. It failed several times in a row this morning. I posted on the Hubitat side.

Yeah, they’re definitely still having some issues. Not sure if you saw that I posted on their thread yesterday that their servers were still having intermittent performance issues.

When I tried to open their authorization screen today, it took 2’11 to load, then it errored out when I tried to log in. So they’re definitely still having some issues.

Seems to be working again but afraid to do anything now! I started all of this by trying to delete two hubs from my setup in Sharptools. I was not able to disconnect them even though they are powered on. I read in another thread that you can delete these on the back end so will send a note through to support. Thanks.

@josh how often does it recheck the connection? I notice that even if it fails it does eventually clean itself up and connect properly.

You also have to have a valid authorization to the hub to be able to disconnect it. As part of the disconnect process, the system sends a few requests to the hub to clean up after itself (removing event subscriptions and such), so it requires a valid authorization token.

There isn’t a fixed schedule, but there are some healthchecks that run based on certain actions. For example, when you open a dashboard, the system checks to make sure it has all the event subscriptions it needs. And when you first load the web app (eg. F5/full page refresh) it runs a series of healthchecks that make sure any event subscriptions the system thinks you need are setup on your hub. With either of those healthchecks, if a request is sent to your hub to update event subscriptions, it also performs a device sync after that to make sure it doesn’t have any stale attributes (from before the event subscriptions were setup).

So it could be that your auth token was still valid and one of those healthchecks caused a device sync.

@josh I am still having issues today. Also I am having issues when I turn on certain devices and I get the :warning: symbol. I assume this is related?

It sounds like you hub may have been (at least partially) deauthorized.

Can you send a note to and we can look into it in more detail?

1 Like

@josh So the process at presents seems to be this:

Add a new device to the Sharptools App in Hubitat
Click Done
Wait a few minutes and Sharptools times out in the background due to Hubitat oauth issues
All dashboards fill up with placeholders
Go to Sharptools App and click on view account
Note that the Hubitat is now missing
Click on Manage connections
Click Hubitat
Wait a couple of minutes for the Hubitat login screen to appear
Select the hub
Scroll down to the bottom and click Next
Get a Congrats screen - most of the time, sometimes the Oops screen appears so repeat process
Wait ~10 minutes for tiles to refresh

One question - when I add the device to the Hubitat Sharptools app - is there a timeout there that can be increased so it keeps trying? Thanks.

Yes and no.

As you noted, the issue is specifically with their OAuth servers. Normally that would only impact your connection if you were explicitly going through the OAuth process (eg. User Page > Manage Connections). But the OAuth server is also touched for one tiny, but critical part of the device sync process: where the system gets a listing of the of the locations that are available.

While this is normally just the briefest of stops along the information highway, this information is supplied by Hubitat’s OAuth servers and when they hang up, the whole process completely hangs up.

On the other hand, for the actual synchronization of devices, the information is sourced from your hub and we do have an exponential backoff and retry algorithm in place. But the device sync process is getting bogged down at the very first brief step mentioned above. :slightly_frowning_face:

As a result of these extended issues with Hubitat, we’re considering adding some logic to try to workaround the need for that first stop to the Hubitat OAuth servers. There’s probably no way to completely workaround it and it’s really not ideal to cache that information, but with all the issues Hubitat has been having with their OAuth servers, we might introduce a stop gap solution until they get things fixed.

I am having another unrelated issue with the Zigbee radio on my new Hubitat C8 and it is looking like this is a hardware issue and others are experiencing the same issue. Just a guess but this may be consuming some of their time right now.

Recently, I’ve been having issues with performing an authorization from Hubitat. Sometimes it would time out before adding my new devices, sometimes after.

I get this error:

Uh oh! We couldn’t complete the authorization. Try again.

Any idea how I can resolve this?


Hi Bruce - I’ve merged your post in with another thread on the same topic. You may want to scroll to the first post and read through some of the replies.

The short version is that Hubitat is having serious ongoing issues with their OAuth servers. Unfortunately, this impacts any app that integrates with Hubitat using their authorization flow (eg. Google Home, Alexa, IFTTT, SharpTools, etc.)

It seems like the issues are temporarily resolved when Hubitat does a hard restart of their OAuth services and then the performance issues start creeping back in.

Thank you for the update, Josh. I will continue to monitor this thread for further updates.