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
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.
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
I created an app that every 15 minutes closes a virtual contact. Then in Alexa I created a routine that runs when the contact closes. That routine turns on a virtual switch. That switch then in my HE app re-opens the virtual contact. The switch is set to automatically turn off after 5 secs.
That gives me both ways every 15 minutes. Don't know if it will do any good, but we'll see.
This is almost exactly what I did when I was having issues with Alexa > HE and it did help a lot for me.
1 Like
I don't think you have to worry about both ways. I tried toggling a couple of virtual switches in Hubitat and they updated in the Alexa app so there is round trip status update.
1 Like
Tried setting up a rule with a virtual switch that is toggled every minute. Made sure that virtual switch is visible to Alexa and Google. Did not prevent connection issues. I'll try the routine where the smart devices are querying Hubitat on changes.
Bummer. maybe try going the other way. Somewhere there's a virtual motion device that can trigger routines in Alexa. If you can find the device, create a motion routine to trigger Alexa routine, have Alexa's routine toggle virtual switch. Hopefully that should keep the pipeline open.
Beyond that I got nothing, sorry if it doesn't work. Besides it's only a workaround until a real fix is discovered.
Edit: I think the creator of the virtual motion device may be @ogiewon.
Edit 2: I think @j715 solution is better.
Within the first couple hours I learned something. The switch that Alexa was to turn on was only occasionally getting turned on. It might work a few times in a row every 15 minutes, then goes a couple hours without getting turned on. Don't know if Alexa is not getting the contact closure from HE or Alexa is not sending the switch status back.
Checked the logs this morning and the same result.
I don't know if there is any way to tell if the Alexa routine is running or not.
Looks like it's losing connection for periods of time and this method is not really helping any.
Same problem here. GH "the Hubitat is unavailable now". The problem is intermittent. Often, whatever the Hey Google command was get executed a few seconds (up to 30sec) later anyway. Hub on static IP from router DHCP reservation. Spectrum ISP on cable modem. Don't understand why its happening.
Thinking through about what happens when it doesn't work and my observations from my test.
It appears that the loss in communication is only one way. I can't remember any time that sending something from HE to Alexa didn't work, But when things don't work is when I ask Alexa to do something and she/he/it just beeps but the function never happens.
I did some testing today and I think I figured out what might be causing this. It appears the random disconnections would happen on Starry Internet very frequently. I have an LTE modem kicking around (GL.Inet X750 Spitz) running T Mobile. I connected the Hubitat directly to my mobile router over ethernet, and we have had ZERO failures all day long since then. (Aside: And, without even setting a DHCP reservation! It's funny to me that people are suggesting the DHCP reservation to be something that's going to immediately remedy problems for people. It's only going to do something if you're on a network that is hopping the assigned IP's around. I get the point of doing the reservation... you're ensuring that your router has a known and predictable path so your hub works locally. Because of the nature of NAT firewalling, the Hubitat API isn't going to know you've reserved IP's at all, because it can't see the local IP's inside your network, except for what you've last used with the Hubitat app when connected locally. And so, for the purpose of keeping the mobile app working correctly, then yes, DHCP reserve away...)
This tells me something... it appears the Hubitat has trouble maintaining a connection to the Hubitat API servers over Starry internet. What's interesting is that Smartthings, which we just migrated away from, never had this issue. There must be something unique about how the Hubitat communicates with the mothership that makes it prone to failure on our ISP's network.
I want to read more into this CGNAT thing, because I'm wondering if that's the feature that's interfering with Hubitat's ability to receive incoming connections. When I run tracert, I'm not seeing any paths identified as the 100.x.x.x block. I honestly dont see any confirmation that would indicate to me that this is a CGNAT topology. I think it's QoS packet shaping that's timing out incoming connections without activity.
I'm also planning on doing another test tomorrow... I'm going to set up my mobile router into VPN gateway mode using a VPN service and force the Hubitat's traffic to exit via a VPN provider. I'm wondering if Starry's internet will allow VPN tunnel traffic easier than whatever protocol the Hubitat uses locally. I have a hunch that Starry is doing bandwidth shaping detection that is changing latencies and connection paths based on requests. Perhaps, even, Starry might be waiting for several connection attempts before even opening the path for traffic to flow. I've noticed that downloads on their system seem to ramp in speed from near zero up to full speed slowly, it doesn't immediately ever give full speed right out of the gate. Doing this test will tell me what kind of bandwidth shaping Starry might be using, and give a possible longer term solution for running the hub.
I'm also very curious for others having similar problems, what kind of ISP are you using, and by what physical hardware do you have an internet connection? How common is this? Could there be any way for Hubitat's team to change the connection protocol to make connecting behind this kind of ISP more feasible?
I have a T mobile LTE modem which supplies my internet connection. It is also a router, but not a very good one. So I come out of that unit from a LAN port into the WAN port on another router which handles all my local network. All the DHCP is done from that router. The IP from the modem into the WAN is a different subnet, But it is fixed. The modem does not have the DHCP enabled.
Support finally got back to me, but it was basically a "We'll forward this to our engineers, good luck!" kind of thing. I've put our Hubitat back onto our carrier's router for now so if/when they do decide to maybe look into why this is happening, they might be able to see the problem.
Certainly hoping for a resolution soon.
2 Likes
Double NAT is not a problem. We have dual internet service to our home, one is GigE with Xfinity, one is DSL for my home office. The Xfinity is dual NAT through our firewall router that does DHCP reservations for everything (so no LAN IPs change), the home office DSL provides static WAN IP to the firewall router when it is moved over from Xfinity when Xfinity fails (as it does a few times a month). Hubitat and all other devices on the LAN never have a problem, even though Xfinity access is double NAT, DSL access is single NAT.
Yes, the WAN IP does change when that switchover occurs, but all LAN IPs stay the same.
I have my hubitat hooked up and works fine with the Hubitat App. I shared my device with google through the "works with google" on google home app. Lights work fine via google app as well. When I try to speak to google and ask it turn the lights on with a Google Home or google home mini it says "I am sorry, but it looks like the hubitat is unavailable right now" If I do it from my phone via the home app and speak to my phone, it works. I would love to know what is going on.
Do a refresh on the integration and then check the naming conventions of the devices you exposed to google... (you did expose them right?)
So, I did expose the devices to Google via Hubitat and they all show up on Google Home. I also had to make some of the color bulbs, generic Zigbee rgb bulbs (in Hubitat) so they would show up in Google. All works well in the home app and it also works if I use my phone to speak the commands but when I speak to my google home devices, they all respond " I am sorry, but the hubitat is unavailable right now" or "Sorry, it looks like the hubitat is unavailable right now" Also, I already had google working, and decided to soft reset my hubitat hub and start fresh with a new Google Home and this is when it all started.
So, Google Home is probably a little confused at this point from the above steps.
I have seen posts like the following, where it mentions going into the Google side of things and completely removing any lingering vestiges of the Hubitat integration, and then starting over. I know it is odd that you phone's Google Home app works, but the Google Home devices do not. 
