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”…
I have read through the documentation but I can not make sense of my problem.
It seems that I do not receive updates immediately for my power meter. The web ui for the shelly device updates immediately but it doesn’t get into openhab until later.
I see there’s a 60 second interval configured (that can be set to minimum 10) but as I understand it this data should also be “pushed”. For gen 1 devices CoIoT is mentioned.
I however have a gen 3 device. Do I need to make any specific configuration to get that to report power more often?
Edit: Ok, so it seems after “disabling“ and then “enabling“ the thing in OpenHAB updates started coming immediately. Is there some known bug that the direct reporting gives up sometimes or have I just been struck with a curse of bad luck?
Maybe interesting for all Shelly owners…especially those writing scripts on their devices
During our intense debugging session around Blu Gateway Script OOM, I invested quite some time to set up a remote logging server on my OpenHABian RPi. I thought it might be worthwile sharing it with you 
I started with installing rsyslog and setting up the directories:
sudo apt install rsyslog
sudo mkdir /var/log/rsyslog
sudo mkdir /var/log/remote
sudo chown root:adm /var/log/remote
sudo chmod 0755 /var/log/remote
I put both the actual logging dir as well as the spool directory into /var/log/…, as this is placed in ZRAM and so our remote logger will be 100% SD card safe.
Then, I edited the config file (sudo nano /etc/rsyslog.conf) to use the dirs named above, to:
# /etc/rsyslog.conf configuration file for rsyslog
#
# For more information install rsyslog-doc and see
# /usr/share/doc/rsyslog-doc/html/configuration/index.html
#################
#### MODULES ####
#################
#module(load="imuxsock") # provides support for local system logging
#module(load="imklog") # provides kernel logging support
#module(load="immark") # provides --MARK-- message capability
# provides UDP syslog reception
module(load="imudp")
input(type="imudp" port="514")
# provides TCP syslog reception
module(load="imtcp")
input(type="imtcp" port="514")
###########################
#### GLOBAL DIRECTIVES ####
###########################
#
# Set the default permissions for all log files.
#
$FileOwner root
$FileGroup adm
$FileCreateMode 0644
$DirCreateMode 0755
$Umask 0022
#
# Where to place spool and state files
#
$WorkDirectory /var/log/rsyslog
#
# Include all config files in /etc/rsyslog.d/
#
$IncludeConfig /etc/rsyslog.d/*.conf
###############
#### RULES ####
###############
#
# Log anything besides private authentication messages to a single log file
#
#*.*;auth,authpriv.none -/var/log/syslog
#
# Log commonly used facilities to their own log file
#
#auth,authpriv.* /var/log/auth.log
#cron.* -/var/log/cron.log
#kern.* -/var/log/kern.log
#mail.* -/var/log/mail.log
#user.* -/var/log/user.log
#
# Emergencies are sent to everybody logged in.
#
#*.emerg :omusrmsg:*
# --- Template for hostname, sanitized ---
template(name="RemoteFileByHost" type="string"
string="/var/log/remote/%$!safehostname%.log"
)
# --- Ruleset: sanitize hostname or fallback to IP ---
# First, compute a safe hostname variable
if ($hostname != "") then {
# Copy hostname into a global variable and replace illegal chars
set $!safehostname = replace($hostname, '[^a-zA-Z0-9_-]', '_');
} else {
# Fallback to IP address
set $!safehostname = $fromhost-ip;
}
# --- Only accept remote messages ---
if ($fromhost != "localhost") then {
action(type="omfile" dynaFile="RemoteFileByHost")
}
Load the config and make the service persistent by:
sudo systemctl restart rsyslog
sudo systemctl enable rsyslog
As it immediately starts after installation via apt and logs local events, it might be necessary to remove unwanted logfiles it created:
sudo rm -rf /var/spool/rsyslog/
sudo rm /var/log/syslog /var/log/auth.log /var/log/cron.log /var/log/kern.log /var/log/user.log
sudo rm -rf /var/log/exim4/
As it’s only used for remote logging, there is no time pressure to get it started early in boot. Rather be safe and wait until systemd reached multi-user.target - ZRAM is surely mounted, networking is surely up at that time. Therefore, I created an overlay for systemd:
sudo systemctl edit rsyslog.service
and insert:
[Unit]
Description=Remote System Logging Service
After=multi-user.target
Wants=multi-user.target
Next, I set up logrotate to take care about the logfiles:
sudo nano /etc/logrotate.d/remote-syslog
and write there:
/var/log/remote/*.log {
size 10M
rotate 7
missingok
notifempty
compress
delaycompress
copytruncate
daily
}
This will keep 7 files per client, check once per day, and try to limit file size below 10M.
That’s already it! You can now go to:
[Settings] [Debug] [UDP Logging] in the config website of your Shelly and enter
<OH_Server_IP>:514
and press Save Settings.
Immediately after that, you should see the logs appearing in /var/log/remote.
Hi Markus,
is it possible to re-add the device temperature to the channels?
E.g. for Dimmer Gen3 it is missing but temperature is available:
"light:0": {
"id": 0,
"source": "HTTP_in",
"output": false,
"brightness": 40,
"temperature": {
"tC": 44.2,
"tF": 111.6
},
Hi @markus7017 ,
Am I right, that the new Shelly Flood gen 4 and the new Shelly Blu H&T Display ZB aren’t supported now, also within the latest DEV Builds? If true, I will open up two change requests in GitHub.
cheers
Andreas
If we change it back to Monophase it stops update measurements for Power Meter 3. (Need monopthase profile to have possibility to rename Phases) I’ve read all your comments about the problem. What was your last solution for this issue? BTW I’m very frustrated that absolutely no one has encountered this problem except you and me.