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
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.
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
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).
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
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
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.
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.
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
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.
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.