Shelly Binding

stefan.hoehn · January 9, 2021, 2:55pm

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

36grad · January 9, 2021, 4:00pm

If all devices are on the same subnet, no routing is done and no IGMP proxy is needed. You should use Wireshark /tcpdump to check whether the multicast packetsaare received by openhab
Additionally you can ssh into your unifi AP and use tcpdump/Wireshark there too to check whether the Shelly device is actually sending CoAP packets.

stefan.hoehn · January 9, 2021, 4:59pm

ok, thanks for the clarification. I did the wiresharking in the post above. I see that the packets are sent but how would I actually know if it was received by OH?

36grad · January 9, 2021, 5:15pm

go to the openhab console
ssh -p 8101 openhab@localhost
Passwort: habopen

and do
log:tail

you need to enable logging for the Shelly binding in the log4j2.xml file and I think set it to TRACE.

markus7017 · January 9, 2021, 5:49pm

Make sure you use firmware 1.9.3. Allterco did some improvements on CoIoT latency.
Make sure you disable button / relay events and enable CoIoT events. The action urls don’t provide a benefit if CoIoT is enabled. This provides the fastet response. The binding immediatly processes any CoAP packet and maps that to the channel

markus7017 · January 9, 2021, 5:54pm

I checked your log. I see

Unable to initialize: shellydw2-483fda81f79c: Local IP address was not detected, can't build Callback URL (class org.openhab.binding.shelly.internal.api.ShellyApiException), retrying later

Go to the openHAB network configuration and make sure a valid interface IP has been selected.
Do not set the Host IP in the binding’s settings, this is not required when the device sits on the same subnet.

Go to theOH console and enable debugging
openhab-cli console
login
log:set DEBUG org.openhab.binding.shelly
logout

you should now see CoAP initialization and packet processing in the OH log
and yes, use 3.1.0-SNAPSHOT when running on OH3

adamg · January 9, 2021, 5:59pm

I had been holding off from 1.9.3 due to the currently reported wifi issues, but have updated just on this Shelly for now.

Disabled button and push options, CoIoT events was already enabled.

Unfortunately, it’s now worse in response time to the switch, between 1-2 seconds.

stefan.hoehn · January 9, 2021, 6:02pm

Just to be sure:
Would this be the right setting then?

stefan.hoehn · January 9, 2021, 7:23pm

I can definitely agree that everyone on OH3 should first move manually to the latest snapshot and make sure you have the latest version like I have now

238 │ Active │  80 │ 2.0.0                   │ Californium (Cf) Element Connector
239 │ Active │  80 │ 2.0.0                   │ Californium (Cf) Core
240 │ Active │  80 │ 3.1.0.202101042319      │ openHAB Add-ons :: Bundles :: Shelly Binding

Markus,
the door sensor is working now.

Thanks (for all your work!)
Stefan

PS: Hopefully the new binding makes it into the next release.

pezoli · January 9, 2021, 7:47pm

Hi Markus, maybe i am doing something wrong, but i dont see any sign of CoAP in any of my logs on OH. So what i did:

Restarted my OH server (Synology NAS) and my OH software (v2.5.10)
logged into Karaf and set log to DEBUG first, then to TRACE after 5 minutes because i didnt see anything like CoAP, still no luck…
i tested the communication on both ways
3a) i switched my shelly1 relay On and OFF with the cloud app on my iphone
3b) i switched my shelly1 relay ON and OFF from BasicUI
i checked openhab and event logs. Switching is there in event.log, but only when i used BasicUI. I dont see anything from coap in openhab.log
i have ran Wireshark on both my OH subnet and my Shelly1 subnet, set filter to coap, no sign of it
I am running v2.5.12.202101042318 of your binding, checked in Karaf.
I suspect CoAP is not working at all on my OH server, should i manually enable it somewhere? I thought CoIoT is auto on, once i have shelly fw version 1.9+. When i installed my deviced last year, they all reported in openhab.log: “INFO: Firmware is full-filling the minimum version to auto-enable CoIoT”, but only once, never again, even after i restarted my OH server several times. Is this normal, the status is saved permanently somewhere?
Otherwise, my OH installation is working fine, sometimes i see my Shelly devices are updating the status, maybe this is the REST API updates, but it never worked instantly as i would expect, like it does for my MQTT devices.
Please direct me where to look further.
logs attached
2021-01-09 shelly binding oh trace1.txt (8.3 KB)

pezoli · January 9, 2021, 7:54pm

On PaperUI, binding is set as follows:

localIP = IP of my OH server
autoCoIoT = true

pezoli · January 9, 2021, 8:36pm

Checked with latest binding (2.5.12.202101090955), after cleaning cache. Same results operation side, receiving updates of thing changes (when i do it from cloud app) in every 15 seconds. BUT i noticed a new log entry, first sign of CoAP:
“2021-01-09 21:28:00.836 [WARN ] [network.InMemoryMessageExchangeStore] - coap Exchange[L17] with manual token overrides existing Exchange[L16] with open request: KeyToken[IPofMYShelly25:5683-]”
Only one, although i have 7 Shelly devices. Not sure if that mean something, just wanted to add.

markus7017 · January 9, 2021, 8:57pm

what made the difference?

stefan.hoehn · January 9, 2021, 9:58pm

Sorry that I wasn’t clear in my answer: by saying everyone should update I wanted to say that it solved my problem . It was definitely the old binding that comes along with OH 3.0.0. Now with the 3.1 binding it works well as expected. The network setting as mentioned below I am sure makes sense in general but didn’t make a difference towards my issue!

