Shelly Binding

The binding uses the credentials from the binding settings to access the device. If that works it get‘s the thing type from the device‘s mdns name, e.g. shelly1. In this case it creates a thing of type shelly1.

If the http access fails it creates a thing of type shellydevice. This is a placeholder so the user see a thing, which needs additional information. Otherwise the device won‘t show up anywhere. If you edit the thing and enter the correct credentials the binding will re-initialize and change the thing type to the detected one. However, I can‘t change the name of the thing anymore so it stays shelly:shellydevice.

If you still see shellydevice after deleting and re-discovering the thing:

  • the binding should now be able to access the device so the thing should become online
  • nevertheless the name might stay the same, because OH keeps the old record in the JSON DB and if you re-discover the device it reuses that record. This is nice, if you really want to delete/re-add the same device, but prohibits reset to a clean status.

If you realy want to have a clean setup you need to clean-out the JSON-DB and remove all references/entries with shelly in the name. In this case all things get re-discovered and create clean entries in the DB. I know, a lot of details under the hood :wink:

1 Like

First of all happy new year and thanks for this great binding!
Initialisation of shelly binding in Openhab 3.1.0 takes quite long. As already described in the previous post the new openhab release 3.0 comes with a lot of changes under the hood and also in the way you interact with the bindings. I was able to get along with the new model based topology and was able to integrate my shellys quickly.
But as far my openhab restarts and the web app refreshes all shelly things are uninitialised and it takes several minutes (up to 5min) until they are online (shelly uni and shelly 1pm) So the startup procedure of the shelly binding for openhab 3.1 takes very long which can be problematic if you work with rules based on the shelly states… How is your experience?
An other inconsistency which i noticed is that the current item value like power consumption or temperature does not show up in the sites where all things are displayed according they semantic group (location, devices…) and only when i press analyse the values are displayed on the graph.

My setup is openhab 3.1 as a docker container on a Raspberry pi 4 with 4GB Ram.

Cheers

that must be specific to you installation. I never saw an issue that initialization takes 5 minutes. Check openhab.log to locate time delay.

I don’t get that, please explain

Thx for the fast reply. As follow two log series are postet which shows the exactly startup behaviour of my system. Sometimes the binding has up to 4 min until all shellies are online…
events_2.log (13.0 KB) events_1.log (7.8 KB)

I don’t get that, please explain

This is not related to the shelly binding as I could figure it out… The new UI which comes with OH 3 does not display the actual item’s state of my shelly devices only the trend line is displayed so far…

Hi,

I have an issue with the amount of data logged by a Shelly Plug S.
As of the setup of the metercurrentWatts item my log is flooded with values (see below).

Any idea how this can be avoided?

I am using OH 3.0

Regards
Tim

2021-01-04 08:05:00.758 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'shellyplugs977c43192168251_metercurrentWatts' changed from 9.8 W to 10.0 W

2021-01-04 08:05:14.714 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'shellyplugs977c43192168251_metercurrentWatts' changed from 10.0 W to 9.9 W

2021-01-04 08:05:15.910 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'shellyplugs977c43192168251_metercurrentWatts' changed from 9.9 W to 9.8 W

2021-01-04 08:05:29.725 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'shellyplugs977c43192168251_metercurrentWatts' changed from 9.8 W to 9.9 W

2021-01-04 08:05:44.731 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'shellyplugs977c43192168251_metercurrentWatts' changed from 9.9 W to 9.8 W

2021-01-04 08:05:46.196 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'shellyplugs977c43192168251_metercurrentWatts' changed from 9.8 W to 10.0 W

2021-01-04 08:05:59.708 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'shellyplugs977c43192168251_metertotalKWH' changed from 0.096 kWh to 0.097 kWh

check out this post to filter logging for those entries: Log filtering in OH 3

Hi, did you find a solution for this issue? I’m seeing the same with a Shelly Dimmer 2 on FW 1.9.3 but only when the SHDM-2 is connected to its dedicated VLAN. If the SHDM-2 is on the same network as the OpenHAB (3.0) server, then the item updates keep coming in (at least more than 10 minutes).
If the SHDM-2 is on the dedicated IoT network, then the item updates stop (either 4.5 minutes after initialization or 5 minutes after discovery).

FW rules are disabled and routing between OpenHAB network and IoT network is enabled, so I don’t think this is a network issue.

Is there anything inside the binding that will timeout if the shelly device is on a different subnet? Or could this be a firmware issue?

I’m logging the shelly binding through the log4j2.xml (<Logger level="TRACE" name="org.openhab.binding.shelly"/>) - at some point no more heartbeats arrive and that’s when item updates also stop. I assume this is because no more CoAP messages are received.

@markus7017 does every received message get logged? Do the missing messages point to the shelly device?

Unfortunately I do not have any other shelly devices here.

Does anybody have a similar setup working?

Thanks in advance and best regards.
Jake

/Edit:
After restarting the openhab service, item updates will be received again for about 4.5 minutes before again no more heartbeat messages are logged.

yes, every message gets logged
run tcpdump of the OH server, you should see the CoAP updates every 15sec, but be aware, CoAp uses UDP via Multicast IP

I do have an mDNS reflector and an IGMP proxy configured and things are working for about 4 to 5 minutes. But after that, openhab seems not to receive any CoAP messages anymore. The other way around things still work, i.e. I can control the Shelly from openhab.

Sotthe realwquestion for me is why does it stop working after four and a half minutes :man_shrugging:

You need to differ between

  • control: This is done via http (binding sends command using the REST API)
  • regular refresh: Once a minute (default) a status poll based on http REST
  • near-realtime updates from the device; those are received
    a) every 15sec
    b) when something happens (event)

