You can’t use sms or email otp. only authenticator app based works.
I am noticing delays between triggering the announcement via echo in the flow and the execution of the command, is it only my case or have you noticed same…? (I had issues with zigbee too…)
Hi there
Unfortunately I have connection problems with the echo app.
Since I upgraded to Alexa plus it seems like I have to reconnect to the Amazon server on a daily basis…
Any ideas ?
Thanks a lot
Greets from Germany
Everyone here seems to be struggling with this problem 
and again the same problem as a few months ago…
Every day I have to log in again.
in the last problem, I was able to solve it by taking Amazon.com as a server. Unfortunately, it doesn’t work anymore today…
Auch bei mir wird die Verbindung seit etwa 2 bis 3 Tagen täglich unterbrochen. Zuletzt hatte es längere Zeit gut funktioniert. Gibt es hierfür schon eine Lösung?
Außerdem funktioniert die Neuverbindung nur am PC, nicht an meinem Smartphone. Gibt es hierfür eine Erklärung?
Here also problems with the login and disconnecting
Amazon site not reachable today here on the USA west coast. ERR_ADDRESS_UNREACHABLE. Are others seeing this?
I was able to resolve the ERR_ADDRESS_UNREACHABLE by completely resetting Chrome and the Macbook. Still fighting with the Amazon Echo app reconnects since this last Amazon upgrade. Assume everyone is running into the same hassle.
I’m currently testing a complete rewrite of the app which I have migrated to python and it now uses the same underlying library that the official home assistant alexa integration uses. I want to give it until tomorrow to see if there are any crashes before I publish a public test version.
Be aware that there are two breaking changes though. After updating the app you will need go to the settings and fill out your login information (including a currently valid OTP code), so no more logging in via the Amazon proxy. The other breaking change is, if you are using the “Run Routine” action you will need to set those up again.
The new version is now released as a test version. Let me know if you notice any behavioral changes or bugs.
Connecting has been successful. Would be nice if you can show your password while login. Had to try 2x. Maybe of mistake while writing account password. Thanks a lot for your update. Hope this solves the problems with the daily reconnect.
Note that converting an app to Python does break support for the older Homey Pro 2016-2019. If you are planning to remove support for older models, I would recommend you to make sure the last published JS version is at least working stable because once you publish the Python version, you can’t update the app for Pro 2016-2019 anymore.
Also seemingly breaks Homey SHS as well. “Could not mount /python 32”
root@homey:/python# ls
cpython-3.13-linux-x86_64-gnu cpython-3.14-linux-x86_64-gnu
cpython-3.13.13-linux-x86_64-gnu cpython-3.14.5-linux-x86_64-gnu
root@homey:/python#
If the 32 is referring to 32bit then seeminly SHS is 64 bit
The JS version is as stable as I ever got it with the underlying library. Anybody is welcome to fork my code before the python migration and maintain it themselves.
This is outside my area of expertise, but this is what I got back from Claude:
This is a Homey Self‑Hosted Server limitation, not an app bug: Python apps need to mount the Python runtime at /python, which an unprivileged SHS container (the Proxmox LXC default) can’t do — hence “Could not mount /python” (32 = mount‑failure, not 32‑bit). Fix: run SHS in a privileged container — on Proxmox, recreate/restore the LXC as privileged (the community interactive installer has a privileged option); or use Athom’s official Docker image, which already runs privileged: true. After that, installed Python apps start normally.
EDIT: To confirm that it’s not just my app you could try this one as well, which should also be a python app AI Hub | Homey
Hi everyone,
I’ve been working on a fork of Stefan’s Echo app and made some changes to improve session stability. Sharing what I did and where things stand — feedback from anyone who’s seen similar issues would be great.
Background
I noticed the Amazon connection tends to become unstable after longer uptime (around 24 hours): devices go unavailable, flows fail, and sometimes a full re-login in the app settings is required. I suspect this is related to expiring website cookies and the HTTP/2 push channel not reliably recovering on its own.
What I changed
In lib/alexa.py and app.py:
- Proactive session refresh in the 5-minute sync heartbeat — renews access tokens and website cookies, and persists updated login_data to Homey settings.
- try_recover_session() — on auth/connection issues, attempts “soft recovery” first (refresh tokens/cookies, reload stored session, restart HTTP/2 push if needed) before asking the user to re-authenticate.
- Push channel watchdog — if the HTTP/2 background task stops unexpectedly, recovery is triggered automatically.
- reconnecting state — devices stay available during reconnect (no brief unavailable flicker).
This builds on Stefan’s v2.0.0 (Python / aioamazondevices) — connection/session logic only, no new user-facing features.
Fork
Repo: GitHub - Copiis/dev.schweiger.echo · GitHub
Status: still testing
The changes are running locally on my Homey (deployed 22 Jun 2026). Short-term tests (device control, TTS, logs) look good so far. I’m now running a 24h soak test — leaving the app running overnight to see if everything stays connected without requiring re-auth the next day.
Question for the community
Has anyone else seen similar behaviour — connection drops after ~1 day, devices unavailable, re-login needed? If so, what Homey firmware are you on, and roughly how long until it happens?
I’ll post the soak-test results here. Happy to share a test build beforehand if anyone wants to try it.
Thanks,
Copiis
Just to understand this, did you actually run into any connection issues with version 2.0? Because this has been public (and also only as a test version) for less than 24 hours and is a complete rebuild with a completely new connection and authentication handling. What I’m saying is the only person who had it running for more than 24h is me, and I had no connection issues so far 
If you had connection issues before that it was related to the old JS/node based version.
The ~24h connection drops I mentioned were from the old JS version, not v2.0. I only installed 2.0 yesterday, so I haven’t been able to reproduce anything on the new stack yet.
The changes in my fork are preventive — based on that old behaviour and how session/cookie refresh works in the Python rebuild. I’m running a 24h soak test on my Homey now and will post the results here either way.
If 2.0 stays stable as-is, that’s great — then it’s just an extra safety net, not a fix for a confirmed bug.
Thanks for calling that out.
