I can also confirm that the error on my system is gone with the last fix:
“org.openhab.binding.amazonechocontrol-2.5.6-fix-leaks-fix-connection”
Very good feeling!
Thanks a lot
Cheers
Stef
EDIT: The path changed once it was merged. Here’s the new path.
Best, Jay
J-N-K’s jar file fixes the Release Candidate binding version. There is no fix for the Beta binding version at the current time: none of the Alexa “Smart Home Devices” (things, items) are currently working at present.
That’s why I always user just a part of the name like “| grep lueto” to get Bluetooth / bluetooth 
Thanks to everyone for their good work.
I’ve no idea how to implement the beta .jar add-on fix.
However this has identified to me why my Pi was having a brown out on RAM and my z-wave devices stopping.
I’ve disabled the buddle from the console menu and I’m all up and running again. Thanks for community figuring this out and posting.
I’ll just wait and see when we get a fix that I can update and go from there.
At least my system is working again.
I’m not shure if iget you right:
All exposed items like (old fashioned style)
Switch Lam_Wz_Schrank_EA “Schranklicht” (g_Z_Wz,g_L) [“Lighting”] {channel=“zigbee:device:some:extra:extra_3_switch”}
are working here using the last version from J-N-K. They did with each version in past (well, back to half a year o so).
I say: “Alexa, Schranklicht an”. And IT does.
Are you writing of something else?
What you describe is done by the Amazon Alexa Smart Home Skill not via the Amazon Echo Control Binding. But the Amazon Echo Control Binding can handle devices which are connected to Alexa. I think @richaardvark talks about the second one.
1 Like
Oh yes, shure. I should have realized that. ^^
Essentially, if you’ve done most of your setup work using Amazon’s systems (defining your lights/devices/device groups/media infrastructure/scenes, etc.) and more or less use Amazon’s smart home infrastructure acting as the general core of your whole setup, the Beta release AmazonEchoControl binding is really awesome and very nice to work with, because everything you’ve already setup is right there and can easily be pulled right into openHAB. You don’t have to deal with making duplicate device definitions in multiple systems, it just works and works well! I’ve been very happy with it! I do also use both the Hue Emulation and other Alexa/Amazon binding as well for manual or virtual devices and switches that I have setup in openHAB and yes technically I could duplicate everything I’ve already setup on the Alexa/Amazon side in openHAB and could expose them to Alexa but I find that just gets messy. I’ve been very happy with the features offered through the Beta AmazonEchoControl binding/add-on. 
But at the current moment, with the Beta not working properly, Alexa still sees the devices but nothing happens when she or openHAB switch them on and off. It shows in the logs, but nothing happens, because the “Smart Home Devices” (see the very bottom of the setup guide for the Beta EchoControl binding) just don’t exist right now, if I load the newly updated jar that was created yesterday.
Dear Colleagues,
I have got bundle update as link above, but even that I’m receiving websocket message, is that normal? memory looks normal so far (75%), 30 minutes after update and openhab2 service restart, not sure if it will remain like this…
openhab> bundle:list | grep -i amazon
262 | Active | 80 | 2.5.6.202006141340 | openHAB Add-ons :: Bundles :: Amazon Echo Control Binding
"==> /var/log/openhab2/openhab.log <==
2020-06-16 12:02:18.595 [INFO ] [nternal.WebSocketConnection$Listener] - Web Socket error
java.nio.channels.AsynchronousCloseException: null
at org.eclipse.jetty.client.http.HttpConnectionOverHTTP.close(HttpConnectionOverHTTP.java:181) ~[?:?]
at java.util.ArrayList.forEach(ArrayList.java:1257) [?:1.8.0_252]
at org.eclipse.jetty.client.AbstractConnectionPool.close(AbstractConnectionPool.java:208) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.client.DuplexConnectionPool.close(DuplexConnectionPool.java:237) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.client.HttpDestination.close(HttpDestination.java:385) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.client.HttpClient.doStop(HttpClient.java:260) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:93) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:180) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:201) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.websocket.client.WebSocketClient.doStop(WebSocketClient.java:371) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:93) [bundleFile:9.4.20.v20190813]
at org.openhab.binding.amazonechocontrol.internal.WebSocketConnection.close(WebSocketConnection.java:171) [bundleFile:?]
at org.openhab.binding.amazonechocontrol.internal.WebSocketConnection$2.run(WebSocketConnection.java:200) [bundleFile:?]
at java.util.TimerThread.mainLoop(Timer.java:555) [?:1.8.0_252]
at java.util.TimerThread.run(Timer.java:505) [?:1.8.0_252]"Just to report: Updated the bundle with the new connection fix version and the connection error message is gone. My logs are clean and everything seems to be working ok.
Many thanks!
This seems to be the wrong version. You need the other one. I’ll edit-out the wrong link
Thanks for quick reploy, which link should I use as correct? thanks in advance
If its any help, the following worked for me. It sorted out the mem leak and log errors. Bundle listing shows 2.5.6.202006152137
https://janessa.me/esh/org.openhab.binding.amazonechocontrol-2.5.6-fix-leaks-fix-connection.jar
Cheers
2 Likes
The web socket issue creeped into my system a couple days ago. I see the web socket errors every 70 seconds. I’m running openHAB 2.4.0~20181104134837-1 (Build #1412) with manually installed amazonechocontrol:2.5.0.Beta_07_Preview_1 jar file.
I don’t see a log message that specifically reports out of memory, but that must be happening since OpenHAB gets lost after running for a few hours. A reboot restores operation, but this temporary fix is at best a rinse and repeat situation.
I manually installed J-N-K’s special jar and found it does not work at all on my 2.4.0 installation. I see the expected log messages when I issue voice commands that show the rules have been triggered. But the rules’ action do not occur and the Text-to-Voice responses are not heard. Furthermore, the amazonechocontrol/account web page shows the page is not available. Reverting to the previous jar file restores echo control, but now I’m back to rebooting every few hours.
If any of you are running 2.4.0, and have success with the new jar that J-N-K kindly provided, I would greatly appreciate any tips you may have.
- Thomas
I noticed websocket error for amazon echo in my logs and broken functionality of amazon echo while running 2.4 about a month ago and thought I messed up my installation with experimenting and decided to rebuild everything with clean openhabian 2.5 and the websocket error was worst until this fix. At least my code has been cleaned up and almost everything is configured with Paper UI as much as possible.
TTS works since I use it to announce house alarm messages mainly.
The PR for this [amazonechocontrol] Add features to control smart devices connected to the Amazon Echo by lkn94 · Pull Request #6140 · openhab/openhab-addons · GitHub is open since several month.
1 Like
