Hello @rose78 ,
Have you also copied the additional JAR files to the addon folder (or alternatively installed Tradfi Binding)?
See “Installing DEV build” → myfiles/READMEbeta.md at master · markus7017/myfiles · GitHub
Hello @igi
When I also add the tradfri Binding, I get this two errors:
2022-01-01 12:10:14.303 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/usr/share/openhab/addons/org.openhab.binding.tradfri-3.3.0-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.tradfri [313]
Unresolved requirement: Import-Package: org.eclipse.californium.core; version=“[2.0.0,3.0.0)”
at org.eclipse.osgi.container.Module.start(Module.java:463) ~[org.eclipse.osgi-3.16.300.jar:?]
at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:445) ~[org.eclipse.osgi-3.16.300.jar:?]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [bundleFile:3.7.2]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [bundleFile:3.7.2]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:520) [bundleFile:3.7.2]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [bundleFile:3.7.2]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [bundleFile:3.7.2]
2022-01-01 12:10:14.307 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/usr/share/openhab/addons/org.openhab.binding.shelly-3.3.0-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.shelly [314]
Unresolved requirement: Import-Package: org.eclipse.californium.core; version=“[2.0.0,3.0.0)”
at org.eclipse.osgi.container.Module.start(Module.java:463) ~[org.eclipse.osgi-3.16.300.jar:?]
at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:445) ~[org.eclipse.osgi-3.16.300.jar:?]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [bundleFile:3.7.2]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [bundleFile:3.7.2]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:520) [bundleFile:3.7.2]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [bundleFile:3.7.2]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [bundleFile:3.7.2]
@rose78 Please just download the 3 JAR files:
californium-core-2.0.0.jar
element-connector-2.0.0.jar
org.openhab.binding.shelly-3.2.0-SNAPSHOT.jar
and copy them to the addon folder. Before that, make sure that the official Shelly Binding version has been uninstalled.
Also make sure that there is no other DEV version of Shelly Binding in the addon folder.
Thanks this works.
Obviously you are used the 3.3-SNAPSHOT build
Which OH version do you run?
I’ll most likely not accept this PR. The is no response to reduce min update interval from 10 to 1 minute. The binding is event driven in most cases, polling is only a fall-back.
What’s the use case here?
I have OH version 3.2.0. Since I have the 2 additional jar files in the addon folder, there is no error in the log.
The use cases are this two:
Example 1
With the minimum value of 10s on the Shelly 1 PM it’s not possible to implement a consumption based rule which relies on current data (e.g. when starting a saw in our workshop we want to activate the suction system; but currently we have to wait for 10 seconds).
Example 2
With the minimum value of 60s on the Shelly DW 2 it’s not possible to immediately react to alarms raised by this component. When implementing a security system based on this sensor, lower update intervals are needed.
Why is there a minimum value higher than 1 second needed? In the binding mystrom the minimum is 1s and that works as it should. There are no big datas to transfer and the users do not have to modify the default values when is not necessary.
At the moment with 60 seconds minimum polling time the door/window sensor delivers the burglary alarm event after 1 minute in openhab. In this case I receive the alarm too late and a burglary protection is not given.
You misunderstood what @markus7017 wrote.
The DW 2 will send state changes immediately via coiot protokol, polling is used for fallback only. Same applies for any other Shelly. There is no need to reduce the polling interval!
@hmerk
How can I make the rules value based running faster than at the moment?
I put the ON button in the shelly app, then it takes more than 10seconds until OH shows the status ON in the item and it takes also more than 10seconds until OH shows the value “currentwatts” higher than 0 watt. What do you propose as a solution?
There must be something wrong in your config.
If one of my Shellys is switched, I can see the change immediately in openHAB.
Are you shure that CoIOT is enabled in your Shellys and openHAB ?
You can try to change CoIOT from multicast to unicast by entering your openHAB server IP-Address.
Many thanks for this inputs. I have found the solution in the documentation (only beginners read the instructions 
):
Disabling this feature allows granular control, which event types will be used. This is also required when the Shelly devices are not located on the same IP subnet (e.g. using a VPN). In this case autoCoIoT should be disabled, CoIoT events will not work, because the underlying CoAP protocol is based on Multicast IP, which usually doesn’t passes a VPN or routed network.
We have a lot of shelly things in OH (more than 30). OH and the shellys are in a different subnet. Now we put the 2 shelly (who should faster react) in the same subnet as OH. The state and value updates takes now 1-2 seconds.
Please note though that it is not necessary to put them in the same subnet. You may also configure the shellies to send unicast messages directly to your openHAB host. In my opinion this is usually the best option unless you really want to receive the messages on more than one device. You would only need one simple firewall rule and potentially reduce the overall network load.
To do so change CoIot peer from mcast to 10.9.0.101:5683 (change ip as needed) in the Shelly web UI.
1 Like
Exactly what I wrote 
1 Like
Thanks, it works!
Hi all, i hope it’s ok to ask my question here, if not just tell me to open a new topic.
At least it is shelly related.
I’m currently writing a widget for all my shellies, and it looks like that
Actually i do have two questions:
1: You see the red line “Firmwareupdate…” that is displayed when the shelly reports that a firmware update is available. When you click on it, the website of the device is being opened. For that to work, i need to manually configure the IP adress, but the Shelly thing should know its IP. Would it be possible for the future to have the IP adress also available in the channels?
2: It seems to me that the channel names are being localized. Which basically is good, but if you want to have a widget that automatically generates the names of the items based on the group like follows:
- component: oh-link
config:
action: analyzer
actionAnalyzerItems: =[props.group + '_Laufzeit']
iconF7: timer
text: =items[props.group + '_Laufzeit'].state
visible: "=(items[(props.group + '_Laufzeit')].state === undefined) ? false : true"
style:
color: "#666666"
So i just need to select the basic group that represents the shelly, and all other parts of the widget are extended by adding the localized suffixes ('_Laufzeit') that are generated by the binding when you automatically link the channels to items.
In order to share my widget for the community, i either have to let the user define all items within the widgets properties or users would have to change the suffixes in the YAML file of the widget. Is it somehow possible to not translate the channels (at least on an item name level)?
Do you know Shelly Manager: http:<oh ip>:8080/shelly/manager ?
Nope, didn’t know that. But i think that would work for the widget. Thanks 
Hello and a happy new year,
I hope it is ok to post here instead of openening a new thread.
I run OH 3.2 release on a RPI.
I have a bunch of Shelly 2.5 already included to controll my rollers, and I wanted to use some them to monitor my Voltage. So I created a Number:ElectricPotential item and linked it to a the Channel shelly:shelly25-roller:10fa1f:device#supplyVoltage (Number:ElectricPotential) of one of my Shelly 2.5. But the value stays NULL. In the Shellys Status the voltage is reported:
,"ram_total":49944,"ram_free":34836,"fs_size":233681,"fs_free":142568,"voltage":235.95,"uptime":2007925
I also tried to change Item type to “Number” but it still stays NULL. Any ideas why this item is not updating? Of course I can do a HTTP request to the Shellys status and use JSON to parse voltage, but I think this job is done by the binding also?
did you discovered the thing in main ui or did you defined it in a .things file?
@rose78 you could change the setting using Shelly Manager. Put all of them into Unicast mode and you could run them in a separate ip subnet using regular routing and filtering
