Unable to setup new C-5 hub

Update: here's where we are, still unresolved

Support asked for my network IP address, and internal IP address for the hub so they could manually register it.

I gave them both and they manually took some steps on their end. Afterward, I could see the hub at portal.hubitat.com. However, when I clicked "Register" it would take me back to the http://hub_ip:8081/setup page with "Update failed, please try again".

Support then asked me to disable my firewall, which is not possible with Google Wifi.

So I disconnected everything from Google Wifi and got my old TP-LINK Router again. I did a 30-30-30 fresh reset on the router (holding reset for 30 seconds plugged in, un plugged, plugged back in to fully wipe it to factory settings). I disconnected the Google WiFi, and plugged the hubitat, and laptop into the router, and then plugged the router into my modem directly. Then, I set DHCP rules to force the IP address of the Hubitat to the original IP address it was at when on the Google Wifi (Let's say it was for example). I then disabled the firewall on the TP-LINK (see screenshot).

I then went to portal.hubitat.com again, and initially the hubitat did not display there. After several reboots of both the router and the hubitat, eventually it showed up. BUT the link to register the hubitat is now "" not Obviously when I click on "register" with the incorrect IP address in the URL, it goes to a page-not-found. I verified the DHCP rules were working by going to and can see the same "Update failed, please try again" error message.

I shared all of this information with the support rep, and asked if I should change the DHCP rules to point the hubitat to The support rep told me "no, the hubitat is now tied to It must be registered to that IP address. But when the hubitat was plugged into the new router, and hit the cloud registration service it said "Hi! I'm at IP address, please register me here!" It's not possible due to the hard-coding of my ip address registration, so we need to restart the manual process with support at another time when they are available to help me. It is understandable the rep thought hard-coding might work the first time, but we are now back at square one with a manual reset being required on a brand new hub.

Disabled firewall on TP-Link router

As I mentioned, I am migrating from Wink. I knew there would be a learning curve with Hubitat, but I also thought the hardest/most time consuming part of all of this would be documenting 30+ devices/switches, dozens of automation scripts and IFTTT rules, along with disconnecting everything from my Wink hub and re-pairing it to Hubitat, and then setting up all of my rules again. This was an incorrect assumption.

To anyone coming over from Wink, please note there is a possibility that it will be a 5+ hour ordeal just to get the Hubitat registered to your account and activated for the first time before you can begin pairing things to it. Given that Smart Things seems to have more problems than Wink, our only (reasonable) alternatives to Wink that support z-wave and zigbee are Hubitat and Home Assistant/Hass.io. I was originally concerned that Home Assistant might be even more wonky to deal with. While I AM impressed at the response time from Hubitat support, I am not at all impressed with how the setup process is going just to get the hub working. Hopefully that is something that can be resolved with future hardware/software updates. Reading posts on here make it seem like the new C-5 hubs are more prone to being soft-bricked at unboxing than previous hubs were.

We have reached the end of the day for my Hubitat support rep - understandable - so it appears we will have to work on resolving this another time. I will post more updates if we are able to get the hub working. For now I am going to put my network back together so the rest of my household has internet access again.

I am hopeful we can get this hub working, as it seems like a great community and that it is likely a great product. I am certainly frustrated right now though (not at anyone personally, just at the process thus far).

Thank you for the ideas vjv. It was connected to an unmanaged switch and then to the Google Wifi puck from there. I am holding off on making any further changes as it sounds like there are some things that the support reps need to do on their side to unlock my Hubitat before I can proceed. I do appreciate your suggestions however.

Finally - yes, the hubitat was fully power cycled between each time that any changes were made to the routers (plugging in the TP-Link, making changes to TP-Link, etc).

1 Like

try googling "Google WiFi double NAT" and you'll find lots of people discussing how cameras and other devices needing to be on the same network, aren't working for them.

The point being, it's a problem that a lot of different people are attempting to solve, not Hubitat alone. Please don't read anything into my reply other than: here's more data.

It might apply, it might not, or as is often the case, your mileage may vary. :slight_smile:

1 Like

Thank you for the advice csteele. I did as you suggested. Of note, our ISP has us hooked up with fiber, and our modem has no wireless capabilities. It's literally a single cat-6 line direct to a Google WiFi puck. Then the Google WiFi puck into the switch into the Hubitat.

Again, worth noting that I turned off the Google WiFi entirely to try to set everything up, and used an entirely separate router to see if that would resolve the issue, but alas it did not.

Again, I do appreciate your suggestion.

Could your Fiber provider be blocking access to Google DNS?? Google this.. There are many reports of that happening. According to this thread it appears that the C-5 hub explicitly uses Google DNS.

When you open portal.hubitat.com on your laptop, that domain name is resolving using your ISP DNS. However, if the hub is hardcoded to use Google DNS, and your ISP is blocking, that would explain why the hub is failing to register, even though both have a valid internet connection.

I too had setup problems with my C5. And I'm currently a Wink v2 user. After a lot of e-mails with Bobby in Support, I discovered that the Hubitat was not receiving an IP address via DHCP from my router. Its MAC address was in the connected devices listing, but had an 169,,, address (self addressed) instead of one issued by my DHCP server. Support sent out a replacement unit, and I installed it yesterday. Bang! Works like a charm. My point is that your unit may be suffering from the same issue my old Hubitat did.

1 Like

I just ran a little experiment with lowering the Network MTU settings on my router. I'm a CC/XFinity customer and their Cable service is setup at 1500 MTU.

Some Fiber services lower this value somewhat, and if the downstream components (eg. Hubitat) aren't able to handle the lower MTU, they can mis-behave.

Here's a screenshot of the Hubitat's Settings / Check for Updates screen at 1500 MTU on my router:

and here's what happens when I drop the MTU (rather extreme) to 1400:

In both cases, I rebooted the Hubitat before getting the screenshots. I'm wondering if there's something amiss in it's Network layer and whether folks like @craigspree have lower-than-normal MTU's (potentially due to Fiber)

NB: Yes, yes, 1400 is a very low MTU :wink:

Welcome to HE, nice picture.

Responses to some of the suggestions:

Next step: I have to wait for Support to 'un-lock' my hub from the attempt to manually register it so we can start over. I don't think there's any way around this per my discussion with them before their day ended.

Google DNS: Interesting theory as I was using Cloudflare. I just changed my DNS to It is not blocked by my ISP. I then I unplugged and rebooted everything. Then I plugged the Hubitat back in according to the directions. Still getting Update Failed, Please Try again. It's possible this caused the initial issue, but with the device soft-bricked right now, there is nothing more I can do until support is available again.

IP Address via DHCP: This is not my issue. The IP address is fine, Hubitat support were able to access the unit remotely.

Network MCU: My MTU is not below the 1500 threshold.

Whenever we do get this issue sorted out, I plan on posting here whatever the solution was for others that may run into similar issues. I recognize it is in my own, and all of our, best interests that the platform continue to evolve. More users = more features = more benefits for us all.

It's sometimes difficult to see that from the machines on the Network. Even devices that are on a Network with MTU < 1500 can advertise 1500 as their MTU.

My "devices" VLAN is MTU 1400, and my RaspPi (on Wifi, on that Net) is showing 1500 MTU.

I'm currently packet tracking the Hubitat's interaction on the page(s) above, to see what it's actually doing (apart from calling AWS's iotmoonraker service, with a somewhat poorly formed DNS name (it's workable, but not optimal)

There are potentially ways, using ping with the appropriate OS "DF" flags, against the right sites...

Do you have access to your (Fiber) Router admin/status screen? It might show what it sees as the MTU - esp if PPPoE layering (etc) is involved.

Yes. MTU is set to 1500.

Giving a hand here I also have google Wifi I have the c-4 hub and it worked and connected out of the box with google Wifi so as the op said it could be the c-5 causing the issues.

Some findings based upon review of the successful (1500 MTU) and unsuccessful (1400 MTU) packet responses to the updates server:

  • The server (AWS Hosted) this is reaching out to sets the DF flag on all it's IP responses
  • The client (Hubitat C5) sets DF flag on all it's IP requests
  • With the DF flag set, nothing in the delivery chain is permitted to fragment packets (they'll be rejected, see below)
  • The server is using 1448 bytes in each response packet, allowing for 52 bytes of overhead (on 1500 MTU). Typical overhead is ~40 bytes (MSS 1460), but some environments (eg. VPN, MPLS) increase the overheads.
  • Lowering the MTU is (effectively) just a way to lower the MSS at my end.
  • If anything in the delivery pipeline (server <-> client) has > 52 bytes of overhead the request/response packets will be rejected.
  • The overhead can be anything layered by the Network Operator (PPPoE, MPLS, etc)
  • Looking at the WAN-side of my Network, this is how these rejections appear ("unreachable - need to frag").

As a result, these packets never get to the Hubitat, the router is throwing them out, as they're too big to deliver to the internal network (and DF is set, so they cannot be fragmented):

03:26:35.726191 IP > MyWAN.54244: Flags [.], seq 1:1449, ack 255, win 110, options [nop,nop,TS val 2337096152 ecr 2964], length 1448
03:26:35.726347 IP MyWAN > ICMP MyWAN unreachable - need to frag (mtu 1400), length 556
03:26:36.846128 IP > MyWAN.54244: Flags [.], seq 1:1449, ack 255, win 110, options [nop,nop,TS val 2337096432 ecr 2964], length 1448
03:26:36.846245 IP MyWAN > ICMP MyWAN unreachable - need to frag (mtu 1400), length 556
03:26:39.214073 IP > MyWAN.54244: Flags [.], seq 1:1449, ack 255, win 110, options [nop,nop,TS val 2337097024 ecr 2964], length 1448
03:26:39.214202 IP MyWAN > ICMP MyWAN unreachable - need to frag (mtu 1400), length 556
03:26:43.822126 IP > MyWAN.54244: Flags [.], seq 1:1449, ack 255, win 110, options [nop,nop,TS val 2337098176 ecr 2964], length 1448

Given the above, I'm wondering:

  • a) what's the effective (measured) MSS is in these environments (delivery pipeline)
  • b) Whether the DF Flag can be disabled in the Server/Service delivering the content.
  • c) Whether the packet content can be made smaller (than it's current 1448 bytes)



Make sure IPv6 is disabled.

Turn back on a firewall.

Couple of tests to confirm your network connection is working properly.

Open a command prompt and type:

tracert cloud.hubitat.com

and look for any * in the hops, and note the hop count.

Do a check for MTU size, following these instructions:


Check your ping/jitter line connection here: Ping test - how good is your internet? | DSLReports, ISP Information

lastly, check your isp's connections to AWS here: Amazon Web Services Network Test | CloudHarmony

1 Like

verify that IPv6 is disabled while in command prompt (assuming windows)...

ipconfig /all

Any chance you also have an android phone? https://play.google.com/store/apps/details?id=edu.berkeley.icsi.netalyzr.android is a great network troubleshooting tool.

The trace route, looks fine, something in the middle doesn't appear to respond to pings, but that's nothing to worry about. It's resolving the names correctly as well.

This might sound strange, but unplug the C5 hub, do not unplug the ethernet cable. Wait 30 seconds. Plug it back in. Wait 3 minutes.

Verify the hub is available at ip:8081

unplug and repeat this process 3 times.

Then go to portal.hubitat.com and see if the hub shows up with the same ip address. Click on the register hub link. Does it go to the hub and start the install process at all?

Does it start the download?

Hi @patrick (et al). After several hours of AWESOME customer support effort from 3 staff at Hubitat, including them rousing a developer close to midnight to try to help.

We aren't sure why my hub wont connect. So Hubitat is sending me a new C5 for me to try, that will come pre-loaded with the software.

What I DID learn tonight, is that the support from Hubitat is AWESOME! This makes Hubitat a no-brainer to migrate to from Wink. I'm sure I'll have more bumps along the way as I migrate all of my stuff over, but after tonight I'm confident that whatever issues I face I will be able to resolve thanks to the community and, especially, the support staff.

For those of you coming over from WInk, if you have issues, don't hesitate to email support or post here. The support team have the patience of saints and will do everything they can to get your issue resolved.


UPDATE: We got my hub working, and I have fully transitioned over from Wink!

FIX: I was sent a new C5 Hub from Hubitat support, and shipped my original hub back. The new hub came per-configured with some of the software. Once I received my hub, I plugged it in and then sent the IP address to support. They configured some things on their end and had me run a simple script. Then it worked!

So if you run into the same issue, send an email to support@hubitat.com. Then connect with your support rep on the forums as it's much easier to chat with them via direct message here than over email.