Shelly Binding

why do you use a reverse proxy?

I’ve setup my 3EM a couple of months ago with the shelly binding. I configured the thing with an updateInterval of 300. This always worked fine, but since a couple of days my items are modified on every change. So this meens, these items are changing non-stop. I already restarted openHAB and updated the firemware of my 3EM (Current version: 20210323-110413/v1.10.1-gf276b51). What else can be wrong? This binding is running on OH 2.5.12.

what does that mean?

try DEV build


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.

I updated the DEV build and keep the warning, but removed disabling CoIoT by default. Maybe there are good reasons for a setup like that (like your’s). You need to update to the latest DEV build.


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.

I installed 2.5.13, but I get the same issue: the updateInterval doesn’t do anything
I even reinstalled openhab completely, so the thing is completely new.

I will test the 3.0 version in my test 3.x setup later today.

Hi Markus,

thanks for the fast reply.

why do you use a reverse proxy?

I have several docker container running on my synology and I found the warnings from the browsers annoying, when going to the pages with http.
Also I found the different ports from the different services annoying.
So I decided to start a container with traefik reverse proxy, so I could reach all services with https (traefik manages the certificates) and on the same port.
The only thing is, that this construct only works with dns-names and not with ip-adresses, when connecting over traefik.

I updated the DEV build and keep the warning, but removed disabling CoIoT by default. Maybe there are good reasons for a setup like that (like your’s). You need to update to the latest DEV build.

Thanks a lot.
I will give it a try at the weekend.

Thomas

In openHAB 3, it’s working fine!.. very strange, because I didn’t changed anything on my 2.5 setup.

I also tried the DEV version first (I want to connect my UNI), but I get an error when putting the .jar file (I first stoped OH, added californium-core-2.0.0 & element-connector-2.0.0 and started OH again without errors):

2021-04-13 17:53:30.296 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/openhab/addons/org.openhab.binding.shelly-3.1.0-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.shelly [291]
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]

My OH3 setup is running on Docker, my 2.5 setup on a Pi.

Hi,
same error here as wars above. I’ve just installed latest SNAPSHOT 3.1.0 build, as I want to use my Shelly UNI. I think I have all needed budles:

240 │ Active    │  80 │ 2.0.0                   │ Californium (Cf) Core
241 │ Active    │  80 │ 2.0.0                   │ Californium (Cf) Element Connector
242 │ Active    │  80 │ 2.0.0                   │ Californium (Cf) OSGi
243 │ Active    │  80 │ 2.0.0                   │ Scandium (Sc) Core
244 │ Installed │  80 │ 3.1.0.202104061052      │ openHAB Add-ons :: Bundles :: Shelly Binding

But start of 244 fails with:

openhab> bundle:start 244
Error executing command: Error executing command on bundles:
        Error starting bundle 244: Could not resolve module: org.openhab.binding.shelly [244]
  Unresolved requirement: Import-Package: org.osgi.framework; version="[1.9.0,2.0.0)"

Previous builds of 3.1.0 was probably ok, but did not backup them.

I think I found out the reasons:

They are working on updating the core components of the framework, in fact Karaf with OSGi. That means even I didn’t changed my code the build environment puts in dependencies on newer component versions than 3.0/3.1M1…3 have. Let me try to work around. Switching back to an older build environment should fix that issue, but I need to think of a proper way to keep backward compatibility. Having 3 versions (2.5.x, 3.0 and 3.1 latest) is no option.

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 :slight_smile:
Cheers!

@Daniel_O @laifrvo Build problem fixed, @wborn :+1:
Please try the updated DEV build

1 Like

Markus, thanks, it seems that new build finally works!