Yes, notifications are inbound only. The information is used to route the event to the matching thing.
Nevertheless, if this shows up every minute it has something to do with the device
@alaub81 Could you please provide
So⊠I double checked in the web console of the shelly for the no DST warning. And yes it was shown up every full minute. After activating trace log in openHAB, the warning was gone in the web console. Then I rebooted the shelly, and after the reboot the message was there again.
shelly_notification:116 ch type=WS_in info=192.168.50.20:47394 has no DST
here is another interesting log line:
Mar 5 10:01:23 shelly-dl-schuppen shelly1pmminig4-7c2c676ddb6c 78 6.724 2 2|shelly_notification:164 Status change of sys: {"last_sync_ts":1772701282}shelly1pmminig4-7c2c676ddb6c 79 6.724 2 1|shelly_notification:116 ch type=WS_in info=192.168.50.110:58521 has no DSTshelly1pmminig4-7c2c676ddb6c 80 6.724 2 2|shelly_notification:164 Status change of sys: {"time":"10:01","unixtime":1772701282}shelly1pmminig4-7c2c676ddb6c 81 6.724 2 1|shelly_notification:116 ch type=WS_in info=192.168.50.110:58521 has no DST
Got the message when connecting via my notebook to the shellyâs web interface.
@markus7017 will send you tracelog and web console log as direct message.
Iâm still confused by the timestamps here. 1772701282 is Thu Mar 05 2026 09:01:22 GMT+0000, so itâs 10:01:22 in CET. But, who/what sets the time field shown above? Is it the binding? Why are there no seconds? IF the device should accept both 10:01 and 1772701282, it must have CET set as a timezone, or it wonât make sense. So, if the binding sends both these fields, this could still be about timezone.
Iâll add that, from the Shelly API documentation, they refer to the header field as dst and the timezone related stuff as DST. So, the fact that the error reports DST might indicate something.
New DEV version under 5.1.3 is running. NO problem seen, so farâŠ
I tried again today with latest snapshot binding.
again no hardware switch or web-ui switch is reflected to openhab. in debug i see nothing special. I need to test in a test-openhab. i have over 30 shelly in my network. i rollback my backup. maybe tomorrowâŠ
greets
I also tested this cases, on my side everything is working fine. The I press the hardware switch, or I enable the light via Shelly App, or via Webui, milliseconds later I see the switch goes on/off in openHAB.
Which relays are you using? Is openhab in the same network as the Shellies? Are you using Docker? If yes, you are using docker networks host mode?
it is just with update openhab >5. with my backup debian12 openhab 4.3.6 I never saw this behavior.
VM with debian 13 and latest openhab.. installed yesterday. I tested old shelly1. 2 different devices. both show the same behavior.
Log is difficult because I have around 40 shellys in my network.
when I have time I will install a test-openhab with one shelly for testing.
Greets
I donât have any Gen 1 Devices running, only newer gen2-4 Devices. If I remember correctly, old devices need this CoIoT connection. So devices need to talk to openhab. The IP or FQDN of openHAB must be configured on the devices and the CoIoT service must be reachable on the openHAB side. look into the binding configuration under addons. There must be Auto-CoIoT enabled and I would enter manually the correct IP under Host Interface IP. Also check if the CoIoT Service is running via netstat. Port should be udp/5683.
@markus7017 If I am correct here and the shelly Binding is enabling the CoIoT Service on UDP 5683, then it could be broken, because I canât see anything on this Port running on my machine.
Perhaps someone else can answer to the usage of CoIoT and the older Gen 1 Devices. I am no expert here 
I used my Backup from openHAB in the new Debian. I think there was no configuration error.
Iâll check this if I boot up my debian13 VM again.
Greets and thx for your tips.
PS. my Shelly motion worked.. They use CoIoT too. I saw the motion switch ON
thatâs normal, youâll see those lines on every event
this is a notification from the device to the binding so those files are filled by the device. You could also set the timezone on the device and by default it uses ntp time sync
Are you sure? The last part of the line is
shelly_notification:116 ch type=WS_in info=192.168.50.110:58521 has no DST
Yes, you must set a timezone to use NTP, or it wonât know âwhat timeâ to get. So, it seems like the timezone set on this device is +01, thatâs the only way to explain the difference between time and unixtime. But, âhas no DSTâ could mean many things - it can mean that itâs set to a fixed +01 offset, that doesnât respect DST, it could mean that itâs set to CET or a zone ID within CET like Europe/Berlin and that the zone isnât currently in DST (which is correct because DST doesnât start until after March 29), or it could mean something regarding the dst field in the header, or something else that I havenât thought about.
The question is what it actually means, and if itâs an error or just information. I donât know these logs, is it logged in a way that indicates that itâs a warning or error, or could it just be âinformationalâ?
Good morning..
I tried again:
openhab 5.1.3, shelly binding 5.1.0.202603041116
I found the issue..
itâs the openWRT Repeater with relaydâŠ
All shelly who are connected to this repeater dont work..
is think its a forwarding problem..
But it has to do with openHAB5.. with openHAB4 where no problems⊠
oh I got itâŠ
in the shellys behind the relayd repeater i have to set mulitcast. now it is working.
halleluja 
Yay, installed. The version reports 5.1.0.202603041116, which was updated in Github on March 4 (2 days ago).
Startup is fine, immediate operation as expected.
But two old acquaintances are back on the my Plug S Gen3 devices, which were gone in our âwild trialâ builds - so you probably have them on your ToDo list of PRs to come, but just for completeness:
shos_rpc_inst.c:243 Shelly.GetConfig [1619580316@openhab-] via HTTP_in POST 192.168.85.2:47836 12:51:00
shos_rpc_inst.c:243 Shelly.GetConfig [324672874@openhab-] via HTTP_in POST 192.168.85.2:47862 12:51:00
shos_rpc_inst.c:243 Shelly.GetConfig [1187934876@openhab-] via HTTP_in POST 192.168.85.2:47884 12:51:01
shos_rpc_inst.c:243 Shelly.GetConfig [2093758815@openhab-] via HTTP_in POST 192.168.85.2:47918 12:51:01
shos_rpc_inst.c:243 Shelly.GetConfig [1465273604@openhab-] via HTTP_in POST 192.168.85.2:54990 12:51:10
shos_rpc_inst.c:376 0x3fccab8c: duplicate id 'openhab-' 12:51:10
shos_rpc_inst.c:243 Shelly.GetConfig [1874470385@openhab-] via HTTP_in POST 192.168.85.2:55000 12:51:10
shelly_ejs_rpc.cpp:41 Shelly.call Switch.GetStatus {"id":0} 12:51:14
shelly_script.cpp:205 script:1 0.2% CPU utilization 12:51:14
shos_rpc_inst.c:243 Switch.GetStatus [835140@RPC.LOCAL] via loopback
Furthermore, I will keep free memory of both OH and the Shellys under observation.
Thanks so far! 
I checked my logs again for the duplicate ids, none are found. But I am using the 5.2 version.
The âfox dupl idâ has just been merged. Maybe I built the 5.1 version on an older code base my mistake. Iâll provides updates soon.
Fascinating - 5.2 does not have the duplicate ID issue.
Well, that kind of divergence happens when much work is going on. 
But anyway, I stumbled upon something completely different there.
First of all, I am using two Shelly Blu Gateways (the older,. Non Gen4 type) for linking my Shelly Blu devices to OH. Other than the Plug S Gen3, they have no issue running the OH-blu-scanner script.
For quite some time, I ran the âcachemdnsâ trial version of the binding. Mem was stable on both OH and plugs. No dup IDs, single Shelly.getStatus.
But whenever the connection to my Shelly Blu Gateways was interrupted - e. g. device reset, OH reboot - my Blu Button 1 devices stayed in âONLINE - CONFIG PENDINGâ no matter how often I pressed them. They came back to life only after manually disabling and re-enabling the Thing of the Blu Gateways followed by once pressing the Blu Buttons.
The current 5.1 dev version did not have this issue. Pressing the Blu Button 1 once always immediately triggered the transition from PENDING to ONLINE, no matter which reboot / reconnect history it had.
To increase the surprise, the current 5.2 dev version was even worse! I actually did not find any way to finish the initialization of the Blu Button 1 devices, they stayed in PENDING forever. I even tried deleting the scanner scripts from the gateways and re-installing via OH. This worked, but did not change the issue.
Again, to make sure you get it right: The Blu Gateway Things always do the transition OFFLINE - CONFIG PENDING - ONLINE within seconds. Itâs the Blu Button 1 devices which can get stuck in PENDING. But if itâs fixed, this happens by a disable - enable sequence of the gateways they are connected to.
And now to finalize it: All of this seems not to affect the Blu Button 4.
Therefore I am back on the 5.2 cachemdns version for nowâŠ
There are way too many things going on at once here for my to know whatâs going on, but there are still fixes waiting to be merged into the latest dev, so in a way itâs not that unexpected.
That said, I think itâs most interesting which things donât work with the latest dev version. What is this issue with gen1 devices? Do you have any logs that show whatâs going on?
The PRs we have done lately should have very little impact on gen1, so Iâm somewhat surprised if thereâs a new bug for gen1 devices. But, anything is possible of course.
Itâs not about Gen 1 devices, itâs the Blu Button 1, where the â1â means a single button.
The Blu Button 4 is the one with 4 buttons.
The number are similar but do not relate to the generations 
AFAIK the Blu series donât have anything to do with the Gen 1 to 4 of the Shelly processor / API.
I donât even know what âBluâ is, except that I suspect that bluetooth might be involved. But, from the code, âBluâ devices are gen2:
public class ShellyBluApi extends Shelly2ApiRpc
So, the changes we have done are likely to have impacted these, but apart from that, I have no idea what exactly goes wrong here - or even whatâs supposed to happen. Why would you need to push a button to âinitializeâ them at all? Is it because they are battery devices that only contact the âserverâ infrequently, and the button push makes this happen sooner rather than later?