@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.