OpenHAB4 not updating status of Shelly devices (shelly-binding)


I have the issue that the status of my Shelly devices does not get updated in OH4.
I see all my Shelly devices in OH as Things, discovery works, I can also control all of them with OH4.

If someone presses the physical switch and a light gets turned on OH4 does not show this.
The official Shelly App shows that the Light is now turned ON, but OH4 still shows it as OFF, the state never changes, I wait for like 10 minutes.

Unfortunately I cannot post any logs because there is no log entry as far as I can see, as OH4 does not register any state change.
Same issue with all my Shelly devices, several Shelly1, Shelly2.5 and Shelly Dimmer2.

Tested with Eco Mode On and Off.
openHAB 4.0.0
Shelly FW: 20230510-082818/v1.13.1-gda6f9f2

Any hint or suggestion is appreciated!
Also if I should post any specific log please let me know!


Quick update, the issue is now fixed, however I am unsure what change made it work again.

I noticed that there was the log entry:
Found multiple local interfaces - ignoring

And therefore I set a fixed IP in OpenHab through the UI in the menu point “Network”

I have a similar problem during setup of OH4 on a new Raspberry PI. The Shelly Binding correclty discovered my 20 devices but after creation of a thing for a device (with a custom name) the device does not disappear from the inbox.
Is there a way to remove them from the inbox (not just hiding them) ?

No, unfortunately, the Shelly Binding needs the devices MAC address to be the UID. You can only label the Thing to your likings.

Is this already reported as a binding error? In my opinion it’s a big error of the shelly binding if the system allows the usage of custom UID’s and the binding does not support it.

@markus7017 are you aware of this „misbehaviour“ ?

I have set a fixed IP for my shelly but they still don’t update if you press physical button. How to fix? They only update when status is polled actively (atm 60seconds). But it’s not actively updated

I have a similar issue with Shelly 1 Plus and OH 4.0.3. I can turn the light on and off from OH, but when the status is changed outside of OH, either using the physical button or via the Shelly web interface, the status is not updated in OH.

Shelly FW_ID: 20231031-152227/1.0.7-g5db02bd

hi @admir86 I just encountered this exact same problem with a Shelly Plus 1. In my case it might have been caused by manually assigning a duplicate ip address to this shelly (although I cannot find another assignment in my DHCP server). I changed the IP address in the router, then changed it in the Thing and I rebooted the shelly from the shelly UI settings page. all my items are updating correctly now.

edit: apparently this issue is a bit more difficult than it seemed at first glance: I have another Shelly Plus 1 with the same symptom, which cannot resolve with this trick.

I activated the debugging for the shelly binding. I think the channel receives the update, but the state is not parsed into the item?

situation. openhab items are aligned with shelly states in UI:

I then flip the physical switch, (which is setup in Edge mode):

2023-11-14 14:25:41.930 [DEBUG] [g.shelly.internal.api2.Shelly2ApiRpc] - shellyplus1-441793944e7c: NotifyStatus update received: {"src":"shellyplus1-441793944e7c","dst":"shellyplus1-441793944e7c","method":"NotifyStatus","params":{"ts":1.69996834189E9,"input:0":{"id":0,"state":true}}}
2023-11-14 14:25:41.933 [DEBUG] [y.internal.handler.ShellyBaseHandler] - shellyplus1-441793944e7c: Channel relay#input updated with ON (type class org.openhab.core.library.types.OnOffType).
2023-11-14 14:25:41.974 [DEBUG] [g.shelly.internal.api2.Shelly2ApiRpc] - shellyplus1-441793944e7c: NotifyStatus update received: {"src":"shellyplus1-441793944e7c","dst":"shellyplus1-441793944e7c","method":"NotifyStatus","params":{"ts":1.69996834189E9,"switch:0":{"id":0,"source":"switch","output":false}}}
2023-11-14 14:25:41.976 [DEBUG] [y.internal.handler.ShellyBaseHandler] - shellyplus1-441793944e7c: Channel relay#output updated with OFF (type class org.openhab.core.library.types.OnOffType).


the input item is updated by the channel, but the the output item is not…

1 Like

Hi @fennepa, thx for sharing your investigation.

I have set up IP reservations for my Shelly devices on DHCP, so it shouldn’t be possible for the same IP to be assigned twice.

But I accidentally discovered the following:
If I delete my Shelly Thing, then add it again, but not through the INBOX. Instead, I go to ‘Add New Thing,’ choose the Shelly binding, and perform a scan. Click on my newly found Shelly and add it WITHOUT changing the suggested label. Then go to the binding and just add user name and password → save. And it works as it should until I adjust the label or location in the Thing; after that, it stops working again.

Can you confirm this, or am I just doing something strange? :smiley:

Hi @admir86, I have added the thing from the manual scan. I created the thing and the items without making any changes. All items are currently working as expected. I will keep it running like this for a few days to see if anything changes and only then I will start making some updates to the labels

I just noticed that the e.internal.SseItemStatesEventBuilder keeps trying to update items that are no longer existing. for example:

2023-11-14 19:25:07.176 [WARN ] [e.internal.SseItemStatesEventBuilder] - Attempting to send a state update of an item which doesn't exist: shellyplus1schakelaar_hal_Power
2023-11-14 19:25:07.178 [WARN ] [e.internal.SseItemStatesEventBuilder] - Attempting to send a state update of an item which doesn't exist: Schakelaar_hal_InputButton
2023-11-14 19:25:07.181 [WARN ] [e.internal.SseItemStatesEventBuilder] - Attempting to send a state update of an item which doesn't exist: Schakelaar_hal_Update_available

I normally press “unlink and remove all items” on the channel page of a Thing, although I’m not 100% sure that is what I did that particular occasion. I executed /links/purge, but if the API output reports out what was deleted, then I my case it did not resolve anything, as I build my entire config on 4.0.3, I was assuming that these orphaned links were a thing of the past…

You’ll see that error if you have a MainUI widget that references those Items. You’ll see them when the page that references the Items is loaded the first time.

There has never been a MainUI widget for these items, so that should not be the cause here. I don’t think a first time load activity is causing this at all as I had them randomly in my log every day for a week. sometimes only once, but sometimes 4 times a day. I have not seen them since I purged them with the API.

But there must be a reference to those items somewhere in your UI‘s
Could be they have been members of a group before you purged them but are still referenced in that group.

Yes, that is a possibility