thanks, that with roller_open solved my problem. now i receive the triggers
Is there a possibility to set the total & total_returned values on the Shelly device itself to something else? I had a power outage and my Shelly 3EM started counting from 0 again. Now my database is not so pretty 
I was able to play a bit with API and was able to change things like the name (POST http://192.168.0.35/settings?name=shellytest, tranfsformer type (POST http://192.168.0.35/settings/emeter/0?ctraf_type=120), but when I do eg POST http://192.168.0.35/emeter/0?total=20, the command is accepted, but nothing changes.
API Reference
Anybody has experience with this? Otherxise I will need to edit the values in my db, so everything matches again.
edit: if this is not possible in the Shelly device, I just found out that I can set a profile offset on the item, so I can correct it from here.
edit2: I received a message from Shelly that this is not possible
Today i’ve started to work a little bit more with CoIoT and set my openhab ip to all devices to reduce mcast in the network.
Now i have problems with 4 devices:
Plug S (PS01) - IP: 10.10.21.9
Plug S (PS04) - IP: 10.10.21.94
H&T (HT09) - IP: 10.10.21.24
H&T (HT03) - IP: 10.10.21.243
PS01 is getting its own channel data
and additionally the data from PS04
Same Issue on HT09, its getting its own data and the data of HT03
Here is an example of the log:
2021-12-15 21:22:38.513 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ht09_Temperatur' changed from 18.3 °C to 22.9 °C
2021-12-15 21:24:44.354 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ht09_Temperatur' changed from 22.9 °C to 18.3 °C
2021-12-15 21:32:47.761 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ht09_Temperatur' changed from 18.3 °C to 23.3 °C
2021-12-15 21:35:23.040 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ht09_Temperatur' changed from 23.3 °C to 18.1 °C
2021-12-15 21:38:01.188 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ht09_Temperatur' changed from 18.1 °C to 22 °C
2021-12-15 21:40:28.482 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ht09_Temperatur' changed from 22 °C to 18.1 °C
2021-12-15 21:43:15.591 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ht09_Temperatur' changed from 18.1 °C to 21.6 °C
2021-12-15 21:45:32.807 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ht09_Temperatur' changed from 21.6 °C to 18.1 °C
2021-12-15 21:48:29.129 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ht09_Temperatur' changed from 18.1 °C to 21.6 °C
2021-12-15 21:53:01.646 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ht09_Temperatur' changed from 21.6 °C to 17.9 °C
2021-12-15 21:53:43.855 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ht09_Temperatur' changed from 17.9 °C to 21.5 °C
The temperature around 18 °C is the value of HT03
The temperature around 22 °C is the value of HT09
2021-12-15 22:21:52.871 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ps01_Leistung' changed from 0 W to 0.83 W
2021-12-15 22:21:53.215 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ps01_Leistung' changed from 0.83 W to 0 W
2021-12-15 22:22:07.859 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ps01_Leistung' changed from 0 W to 0.85 W
2021-12-15 22:22:08.351 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ps01_Leistung' changed from 0.85 W to 0 W
Same here … PS01 has no power usage (nothing connected) and PS04 is using a littlebit more than 0.8W.
After changing the IP of HT09 to 10.10.21.100 the problem stopt for the H&Ts.
Before changing from mcast to ucast, there was no problem with this.
I’ve tested this issue with the stable version of the shelly binding and the 3.2.0.202112131842, the issue persist.
I also tested to swith the both Plug S back to mcast, but it didn’t solved the problem.
Maybe one solution will be to change all shelly devices to ip-addresses higher than 100 … but its no good solution 
I’m not sure of this is a bug or if i’m doing something wrong. Can any one help me please?
Hi all,
first of all merry xmas to you all here. Since a reboot of my PI this morning I all my shelly devices are “uncontrolable” and I get the following message I have never seen before:
shellyswitch25-68c63afb89e6: Unable to initialize CoAP access (network error)
I have already tried to disable CoIoT, but no effect. Does anybody know what this is and how to resolve?
Scuby
restart OH and/or host system
1 Like
Can someone help me?
Hi @markus7017
First I wish you a happy new year!
Why do I get this error
2022-01-01 11:25:13.289 [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 [304]
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]
when I put org.openhab.binding.shelly-3.2.0-SNAPSHOT.jar in the addons folder of the openhab installation?
I want to do this to make a test of my pull request #11918
Many thanks for your help.
Happy new year to everyone!
Does the new .jar works with Plus devices?
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