Web Socket Error on AmazonEchoControl binding every 65 seconds

Tags: #<Tag:0x00007f616f103df8>

Having the same problem described here with the Amazon Echo Control binding throwing a Web Socket error every 65 seconds.

Tried uninstalling binding and reinstalling, but no luck.
In fact, wondering now whether it is the cause of my memory issues

8 Likes

Same here.
Last time I think it was on amazons end.
Let’s wait for a few days.
You can try to stop bundle to get rid of the anoying logs

3 Likes

Good to know it’s not just me!

It’s something that happens on my system sporadically and fairly frequently, although rarely for long stretches like this. It’s become a prevailing reliability issue in my setup, which relies on the echocontrol binding’s lastCommand item to trigger a lot of my home automation. In the last 3-4 days it hasn’t worked at all! No commands or actions are appearing in the openHAB console, just this error report:

22:10:10.290 [INFO ] [ocontrol.internal.WebSocketConnection] - 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_221]
        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:159) [bundleFile:?]
        at org.openhab.binding.amazonechocontrol.internal.WebSocketConnection$2.run(WebSocketConnection.java:184) [bundleFile:?]
        at java.util.TimerThread.mainLoop(Timer.java:555) [?:1.8.0_221]
        at java.util.TimerThread.run(Timer.java:505) [?:1.8.0_221]

This appears randomly about every minute or so. It also appears a few seconds after a voice command is given to alexa.

As mentioned above, the ‘solution’ given on the aforementioned thread is to wait for it to be resolved server-side. I accept that, but in the meantime I wonder whether anyone has any further insight as to why it happens, and whether anything could be done to make the binding immune to this (likely) server-side problem?

2 Likes

Are you also having Out of Memory problems? I started having them a few days ago and thought it was my upgrade to 2.5.5, but now thinking it might be this - which apparently started happening shortly before my upgrade

1 Like

No memory issues here, but I’m running a very different setup on Windows 10 so it could be a 2.5.5 upgrade or some other issue. I’ve actually never seen [WARN] the message in your other post! But in general I find that those kinds of problems are resolved by re-adding bindings and/or things, especially after an update.

However, the amazon echo websocket error doesn’t appear to and (on my setup) has never been related to out of memory warnings.

1 Like

I downgraded to 2.5.4 today but just had another crash on out of memory after just a few hours, so ruled the version upgrade out as the cause.

On the out of memory trace there’s actually a reference to the echocontrol binding:

 2020-06-12 16:43:28.276 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
    java.lang.OutOfMemoryError: Java heap space
 ...
 ...
    at org.openhab.binding.amazonechocontrol.internal.WebSocketConnection.<init>(WebSocketConnection.java:102) ~[?:?]

I’ve uninstalled the binding and will see if that fixes it, but not a great situation as it also breaks a lot of my functionality.

1 Like

Same Issue here.

2020-06-13 01:40:27.870 [INFO ] [control.internal.WebSocketConnection] - 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:159) [bundleFile:?]
at org.openhab.binding.amazonechocontrol.internal.WebSocketConnection$2.run(WebSocketConnection.java:184) [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]

1 Like

Same here, including a very severe memory leak, which after a few hours being unnoticed during the night even corrupted my configuration (all Things which were configured via PaperUI gone), had to restore from a backup.

I have uninstalled and reinstalled the binding, which made no difference, the error logs were there afterwards as well.

Funny enough, the binding seems to work despite all the errors in the log, just clogs the memory over time.

For the moment, I will keep the binding uninstalled to not break OH again, which is unfortunate, because I also have some rules depending in the Echo binding.

Running in RPI4 4 GB.

1 Like

Same thing here. And same problem it is one of the most used bindings in my setup.

I will leave it enabled for a short time and see if it comes back, I have seen some stupid issues creep in to the echos and get fixed over the last week, let’s hope they work out this one sooner rather than later.

I still think the binding needs more exception handling though.

Regards

Paul

1 Like

Had also the memory issue, had to restore from backup. still in startup phase

1 Like

I have the same issue… After the Java heap space OutOfMemoryError, I rebooted the whole system (VM in my case) and everything is ok. Strange that you guys have to restore from backup… I can’t see any reason why the config should be gone due to the memory leak…

Regards,
Flip

1 Like

Interessting. Also my installation crashed yesterday like @helmut described.
I needed to restore from backup. This Morning I noticed that my EXTRA_JAVA_OPTS are also lost. Set them back to

EXTRA_JAVA_OPTS="-XX:+HeapDumpOnOutOfMemoryError -Xms400m -Xmx650m"

I had 2.5.4 installed. Now I updated to 2.5.5
The Websocket exception every 65s is still there. Everything else works fine now. But you scared me with this here… :wink:

Just had a look on my RAM usage:

Unbenannt

My installation crashed yesterday arround 8pm. I fixed it around 10pm. Over night you see RAM usage went constantly up. This morning I noticed memory Heap problems in log and I fixed Java memory settings in /etc/default/openhab2. You see the restart in the graph. And now it seams to increase again…

Running in RPI4 4 GB.

1 Like

Stop amazonechocontrol binding in karaff shell, than monitor again…
Let’s see, if the memory leak is gone afterwards…

I stopped the binding, the log message is gone…

1 Like

Thanks for pointing this out, @olialb .

I checked my /etc/default/openhab2, in my case EXTRA_JAVA_OPTS was still there after the crash. I “only” lost all my Things. Items and everything else (as far as I checked) were still there.

One assumption:
One of my bindings (Somfy Tahoma) regularly updates Things for reasons I haven’t understood yet, although nothing in the Things has changed. Probably a full heap, “changed” Things and the attempt to write the “new” Things to disk again produced the loss of my configuration.

I have reinstalled the Echo binding for a few hours just to see, what will happen. Memory usage went up by ~100MB / hour. Deinstalled again, memory consumption stable again.

1 Like

Opened a ticket at gitbhub:

To prevent next crash i stop binding via Karaf.

2 Likes

Just a ‘me too’…
OH 2.5.5
RPi 3B

I will try stopping the binding but of course will lose some functionality.
Main reason I use OH is for its Amazon Echo interoperability.

Overnight Out of Memory
EchoControl binding web socket error every 65s
No configuration corruption

1 Like

This happens in past and no one fix it, 'cause of an issue on amazon server side.
I think something like this must prevent in code that openhab didn’t crash if binding not work or if there is an issue with amazon server.

1 Like

I stopped the amazan echo controll binding now in karaf console and the memory consumption ist stable and websocket error message gone.
I can confirm: There is a memory leak.

@Wikibear: Thanks for opening a ticket. I totally agree. I hope this time it will be fixed!

2 Likes

Same issues here on Raspbian with 2.5.5. Waiting for the fix.

1 Like

…as expected
disabled binding
no errors

just loss of functionality :face_with_raised_eyebrow:

2 Likes