Web Socket error {}

Same here, occurs every ~66 to ~80 seconds.

Here too… That big problem is that Openhab crash after while and get out of memory.

2 Likes

So, what have you guys got in common?
It might be worth at least listing -
bindings in use
UI in use, include e.g. remote my.openhab use

EDIT - right, now I see

This is really a duplicate thread for

Same error here.
The openhab.log points at amazonechocontrol binding:

at org.openhab.binding.amazonechocontrol.internal.WebSocketConnection.close(WebSocketConnection.java:159) [122:org.openhab.binding.amazonechocontrol:2.5.0.RC_3]
at org.openhab.binding.amazonechocontrol.internal.WebSocketConnection$2.run(WebSocketConnection.java:184) [122:org.openhab.binding.amazonechocontrol:2.5.0.RC_3]

As you can see I run Amazon Echo Control Binding version 2.5.0.RC_3.
On my side this error usually occured previously one time in the night when my router reconnected to my internet provider, but since last reconnect today at 03:30am this error occurs nearly everey minute.

Maybe @michi can have a look on that.

My environment:

  • openHAB 2.5.0.M4 on Raspberry PI3 with Raspbian Jessie
  • Basic UI and openHAB Android app
  • remote connection via myopenHAB in use

Regards,
Andy

Hi,
good approach…

i think a least java!!! zulu, because i use openhabian. maybe all other too.

the last i have done bevor these behaviour is I do an update with:

  • openhabian-config 03
  • openhabian-config 10 (all)
    BTW That was the first time I saw the info, that you can choose java 64bit for x86 or java 32bit for arm-systems… maybe ther is the problem.

on the other hand, all,of us report the web-socket error coming from java! this is the common point of failure.

openjdk version “1.8.0_252”
openjdk runtime env (zulu 8.46.0.225-ca-linux_aarch32hf) (build 1.8.0_252_b225)
opnejdk client vm (zulu 8.46.0.225-ca-linux_aarch32hf) (build 1.8.0_252_b225, mixed mode, Evaluation)

what else can I report?

i use paperui habminui basicui (also install habpanel but never used and classiui)

service:
hue emulation, openhab cloud
language server (lsp)

bindings:
amazone echo control
exec
hue
icloud
kodi
network
ntp
samsung tv
z-wave

Anything else to determin the system?

cheers Stef

Hi,
first I use the same amazonechocontrol binding as Andy

Secound
isn´t it possible to send this INFO to dev/null to protect memory overflow?

Third

What about testing java 11 beta? which is offered by openhabian-config?

And when i try new java is there a secure way back? Can anybody of openhabian deleoper/maintainer give a statement?

Thanks
Stef

Hi again me,
i forgot:

I reinitial the openhabian-config 03

than i saw:

OK
2020-06-13_13:53:12_CEST [openHABian] Optimizing Java to run on low memory single board computers…
$ systemctl daemon-reload

$ systemctl restart openhab2.service

$ java -version
Picked up JAVA_TOOL_OPTIONS: -Dgnu.io.rxtx.SerialPorts=/dev/tty96B0
openjdk version “1.8.0_252”
OpenJDK Runtime Environment (Zulu 8.46.0.225-CA-linux_aarch32hf) (build 1.8.0_252-b225)
OpenJDK Client VM (Zulu 8.46.0.225-CA-linux_aarch32hf) (build 25.252-b225, mixed mode, Evaluation)
2020-06-13_14:00:07_CEST [openHABian] Checking for default openHABian username:password combination… OK (unknown user)
2020-06-13_14:00:07_CEST [openHABian] We hope you got what you came for! See you again soon :wink:

What does the first “Optimizing Java to run o…” mean?

And What is “openHABian username:password combination… OK (unknown user)” “unknown user”
?

Sorry for posting so often, but the systtem stocks after a few hours and so the system is not suitable! to controll for examble my hot water system… open a tap and getting showerwater with 80°C is not very funny!!

Cheers
Stef