scheuerer · January 11, 2021, 12:52pm

Hello shelly plug S users…

Can one of you do me an example, step by step, how and what I need do to, to setup a rule which switch off my new shelly plug S, when the connected power supply has lower than 3 W power usage?
It would be perfect to get a example how to do that.

Thanks
Scheuerer

pezoli · January 12, 2021, 3:03am

Hi @markus7017 , i made another attempt.

enabled DEBUG log for shelly bundle
stopped OH
removed shelly binding from addon folder
deleted all files from tmp, cache, log
moved latest jar into addon folder, version 2.5.12.202101110704
removed all shelly things from definition text file, except my shelly1
started OH and watch logs, while is was running Wireshark (on shelly1’s subnet) with coap filter
Pressed switch ON/OFF on BasicUI at 03:00:06 (responded immediately, also shown in Shelly App in 1-2 seconds), but when i push the button ON/OFF then again ON/OFF in Shelly App between 03:00:30-03:04:30, OH recognized it only within a minute (not immediately, so not via CoAP), probably via HTTP update.

What i see from logs, that coap listener started, first coap messages arrived and processed by OH, but never ever appears coap handling again, only HTTP updates are initiated and received every 60 seconds approximately (i saw it in TRACE earlier). In the same time, Wireshark clearly shows, that CoAP message is broadcasted from my shelly1 ip every 15 seconds, and when i switch lamp ON/OFF, it is also there immediately. Please note Wireshark was running on the subnet shelly1 is installed, but i checked those were repeated on the OH subnet as well.

Few things i noticed: ShellyEventServlet and ShellyManagerServlet starting, stopping and starting again at the beginning. I checked, shelly binding v2.5.10 is not installed on PaperUI, so no idea why is the duplication.

Can you pls suggest where else to look further?

Logs:
openhab.log each lines include “shelly” text: openhab.log.txt (31.3 KB)
event.log each line include my shelly1 item: event.log.txt (2.2 KB)
whireshark on shelly1 subnet: wireshark.log.txt (4.0 KB)

markus7017 · January 12, 2021, 6:22am

What you describe is usually the problem when having OH and device on different subnets. In this case http goes through as usual, first CoAP messages (because standard UDP traffic) and then nothing, because Multicast CoAP messages are not proxied between the subnets.

There might be 2 reasons:
a) Your router/switch is not passing the IP Multicast traffic between both subnets - maybe this needs to be enabled or you need a IGMP proxy

b) CoAP support is broken in the latest build. I’m working on Shelly motion integration, which requires some specific things and did not cross-check other devices for now. Try a binding from beginning of the year (go to GitHub history of the jar file).

The usual flow

On initialization the binding does a REST poll do read current settings and status
Then it sends a /cit/d request to the device, which reports the device characteristics
Next is a standard UDP Coap /cit/s to trigger device updates
The device will now start to provide CoAP update messages every 15sec or when something happens. The difference to the previous one is that those are using Multicast IP (device ip → 224.0.1.187:5683) - you could see that traffic in Wireshark. If the router doesn’t proxy those packets you’ll see them on the subnet the device resides, but not on the network OH resides = the binding doesn’t get that traffic
Beside periodic device updates the binding does one REST poll per minute to make sure binding state and device status are in sync (there is various status information, which are not available through CoAP)

Current I’m trying to push Allterco for a config option to set a spefic IP in the device config so the user can set this to the OH IP. More and more users are separating IoT devices from the main network and Multicast IP is usually not enabled out-of-the-box for most routers and many of them don’t have this feature. Using standard UDP to a single IP would fix those issues immediately.

stefan.hoehn · January 12, 2021, 6:44am

Can you tell me what kind of experience you have in writing rules at all? Are you refering to OH2 or OH3? What rules language do you intend to use? Otherwise it is hard to provide you with an example.

regards
Stefan

pezoli · January 12, 2021, 6:49am

Thank you for the quick reply Markus!
Im pretty sure CoAP multicast messages come over to my OH subnet (i installed PIM routing using IGMPv2 to be 100% sure), i have seen it in Wireshark, just used the Shelly1 subnet capture in my previous post because you can see the origin of the multicast message their easier. On OH subnet the multicast source is the router itself (router ip -> 224.0.1.187:5683), so you need to look into the message to find who is the originator. I did check and i saw my Shelly1’s broadcast repeated on OH subnet. Next i will make some test with older bindings - thanks for the idea - and report back to you if i find one which works better on my network setup. I can also try to move one Shelly device back to main network just to see if it behaves differently on OH subnet.

scheuerer · January 12, 2021, 7:42am

Hello Stefan,

thanks for your question.
I have NO experiance in “writing” rules in a script. I used always in past to create rules via NG-Rules under PaperUI.
I’m using OH 2 since more that 2 years now, with around 30 things from TP-Link and shelly.
After x-mas time migration to OH3 stable installation all my old rules run fine with measurement the power for other things e.g. mobile changers.
But the shelly plug S seems to have other results from the rules.
As told before I want to shut off my bike charger after my the battery was fully loaded.
So the idea is to trigger via a rule, when the power is less then 3 W to switch the shelly s plug off.
But when when manuell switch on the plug it stops chargiung, because the rule runs. (which is correct because the value ist 0W, so under 3W which was set)
Adding a secound value “but only if it is not 0W”, in the rule e.g. if the power is 0W which is working with TP-Link rule, this will not work with Shelly Plug S .

So what kind of value I should use for:

trigger for start the rule
end the rule by less than 3 W
and what kind of “but only if” values.

Thanks for your pictured examples.

BR
Scheuerer