I use the “Smarthome/J” variant of the echo control binding. A few days ago I lost the ability to control some of the non-echo things (a few fans and bulbs that aren’t otherwise directly compatible with openHAB) that are connected via that binding.
I tried to switch to the official echo control binding, and couldn’t log in. The log in screen would get to the point where it asked for my 2FA code, but before I could enter the code, the page would refresh back to the start of the log in process.
Switching back to the Smarthome/J version, my account Thing has stayed logged in, but I still can’t control the non-echo things connected through that. I tried removing one of those things to see if I could re-add it, but the scanning for new devices doesn’t result in anything showing up in the inbox.
It definitely seems like Amazon has changed something in their API. Hopefully it’s something that can be adapted to, and not an attempt to lock out folks like us!
I wonder if it has something to do with the rollout of Alexa+?
EDIT: I just tried to access the alexa.amazon.com page to see if they changed anything there… it just redirects to a regular amazon page that announces Alexa+. It seems amazon wants people to use the app to control their alexa devices, and is no longer allowing control via the web page?
Since the binding is based on emulating the web-based control, this could be the problem.
As someone mentioned in the GitHub issue Home-Assistant already released a fix updating the underlying aioamazondevices version. I couldn‘t exactly figure out what they changed and how to implement it in OH but there seems to be a solution for this.
I’m on running OH5M3 on a Pi 5
My Amazon account thing is online, but I’m seeing this in the openhab log:
2025-07-11 20:01:58.878 [WARN ] [rol.internal.util.HttpRequestBuilder] - Parsing json failed: false
com.google.gson.JsonParseException: Empty result
at org.openhab.binding.amazonechocontrol.internal.util.HttpRequestBuilder$Builder.lambda$0(HttpRequestBuilder.java:268) ~[?:?]
at java.util.concurrent.CompletableFuture$UniApply.tryFire(Unknown Source) ~[?:?]
at java.util.concurrent.CompletableFuture.postComplete(Unknown Source) ~[?:?]
at java.util.concurrent.CompletableFuture.complete(Unknown Source) ~[?:?]
at org.openhab.binding.amazonechocontrol.internal.util.HttpRequestBuilder$HttpResponseListener.onComplete(HttpRequestBuilder.java:364) ~[?:?]
at org.eclipse.jetty.client.ResponseNotifier.notifyComplete(ResponseNotifier.java:218) ~[?:?]
at org.eclipse.jetty.client.ResponseNotifier.notifyComplete(ResponseNotifier.java:210) ~[?:?]
at org.eclipse.jetty.client.HttpReceiver.terminateResponse(HttpReceiver.java:481) ~[?:?]
at org.eclipse.jetty.client.HttpReceiver.terminateResponse(HttpReceiver.java:461) ~[?:?]
at org.eclipse.jetty.client.HttpReceiver.responseSuccess(HttpReceiver.java:424) ~[?:?]
at org.eclipse.jetty.client.http.HttpReceiverOverHTTP.messageComplete(HttpReceiverOverHTTP.java:374) ~[?:?]
at org.eclipse.jetty.http.HttpParser.handleContentMessage(HttpParser.java:596) ~[?:?]
at org.eclipse.jetty.http.HttpParser.parseContent(HttpParser.java:1669) ~[?:?]
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:1552) ~[?:?]
at org.eclipse.jetty.client.http.HttpReceiverOverHTTP.parse(HttpReceiverOverHTTP.java:208) ~[?:?]
at org.eclipse.jetty.client.http.HttpReceiverOverHTTP.process(HttpReceiverOverHTTP.java:148) ~[?:?]
at org.eclipse.jetty.client.http.HttpReceiverOverHTTP.receive(HttpReceiverOverHTTP.java:80) ~[?:?]
at org.eclipse.jetty.client.http.HttpChannelOverHTTP.receive(HttpChannelOverHTTP.java:131) ~[?:?]
at org.eclipse.jetty.client.http.HttpConnectionOverHTTP.onFillable(HttpConnectionOverHTTP.java:172) ~[?:?]
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311) ~[?:?]
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105) ~[?:?]
at org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:555) ~[?:?]
at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:410) ~[?:?]
at org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:164) ~[?:?]
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105) ~[?:?]
at org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104) ~[?:?]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:338) ~[bundleFile:9.4.57.v20241219]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:315) ~[bundleFile:9.4.57.v20241219]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:173) ~[bundleFile:9.4.57.v20241219]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131) ~[bundleFile:9.4.57.v20241219]
at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:409) ~[bundleFile:9.4.57.v20241219]
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:883) ~[bundleFile:9.4.57.v20241219]
at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1034) ~[bundleFile:9.4.57.v20241219]
at java.lang.Thread.run(Unknown Source) [?:?]
I haven’t studied it closely, but it appears that linked Items are not updating and commands are not being executed.
I have two installations and they are both doing the same thing.
Hi OpenHabbers,
I am facing the same communication error and the link to the API seems to have changed. Generally I am not so happy with the speed of updates (Shelly also has new things out there and it takes really long to have an update for OpenHAB). I want to contribute and help making things a bit faster but developing or fixing a binding has proven to me very complex (despite being a developer for 4 decodes - but very traditional one). I am wondering if I should switch to Home Assistent as they seem to fix things much quicker. What are your experiences? Do you have a good hint how I could better contribute and learn the OpenHAB development environment?
Start with simple stuff and you’ll gain experience over time. Ask specific questions, someone will help.
I don’t know how far you’ve gotten, so my apologies if this is a super basic advice:
Start with forking the openhab-addons repo, and see if you could build the addon you’re interested in. Once you’re able to build a jar, then it should be easier from there. AFAIK this process should be well documented and should be easy to follow. If not, perhaps you can point out which part isn’t clear or could use further explanation / guide, that way we can improve the doc to make things easier for other people in the future.
Yes, that’s a bit inconvenient. The binding has been offline for a week. If you want to use it seriously/professionally, I think that’s a real showstopper.
Please keep in mind that openHAB is all volunteering work. If the Binding developer does not have spare time to look into the issue, you‘ll have to wait.
But anybody else can contribute a PR with a fix.
I use amazon echo binding, and although there’s the error / warning in the log about empty result (related to /api/phoenix), as far as I know, my amazon related functionalities are working. The binding is online and working.
I can tell alexa to control my lights / tvs, etc.
I don’t have devices in alexa that I need to control from openhab. It’s the other way around, openhab devices, controlled by alexa and that’s working fine.
Thanks for pointing that out. I forgot about this.
The binding is used to control the echo devices, e.g. setting their volume, doing TTS, etc.
Mine are all green / online. I’m using the official binding, not the smarthome/j, on openhab 5.0 snapshot (not that it had any recent changes since February 2025).
I can send TTS to my echo, control its volume, etc.
I still have the issue and I control my Zigbee devices (IKEA, Osram) over My Echo. :-(. Still get this errors when try to login via http://my-ip:8080/amazoncontrol.
I’m in the same state - things online and working. I’ve actually noticed the parse errors in my log for quite some time, but for the most part things are working. My guess would be Amazon is doing a staged rollout across different regions, so just because it’s still working for us right now, it might not be next week. Or vice versa - Amazon may have inadvertently broke something, and it’ll just start working again for everyone next week. It’s hard to say, and unfortunately this is to be expected when we rely on undocumented APIs from a cloud service.
