Basically i have the same opinion than you and @Nadahar, but the Matter binding is a very capable binding which is worth to have a look at.
I personally have been very surprised that i can expose extremely old hardware (20y+) to Alexa using the Matter binding as a bridge. This was great, especially because the OH Alexa integration doesn’t actually work proper.
Thus, its always good to have several options 
.
Hej all,
don’t know if it’s a good place to post this here, sorry if not…. And sorry once more I cannot read this whole thread…..
With six Shelly PlugS Plus (FW 1.7.1) there are troubles polling the state and do the switching. I was able to finally focus it with setting the loglevel to DEBUG in the console an get this:
2026-01-16 22:14:21.540 [DEBUG] [.internal.handler.ShellyRelayHandler] - shellyplusplugs-e465b8457efc: Set relay output to ON
2026-01-16 22:14:21.541 [DEBUG] [g.shelly.internal.api2.Shelly2ApiRpc] - shellyplusplugs-e465b8457efc: Connect Rpc Socket (discovery = false)
2026-01-16 22:14:21.578 [DEBUG] [helly.internal.api2.Shelly2RpcSocket] - shellyplusplugs-e465b8457efc: WebSocket connected /192.168.24.121:47346<-/192.168.28.17:80, Idle Timeout=2147483647
2026-01-16 22:14:21.581 [DEBUG] [g.shelly.internal.api2.Shelly2ApiRpc] - shellyplusplugs-e465b8457efc: WebSocket connection closed, status = 1006/Failed to open local endpoint
Restarting the binding with
bundle:restart org.openhab.binding.shelly
makes the whole thing work well again - for few hours, until the issue comes back.
I got the hint to restart the binding frequently with cron but that’s quite dirty, isn’t it?
How do you think this should be fixed in a way of best practice?
Thanks and regards,
BruderB
There are some unresolved issues with the binding at the moment, so while definitely dirty, I wouldn’t necessarily reject it at the moment. The error message itself is a bit strange, failed to open local endpoint. That shouldn’t normally be where the problems are, so it suggests that it has consumed all resources of something, which prevents it from opening a new connection. It could also be a threading issue, trying to open a socket that already exists I guess. In either case, it sounds like a bug in the binding, not really something you can remedy.
Hej Nadahar,
thanks for your statement.
So I created a cronjob every 4 hours and will be fine with that for the moment. I’ll try to follow this thread and/or github and hope it will be fixed some day.
Regards,
BruderB
Hej Nadahar,
hej all,
finally, the 4-hours-sequence doesn’t make it. I went down to 2 hours….
BruderB
Tjenare - has nothing else changed? I mean, have you configured more devices, reduced refresh intervals or done something else that could cause whatever “overflows” to overflow sooner?
Arrgghh, sorry, i built a bad crontab-entry. It didn’t start the binding.
Until now, I didn’t find a way to restart the binding only. So I’ll restart the whole openhab.service every 4 hours.
Is there a smart way to only restart the binding?
I tried with
0 */2 * * * root /usr/bin/openhab-cli console -p mypassword “bundle:restart org.openhab.binding.shelly” >> /var/log/openhab/shelly-binding-restart.log 2>&1
but ‘openhab-cli console’ doesn’t seem to work inside cron’s environment….
To answer your questions: There are more devices, at least one, a Shelly Pro 3 em, that is quite verbose…. I don’t use it within openhab.
I’m really far from being a Linux command line wizard, so I can’t really help with the syntax, but can you pipe the output somewhere you can see it? Perhaps there is some error that is returned that can give you a hint of what doesn’t work?
The issue with the socket which is already existing is really severe and in my view of utmost importance. Here it results in a problem which requires an OH restart. If i disable the Shelly binding, everything is fine and stays for weeks.
Yes, I know that there are some issues with the binding. I have no direct knowledge of the problems, I don’t own any Shelly devices.
I really don’t know what else to say, I’m not the one with the details. @markus7017 is the one what must answer the specifics regarding this issue.
Did these problems start recently, with 5.1? If so, perhaps an older version of the binding could be an “emergency solution” in the meanwhile?
The issues startet with my upgrades from OH 3.4.6 (was extremely stable, OH ran for weeks without any restart) to OH 4.3, OH 5.0.3, OH 5.1 and now OH 5.2.0-SNAPSHOT #5106. The issues didn’t improve during the recent upgrades.
@markus7017 : have one question. Is the binding basically the same version for OH 5.0 to OH 5.2 and is the actual development binding with improvements always the marketplace version?
I’m running 4.2.3 myself, and it’s running for months at a time without issue. Frankly, that’s what I expect from any working system. I never “just restart”, I’ve disabled automatic updates as I always do, because I can live just fine without things breaking without me being involved at all. It’s running with battery backup on a RPi4, the only wire connection is the power, which is disconnected if the weather is unstable (lightning, storms). As a result, there aren’t many reasons to restart…
You’re bascially saying that this problem has been around at least since 4.3?
This sounds great. But i am a Windows11 user and Microsoft “forces” me to update Windows every 4 weeks (patch Tuesday). This is my trigger to restart OH.
If i go through this thread i found notices that the socket issue should already be resolved. Therefore i am not sure and asked Markus about the versions. If i upgrade OH, i have no date information on the binding. It tells me only 5.2.0, different to e.g. .jar files in the addon folder which show me the precise version date.
If you’re still experiencing it with the latest 5.2.0 snapshot, I think it’s a safe bet to conclude that it hasn’t been resolved. Don’t expect there to only be one “socket issue”…