Alexa/Google Home "couldn't reach the Hubitat"

🛎️ Get Help
1

I just got and set up my Hubitat for the first time yesterday, and I'm very excited about this system. I'm running into a problem though that is pretty big and I don't know how to fix it. I'll try to explain below with as much depth of information as I can. I am running the latest hub firmware version to date, and have no malfunctioning smart devices on my Zwave/Zigbee networks.

Essentially, what's happening is the Hubitat performs commands issued through Google/Alexa integrations for a while, but if the hub is left idle for a few hours, the next Google/Alexa commands issued will report back "Couldn't reach the Hubitat" and the command won't run. If I bring up the dashboard manually in the Hubitat app, I can run the commands locally. After running a command locally, suddenly Google/Alexa voice commands work just fine. It's acting as if the hub is going to sleep and not keeping itself available to process network driven commands.

When configuring my system, I added Google home from the Google side of things. I went into the Google Home app, located the Hubitat integration, and went to enable it. It asked for my username and password on Hubitat. I entered my credentials into Google's prompt. Google then comes back, asks which hub you want to use by given name, and which devices to synchronize. I save and everything works fine. There was no opportunity to enter IP addresses, ports, or anything in particular, just the user account.

Similar thing for Alexa, but instead I first added the Alexa Skill app on the Hubitat side, as instructed through the documentation. Then I went into the Alexa app, found the skill, installed it, then it asked me for the username and password for Hubitat. I entered my spouse's credentials here, since he mostly uses the Alexa. (For user accounts, mine is admin, and my spouse is a normal non-elevated user). Alexa's app takes you through adding each device. There was no opportunity again to do anything with IP addresses or ports.

The reason why I'm mentioning the IP addresses thing is because a member of an unofficial Hubitat community group on Facebook mentioned I should make sure my hub is on a dedicated IP and not using DHCP. With what I understand from the documentation, this shouldn't matter at all? Currently, my hub is on DHCP, but hasn't changed IP addresses. I was never instructed by the setup to enable any kind of port forwarding to make these third party integrations work. I am behind a double NAT, but again I didn't think anything of this because I was never told I needed to expose the Hubitat to the internet through any kind of networking means. I don't even know what ports Hubitat would use for incoming connections if I did need to do this. My assumption here is that the Hubitat locally establishes a connection with the Hubitat API translation servers, so it is able to receive these commands through the connection initiated from my side. Like I said above, Google and Alexa will work fine for hours as long as I'm using them often. Once the system is left idle for a while, all the third party integrations just fail until a local command is given over the dashboard.

Can anyone help me understand what's going on here, and why I'm getting Google Home/Alexa dropping connection to the Hubitat randomly?

2

FWIW I don’t quite agree with that recommendation. If your router is using DHCP (as nearly everyone does), then it makes sense to have a DHCP reservation set for your Hubitat hub.

If the internal IP changes (i.e. if there’s no DHCP reservation set), it can throw off the Hubitat cloud’s connection to your hub. But from what you’ve described that shouldn’t be the case here.

3 Likes
3

If your hub doesn’t have a DHCP reservation, or a static IP address, it takes a little longer for the connection to be made back to the service; sometimes that delay is the difference between Alexa/Google timing out or not.

2 Likes
4

I agree with this - either DHCP or static. Good idea to fix the IP address if you can, keeps everybody happy.

I had a client who had a router that would not do reserved dhcp addresses, ended up setting a static IP address thanks to HE's recent update allowing it. That is working well too..

3 Likes
5

AFAIK that’s correct. There is never a need to directly expose Hubitat to the internet by port forwarding, for Google/Alexa integration or anything else.

Edit: and since it’s never needed, by definition it’s a bad idea due to the security risks doing so can create (but from some of the details in the OP it sounds like you already knew that :slightly_smiling_face:).

3 Likes
6

Even in the case of a double NAT like this? The problem here is my ISP provides a router combo with very limited capabilities, and our home network is connected to a router downstream of that ISP provided router. We can't plug directly into the WAN, because we're given a twisted pair using some proprietary compression protocol over RJ-11. The ISP router is necessary to convert that signal to ethernet. And, of course, there's no DMZ options on that router they provide. I've tried...

I'm wondering if maybe putting the Hubitat up one level on our network might help. We have no locally controlled LAN devices, only ZWave and Zigbee. We would still be able to access the hub directly from below the topology, and if the hub is trying to use automatic port negotiation or something, it might have better success. Thoughts?

