Alexa device not responding on first try

@emkay - I can echo your observations verbatim. This is a “new” issue but who knows whether it is due to a change on Amazon’s part or HA. Hopefully the latter as there is more hope for a fix.

Another poster mentioned network connection lag. At times I’ve wondered whether there is something on my network interfering with Alexa to cloud, and HASS to Alexa connectivity. I use the Nabu Casa integration for Alexa and never tried the manual option. This issue started a while back but it seems like it got worse. I will detail a little on my ecosystem in case we find similarities:

  • More than a dozen echos around the house from various generations
  • While I try to keep echos on a 5GHz only SSID, they often wind up to the 2.4GHz only SSID. My kids’ amazon tablets work better on 2.4GHz so I can’t delete the 2.4GHz SSID wifi credentials from amazon. Is there any way to lock the echos on a specific SSID?? Anyhow, this morning I had the issue happen twice on two different Echos with one working on 5GHz, and the other on 2.4GHz so the issue doesn’t seem related to wifi performance.
  • Both Home Assistant and the Echos are all on the same untagged network (not on IoT VLAN like some of my other IoT devices… like LIFX bulbs (nothing but trouble…).
  • I have 2 PiHole DNS servers (w/ unbound) on my network. I just found that one of them is down (Primary). Anyhow, this has never happened before so I doubt it is the cause. In the PiHole that is still up I only found one DNS query from the echo in my office where I got the error last.
  • ISP is FTTH 1Gbps symmetric and speedtest.net shows > 940 up/down and a latency of 9ms with a nearby server
  • Networking gear is 100% Ubiquiti. Router is UDMP (pass through from ATT’s junk), and the 3 APs are U6-LR and UAP-AC-HD (different chipsets and generations Wifi5 & 6).
  • No fancy firewall, routing, etc configurations but they surely can be faulty as I don’t fully understand all the settings yet.
  • Issue happens with both Zwave and Zigbee devices. The logs below are what I see when the repeat the same command twice, with Alexa saying it failed the first time. There were no log entries when it failed, but when I repeated the command it seemed like I got more than one log entry appear.
2021-11-12T17:10:30.790Z SERIAL » 0x011300a90124076c0190032601ff2500000000eb8f                        (21 bytes)
2021-11-12T17:10:30.791Z DRIVER » [Node 036] [REQ] [SendDataBridge]
                                  │ source node id:   1
                                  │ transmit options: 0x25
                                  │ route:            0, 0, 0, 0
                                  │ callback id:      235
                                  └─[SupervisionCCGet]
                                    │ session id:      16
                                    │ request updates: true
                                    └─[MultilevelSwitchCCSet]
                                        target value: 255
2021-11-12T17:10:30.798Z SERIAL « [ACK]                                                                   (0x06)
2021-11-12T17:10:30.798Z SERIAL « 0x010401a90152                                                       (6 bytes)
2021-11-12T17:10:30.798Z SERIAL » [ACK]                                                                   (0x06)
2021-11-12T17:10:30.799Z DRIVER « [RES] [SendDataBridge]
                                    was sent: true
2021-11-12T17:10:30.985Z SERIAL « 0x011800a9eb00001200c57f7f7f7f000003000000000301000073              (26 bytes)
2021-11-12T17:10:30.986Z SERIAL » [ACK]                                                                   (0x06)
2021-11-12T17:10:30.987Z DRIVER « [REQ] [SendDataBridge]
                                    callback id:     235
                                    transmit status: OK
2021-11-12T17:10:30.996Z SERIAL « 0x010e00a8000124056c0210ff0000c43c                                  (16 bytes)
2021-11-12T17:10:30.997Z SERIAL » [ACK]                                                                   (0x06)
2021-11-12T17:10:30.997Z DRIVER « [Node 036] [REQ] [BridgeApplicationCommand]
                                  └─[SupervisionCCReport]
                                      session id:          16
                                      more updates follow: false
                                      status:              Success
                                      duration:            0s
2021-11-12T17:10:36.000Z SERIAL » 0x010e00a901240226022500000000ec92                                  (16 bytes)
2021-11-12T17:10:36.001Z DRIVER » [Node 036] [REQ] [SendDataBridge]
                                  │ source node id:   1
                                  │ transmit options: 0x25
                                  │ route:            0, 0, 0, 0
                                  │ callback id:      236
                                  └─[MultilevelSwitchCCGet]
2021-11-12T17:10:36.007Z SERIAL « [ACK]                                                                   (0x06)
2021-11-12T17:10:36.008Z SERIAL « 0x010401a90152                                                       (6 bytes)
2021-11-12T17:10:36.008Z SERIAL » [ACK]                                                                   (0x06)
2021-11-12T17:10:36.009Z DRIVER « [RES] [SendDataBridge]
                                    was sent: true
2021-11-12T17:10:36.802Z SERIAL « 0x011800a9ec00004e00c57f7f7f7f000003000000000301000028              (26 bytes)
2021-11-12T17:10:36.803Z SERIAL » [ACK]                                                                   (0x06)
2021-11-12T17:10:36.803Z DRIVER « [REQ] [SendDataBridge]
                                    callback id:     236
                                    transmit status: OK
2021-11-12T17:10:36.813Z SERIAL « 0x010e00a800012405260318180000c498                                  (16 bytes)
2021-11-12T17:10:36.813Z CNTRLR   [Node 036] [~] [Multilevel Switch] targetValue: 255 => 24         [Endpoint 0]
2021-11-12T17:10:36.814Z CNTRLR   [Node 036] [~] [Multilevel Switch] duration: {"value":0,"unit":"s [Endpoint 0]
                                  econds"} => {"value":0,"unit":"seconds"}
2021-11-12T17:10:36.814Z CNTRLR   [Node 036] [~] [Multilevel Switch] currentValue: 0 => 24          [Endpoint 0]
2021-11-12T17:10:36.814Z SERIAL » [ACK]                                                                   (0x06)
2021-11-12T17:10:36.815Z DRIVER « [Node 036] [REQ] [BridgeApplicationCommand]
                                  └─[MultilevelSwitchCCReport]
                                      current value: 24
                                      target value:  24
                                      duration:      0s

The only log entry related to Zigbee I could find was in the Supervisor / Core logs:

2021-11-12 10:07:31 WARNING (MainThread) [zigpy_deconz.api] No response to 'Command.aps_data_indication' command with seq id '0x2d'

The log above is a random one I found and I am not sure it is related to the issue, however I recently started getting quite a few of these errors and have no clue what they are or even refer to.

I’ve seen log entries saying that something failed 3 times and would stop. Can’t recall details and I never really found what the issue was other than possibly some device that was offline or acting up.

SUMMARY: Just like @emkay said… often, Alexa will say that the device is not responding, yet it will execute the command immediately upon a second identical command. I have not noticed any connection with a specific device or device type, but the devices we tend to control with Alexa most often are lights and fans.

Any suggestions on troubleshooting or on how to further optimize things (network, config, etc)?

EDIT: Soon after writing this, I was reminded by it happening, that sometimes Alexa will say that the device is not responding even though, after her saying it would not work, it actually does.

Almost identical setup to @aruffell (different UniFi APs) with exactly the same experience.

Everything worked flawlessly before, now a bit of a nuisance.

@aruffell - Have you tried turning off DPI on the UDMP? How many entities are exposed to Alexa? I have a lot!, I am thinking just too many entities and maybe the polling is high. I need to have a play at this after the Thanksgiving holiday.

@curt7000 I expose 219 entities out of 1500. The number of exposed entities has been pretty stable so there must be some other variable that changed if the number is part of the equation.

I remember reading that DPI and Threat Management can have an impact on throughput however I get my full ISP 1Gbps up/down so I have not tried to disable either one. Have you seen something that may connect our issues to that?

The one big issue that is torturing me is the extremely unreliable LIFX connectivity on my network. One of my AC APs broke and I replaced it and an older AC-PRO with U6-LR thinking it might help, but my initial impression is that it made it worse.

I don’t know how to test whether Alexa has any ‘obstructions’ to reaching its servers that may be causing issues… maybe I should turn off PI-Hole, DPI, and Threat Management for a few days as a test… but I really despise ads so that will be tough :wink:

@emkay @Stiltjack @vanstinator @stackner @kcarriello I opened an issue on Githuib. Can you all go add a thumbs up to my post (rather than a “same here” post? Some maintainers seem to prefer that as it doesn’t spam their email.

Please add any details I may hove not touched on.

1 Like

I noticed the same problem few weeks ago and i feel it occurs more often now.

Yesterday i reactivate the HA Skill (and deleted all devices in the Alexa App before before I reactivate it again). Since then i only got one ‘not responding’ until now (before that it was almost every one or two hours).

For me this behavior happens randomly. Sometimes it works even with long time pause between commands. Sometimes the first action is not executed and sometimes it’s executed but alexa responding ‘device not responding’.

I did some research about that and it seems like the problem is related to Home Assistant Cloud but for now the only solution is to re enable the skill and cloud login. Would be interesting if someone else can report an improvement doing this.
Source: cloud HA Discord

Related Topics:

We’ve been trying to get to the bottom of this but have not been able to figure it out yet. We’ve made some tweaks that made some things better for some, but we still hear that people having issues.

1 Like

Same issue here for me too. It’s almost enough to drive me back into SmartThings and webcore. Has been going on for a few months and its driving me crazy. Most every time I use alexa to control lights (all the time) it doesn’t work with a not responding message, and I have to repeat it or it is super delayed.

Same issue for me. Happens if Alexa has interacted with a device in a while.

The behavior for me is fairly consistent at least:

  • If Alexa hasn’t interacted with a device in several days, the first call will say “Device isn’t responding” but will actually execute the command after it says this.
  • After the first “not responding” command, subsequent commands to the same device execute instantly.

This behavior is consistent across several integration types (Z-Wave, Zigbee, TPLink Kasa)

I’ve observed the same behaviour but with Google Assistant. First command is executed right after message saying that Home Assistant by Nabu Casa couldn’t be reached.

Hello, this is my first post :slight_smile:
Few days ago I’ve connected to Nabu Casa and now I have the same issue. It happens that Alexa answers immediately, it happens that it says that device is not responding (nevertheless it executes the action, for example turns lights off). Sometimes Alexa just confirms an action and does nothing. It is completely random when the issue occurs.
My Home Assistant is on Docker, wired LAN connection, installed on Debian on old Mac Mini. There are few custom configurations on my network (f.e. AdGuard Home, Traefik, some DNS rewrite rules). Before I had port on my router forwarded to Home Assistant and everything was working perfectly. Then I switched to Nabu Casa (because of security reasons, I do not want to expose any ports to Internet) and Alexa is not reliable any more. I hope that the issue will be fixed, because I liked Nabu Casa and I really do not want to resign from it! :slight_smile:

2 Likes

Got pretty much the same issue as others… device unresponsive but does work. Subsequent commands mostly work ok until it’s left for a little while then the issue will repeat again.

Not sure what I can do to help but if you require anything please let me know.

Just like here, after I switched to #Nabucasa these problems came up, but in my case it wasn’t right away, it took a few weeks for that to show up. It seems that there is a history that accumulates and then the problems begin. But between security and asking twice, it’s better to ask twice and keep my house safe. I already need to ask my son 2 or more times to do the routines at home, so I should be used to it. hahahahaha

Add me to the list of users who is experiencing issues with the Nabu Casa/Alexa integration.

It does seem to have gotten worse over time. I regularly get a mixture of “device is not responding” or issues with lonnnngggggg delays in the device operating.

Sometimes things are virtually instantaneous, but more times than not I have issues. It’s getting to the point where it’s unusable and I might look at cancelling my Nabu Casa subscription :frowning:

I’ll pile on with the same issue, plus… sometimes I’ll say “Alexa, turn on kitchen lights” and get a response “there is more than one device with the name kitchen lights” then 2 minutes later it works just fine.

This particular error is an Amazon problem that typically happens if you have lights that share the same name as the room they are in (EX: lights named “kitchen lights” in a room named “kitchen”). And yes, this error can be random (does not always happen).

The other problems (long delays, “not responding”, “doesn’t support that”, have been traced to Nabu Casa.

Thanks. I’ll change the room name and see what happens.

I also have the same as being reported here. Has been happening for the last couple of months.

Going through Nabu Casa and Alexa mostly responds with ‘the [deviceName] is not responding.

Seems like the Nabu Casa team is working on it for those of us using their integration: Frequent Nabu Cloud timeouts with both Alexa and Google Home HA Skills · Issue #298 · NabuCasa/hass-nabucasa · GitHub

I have the same issue since months. In random mode, but now more and more frequently asking Alexa to do something on a device can either:

  • wait few seconds and get the “The device xxxx is not responding”
  • do absolutely nothing (worse) e.g. like the command succeeded.

If I immediately reissue the command to Google, I got the message “Sorry, at the moment I can’t access to Home Assistant Cloud by Nabu Casa”. This is the same behaviour also if I start the command on Google, got the Nabu Casa error and immediately retry on Alexa and got the “device non responding” error message.

So this clearly shows that the issue is not Alexa or Amazon or Google, but the Nabu Casa hosting system. I hope that Nabu Casa team fix quickly the issue, or they risk a lot of starting loosing all the customers that will move to other working solutions.