Issues with Shelly Plugs

hej openHABers,

there’ s an ugly issue with Shelly plugs on my openHAB-system. For I am quite a beginner with openHAB (although I have it running almost for two years), I hope for help to find out an eliminate the cause in here…..

Basic infos:

  • Platform information:
    • Raspi 4
    • Debian 13 all stable repo, was installed as Debian 12 and upgraded
    • OpenJDK Runtime Environment build 21.0.9+10-Debian-1deb13u1
    • openHAB version: 5.1.1-1

The setup is quite minimal: There are four Tasmota Plugs an six Shelly Plugs controlled by openHAB, simply to switch some devices on and off manually from a central webpage by item switches in openHAB.

All Plugs are connected by2.4 GHz WLAN that is proofed in best quality.

Right after a reboot of the Raspi, all is working well. After some time (might be half a day or so, The item switches seem to ‘hang’.

The issue varies:
The icon slips back into the ‘off’ position immediately after switching on.
The correct status (on or off) is not recognized correctly when the site is called up.
Switching is extremely delayed.
The Shelly Manager recognizes the plugs as offline, even though they can be pinged perfectly from the Bash…

The firmware upgrade of the Shelly plugs did not work from the manager. The plugs did not respond, even though they had long since been back online.

Unfortunately I can not reconstruct the time of beginning of those troubles. Evereything worked for a long time. Perhaps it was the openHAB 5.0-upgrade that started the trouble….

During all the time, the Tasmotas work without any problems.

The openHAB.log doesn’t show any drama, almost nothing but this:

2026-01-09 06:35:40.330 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
org.eclipse.jetty.websocket.api.WebSocketException: Session closed
at org.eclipse.jetty.websocket.common.WebSocketSession.outgoingFrame(WebSocketSession.java:350) ~[?:?]
at org.eclipse.jetty.websocket.common.WebSocketRemoteEndpoint.uncheckedSendFrame(WebSocketRemoteEndpoint.java:322) ~[?:?]
at org.eclipse.jetty.websocket.common.WebSocketRemoteEndpoint.blockingWrite(WebSocketRemoteEndpoint.java:109) ~[?:?]
at org.eclipse.jetty.websocket.common.WebSocketRemoteEndpoint.sendString(WebSocketRemoteEndpoint.java:400) ~[?:?]
at org.openhab.binding.shelly.internal.api2.Shelly2RpcSocket.sendMessage(Shelly2RpcSocket.java:185) ~[?:?]
at org.openhab.binding.shelly.internal.api2.Shelly2ApiRpc.asyncApiRequest(Shelly2ApiRpc.java:1280) ~[?:?]
at org.openhab.binding.shelly.internal.api2.Shelly2ApiRpc.getDeviceProfile(Shelly2ApiRpc.java:347) ~[?:?]
at org.openhab.binding.shelly.internal.handler.ShellyBaseHandler.initializeThing(ShellyBaseHandler.java:334) ~[?:?]
at org.openhab.binding.shelly.internal.handler.ShellyBaseHandler.refreshStatus(ShellyBaseHandler.java:559) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572) ~[?:?]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:358) ~[?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642) ~[?:?]
at java.lang.Thread.run(Thread.java:1583) [?:?]
2026-01-10 18:09:24.394 [WARN ] [org.eclipse.jetty.io.ManagedSelector] - java.nio.channels.ClosedSelectorException
2026-01-10 18:11:24.674 [WARN ] [e.jetty.util.thread.QueuedThreadPool] -
java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@5166bd73[Not completed, task = java.util.concurrent.Executors$RunnableAdapter@5b9ed603[Wrapped task = org.eclipse.jetty.util.SocketAddressResolver$Async$$Lambda/0x0000000100f84798@55592300]] rejected from java.util.concurrent.ScheduledThreadPoolExecutor@160e45bb[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0]
at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2081) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:841) ~[?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(ScheduledThreadPoolExecutor.java:340) ~[?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor.schedule(ScheduledThreadPoolExecutor.java:562) ~[?:?]
at org.eclipse.jetty.util.thread.ScheduledExecutorScheduler.schedule(ScheduledExecutorScheduler.java:125) ~[bundleFile:9.4.57.v20241219]
at org.eclipse.jetty.util.SocketAddressResolver$Async.lambda$resolve$1(SocketAddressResolver.java:157) ~[bundleFile:9.4.57.v20241219]
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:883) ~[bundleFile:9.4.57.v20241219]
at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1034) ~[bundleFile:9.4.57.v20241219]
at java.lang.Thread.run(Thread.java:1583) [?:?]

Does anybody have hints how to get close to get rid of this? Thank you very much!

Boris

I forgot to mention, that during all the time, the Shelly Plugs just work fine by using their own web frontend.

I’ve also experienced a similar issue. I modified the loglevel of the Shelly binding to debug to help me investigate and since than the problem disappered. :slight_smile: So my suggestion is to try modifying org.openhab.binding.shelly to ‘debug’.

Hej Pokica,
I doubt that changing log-level can have persistent healing influences to that issue.
Finally I found a better place to talk about. Have a look: Shelly Binding - #4923 by BruderB

BruderB