Device not responding - August 2025

[aberens]

Seit Anfang August 2025 beobachte ich eine zunehmend instabile Konnektivität zwischen Alexa und den über node-red-contrib-amazon-echo eingebundenen Geräten.

Konkret:

• Geräte werden von Alexa nicht mehr zuverlässig erkannt.
• Die Gerätesuche schlägt häufig fehl, obwohl Node-RED korrekt läuft und Port 80 verfügbar ist.
• Bereits erkannte Geräte verschwinden temporär aus der Alexa-App oder zeigen "Gerät reagiert nicht"
• Sprachbefehle führen zu „Gerät reagiert nicht“, obwohl die Aktion technisch zeitverzögert ausgeführt wird.
• Ich nutze die aktuelle Version 0.1.14 vom 23. April 2025

In verschiedenen Foren berichten andere Nutzer von ähnlichen Problemen. Es wird vermutet, dass Amazon Änderungen an der lokalen Geräteerkennung (UPnP/SSDP) vorgenommen hat, die virtuelle Bridges wie die von diesem Modul betreffen.

Gibt es Pläne, das Modul entsprechend anzupassen oder eine alternative Lösung innerhalb des Projekts?
Ein offizielles Statement oder ein technischer Hinweis wäre sehr hilfreich.

Vielen Dank für die bisherige Arbeit und Unterstützung!

---

Since August 2025, I’ve been experiencing increasingly unstable connectivity between Alexa and devices integrated via node-red-contrib-amazon-echo.

Specifically:

• Devices are no longer reliably discovered by Alexa.
• Device discovery often fails, even though Node-RED is running correctly and port 80 is available.
• Previously discovered devices temporarily disappear from the Alexa app or show “Device not responding.”
• Voice commands result in “Device not responding,” although the action is technically executed with a delay.
• I’m using the current version 0.1.14, released on April 23, 2025.

In various forums, other users have reported similar issues. It is suspected that Amazon has made changes to local device discovery (UPnP/SSDP), which may affect virtual bridges like the one used by this module.

Are there any plans to adapt the module accordingly or offer an alternative solution within the project?
An official statement or technical guidance would be greatly appreciated.

Thank you for your work and support!

ECHO DEVICES

Echo Dot 5th generation

MODULE VERSION

Version 0.1.14

[smartsourcefreak]

Yep. The same issues for me. Amazon server seem completely unresponsive. I'm observing the whole thing since around 12 to 24 hours ago.

Would be great to have the issues fixed asap.

Thanks for your great work!!

ECHO DEVICES
Various Echo (Dot) devices 3rd and 4th generation

MODULE VERSION
Occured with version 0.1.10 and 0.1.14

[myounges]

+1 here as well. Same setup. Same results.
Alexa reports "device not reachable" even though the command works.

[davids5]

+1 @datech I would be willing to debug this. Any Idea where to look?

[datech]

Thanks everyone for reporting this.

As many of you know, this module simulates a Philips Hue Hub, which was natively supported in early versions of Echo devices. Unfortunately, I’m currently traveling and unable to fully investigate the issue right now. However, based on your reports, it seems likely that Amazon has made changes to their local discovery mechanism, possibly altering or dropping support for local Philips Hue emulation altogether.

It's important to note that this issue appears to affect multiple generations of Echo devices (3rd, 4th, and 5th gen), and is not tied to a specific node-red-contrib-amazon-echo module version. That strongly points to a change on Amazon’s side, rather than a regression in the module itself.

I'll be able to look into this in more detail next week. In the meantime, here are a few things you can try if you haven’t already:

1. Remove all devices from Alexa and re-run discovery.
2. Run Node-RED with the environment variable DEBUG="node-ssdp:*"
This enables SSDP debug logging and may provide more insight into the discovery process.
3. Enable debug logging in Node-RED by setting the log level to "debug" in your settings.js:
https://nodered.org/docs/user-guide/runtime/logging

I’ll share updates as soon as I can dig deeper into the root cause.

[smartsourcefreak]

Thanks for the quick response! Looking forward to seeing the issue resolved. Regrettably removing and rediscovering a device doesnt solve the issue for me. But frankly I didn't try removing all devices from Alexa since it's in the hundreds and I don't want to rebuild the whole setup.

Hopefully you can adapt the module to the current changes Amazon obviously made. Nevertheless vaction and journey has a higher priority. Enjoy you ride and have fun,

Until next time!

[aberens]

Thanks so much for the update and for staying engaged with the community — especially while you're traveling. I really appreciate it!

First of all, I wish you a wonderful and restful vacation. Hopefully you'll get a chance to fully unwind!

Regarding the issue: I can confirm that completely removing and re-adding the devices does not resolve the problem. Based on what you've described and what others have reported, it does indeed seem that Amazon has made changes to their local discovery mechanism.

Thanks again for your continued work on this module. Looking forward to any insights once you're back!

[myounges]

Thanks for the reply! Some random tests I made that can trigger some ideas.

1. I noticed that "routines" do work. Meaning: I created a routine called "Light" when called (Alexa... Light) it runs a certain light off. This doesn't trigger any errors messages.
2. On a Tasmota device 14.2.0 I enabled a Hue Bridge multi device option (emulates a Phillips Hue bulb as well) enabled discovery and works with no issue. Which suggests, the phillips Hue support from amazon is still valid.