This is nothing to do with mDNS (only used for device discovery).

Obviously your network layer is not transparent and the 15sec updates die after 15sec. You already confirmed that it runs fine when OH and device are on the same network. Again: Run a tcpdump/Wireshark and check what happens on the network layer. You need to see inbound Multicast-UDP traffic from 224.0.1.187:5683. I usually set a “ip.addr==OH ip” filter in Wireshark to see the traffic for all devices. Wireshark also supports decoding CoAP packets (underlying standard), CoIoT just defines the payload format (Allterco/Shelly specific).

Hello,

I have an issue with the shellydw2 on my openhabian. I have connected the sensor in my shelly cloud and openhab. In the beginning, both worked perfectly. When I opened the window, both apps showed the updated sensor state.
I tried it after a long time (1-2h) again. The Shelly Cloud updated the sensor state but there didn’t happen something in openhab. It still shows the sensor is closed and not opened. I activated the DEBUG in the console and found this:

2021-01-07 11:12:09.092 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shellydw2-d8bfc01a8411: CoAP Request timed out

2021-01-07 11:13:32.152 [DEBUG] [y.internal.handler.ShellyBaseHandler] - shellydw2-d8bfc01a8411: Status update triggered thing initialization

2021-01-07 11:13:32.154 [DEBUG] [y.internal.handler.ShellyBaseHandler] - shellydw2-d8bfc01a8411: Start initializing thing Shelly Door/Window Sensor 2 (SHDW-2), type shellydw2, ip address 192.168.1.123, CoIoT: true

2021-01-07 11:13:32.156 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shellydw2-d8bfc01a8411: Stopping CoAP Listener

2021-01-07 11:13:32.163 [DEBUG] [helly.internal.coap.ShellyCoapServer] - CoAP Listener stopped

2021-01-07 11:13:32.165 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shellydw2-d8bfc01a8411: CoAP Request was canceled

2021-01-07 11:13:32.167 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shellydw2-d8bfc01a8411: Starting CoAP Listener

2021-01-07 11:13:32.169 [DEBUG] [helly.internal.coap.ShellyCoapServer] - Initializing CoIoT listener (local IP=192.168.1.110:5683)

2021-01-07 11:13:35.328 [DEBUG] [y.internal.handler.ShellyBaseHandler] - shellydw2-d8bfc01a8411: Ignore API Timeout for battery powered device

I’m new in the Smart Home and don’t know exactly how to work with CoAP or the API Timeout. In my PaperUI, the sensors last update shows this:
image

I hope, you can help me & have a nice day

Greetz
Leo / Sulu

I have also trouble with updating Shelly devices on Basic UI. It seems that they are receiving updates every 15s, but never immediately when something happens. This means that when i push a button in Shelly Cloud app, the updates are displayed 5-10 seconds later. If i push a button on my Basic UI page, it is shown in 1-3 sec on my Shelly Cloud app. I have Shelly 2.5 (roller), Shelly 1 and Shelly Uni devices, all of the mon different subnet behind a NAT, but all communication allowed in firewall. Is there a recommended way how i can test where the events are stopped to reach my OH server? I could remove NAT, but then later i want to limit access of my wifi (especially the IoT) devices to reach some points of my main network. Any suggestion is welcome. And btw, great job Markus, i am your loyal customer with your Gree binding as well. :slight_smile:

Thanks for the hint regarding Wireshark which is a very useful tool indeed. I can see now that after 9 multicast packets (i.e. 4.5 minutes since packets appear to be sent every 30s) no more packets arrive - clearly an issue with my network.

For what it’s worth, it turned out that turning off IGMP snooping on the IoT VLAN made things work. If IGMP snooping on the IoT network was enabled, then after 9 packets the US-24 switch somehow stopped transmitting the CoAP packets - they didn’t reach the router at all anymore.

So, for anyone who has problems with a similar setup (Unifi APs, switch(es) and USG), be sure to have a IGMP proxy enabled but check whether disabling IGMB snooping helps.

You probably need to have an IGMP proxy on your router that forwards the shelly multicasts (224.0.1.187) to the subnet where your OpenHAB server lives.

For my Unifi equipment, I was able to ssh into the AP and Router and run a tcp dump on the respective interfaces. Other managed routers might offer the same possibilities?

you Wireshark to check that OH system is receiving the CoAP traffic. You have an issue with your network setup. CoAP has been tested with all devices and works fine. If you decide to have device and OH on different IP networks you need to verify that the traffic is passed correctly

Markus, i thought receiving the updates within 15s confirms CoaP working, am i wrong?

  • run Wireshark with the matching filter
  • set the binding log to DEBUG
  • restart OH/binding
  • Press the button etc., wait 5 sec, press again (should generate 2 CoAP events)
  • Check if you see a CoAP packet in Wireshark
  • and post the relevant log part here

I like to see the complete thing initialization and the CoAP processing when you press the button twice in the log.

Hi Markus,

for the Shelly Dimmer it would be nice to have a dedicated channel to turn the light on and off. I ahve disabled “Brightness Auto-ON” as I want to adjust the brightness depending on the daytime, but now I can’t turn the lights on or off through the binding.

Was there a specific reason to omit this control channel? If not, would it be possible to include it? If so, I’m happy to create a feature request and test out a dev build.

Best regards
Jake

Is any of you using the Duo bulbs with this binding? For me the Colortemp does not work. From comparing the values in the UI it seems that the binding uses the white value instead of the temp value, which is of course not in the given Kelvin Range.

Any idea, how to setup the shelly HT under OH3 that the temperature looks like xx.x C and not like in the picture with xx.xxxxxx C???

Thanks for all the tipps…
BR
Scheuerer