No, im referring to OH 4.1 SNAPSHOT.
Looking at your heap dump - it doesnāt seem to have memory issues, its fairly small (300 megs). From thread list however I can see a lot of WebSocketClient
instances, way too much for a regular launch. Looking at references it seems to be related to the lgthinq binding. I canāt see anything wrong in its code for now. I could be blind or wrong (I prefer later!).
Edit: Second suspect place is shelly and its Shelly2RpcSocket
. Looking at its code - there are multiple calls to close
which is grateful shutdown of connection.
@cmachtel Heap dump contains 261 instances of websocket sessions. Do you have so many shelly devices?
Cheers,
Åukasz
Hi @splatch ,
Thank you for taking time for me.
I have around 60 Shelly devices and 4LG devices. The LGBinding works well and if Shelly is not installed there is no issue and the thread numbers are constant around 330.
I currently upgrading to the latest snapshoot (What i would have preferred not to do on a daily used system) but lets seeā¦
@markus7017 sorry for disturbing but you seems to be maintainer of Shelly binding, could you help me on this?
Bad news, using latest release 3659 the problem is exactly the same. Shelly generates a lot of threads and brings the system to collapse after 30mn.
Additionally, the Hue bridge also does not work out of the boxā¦
Iām now trying to do a roll back to 4.0.3 as this one was at least stable and the other part of my home works (except shelly)
I have also done some tries with Eclipse Mem but as iām not used to i could not find anything :-
Any idea what i can do next?
Which version of the shelly binding do yo have installed? dev or release version? You might want to use the dev version if not already installed.
Thank you @Oliver2 for suggestions, currently using release version.
After work and kids came in between, I finally worked on it today.
Sorry, but I did not manage to change Shelly binding version.
Followed this guide: https://github.com/markus7017/myfiles/blob/master/shelly/READMEbeta.md
I have tried everything, rebooting, clean, ā¦with 4.0 and 4.1 snapshoot. I do not understand because I managed to install the LG binding Iām now using since 6 months like that without issues.
The version from marketplace seems to be 4.0.3
I did the test again, deleted all my Shelly things installed the binding and after 30mn same thing⦠a lot of threads and system freeze.
Am I the only one with this issue? What can I do? I have a new installed openhabian, why does it work for others?
@Oliver2 & @markus7017 Hello,
I tried something new. I installed a fresh Openhabian image, did the initial setup and installed nothing else than the Shelly Binding. Discovered 32 Things and added them all. Did nothing else, no items, no rules, nothing.
After 30mn, I have exactly the same issue. Thread size grows and grows.
This should be reproducible from any other one?.. It still gives me no way to solve it but maybe for you to find the problem ??
UPDATE:
one hour later: I did the same experience with OH 4.1.0.M1 and the result is exactly the same
one more hour later same test with latest build (3664) and shelly binding 4.1.0.202310070405 and reaction is exactly the same
Maybe it helps to unconditionally stop the client and not only if it is started? It could also be āfailedā or āstartingā.
@wborn
Would it help if i change logging level for more details?
hmm, usually the binding creates one rpc session (WebSocket connection) device and it staS open unless the connection breaks (device restart etc.)
@splatch
Could you guide me how to check the thread list and heap?
Could someone create a TRACE log?
(OH console: log:set TRACE org.openhab.binding.shelly)
@cmachtel Which type of devices are you using?
Maybe itās related to a specific devices or tPe of device. Start to disable things.
- If itās related to Shelly2Rpx disable all Gen1 devices, they donāt use the web socket interface
- then disable relays, sensor devices ise temporary inbound web socket connections, relays permanent outbound
- maybe you could identify a single device type, but list them here anyways, also if including a a shelly addon
No worries, we get that working
Iāve created a PR to make sure WebSocketClients are always stopped:
I do not agree with this change. Itās not a solution to remove conditions and enforce a close. I want to understand the logic problem at least tommake sure that there will be no side effects. If checking the logical state fails at this point there must be a problem in an upper level
I could imagine that this caused by sensor devices creating an inbound web socket and the bindjng refuses to accept, because it couldāt find a matching thing
I would have preferred a review by you before it got merged.
@markus7017 : I see you are there, I just reviewed your other PR fixing several bugs. I need your feedback to merge it.
Iām sorry, I did not follow this thread before merging, I wrongly considered the fixes trivial/obvious and didnāt await your approval, @markus7017
@wborn, @markus7017 - would you prefer reverting that commit before M2 build is started?
If @markus7017 thinks the PR does more harm than good. I read in this thread some users cannot use the binding at all due to the memory issues.
Before trying a āquick fixā, we should narrow down the issue. As said before, I am using the Shelly Binding with approx. 45 devices without any memory issues. I would therefore vote to revert the PR.
Change in shelly binding has been reverted.