I’ve been struggling with an issue for the last few weeks where Alexa will respond with “device is not responding” or simply not responding at all on first attempts despite having acknowledged the command. Strangely, a second attempt will often successfully execute the command. Subsequent commands will also work for a while. It feels almost as if something is timing out or something is “going to sleep”. Can anyone help point me in a direction as to how I can begin to solve or test for what may be wrong? Unfortunately we primarily interact with HA through Alexa here and this is getting a little frustrating. Thanks everyone.
2 Likes
I get this too occasionally. Sometimes Alexa will say “the device is not responding”, then the light will come on anyway; sometimes Alexa manages it on the second attempt; sometimes it doesn’t work at all but Lovelace switches the light on without any problem. Others have had the same experience - there are a couple of similar threads.
I seems to be Alexa that is timing out. The Amazon developer forums say that it is set to about 10 seconds, and this can’t be changed for security reasons. It might help to check your HA setup, your network and your internet connection to see whether you can remove bottlenecks. In my case, lights are controlled by RF, with switches in HA. Throw in Alexa talking to Dublin (or wherever it is) on a flaky internet connection and that’s quite a lot of to-ing and fro-ing. I’ve migrated most of the lighting control to wall tablets and motion sensors.
Not much help. 
Good thinking, but unfortunately the time between the issuing of the command and the response is nearly immediate. Maybe a second of delay before Alexa responds with “device is not responding”. What’s strange is the consistency to the inconsistency. In other words: when there’s a successful command, subsequent commands are always successful and fast. However, when the system has been dormant for a little bit, it seems to consistently miss the first command. This is not the case with local Alexa commands, just those going to HA. That’s why it feels so much like something “going to sleep” in HA and the first command wakes it for a period.
I might test this with a timed routine issuing a random HA command every 20 minutes or to see if this keeps things “awake”.
I’m seeing the exact same symptoms on a daily basis myself. Just as you’ve said too if it’s been dormant awhile it won’t work on the first go. But if I’ve just issued a command it’ll be quick and reliable every time. We also primarily interact with HA via Alexa so it’s very frustrating that the connection has been flaky for a few months now.
I experimented with the manual Alexa integration awhile back but switched to Nabu Casa due to how easy it was. I’m planning to try the manual integration again to see if I can replicate the behavior.
any updates on this? ive been having the same issue for weeks.
I’m getting the same issue.
The problem seems to have intensified since last week.
no solutions?
Same issue here
I’m also experiencing the same issue.
Same problem 
@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 
@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.