@DileRGorE@Oliver2
please try the DEV build, as you know I made a change that button events are not filtered in detached mode. I’m not sure which code base was merged into 3.1M3
@Polo or @Tomibeck I started working on this. It’s included in the DEV build, waiting on feedback.
I am interested to help developing this add on. For me it’s working with one sensor, but with two it gives same readings.
70 year old beginner, slow learner. Don’t blame me
I’ve a problem with the shelly binding, so I created a new topic in den binding-section, but after reading this thread, I thing it should be better placed in this thread.
I would like to configure CoIoT Unicast, but I get the following message “CoIoT peer in device settings does not point this to this host, disabling CoIoT”, because I run openHAB in docker container behind 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.
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.
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.
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.
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.
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?
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]
