Re-starting from scratch, cloud connectivity issues

I'm putting this under migrating to hubitat as ive moved off wink relatively recently and am still having some residual issues with my hubitat.

Backstory - a long while ago, I had played with hubitat and it worked well with mobile app, cloud access etc. Flash forward wink delights customers with a ransom demand. I light up the hubitat again and start migrating. Everything was good except I had one device with duplicate entries (Artifact from my initial playing and then shows up again due to my migration).

I factory reset the hubitat to start fresh and this is where the problems start

I Cannot:

  • access hubitat through cloud (used to work prior to my factory reset)
  • access or locate hubitat via local discovery on my smart phone
  • access hubitat dashboard via mobile app as well.
  • update hubitat via portal.hubitat.com
  • update to latest 2.2.0.130 direct from the hubitat itself (spins and stuck on checking for update)

I can

  • browse to hubitat via DNS or direct to the IP from wired network (same dhcp server, vlan etc as WLAN)
  • add z-wave devices without issue

I have validated:

  • the IP of hubitat and it is correctly bound from my DHCP server
  • to ping
  • web UI is accessible from local network

I have tried:

  • Rebooting Hubitat several times
  • Factory Resetting again
  • Contacting support, but no response in 10 days (I understand pandemic might be an issue, but 10 days seems a bit long)

I'm at a bit of a loss right now and am strongly considering trying another platform. Anyone have any suggestions?

If it helps, my local network is as such:
DHCP/DNS Server via PiHole
Hubitat IP is bound via reservation in PiHole

LAN/WLAN enterprise grade HPE/Aruba hardware, flat vlan structure, no security policies blocking LAN to WLAN traffic

I should also add that I have major issues logging in from my mobile device into the hubitat app. It seems to stick on "Fetching users data..." This has been tested against wired network and on the cell carrier network as well.
Mobile device is Galaxy S10+
App has had data cleared and reinstalled several times

Additional info:

Trying to connect to hubitat from mobile device yields
Error: okhttp3.ResponseBody$1@f6699e4

First of all, welcome!
Second, if you haven't already, I would reach out directly to Hubitat support. As this issue does not sound like something we here in the community could help guide you through.

Maybe I'm wrong and someone else has hit this, but regardless I'd email support as this sounds to me like a core registration problem post reset.

Thanks, I currently have 2 emails into support@hubitat.com

They are 10 and 13 days old with no response respectively. Is this normal?

It's not exactly normal...however, right now, with the huge influx of Wink users, I believe Hubitat's support team is pretty busy. Tagging @bobbyD to see if he can help get things sorted out for you. It sounds like your hub is having difficulty syncing up with the Hubitat cloud endpoint server, perhaps...

1 Like

Definitely not normal, but they might be inundated with support inquiries given the flux of new users these last few weeks.

Look at this thread, seems like a similar issues, and you could tag support directly as well to inquire.

Here is another I found searching:

1 Like

Thanks for that snippet.

Something must be broken then. When I do the full reset on the system, it still shows up in my portal and first access still shows my account as registered...

Yes, I imagine they have had good sales this past couple weeks with what Wink has been doing.

Fingers crossed on a response soon.

Did you get an automated response, or absolutely nothing from support?

If you received nothing, then the ticket probably didn't go through, or your ticket went to your spam mail.

Automated response:

Tagging @bobbyD in the event this is an easy win or common issue being hit right now.

Ok, that is good, some people never received a ticket, and were annoyed they weren't getting support.

In your case, at least that part went correct. I see bobbyD was tagged above, so hopefully he sees this thread soon.

Just out of curiosity, did you plug the Hubitat into a switch/router/modem that is not controlled by the Pihole? In other words, totally disable Pihole and plug the Hubitat in without anything else in the network possibly affecting it?

PiHole isn't really controlling anything, but I do need it for DHCP. I also checked the logs and couldn't find any blocked DNS queries related to Hubitat... I actually didnt see any DNS queries from the Hubitat.

Is that normal? Do we know what services hubitat typically reaches out to to phone home to the cloud?

Edit: NVM, I see queries going to service.cloud.hubitat.com as well as some AWS services and they are passing fine

That is not something I can answer. However, it sure acts like it is being blocked somehow by something on your network. Hopefully support can answer these questions for you.

Thanks all for the responses. Bobby from support did get back to me, @SoundersDude tagging him must have helped nudge it along.

I'll go through some more troubleshooting and update with the resolution here. Thanks again

3 Likes

so still working through support but there has been a new revelation here.

When connecting through LTE modem, I have full access to the cloud services etc.

This means its likely something on my network but here's the rub. I have no firewalls or other applications blocking anything on my network.

In verifying the DNS logs on PiHole, every query from the hubitat is being responded to correctly.
It was working before on the exact same network.

The only thing that was changed was the DHCP addres was moved from my pool range into a static 192.168.1.93 -> 192.168.1.4

So being on the .4 was reserved, .93 is what it had dynamically picked up initially. I'm pulling it off the static range next to see if this fixes anything and I have moved it off my edge switch onto the "core" switch in the network.

Ok, thanks everyone for your assistance here. I was able to solve the problem.

Very silly and basic fix, but It seems there was an IP conflict with the statically mapped 192.168.1.4 address.

Seems a device has been holding on to that address or something for a while as I have the 192.168.1.2-10 range reserved.

Still need to hunt around to figure out what it is as I only know the MAC but thats a problem for another day.

Recommendation for anyone with strange connectivity issues, revert back to DHCP assignment. If this fixes it, find another static IP that isn't in use.

4 Likes