Used like 20 hours on trying to fix this :-/ looks like Alexa changed something again? I can use it to control my zigbee switches, again but whatever i do, alexa can not find deleted devices or new devices anymore. any idea?
Hi everyone,
I know this thread discusses the direct integration, but for anyone who happens to run Home Assistant alongside DeCONZ, I found a reliable workaround to eliminate the “Device not responding” error completely.
I am running DeCONZ on a QNAP via Docker and expose my lights to Alexa via Home Assistant (Nabu Casa). It seems the latency/feedback loop (Zigbee → DeCONZ → HA → Cloud → Alexa) takes a few milliseconds too long, causing Alexa to time out even though the light eventually turns on.
I managed to solve this by creating a “wrapper” light in Home Assistant using the Template Light integration with optimistic: true.
The Logic: Instead of exposing the DeCONZ entity directly to Alexa, I expose a template light. By setting optimistic: true and removing the state-check, Home Assistant immediately reports “Success” to Alexa the moment the command is received, without waiting for the slow physical Zigbee confirmation from DeCONZ.
The Solution: Add this to your configuration.yaml in Home Assistant. Using my office light (light.buro) as an example:
template:
- light:
- name: "Office Light"
unique_id: wrapper_light_office
# 'optimistic: true' is the key here!
# It forces HA to assume success and report "OK" to Alexa immediately.
optimistic: true
turn_on:
- action: light.turn_on
target:
entity_id: light.buro
turn_off:
- action: light.turn_off
target:
entity_id: light.buro
set_level:
- action: light.turn_on
target:
entity_id: light.buro
data:
brightness: "{{ brightness }}"
Steps:
- Add the code to HA and restart.
- In HA Settings → Alexa, unexpose the original DeCONZ entity and expose this new wrapper entity instead.
- Discover devices in Alexa.
Since switching to this optimistic wrapper, the response is instant and the timeout error is gone. Hope this helps other HA users here!
One thing to remark: using Alexa App on a phone still has this timing issue but as I want to control the lights with my voice - this solution is perfect for me 
But then you dont need deconz anymore.. this way solutions like Z2MQTT are more reliable
I bought myself a SMlight MR4U stick and ongoing a complette swap . after 10 years maybe its time to change
but you have to link all actors again and for me it would mean I have to open all the light switches in my house to reprogram …
Does someone have experiences with Alexa Echo with Zigbee-Hub integrated?
Yes, I did. It took me about six hours just for my power plugs and a few bulbs — including ioBroker UI adjustments, Alexa re-learning, and some JavaScript tweaks — and there’s still a lot more to do.
If a device is online and you delete it from deCONZ, it will receive a reset signal and can then be discovered by your new Zigbee gateway. Only battery-powered devices need to be reset manually.
I was honestly surprised at how easy to use and well-organized Zigbee2MQTT is compared to deCONZ. On top of that, every device has been recognized so far without needing to adjust any DDF files.
Looking ahead, it’s the safer option. I can back up the configuration and transfer it to another Zigbee stick if needed. You can back up deCONZ as well, but those backups can only be restored into deCONZ itself.
The Alexa hub doesn’t offer any export at all. If you ever have to replace the hub, you have to start everything from scratch. That’s exactly why I moved to deCONZ years ago — when I upgraded from Echo 1 to Echo 2, everything was lost.
looks like Alexa changed something again? I can use it to control my zigbee switches, again but whatever i do, alexa can not find deleted devices or new devices anymore.
I´m still using Deconz 2.30.2 with nginx in front and for me it´s still working. I can control my lights via Alexa and Alexa is also able to discover new (or deleted) Lights.
Hi Marcus, I also ordered now a new hub - so let’s see how it works
Hi,
Yesterday I successfully tried 2.32.2 beta, adding the --ws-port=8443 as command line option. It worked without issues.
Then I downgraded to 2.31.2 since I wanted to try that version with the same option (according to this comment Very slow integration with Alexa - #100 by mattreim).
Surprisingly it worked out of the box, even without adding --ws-port=8443. How is that possible? Maybe some component that was not downgraded properly?
I cannot replicate anymore right now. If I can find the time, I might test from scratch on a bare installation using another setup (I don’t want to mess up my running instance now that I get it working after many months).
For everybody using the docker version of deconz I created a pull request with the changed ws port to 8443. Simple recreate the container and everything should be fine.
I’m running deCONZ Version 2.32.5 (Raspberry 4) on Port 80 and a nginx Reverse Proxy for Port 443.
Alexa was able to control existing devices, but could not discover any new ones. Even when clicking “Authenticate App” in Phoscon, the discovery process failed.
The issue was the SSDP discovery (UPnP) being “stuck”.
Step-by-Step Fix:
- In Phoscon, go to Settings > Gateway > Advanced.
- Toggle “Enable Discovery” (Discovery aktivieren) (the UPnP setting) OFF.
- Wait 10 seconds and toggle it back ON.
This forces deCONZ to broadcast its presence (SSDP) into the network again, which is often needed when running behind a proxy or after network changes. - Click “Authenticate App” (App verbinden) in Phoscon.
- Immediately ask: “Alexa, discover my devices.”
After that fix my new device was successful discovered by Alexa.
I’m running deCONZ Version 2.32.5 (Raspberry) on Port 80 and configured ws port fix (–ws-port=8443) which was working very well until the update to Version 2.32.5. The lamp control works everywhere else.
Now the error is occurring again, whereby Alexa takes an extremely long time to execute the command and either confirms with an error message (device malfunction) or with OK, but the lamp is activated very late.
Starting Nmap 7.95 ( https://nmap.org ) at 2026-03-04 11:17 CET
Nmap scan report for 192.168.0.4
Host is up (0.0049s latency).
Not shown: 995 closed tcp ports (reset)
PORT STATE SERVICE
22/tcp open ssh
53/tcp open domain
80/tcp open http
443/tcp open https
8443/tcp open https-alt
sudo systemctl status deconz
● deconz.service - deCONZ: ZigBee gateway -- REST API
Loaded: loaded (/lib/systemd/system/deconz.service; enabled; preset: enabled)
Drop-In: /etc/systemd/system/deconz.service.d
└─override.conf
Active: active (running) since Wed 2026-03-04 10:12:44 GMT; 37min ago
Main PID: 24040 (deCONZ)
Tasks: 8 (limit: 387)
CPU: 6min 56.666s
CGroup: /system.slice/deconz.service
└─24040 /usr/bin/deCONZ -platform minimal --http-port=80 --ws-port=8443
Mar 04 10:12:44 phoscon systemd[1]: Started deconz.service - deCONZ: ZigBee gateway -- REST API.
Mar 04 10:12:45 phoscon deCONZ[24040]: QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-pi'
Mar 04 10:12:46 phoscon deCONZ[24040]: libpng warning: iCCP: known incorrect sRGB profile
Mar 04 10:12:47 phoscon deCONZ[24040]: This plugin does not support propagateSizeHints()
Mar 04 10:12:47 phoscon deCONZ[24040]: This plugin does not support propagateSizeHints()
Mar 04 10:12:48 phoscon deCONZ[24040]: This plugin does not support propagateSizeHints()
Mar 04 10:13:07 phoscon deCONZ[24040]: This plugin does not support propagateSizeHints()
I suspect that Alexa is calling up the hub with https, which leads to numerous retries and ultimately ends with a blank page.
Requesting via https leads to retries and also error message (Last-modified header invalid)
wget https://192.168.0.4 --no-check-certificate
--2026-03-04 12:02:15-- https://192.168.0.4/
Connecting to 192.168.0.4:443... connected.
WARNING: The certificate of ‘192.168.0.4’ is not trusted.
WARNING: The certificate of ‘192.168.0.4’ doesn't have a known issuer.
The certificate's owner does not match hostname ‘192.168.0.4’
HTTP request sent, awaiting response... 301 Moved Permanently
Location: /pwa/index.html [following]
--2026-03-04 12:02:21-- https://192.168.0.4/pwa/index.html
Reusing existing connection to 192.168.0.4:443.
HTTP request sent, awaiting response... Read error (The request is invalid.) in headers.
Retrying.
--2026-03-04 12:02:24-- (try: 2) https://192.168.0.4/pwa/index.html
Connecting to 192.168.0.4:443... connected.
WARNING: The certificate of ‘192.168.0.4’ is not trusted.
WARNING: The certificate of ‘192.168.0.4’ doesn't have a known issuer.
The certificate's owner does not match hostname ‘192.168.0.4’
HTTP request sent, awaiting response... 200 OK
Length: 520270 (508K) [text/html]
Saving to: ‘index.html’
index.html 14%[======> ] 71.79K --.-KB/s in 0.04s
Last-modified header invalid -- time-stamp ignored.
2026-03-04 12:02:33 (1.77 MB/s) - Connection closed at byte 73517. Retrying.
--2026-03-04 12:02:35-- (try: 3) https://192.168.0.4/pwa/index.html
Connecting to 192.168.0.4:443... connected.
WARNING: The certificate of ‘192.168.0.4’ is not trusted.
WARNING: The certificate of ‘192.168.0.4’ doesn't have a known issuer.
The certificate's owner does not match hostname ‘192.168.0.4’
HTTP request sent, awaiting response... 200 OK
Length: 520270 (508K) [text/html]
Saving to: ‘index.html’
I downgraded to version 2.31.2 and it is working again. The port 443 won’t be exposed which might be related to the issue.
Nmap scan report for 192.168.0.4
Host is up (0.0068s latency).
Not shown: 996 closed tcp ports (reset)
PORT STATE SERVICE
22/tcp open ssh
53/tcp open domain
80/tcp open http
8443/tcp open https-alt
When using those parameters and disabling https “–http-port=80 --https-port=0 --ws-port=8443” its also working with current version 2.32.5.
okay, setting https-port to 0 seems to work with the newest version. Alexa now works as fast as before.
Maybe also a solution for your problem /sarcasm