Well, 3.0 build hopefully will not be needed anymore, after OH 3.1 stable release. Till then, temporary building of shelly binding in 3.0.x environment should be solution?
Damn should have come here first. Have the same error as well, after updating a friend’s installation to test issues with another binding. I suspected cache problems and cleaned out all bindings and cache, then added them again. Didn’t help. But if it’s a general 3.1m3 problem, I’ll just wait. Or is there an older version I could fall back to?
try the updated DEV build
Thank you markus, not sure if I got the right one?
I tried the one from the DEV Link in your post above
Here’s the version:
208 │ Installed │ 80 │ 3.1.0.202104061052 │ openHAB Add-ons :: Bundles :: Shelly Binding
209 │ Active │ 80 │ 2.0.0 │ Californium (Cf) Element Connector
210 │ Active │ 80 │ 2.0.0 │ Californium (Cf) Core
Seems to be the some one that Vojtech got.
And here the error log
2021-04-15 22:12:14.593 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/usr/share/openhab/addons/org.openhab.binding.shelly-3.1.0-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.shelly [208]
Unresolved requirement: Import-Package: org.osgi.framework; version="[1.9.0,2.0.0)"
at org.eclipse.osgi.container.Module.start(Module.java:444) ~[org.eclipse.osgi-3.12.100.jar:?]
at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:383) ~[org.eclipse.osgi-3.12.100.jar:?]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [bundleFile:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [bundleFile:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:520) [bundleFile:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [bundleFile:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [bundleFile:3.6.4]
sorry, the push didn’t work
please try again, I just updated the build
Thank you, the push now worked.
208 │ Installed │ 80 │ 3.1.0.202104152130 │ openHAB Add-ons :: Bundles :: Shelly Binding
Error sadly persists:
2021-04-15 23:49:49.207 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/usr/share/openhab/addons/org.openhab.binding.shelly-3.1.0-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.shelly [208]
Unresolved requirement: Import-Package: org.osgi.framework; version="[1.9.0,2.0.0)"
at org.eclipse.osgi.container.Module.start(Module.java:444) ~[org.eclipse.osgi-3.12.100.jar:?]
at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:383) ~[org.eclipse.osgi-3.12.100.jar:?]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [bundleFile:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [bundleFile:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:520) [bundleFile:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [bundleFile:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [bundleFile:3.6.4]
Yes, as Daniel said, still indeed the same error with 3.1.0.202104061052 build of binding.
Just let me add that my version of OH is a stable release build 3.0.1. May be upgrade to 3.1.0.M3 is needed?
Anyone know why the RGBW2 (COLOR MODE) channel description is gone from the official Shelly Binding page on OH website now? I see White mode, but no color mode any longer…
OK, so if i access the site via google i get a different version of the page that doesn’t have RGBW2 color on it: Shelly - Bindings | openHAB
But from my history: Shelly - Bindings | openHAB … it does have RGBW2 on it… (second is v2.openhab… url, first is www.openhab… URL).
Anyway, the reason i was looking for this, i have an RGBW2 in COLOR mode, i have all channels working as expected, EXCEPT the ON/OFF power channel.
{channel=“shelly:shellyrgbw2-color:xxxx:control#power”}
Which is correct as per the “V2” binding page, but nothing happens with that channel. When i send an ON or OFF command, i see in the log:
2021-04-17 21:15:03.752 [ome.event.ItemCommandEvent] - Item 'play_strip_sw' received command ON
2021-04-17 21:15:03.760 [nt.ItemStatePredictedEvent] - play_strip_sw predicted to become NULL
I’m using DEV build 2.5.13 . Any suggests on what i’m doing wrong here 
Cheers!
Markus, thanks, it seems that new build finally works!
Please try the latest DEV build. It should create a channel control#power. Maybe you need to delete and re-discover the thing. Please try first within PaperUI before defining in the .things file.
You should see a message “Switch light xx” (ON/OFF) in the log if you enable DEBUG, You’ll also find the link to the matching README below.
Latest DEV builds: 2.5.13 - 3.1.0 - README - Installation - Avdanced Users - Shelly Manager - Bugs/Features - Firmware Index - Firmware Archive - API Doc
Note: The DEV build is always newer than the version in the official Distro or the Milestone builds (SNAPSHOTs); OH Distro 2.5 will not receive updates anymore, so you have to switch to DEV build when running OH 2.5, see installation notes.
Thank you Markus, this works again
Was having some problems with the motion sensor not responding again, but after a factory reset it seems to work again for now. Since the internal webserver wasn’t reachable either, this has to be something else.
Good morning together,
I tried figuring out my issue by cross reading this thread, but didn’t find a solution yet.
Any quick approach for my issue would be highly appreciated.
Here is my setup:
Raspberry with Openhab 3.
Shelly Binding 3.0.1, yesterday switched to latest DEV 3.1.
Different Shelly’s in use, one of them in detached mode.
Shellys with each newest firmware.
Issue:
I’m using the input#relay or last event channels to control some lights. That was working for me over the last months with small delays (<2sec.).
Since 2 days, the delay until Openhab receives input relay status increased to roughly 10-20 seconds.
No changes to the setup were made.
I yesterday tried to install the DEV built and I factory reset yes the Shelly 1. I ensured coloT with mcast being activated.
Autodiscovery doesn’t work, shellys are recognized by manual adding over IP.
The delay remains after installing new binding and factory reset.
Any idea what to try next?
Might there be some data to delete on the raspberry (cache files,…) from the binding?
Controlling the shellys over Openhab works flawlessly and with no delay.
Highly appreciate your answers,
Best wishes, Christian
I’m having the same issue as Christian, my config:
- Raspberry Pi 3 with Debian Buster
- Openhabian / Openhab 3.01
- Shelly binding version 3.1.0.202104211647
- same delay issue on a Shelly i3 with firmware version 1.9.4: it takes about 20-40 seconds to get the updated status in Openhab while on the Shelly site, the update is shown instantly.
I didn’t see anything specific in the logs in DEBUG mode.
Thanks,
Mario.
Hi Mario,
I now somehow got it fixed.
I remember that I deactivated and activated CoIoT several times in the Shelly interface. Additionally I set a device name and enabled the discoverable option. Now at least for the moment I get immediate response within Openhab.
I’ll try the same with my Shelly i3 tomorrow and let you know whether I also got it fixed.
you could use Shelly Manager (see README on how to launch) and check if the binding is receiving CoIoT messages, these is also an action to switch btw CoIoT Multicast and Peer mode
- if this is a binding problem the delay should be around 1 minute (standard polling interval)
- you could use Shelly Manager to check CoIoT statistics (righzt columns)
- make sure CoIoT is enabled in the device settings (Web UI), maybe switch it off and on
- Multicast CoIoT is supported if the network layer is transparent, if you have multiple network segments usually CoIoT doesn’t work without special setup. In this case use CoIoT peer mode and enter the IP of the OH host (no port address!)
- if the problem persists I need a DEBUG or TRACE log
Hi Markus,
In the Shelly Manager I do see 613 ColoT messages and counting up. I’ve made a trace after changing log:set TRACE. The very first event is where I trigger an event which changes the output of a lamp “zet lamp uit”. At the very same moment, my son changed the state of the Shelly i3 which also changes the state of that lamp: “zet lamp aan” (=last event), but only 21seconds later. I filtered out the lines from other Shelly devices (such as the Vintage lamp).
2021-04-24 14:44:03.795 [INFO ] [org.openhab.core.model.script.Switch] - zet lamp uit
2021-04-24 14:44:24.867 [TRACE] [y.internal.handler.ShellyBaseHandler] - shellyix3-8caab542bab7: Updating status (refreshSettings=false)
2021-04-24 14:44:24.870 [TRACE] [ng.shelly.internal.api.ShellyHttpApi] - shellyix3-8caab542bab7: HTTP GET for http://192.168.1.235/status
2021-04-24 14:44:24.929 [TRACE] [ng.shelly.internal.api.ShellyHttpApi] - shellyix3-8caab542bab7: HTTP Response 200: {“wifi_sta”:{“connected”:true,“ssid”:“Mbr”,“ip”:“192.168.1.235”,“rssi”:-70},“cloud”:{“enabled”:false,“connected”:false},“mqtt”:{“connected”:false},“time”:“14:44”,“unixtime”:1619268265,“serial”:32,“has_update”:true,“mac”:“8CAAB542BAB7”,“cfg_changed_cnt”:2,“actions_stats”:{“skipped”:0},“inputs”:[{“input”:0,“event”:“”,“event_cnt”:0},{“input”:0,“event”:“”,“event_cnt”:0},{“input”:0,“event”:“”,“event_cnt”:0}],“temperature_status”:“Normal”,“update”:{“status”:“pending”,“has_update”:true,“new_version”:“20210413-154502/v1.10.2-gb89901a”,“old_version”:“20210115-104138/v1.9.4@e2732e05”},“ram_total”:51272,“ram_free”:39860,“fs_size”:233681,“fs_free”:151855,“uptime”:143018}
2021-04-24 14:44:24.934 [DEBUG] [lly.internal.util.ShellyChannelCache] - shellyix3-8caab542bab7: Channel device#heartBeat updated with 2021-04-24T14:44:24.000+0200 (type class org.openhab.core.library.types.DateTimeType).
2021-04-24 14:44:24.937 [TRACE] [y.internal.handler.ShellyBaseHandler] - shellyix3-8caab542bab7: Watchdog restarted (expires in 70 sec)
2021-04-24 14:44:24.946 [DEBUG] [lly.internal.util.ShellyChannelCache] - shellyix3-8caab542bab7: Channel device#uptime updated with 143018 s (type class org.openhab.core.library.types.QuantityType).
2021-04-24 14:44:24.951 [DEBUG] [lly.internal.util.ShellyChannelCache] - shellyix3-8caab542bab7: Channel device#wifiSignal updated with 2 (type class org.openhab.core.library.types.DecimalType).
2021-04-24 14:44:24.957 [DEBUG] [lly.internal.util.ShellyChannelCache] - shellyix3-8caab542bab7: Channel status1#input updated with OFF (type class org.openhab.core.library.types.OnOffType).
2021-04-24 14:44:24.961 [TRACE] [y.internal.handler.ShellyBaseHandler] - shellyix3-8caab542bab7: Watchdog restarted (expires in 70 sec)
2021-04-24 14:44:24.988 [INFO ] [org.openhab.core.model.script.Switch] - zet lamp aan
I hope this trace reveals something.
PS: on the device website itself I didn’t find any way to change ColoT setting, I guess it’s only in Openhab (AutoColoT enabled) and in the Thing:
Thanks,
Mario.