Best regards,

[davids5]

@datech

The problem: Telling Aleaxa office light off (a device in node-red-contrib-amazon-echo) would spin for several seconds (delay*). Then issue the "Device is not responding" Then the office light off would go off.

I had a look in Wireshark. My echo hardware device (xxx.xxx.xxx.30) is trying to connect to my the node-red box (xxx.xxx.xxx.136) on 443. It retries with retransmission. I believe this is the *delay.

sudo ufw allow 443 fixes the issue.

The connection is made and fails immediately as apposed to retransmission timeout and fall back to port 80

[ckerfurt]

Hello everyone,

The same problem here. The command is delivered with a latency of approx. 10 seconds and switches while the Dot says: "Check if the device is turned on".

3x Echo Dot 3
node-red-contrib-amazon-echo 0.1.14

Best regards

[smartsourcefreak]

@davids5

Unfortunately allowing port 443 doesn't fix the issue for me. I had the port open all the time anyways, nevertheless the issue occured. I don't think this is the actual fix and it's rather a change on Amazon's side that led to the issue. But thanks for trying to debug, though!

[ckerfurt]

@davids5

Same here. Allowing port 443 doesn't fix the issue. The command is still delivered with a latency of 10 seconds while the dot says: "Check if the device is turned on".

[myounges]

@datech
Enabled the SSDP debugging and didn't see anything catching my eye. Nodered is serving the description.xml file correctly and when calling commands via alexa I get a the log of the message sent. Here is an example if it is of any use.
2025-08-09T20:53:54.089Z node-ssdp:server Setting LOCATION header "http://192.168.1.38:80/description.xml" on message ID 34f7c7e68xxxde8 2025-08-09T20:53:54.089Z node-ssdp:server Sending a message to 239.255.255.250:1900 2025-08-09T20:13:58.269Z node-ssdp:server Outgoing server message: { message: 'NOTIFY * HTTP/1.1\r\n' + 'HOST: 239.255.255.250:1900\r\n' + 'NT: uuid:00112233-xxxx-6677-8899-fa5528328045cc\r\n' + 'NTS: ssdp:alive\r\n' + 'USN: uuid:00112233-4455-xxxx-8899-fa5528328045cc\r\n' + 'CACHE-CONTROL: max-age=1800\r\n' + 'SERVER: node.js/20.19.4 UPnP/1.1 node-ssdp/4.0.1\r\n' + '\r\n', id: 'e5bd7xxxc423d7f' }

[davids5]

For me: nmap says my 443 is closed. Before I opened the port it did not list it. This correlates to what I saw in wireshark. Originally with the port not open in the firewall. I was getting retries and delays, the device would activate at the end of the "Device is not responding" message from Alexa. Now with it open but not used (no service is listening on it). I get immediate NACKs on the TCP open and the Alexa commands happen immediately.

[davids5]

I should add

sudo ufw deny 443 - has the failure mode stated above.
sudo ufw reject 443 - works
sudo ufw accept 443 - works (I have nothing listening on 443)

deny: This action silently discards the traffic, meaning the originating device receives no response and eventually times out.

Implication: The sender is left waiting for a response that will never come, potentially leading them to believe there's a network issue or that the target isn't active.

reject: This action blocks the connection and sends back an error message (typically "Connection refused" or "Destination host unreachable") to the originating device.

Implication: The sender is informed that the connection attempt has been actively blocked.
Use case: Can be used when you want the other end to know that the port or IP address is unreachable. Some users find this more polite than simply dropping the connection and letting the other end timeout.

accept: This action allows the network traffic to pass through the firewall to its destination.
Implication: The connection is permitted to proceed.

Use case: Used for explicitly opening ports or allowing specific connections that are deemed necessary and safe.

[n1tr0-5urf3r]

I should add

sudo ufw deny 443 - has the failure mode stated above. sudo ufw reject 443 - works sudo ufw accept 443 - works (I have nothing listening on 443)

deny: This action silently discards the traffic, meaning the originating device receives no response and eventually times out.

Implication: The sender is left waiting for a response that will never come, potentially leading them to believe there's a network issue or that the target isn't active.

reject: This action blocks the connection and sends back an error message (typically "Connection refused" or "Destination host unreachable") to the originating device.

Implication: The sender is informed that the connection attempt has been actively blocked. Use case: Can be used when you want the other end to know that the port or IP address is unreachable. Some users find this more polite than simply dropping the connection and letting the other end timeout.

accept: This action allows the network traffic to pass through the firewall to its destination. Implication: The connection is permitted to proceed.

Use case: Used for explicitly opening ports or allowing specific connections that are deemed necessary and safe.

Thank you @davids5, this fixed it for me! I have a network-wide firewall and my Alexa devices and the node-red host are in different subnets. I added firewall rules from my Alexa subnet to node-red-host:443 and the delay is gone. I also have nothing listening on port 443 on my node-red host.
In wireshark, I now see incomplete SYN messages on port 443 which were missing previously. I guess this caused the delay.