Offloading Echo skill to a 2nd hub

For about a month now my logs have been filling up with throttling errors from the Echo skill app...

I've tried numerous ways to resolve the issue, including posting on the forum and opening a ticket with Hubitat support, to no avail. (I think the ticket may have ended up in Phil Collins's queue.). It doesn't actually seem to be affecting anything but it fills the logs so quickly they become basically useless for debugging other issues. This weekend I finally got frustrated enough to simply move the Echo Skill app to another hub and use hub mesh to expose just those devices I need. The Echo Skill app is the only thing running on the spare hub and it is still generating tons of errors but at least I am not using the hub for anything else.

The whole arrangement has worked out well, and I am now able to effectively use the logs on my primary hub to do what they need to do. The only issue is Alexa sometimes does not recognize a device properly, I suspect because the name is so long. In other words, because mesh appends "on primary hub" (or whatever your primary hub is named) to the end of the device name, what was "bedroom thermostat" becomes "bedroom. thermostat on primary hub." For some reason the longer name yields unpredictable results from the Alexa side. Sometimes I'll be in the bedroom and say "set thermostat to 72" and Alexa kindly changes the office thermostat too 72. Then I try setting the office thermostat to 72 and she says "office doesn't support that." So I had to manually go into the Alexa iPhone app and edit the offending device names to something shorter.

Not sure if anyone else has had (and solved) the throttling problem or knows another work-around for the really long device names... ?

1 Like

I have a similar setup - I use the alternate hub for all things network and cloud related and my other 2 hubs (one for Zigbee the other for Z-Wave) for "physical" devices. In doing so it keeps the internet/network somewhat isolated. I never noticed any errors like that before though..

In terms of the device naming - can't you simply rename the device on the hub itself? (NOPE - you need to add a device label, which effectively does the same thing!) That might make it more consistent between Echo and the hub..

3 Likes

Remember that the Echo Skill generates traffic for every device that is shared between Hubitat and Echo. You can divide your devices into three categories:

  1. Devices which you wish to use Echo voice commands to control like lights.
  2. Devices which you with to be able to use Echo to query the status; " Alexa, is the front door open"
  3. Devices which seldom if ever will be commanded or queried. This can include devices like remote control, buttons, etc. that might be needed to trigger actions in Hubitat, but which do not need to be connected to the Alexa skill. If you have any of this type of device included in your Alexa Skill, remove them to simplify communication. If you have already made this distinction, congratulations.
2 Likes

@rwclements228 All great suggestions. None of them resolved the issue though. I currently send about 60 devices to the echo skill. Most of them fall in category 1, a handful in category 2, and the rest out of a total of about 350 in category 3. I also tried temporarily disabling Echo Speaks, wondering if it was competing for AWS resources. No luck. Best the HE goes could figure out was for some reason the Echo Speaks skill was sending multiple updates to AWS in a short time frame but that was the last I heard, maybe a month or so ago. Right now Echo Speaks is the only thing running on the secondary hub.

Yes, and that might be a better option.

2 Likes

I don't know if this will be useful to you, but I can make the following error appear and disappear at will:

It appears every time I use Alexa AND concurrently have (or purposefully cause) DNS issues - for example, take down the SBC running my DNS server.

So now, if I know my main instance of dnsmasq will be unavailable, I start a second one somewhere else (and reconfigure the DNS servers used by my router), or use my ISP's DNS server.

Edit: So, at least in my installation, this is a local network issue that obviously cannot be resolved by Hubitat support.

3 Likes

Session border controller?

I will investigate the potential of a dns issue just to be sure that's not it. I can always switch to a static IP on the hub and choose DNS servers other than the ones provided by my ISP.

Update: Switched to Google's DNS servers, no difference. Could still be a LAN issue I suppose but I kind of doubt it.

On the main hub with the Alexa skill I rename my devices field "Device Label" with the name without the "on the secondary hub" name. I believe that the Alexa Skill uses that. Not sure if that will help....

Yeah I think that may be the best way. Hopefully this will cleanly push the changes to Alexa and not create a new device :slight_smile:

@erktrek @automation The device running the Echo skill app is the secondary hub, which does not actually have any devices. The only devices are the ones on the primary hub and they are exposed to the secondary hub via mesh. There is no option to change the device name on the secondary hub...

And to make it worse... as soon as I push another device up to Amazon, any name changes I made on the Amazon side are lost... ugh.

1 Like

Sorry for the confusion! You can add a device label... and that shows up in the Amazon Echo device selection. ..... clearly I need more coffeee :coffee:

Note: @brad5 After adding labels to all your devices, go into the Amazon Echo Skill app and click on the selected device list box then click on the Update button on bottom left right of the list box.. this should update all the devices to their new labels. Click done when done of course... :grinning_face_with_smiling_eyes:

3 Likes

Are you certain these servers are always available? Is there any large latency in receiving a response to a query? Because I can reproduce this error every single time I limit DNS server availability.

Edit: Also, the solution would be very simple. Just run a local instance of dnsmasq or the DNS server of your choice on something like an RPi (or even in a VM), and direct all DNS queries to your local instance. There should be zero latency issues there. A long time ago, I used to do run a caching name server just to deal with query latency ......

I was using Google's 8.8.8.8 DNS server... before that I was using my router, since it has a small DNS caching/fwd server. Errors occurred with both. Setting up and maintaining local DNS wouldn't be my first choice :slight_smile:

Trying a different DNS server (my ISP's) and I'm going to turn off auto-negotiate on the ethernet port just in case.

1 Like

I got used to that because I've been using dnsmasq as a DNS server and a DHCPd from when it was first released (~20 years ago), and it was just so easy to edit/move the same configuration file to wherever I run it. Also, it is kind of convenient in that you can use DHCP to provide different DNS servers to specific devices, if desired.

But I agree with you - it should be unnecessary.

Yeah ever since I took out the raised floor and the leibert in the spare bedroom I’ve been less than enthusiastic about recreating a data center :slight_smile:

FYI none of those changes made any difference.

1 Like

That's a shame. Because it means that there are multiple conditions that create that particular error - making it harder to diagnose/fix.

1 Like

I would love to do that
And this

But meanwhile I’ve been using Opendns. I get occasional errors like the OP, but nothing worrisome.

I tried openDNS too... no difference. Did a complete reboot of my meshed network and ONT... nothing.

The weird part is it followed me from one HE to another. Different switches, different meshed network nodes. There's literally nothing running on the secondary hub other than the Echo app. Still throwing errors every few minutes. Sometimes it makes it a bit longer, but rarely for more than 10 or 15 min before it starts again. I've tried every conceivable change I can think of. The only thing I haven't done is downrev my hub by a month or two, but alas for mesh to work I need them both on the same revision and I'm using some RM5 rules already.

As long as none of them are made by Netgear.

Worse. Linksys. What do you recommend?