Take a look here: [amazonechocontrol] Add features to control smart devices connected to the Amazon Echo by lkn94 · Pull Request #6140 · openhab/openhab-addons · GitHub
1 Like
no error for last one hour . Now log looks good . Also Ram usage is stabilized
Usage for last 7 days : my system is using swap space 512 with RPI3b+ and 8-10 IOT stack docker container
Last 24 Hrs
Are you planning to address the comments from @cpmeister? After I finished http and did the a review I promised some time ago, I could have a look at that PR if you don‘t find time to do so. Depends a bit on how much needs to be done there.
Continuing the discussion from Web Socket Error on AmazonEchoControl binding every 65 seconds:
I too have been getting these errors with OH 2.4 and OH 2.5 running on two separate Synology servers. The OH 2.4 installation has been running continuously for several weeks with no problems. The log files showed an amazonechocontrol web socket error starting on the 13th June at 11:07 Dublin time and continuing every 65 or so seconds as described. I checked the log files this evening, expecting to see the error continuing, but the errors stopped appearing at 01:42 today (16th June).
I checked the logs for the OH 2.5 version and found that the last error occurred at 07:28 today.
I have made no changes, nor updates, to either installation the problem appears to have gone away by itself!
Maybe Amazon reverted the strict header checking (or it was not activated intentionally in the first place). You‘ll suffer from the
memory leak, but during normal operation it‘ll probably not show up early (Remember: it‘s almost 60 connects per hour, and the error shows up after some hours, depending on available memory. If you only re-connect once or twice a day, you‘ll need several month to exhaust your memory.).
Were any of you using the Preview and Beta: Amazon Echo Control version of the binding (amazonechocontrol_2.5.0.-2019-10-23.jar)? The “amazonechocontrol-2.5.6-fixleaks.jar” version doesn’t seem to allow for any of my Amazon/Echo “Smart Home Devices” to function, as they normally do with the 2019-10-23 Preview and Beta .jar file.
I’m running amazonechocontrol:2.5.0.Beta_07_Preview_1 jar on OH 2.4 (Build #1412). Like you found, the new “fixleaks” jar does not work in my installation. If you’ve found a workaround then please share the details.
- Thomas
I unfortunately have not found a workaround yet but will definitely let you know if I do!
1 Like
The memory leak that occurs with this bug has a big appetite. I’m seeing about 34MB per hour is lost on my OH2.4 running amazonechocontrol:2.5.0.Beta_07_Preview_1.
It takes about half a day to consume all the available memory on my RPI. I’m tempted to run a cron initiated reboot three times a day to buy some time while this problem is sorted out. Easy to do, but this kind of workaround would never win any awards for elegance.
- Thomas
After applying the latest amazon .jar workaround I have got this show up in the logs - different error message, maybe related, maybe helpful???
2020-06-16 22:43:43.450 [WARN ] [trol.internal.handler.AccountHandler] - handling of websockets fails
org.openhab.binding.amazonechocontrol.internal.HttpException: GET url 'https://alexa.amazon.com/api/activities?startTime=1592304223045&size =10&offset=1' failed: Bad Request
at org.openhab.binding.amazonechocontrol.internal.Connection.makeRequest(Connection.java:644) ~[bundleFile:?]
at org.openhab.binding.amazonechocontrol.internal.Connection.makeRequestAndReturnString(Connection.java:499) ~[bundleFile:?]
at org.openhab.binding.amazonechocontrol.internal.Connection.makeRequestAndReturnString(Connection.java:494) ~[bundleFile:?]
at org.openhab.binding.amazonechocontrol.internal.Connection.getActivities(Connection.java:938) ~[bundleFile:?]
at org.openhab.binding.amazonechocontrol.internal.handler.AccountHandler.handlePushActivity(AccountHandler.java:773) ~[bundleFile:? ]
at org.openhab.binding.amazonechocontrol.internal.handler.AccountHandler.handleWebsocketCommand(AccountHandler.java:718) ~[bundleFi le:?]
at org.openhab.binding.amazonechocontrol.internal.handler.AccountHandler.webSocketCommandReceived(AccountHandler.java:706) [bundleF ile:?]
at org.openhab.binding.amazonechocontrol.internal.WebSocketConnection$AmazonEchoControlWebSocket.onWebSocketBinary(WebSocketConnect ion.java:417) [bundleFile:?]
at sun.reflect.GeneratedMethodAccessor112.invoke(Unknown Source) ~[?:?]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_201]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_201]
at org.eclipse.jetty.websocket.common.events.annotated.CallableMethod.call(CallableMethod.java:70) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.websocket.common.events.annotated.OptionalSessionCallableMethod.call(OptionalSessionCallableMethod.java:72) [b undleFile:9.4.20.v20190813]
at org.eclipse.jetty.websocket.common.events.JettyAnnotatedEventDriver.onBinaryMessage(JettyAnnotatedEventDriver.java:133) [bundleF ile:9.4.20.v20190813]
at org.eclipse.jetty.websocket.common.message.SimpleBinaryMessage.messageComplete(SimpleBinaryMessage.java:68) [bundleFile:9.4.20.v 20190813]
at org.eclipse.jetty.websocket.common.events.AbstractEventDriver.appendMessage(AbstractEventDriver.java:65) [bundleFile:9.4.20.v201 90813]
at org.eclipse.jetty.websocket.common.events.JettyAnnotatedEventDriver.onBinaryFrame(JettyAnnotatedEventDriver.java:125) [bundleFil e:9.4.20.v20190813]
at org.eclipse.jetty.websocket.common.events.AbstractEventDriver.incomingFrame(AbstractEventDriver.java:145) [bundleFile:9.4.20.v20 190813]
at org.eclipse.jetty.websocket.common.WebSocketSession.incomingFrame(WebSocketSession.java:321) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.websocket.common.extensions.ExtensionStack.incomingFrame(ExtensionStack.java:202) [bundleFile:9.4.20.v20190813 ]
at org.eclipse.jetty.websocket.common.Parser.notifyFrame(Parser.java:226) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.websocket.common.Parser.parseSingleFrame(Parser.java:262) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.websocket.common.io.AbstractWebSocketConnection.readParse(AbstractWebSocketConnection.java:582) [bundleFile:9. 4.20.v20190813]
at org.eclipse.jetty.websocket.common.io.AbstractWebSocketConnection.onFillable(AbstractWebSocketConnection.java:441) [bundleFile:9 .4.20.v20190813]
at org.eclipse.jetty.websocket.common.io.AbstractWebSocketConnection.onFillable(AbstractWebSocketConnection.java:428) [bundleFile:9 .4.20.v20190813]
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:426) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:320) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:158) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:129) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:367) [bundleFile:9.4.20.v201 90813]
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:782) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:918) [bundleFile:9.4.20.v20190813]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_201]Thanks!!! This worked for me.
Hi ThomasOH,
I have version 2.4.0-1
I have updated the echo control bundle to the version shown below ( using the link I posted earlier )
NOTE : When it originally installed it would not start because of a dependency issue. I had to run the following before it would actually start and become active. This might have been due to the fact that OH 2.4 didn’t have what was needed by the latest echo control Jar file ? I was running a very old version prior to loading this one.
bundle:install https://repo1.maven.org/maven2/com/google/code/gson/gson/2.8.5/gson-2.8.5.jar
From the image above It would appear that I now have 2 libs offering the same services. Not sure if that’s a problem but all appears to be ok and all of my automation is functioning as per normal. The fact that the new one is showing “resolved” and not “Active” as per the other version 2.7.0 might suggest that 2.7.0 could still be providing the necessary services while 2.8.5 is laying dormant just satisfying the requirement for the new echo control Jar file to be bought online ?
Hope some of this helps you. My system has now been stable with no obvious errors in the logs and no noticeable memory leaks.
Cheers,
Karl.
I am NZT in Pacific.
Using the provided jar in this thread, It is working with amazon.com.au as the hub site.
Thank you, my capability is now restored.
Paul
Same here. Can confirm a relationship between the amazonechocontrol binding and an "out of memory " issue after a couple of hours. Also lost things and had to restore from backup. Believe due to an irregular logout from openHAB. A regular logout was impossible after appearance of the “out of memory” issue. Windows 10, openHAB 2.5.5 snapshoz #111. I have changed nothing here during the period of occurrance which was a couple of days ago.
The"fix leaks" .jar also works out for me.
I updated my bundle, but after a few hours I run out of heap again. I look and my bundle has reverted back to the 2.5.5. Am I missing a step?
I updated the bundle. Verified it was running, then BOOM back to 2.5.5 later.
I had exactly the same problem.
about 5000+ threads after some hours, all hanging, nearly nothing working (timeouts everywhere):
After updating this mentioned addon and uninstalling the amazon binding upfront everything worked.
ONE IMPORTANT NOTE TO ADD:
You need to clean cache after uninstalling the amazonecho binding and before installing the new one!!!
sudo openhab-cli clean-cache
then its staying at about ~300 threads stable since hours
I tried uninstalling the binding from PaperUI, then installing it via CLI, But all my things and Items were no longer matched with the binding. I have 19 echo’s and didn’t want to recreate them. Is there a fix/work around for this?
I would suggest to restore a backup , reboot, uninstall, install from cli.
No other idea from my site 
@dotelpenguin
On my headless RPi running raspian not openhabian I too found the binding reverting to the release version after a restart of OH.
My fix was
- Stop release version of binding from within the console
- Uninstall the release binding from the console
- Stop OH
- Download the new jar into the addon folder. I did this from a ssh terminal session on a windows pc changing directory to /user/share/openhab2/addons and the using wget (sudo wget) followed by the full url of the new jar
- Restart OH
- From console check the new bundle is the new one.
1 Like
3rd day, 3rd attempt. Today I removed the add-on from PaperUI, stopped the OH service, cleaned cache, placed the .jar in the addon folder and rebooted.
Earlier, I tried the bundle:update, first to the file org.openhab.binding.amazonechocontrol-2.5.6-fixleaks.jar and then to the org.openhab.binding.amazonechocontrol-2.5.6-fix-leaks-fix-connection.jar (dated 2.5.6.202006152137 in bundle:list). I also rebooted and re-verified the correct version of the addon was running, but was still experiencing memory leaks.
I’ll track this today and see if it’s any better.
Thanks for all the work on getting this resolved!
*editing to add that I’m already seeing low memory on my Pi. before I was starting around 240 megs free, after this update I’m already down to 35. What to most folks run for free memory?
openhabian@openHABianPi:~ $ free -h
total used free shared buff/cache available
Mem: 975M 578M 35M 6.5M 362M 339M
Swap: 99M 0B 99M
openhabian@openHABianPi:~ $
Well I did a second reboot and it seems to have corrected the original memory issue. I figured that cache cleanup may have grabbed extra memory. I’ve got 274 megs free currently, running on a 3b+ for about 1.5 years now too.
openhabian@openHABianPi:~ $ free -h
total used free shared buff/cache available
Mem: 975M 470M 274M 12M 231M 443M
Swap: 99M 0B 99M
openhabian@openHABianPi:~ $