Unable to setup new C-5 hub

craigspree · March 29, 2019, 8:58pm

Hi everyone,

I had a wink for 4 years, but given the issues that platform has been having I decided to research other options and am very excited to switch to Hubitat.

2 weeks ago I received my new C-5 and just today had time to plug it in. The light is blue, and it is connected to my network (see below) but I can't see it at portal.hubitat.com

I've connected it to my switch, and I see it on my network via my router interface. I've reserved an IP address for it via DHCP settings.

My problem: the hub doesn't show up at https://portal.hubitat.com so I can't register it.

What I've tried:

Visited https://portal.hubitat.com logged out and back in several times
Multiple reboots of the hub, router, entire network. Plug and unplugged the ethernet cable, etc.
Visited http://hub-ip:8081
Visited http://hub_ip:8081/setup
Visited http://hub_ip:80
Tried visiting https://portal.hubitat.com in every browser I have (Chrome, Firefox, Edge on Win - Safari, Chrome on iOS)
Contacted support (they told me I did everything right and that I should reboot the hub and router - this had no impact to my issue)

Thus far, nothing has worked, and I can't get my hub working.

Here's what I see when I visit https://portal.hubitat.com

image2268×956 64.8 KB
Here is what I see when I visit http://hub_ip:8081
It asks me to select one of the following versions, but no versions are listed

image1172×789 22.8 KB
Here is what I see when I visit http://hub_ip:8081/setup
Unknown status, please try again

image2033×833 124 KB
When I visit http://hub_ip:80 I get an 'unable to connect' error

I am using Google WiFi for my router, and the hub is connected to a switch. Again, I know the Hub is on my network and powered on given I can see http://hub_ip:8081

I've been following the advice on these threads, and none has worked thus far.

I just got an email from support asking if I can connect the hub and a PC directly to the ISPs modem, bypassing Google WiFi. I will give that a try next and report back if that resolves my issue. I am posting this here in case anyone else has any ideas, or to store this knowledge for others that may have similar issues.

craigspree · March 29, 2019, 9:26pm

UPDATE: I plugged an old TP Link router directly into my fiber modem. I plugged only the hubitat and my laptop into the router. I verified internet access via my laptop. This did not fix the issue, I still can't set up my C-5. Thus far it appears to be unrelated to Google WiFi. I also swapped the ethernet cables to rule that out, and while both cables worked with my laptop, it did also did not resolve my issue.

I'm hopeful that support will be able to help me. I was really hoping to do my big migration this weekend (30+ devices, etc)

Ryan780 · March 29, 2019, 11:01pm

Do you have network isolation turned on for port 80? it is possible that the network itself is preventing you from accessing the hub on port 80. I would advise turning off all other security within the router to see if that could help. When you plug into the tp link, did you power cycle the hub after that. That is the only way it will try for a new IP address on the new router.

vjv · March 29, 2019, 11:04pm

Google wifi doesn't have that kind of tools, must be something with the hub

vjv · March 29, 2019, 11:07pm

Please connect it to google wifi, set a reserved ip but when you doing it change the number to another like 225, then save it, disconnect hubitat from power for 5 min then re connect, refresh your portal page with the laptop connected to google wifi.

I hope you are connecting hubitat to the 1 port available in Google wifi, or you have a switch? If yes then I hope it's unmanaged

craigspree · March 29, 2019, 11:49pm

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 192.168.0.199 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 "192.168.0.50" not 192.168.0.199. 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 192.168.0.199:8081/setup 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 192.168.0.50. The support rep told me "no, the hubitat is now tied to 192.168.0.199. 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 192.168.0.100, 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).

craigspree · March 29, 2019, 11:51pm

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.

craigspree · March 29, 2019, 11:52pm

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).

csteele · March 30, 2019, 12:47am

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.

craigspree · March 30, 2019, 12:54am

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.

srwhite · March 30, 2019, 1:04am

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.

jim · March 30, 2019, 1:08am

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.

guessed · March 30, 2019, 1:08am

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

vjv · March 30, 2019, 1:13am

Welcome to HE, nice picture.

craigspree · March 30, 2019, 1:51am

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 8.8.8.8. 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.

craigspree · March 30, 2019, 1:57am

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.

guessed · March 30, 2019, 1:58am

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.

craigspree · March 30, 2019, 2:15am

Yes. MTU is set to 1500.

biggkatt01 · March 30, 2019, 2:46am

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.

guessed · March 30, 2019, 4:08am

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 13.59.2.98.8883 > 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 > 13.59.2.98: ICMP MyWAN unreachable - need to frag (mtu 1400), length 556
03:26:36.846128 IP 13.59.2.98.8883 > 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 > 13.59.2.98: ICMP MyWAN unreachable - need to frag (mtu 1400), length 556
03:26:39.214073 IP 13.59.2.98.8883 > 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 > 13.59.2.98: ICMP MyWAN unreachable - need to frag (mtu 1400), length 556
03:26:43.822126 IP 13.59.2.98.8883 > 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)

Refs:

DF Flag - soap - Benefits of "Don't Fragment" on TCP Packets? - Stack Overflow
Determining MSS - How to determine the optimal MTU and MSS size - Tips and Tricks - Peplink Community