7

Do you know the brand of the router and which ISP you have? I know many of the Arris modems have a firewall menu and some even have "bridged" mode.

I am assuming you have this:

Internet --> ISP Provided Gateway --> Your router/Access Point --> Hubitat.

1 Like
8

I believe the double NAT is the source of these issues. Tagging @bobbyD and @gopher.ny who would know best from the Hubitat team.

If possible, eliminate the double NAT and see if that helps to eliminate the issue.

2 Likes
9

In that case something could be getting lost btw the ISP gateway and your router, @ogiewon is prob right, and that's worth investigating next.

10

ISP is Starry Internet. The modem/router they provide is called a "Starry Launch", but I don't know if it's rebranded hardware under a different name. I'd have to unstick the modem/router combo from the wall to see the label.

The network topology is:

Internet -> Starry WAN -> RJ-11 to apartment -> Starry Launch modem/router -> RJ-45 -> Our TP Link Archer A9 router -> RJ-45 -> Hubitat.

It might be possible to set the TP Link router as a bridge to the Starry router's DHCP table, but that's such a catastrophic change to try I'd rather not attempt until I know it's going to work.

I'll try to connect the Hubitat to the top level NAT and see if that improves connection. Easy to do, and simple to switch back if I want to.

2 Likes
11

If the double NAT is the problem, the Hubitat documentation should really be updated to reflect this possibility of poor connection performance. Or even an auto-detect feature in firmware that notifies users of decreased performance.

I'll connect the Hubitat one level up and see if that fixes the problem and let you folks know.

2 Likes
12

Ok I now know what is happening, You are using wireless ISP correct? They use a technology called carrier NAT aka CGN or CGNAT. In these configurations you don't get a public IP you get a carrier NAT'd IP address. This is the source the double NAT. You can't open firewall rules in a CGNAT network unless they provide IPV6 dedicated addresses. Starlink, T-Mobile, Verizon and others that do Wireless ISP services have this issue. One solution as you stated is to remove the router in the middle and have devices directly connect to the carriers router.

2 Likes
13

Sort of... Starry is more like IP-over-microwave. It's terrestrial internet linked to central neighborhood infrastructure with microwave links. My Starry Launch modem/router is using phone line twisted pair to connect between our apartment unit and their network infrastructure for the building.

192.168.0.167 // Hubitat ->
192.168.0.1 // TP Link Hub as 192.168.99.130 ->
192.168.99.1 // Starry Hub as public IP 142.79.xxx.xxx

What I can do is put the Hubitat on the 192.168.99.1 Starry network one level up, and I should still be able to reach it from the TP link router. I don't know if it'll break something else, but we'll see?

14

Yes Microwave, WISP's, etc all use the CGNAT addressing principle:

image
image1612Ă—442 74.5 KB

2 Likes
15

Oh interesting. Alright, I'll report back what happens. Hold on. :slight_smile:

1 Like
16

Nope, that didn't help. Google and Alexa both lost control to the Hubitat, went into the dashboard and changed a light manually, and now Google and Alexa are both working again, at least until the next timeout. Being behind the single router from Starry didn't fix the problem.

Back to square one.... :frowning:

17

Perhaps as an interim solution until you find an answer, at least for Alexa, use Echo Speaks and a time trigger. Every 15 minutes, or whatever it takes to keep it active, use voicecommandastext to do something on Alexa .

2 Likes
18

I wonder if a virtual switch could also be used kinda like @terminal3 solution. Make a virtual switch, expose to Alexa as a light, then make a routine to toggle state every 15Min (or whatever it takes to keep it open) This could keep it open without using another app.

1 Like
19

I some cases opening up a output VPN tunnel solves some of these issues but you have a TP Link A9 and that only has a VPN server not a client. The problem with this solution it takes a lot of network expertise to implement and maintain. Even if you get it to work a change on Google or Amazon's end could break the solution and you are back to square one.

20

Interesting conversation as I too experience the same issue with both Alexa and Google dropping off periodically at the same time.

I use a cellular internet connection which has that NAT thingy with both a private and public ip.

I just kinda live with the dropped connections but am interested in trying other solutions. I’ll play around with things mentioned and see if I learn anything. Might take a few days to see if it helps.

2 Likes