The variable EXTRA_JAVA_OPTS is set to
EXTRA_JAVA_OPTS="-Xms16m -Xmx256m
one machines with low memory ( less 900MB ) and to
EXTRA_JAVA_OPTS="-Xms192m -Xmx320m
on others.
Xms: initial Java heap size
Xmx: maximum heap size

A workaround to have openHAB up and running without memory errors is to stop the amazonechocontrol binding in karaf console, worked for me and other OH users - meanwhile @wikibear opened a ticket, see also here:

Regards,
Andy

Hi Wolfagang,

thanks for explanation… I can´t undersand these parameters .i´m not familar with java!.. sorry…

But my Tinkerboard has 2GB RAM … So can i set other / maybe better values for my system - but i think this will only spread the time till crash with memory …

BTW to all
I delete Amazon Echo Control Binding version 2.5.0.RC_3 which rossko57 supposed… but bevor i replug the jar-file i get the same web_socket error!!!
2020-06-13 15:50:03.359 [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]

So in my eyes it is not amazon RC_3 binding is not the cause! (Maybe a part of it!)

Cheers

Well, there it is, still reporting to you.

So far as I can understand the other thread, the underlying issue is a problem at the Amazon end.
But the openHAB end doesn’t handle it very gracefully.

Whether that has anything to do with your supposed “memory overflow” issue that I don’t think anyone else has reported, I woul not know.

1 Like

That isn’t fully right. OOM takes effect after a while if the binding is active. If binding is inactive OOM is gone.

Edit: This issue will discussed here: Web Socket Error on AmazonEchoControl binding every 65 seconds

No need to have to threads.

Been running this version of the binding since it came out last year w/o issues. OH uses my 15 Echo’s quite a bit every day. It has over 629 downloads against the link.

Best, Jay

First answering to Swen:

Why are these lines:
"
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:?]
"

gone in the websocket Info message, when jar-file is deleted and system is rebootet?
As I understand correct the binding or what for hell is “OOM” is still active?

secound… until yesterday fine that it is allready discussed… until yesterday the system crash! That should bring a little more enthusiasm in solution or fixing process!

Answering to Mr Wiseman:
Have you ever read this:
Namenlos

you see:

there is no date for File Beta 2.5 (RC 3)

that´s why you follow the first link in the post:
" Please jump to the Preview and Beta: Amazon Echo Control Binding thread to get the latest features if you want do a beta test."

you find the page:

ther you were tolld to install latest Download Beta 2.5 (2019-10-23)

and so you were send round and round and round …

Can Michi please organise or better stop this vicious circle by fill in jar-file DATE - so everybody can see what is the newest stable!
Thanks

Cheers
Stef

After cleaning the cache after deinstalltion of Amazon binding the Web socket error is gone…

Now i tried:
org.openhab.binding.amazonechocontrol_2.5.0.-2019-10-23.jar
as suposed by Mr Wiseman.
Same behavior: still web socket error … (Even after several reboots!)
So I think this is the source of the problem… which verion of the amazon binding is a fix for now? -remember after latest updates the system crashes because of web socket error by memory overflow!!!
Cheers
Stef

Allready exisit and allready discused in

Web Socket Error on AmazonEchoControl binding every 65 seconds

and there is a fork:
Java heap space…java.lang.OutOfMemoryError

So I think this topic should be closed an point to reopend topic:

Web Socket Error on AmazonEchoControl binding every 65 seconds

to bring all informations together

so all readers please follow Web Socket Error on AmazonEchoControl binding every 65 seconds

…I had the same problem.
It seems to be fixed with 2.5.7xx binding (2.5.6 was also NOK):
2.5.7.202006230342 │ openHAB Add-ons :: Bundles :: Amazon Echo Control Binding
Thanks to all for your effort.

Nothing has changed between 2.5.6 and the version you mentioned.

…that is interesting. I had 2.5.6 some days installed w/o success. The whole system was totally overloaded and was just working a few hours after reset in spite of deinstalling of some bindings.
After installing 2.5.7 the system was clean (no error messages) as never before. Also after new installing of the bindings. Maybe it was a NOK binding.
Anyhow thank you very much for your answer and the great support!

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.