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 
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:
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. 
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
switch to the latest DEV build, this has been fixed
you could send on/off to the brightness channel - don’t ask me why, but it’s standard for OH light control to have the same channel for on/off and dimming the light
Hi Markus,
I’ve just started playing with OH3 with a view to migrating from OH2.5
In OH2.5 I have all my Shellies configured using MQTT and manual rules in a .rules file
For OH3 I have installed the binding, added all my Shellies as ‘Things’ and linked items from the relevant channels.
However upon setting up a rule to turn on 2 lights (2 separate Shellies) by reading the input of a 3rd Shelly, there is a delay of between 0.5-1 second between flicking the switch and the lights turning on/off. NOTE: I have disabled the rule in the OH2.5 instance.
As a test I have configured an MQTT item in OH3 from the 3rd Shelly switch, and now the on/off of the lights is only delayed by an absolute split second, but is acceptable.
So it seems there’s a delay with the Shelly sending the input state change via CoIoT protocol and it being read by OH3 Binding. I have enabled button events and push events in the ‘Thing’ config but this made no difference.
Can you advise if there is some other config options that I have missed? Obviously I would rather keep to either binding or MQTT for all Shelly items, as opposed to a mixture.
Hi Markus,
sorry that I jump in here as I am having problems with the door windows sensor 2 not receiving any updates on OH3 and binding 3.0.0 (while it does in Shelly App)
- Should I rather first update to the 2.5.12 or can I use 3.1.0 on OH 3.0.0?
- I have wiresharked it as you said and it fires the 2 coap responses.
- Everytime I open and close the sensor further coap messages are sent (see logs)
- I have the binding ( CoIoT is on) on debug but nothing appears when the coap messages are sent
Do you btw have any door sensors yourself to test? If not I would offer to sponsor one to you.
shelly-door-openhab.txt (2.0 KB)
shelly-door-capture.pcapng.log (16.2 KB)
How should I proceed to debug the issue?
TIA
Stefan
PS:
Please remove the .log from the wireshark file extension.
Hi Jake,
a question regarding your comment:
I indeed have a unify setup but all my devices live in the same subnet including openhab. Just for the record, the router is actually a fritz box but the wifi is generated by the APs. Note that I do not have a USG where normally IGMP proxy is configured as far as I know.
- Does your comment still apply in my case?
- Do I have to still set IGMP proxy in my router (while I think this is by default on).
Thanks
Stefan