The question is whether there is at all a need to port the persistence service to OH2. So far, there hasn’t been any changes in the persistence APIs (besides the namespace change), this is something that might come in the future. For the moment, it should be perfectly fine to use the 1.x DBMS bundle on OH2 with the compat layer. The benefit of this is that there is no code duplication, i.e. you can continue to maintain the code at 1.x and it will be available directly for both OH versions.
I have been using these by ‘just’ copying over my OH1 openhab.cfg file.
While there is a v2 version of the Astro binding available, it doesn’t support events, unfortunately, which is why I had to revert to using the OH1 version. Having said that, it does work without issues.
I have not yet been able to pull requests for these, as my time is limited. If I get a chance to set up the new development environment, I’ll try to submit the PRs.
With regards to old vs. new Astro binding: You are right, it would be nice to also be able to use the old one. With the current packaging, it is not easily possible to include both, but for the upcoming new Karaf-based distribution, I have already included it.
Hi Kai,
I did some tests of Satel binding recently and in general it works well. However there are some minor issues with items that are added after connection to the alarm system has been established. In most cases this is not an issue, but for items that change very rarely it is. I am working currently on a solution and after that I will add Satel binding to the list.
at least in my case AVM Fritzbox bindings are not working at all. Maybe I miss something in the way of setup. But OH2 doesn’t seem to “search” for them (I have two 7390 boxes installed). I checked with the new addon provided with Alpha2 package and as well imported the addon from 1.7 addon package.
@avdleeuw Mind that the Astro 1.8 binding relies on Timer threads, these are removed in the 2.0 binding. Just for our information, can you telnet into your OH2 runtime and issue a “t | grep Timer” command and provide an indication of how many Timer threads you have in your runtime?
Pretty much a newbie here, some coding experience. Played around with OH1 for a couple of days, decided my time would be better spent on OH2. Got my OH2 IDE all setup. All my devices are Insteon and Z-Wave, only been working with the Insteon so far. With the IDE, I imported the 1.x Insteon PLM add-on, got it working with the Classic UI. I see it’s already listed as tested, so here is the question: What has to happen to make it 2.0? Is that something I can help with?
Nothing has to happen really. A 1.x binding is absolutely fine to use with the new 2.x runtime and these bindings will be further maintained and supported. There is no need at all to port them to the new 2.0 binding APIs. This can happen at a later stage for bindings, where discovery is very helpful and devices can be easily formally described. Therefore testing the 1.x binding as you did is all I am asking for right now!
Sounds great @Lolodomo!
Please note that with the new openHAB 2 beta release, the way of confirming that a binding is working has changed - there is no need to leave the openHAB 1 repo at all, instead you can do a PR similar to this one: https://github.com/openhab/openhab/pull/3720/files
Add-ons that are added this way to openHAB 1 will automatically picked up by the distribution build and thus be available in the official packaging!
I tried Freebox binding 2.0 in openHAB2 beta 1 and it does not work. When I add manually a thing, I get this error:
01:07:13.504 [ERROR] [ome.core.thing.internal.ThingManager] - Exception occured while calling thing handler factory 'org.openhab.binding.freebox.internal.FreeboxHandlerFactory@15a32b6': javax/net/ssl/HostnameVerifier
java.lang.NoClassDefFoundError: javax/net/ssl/HostnameVerifier
at java.lang.ClassLoader.defineClass1(Native Method)[:1.8.0]
at java.lang.ClassLoader.defineClass(ClassLoader.java:760)[:1.8.0]
at org.eclipse.osgi.internal.loader.ModuleClassLoader.defineClass(ModuleClassLoader.java:272)
at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.defineClass(ClasspathManager.java:632)
at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findClassImpl(ClasspathManager.java:588)
at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findLocalClassImpl(ClasspathManager.java:540)
at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findLocalClass(ClasspathManager.java:527)
at org.eclipse.osgi.internal.loader.ModuleClassLoader.findLocalClass(ModuleClassLoader.java:324)
at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:320)
at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:395)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:345)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:337)
at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:160)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)[:1.8.0]
at org.apache.http.impl.client.HttpClientBuilder.build(HttpClientBuilder.java:709)
at org.matmaul.freeboxos.internal.RestManager.<init>(RestManager.java:59)
at org.matmaul.freeboxos.FreeboxOsClient.<init>(FreeboxOsClient.java:52)
at org.openhab.binding.freebox.handler.FreeboxHandler.authorize(FreeboxHandler.java:97)
at org.openhab.binding.freebox.handler.FreeboxHandler.initialize(FreeboxHandler.java:145)
at org.eclipse.smarthome.core.thing.binding.BaseThingHandlerFactory.registerHandler(BaseThingHandlerFactory.java:130)
at org.eclipse.smarthome.core.thing.internal.ThingManager$6.call(ThingManager.java:507)
at org.eclipse.smarthome.core.thing.internal.ThingManager$6.call(ThingManager.java:1)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0]
at java.lang.Thread.run(Thread.java:744)[:1.8.0]
Caused by: java.lang.ClassNotFoundException: javax.net.ssl.HostnameVerifier cannot be found by org.openhab.binding.freebox_2.0.0.b1
Trying to remove the thing caused another exception:
java.lang.NullPointerException
at org.eclipse.smarthome.core.thing.internal.ThingManager$1.statusUpdated(ThingManager.java:186)
at org.eclipse.smarthome.core.thing.internal.ThingManager.thingRemoving(ThingManager.java:388)
at org.eclipse.smarthome.core.thing.internal.ThingRegistryImpl.notifyTrackers(ThingRegistryImpl.java:209)
at org.eclipse.smarthome.core.thing.internal.ThingRegistryImpl.remove(ThingRegistryImpl.java:105)
at org.eclipse.smarthome.core.thing.setup.ThingSetupManager.removeThing(ThingSetupManager.java:434)
at org.eclipse.smarthome.io.rest.core.thing.setup.ThingSetupManagerResource.removeThing(ThingSetupManagerResource.java:158)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)[:1.8.0]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)[:1.8.0]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.8.0]
at java.lang.reflect.Method.invoke(Method.java:483)[:1.8.0]
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)[10:com.eclipsesource.jaxrs.jersey-min:2.22.1]
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:144)[10:com.eclipsesource.jaxrs.jersey-min:2.22.1]
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:161)[10:com.eclipsesource.jaxrs.jersey-min:2.22.1]
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:160)[10:com.eclipsesource.jaxrs.jersey-min:2.22.1]
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:99)[10:com.eclipsesource.jaxrs.jersey-min:2.22.1]
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:389)[10:com.eclipsesource.jaxrs.jersey-min:2.22.1]
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:347)[10:com.eclipsesource.jaxrs.jersey-min:2.22.1]
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:102)[10:com.eclipsesource.jaxrs.jersey-min:2.22.1]
at org.glassfish.jersey.server.ServerRuntime$2.run(ServerRuntime.java:326)[10:com.eclipsesource.jaxrs.jersey-min:2.22.1]
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)[10:com.eclipsesource.jaxrs.jersey-min:2.22.1]
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)[10:com.eclipsesource.jaxrs.jersey-min:2.22.1]
at org.glassfish.jersey.internal.Errors.process(Errors.java:315)[10:com.eclipsesource.jaxrs.jersey-min:2.22.1]
at org.glassfish.jersey.internal.Errors.process(Errors.java:297)[10:com.eclipsesource.jaxrs.jersey-min:2.22.1]
at org.glassfish.jersey.internal.Errors.process(Errors.java:267)[10:com.eclipsesource.jaxrs.jersey-min:2.22.1]
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)[10:com.eclipsesource.jaxrs.jersey-min:2.22.1]
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:305)[10:com.eclipsesource.jaxrs.jersey-min:2.22.1]
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1154)[10:com.eclipsesource.jaxrs.jersey-min:2.22.1]
at org.glassfish.jersey.servlet.WebComponent.serviceImpl(WebComponent.java:471)[10:com.eclipsesource.jaxrs.jersey-min:2.22.1]
at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:425)[10:com.eclipsesource.jaxrs.jersey-min:2.22.1]
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:383)[10:com.eclipsesource.jaxrs.jersey-min:2.22.1]
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:336)[10:com.eclipsesource.jaxrs.jersey-min:2.22.1]
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:223)[10:com.eclipsesource.jaxrs.jersey-min:2.22.1]
at com.eclipsesource.jaxrs.publisher.internal.ServletContainerBridge.service(ServletContainerBridge.java:76)[12:com.eclipsesource.jaxrs.publisher:5.3.0.201512270850]
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:808)[71:org.eclipse.jetty.servlet:9.2.10.v20150310]
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:587)[71:org.eclipse.jetty.servlet:9.2.10.v20150310]
at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:70)[135:org.ops4j.pax.web.pax-web-jetty:4.2.3]
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)[70:org.eclipse.jetty.server:9.2.10.v20150310]
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)[69:org.eclipse.jetty.security:9.2.10.v20150310]
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)[70:org.eclipse.jetty.server:9.2.10.v20150310]
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)[70:org.eclipse.jetty.server:9.2.10.v20150310]
at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:271)[135:org.ops4j.pax.web.pax-web-jetty:4.2.3]
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)[71:org.eclipse.jetty.servlet:9.2.10.v20150310]
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)[70:org.eclipse.jetty.server:9.2.10.v20150310]
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)[70:org.eclipse.jetty.server:9.2.10.v20150310]
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)[70:org.eclipse.jetty.server:9.2.10.v20150310]
at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:80)[135:org.ops4j.pax.web.pax-web-jetty:4.2.3]
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)[70:org.eclipse.jetty.server:9.2.10.v20150310]
at org.eclipse.jetty.server.Server.handle(Server.java:497)[70:org.eclipse.jetty.server:9.2.10.v20150310]
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)[70:org.eclipse.jetty.server:9.2.10.v20150310]
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)[70:org.eclipse.jetty.server:9.2.10.v20150310]
at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)[62:org.eclipse.jetty.io:9.2.10.v20150310]
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)[73:org.eclipse.jetty.util:9.2.10.v20150310]
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)[73:org.eclipse.jetty.util:9.2.10.v20150310]
at java.lang.Thread.run(Thread.java:744)[:1.8.0]
When I tried with the 1.8 version of the Freebox binding, here is the error I get at startup:
00:53:35.382 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/home/pi/openhab/addons/org.openhab.binding.freebox-1.8.0.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.freebox [159]
Unresolved requirement: Import-Package: org.openhab.core.binding
at org.eclipse.osgi.container.Module.start(Module.java:434)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:393)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1245)[8:org.apache.felix.fileinstall:3.5.0]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1217)[8:org.apache.felix.fileinstall:3.5.0]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startAllBundles(DirectoryWatcher.java:1207)[8:org.apache.felix.fileinstall:3.5.0]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:504)[8:org.apache.felix.fileinstall:3.5.0]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:358)[8:org.apache.felix.fileinstall:3.5.0]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:310)[8:org.apache.felix.fileinstall:3.5.0]
After creating a RFXCOM bridge thing manually with the Paper UI (automatic discovery was finding nothing) and then restart OH2, I get this exception in the logs:
Exception in thread "Thread-38" java.lang.NoClassDefFoundError: javax/xml/bind/DatatypeConverter
at org.openhab.binding.rfxcom.internal.connector.RFXComSerialConnector$SerialReader.run(RFXComSerialConnector.java:178)
Caused by: java.lang.ClassNotFoundException: javax.xml.bind.DatatypeConverter cannot be found by org.openhab.binding.rfxcom_2.0.0.b1
at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:432)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:345)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:337)
at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:160)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 1 more
Weather binding 1.8 not working => issue created
Mios binding 1.8 not working => issue created
Netatmo binding 1.8 not working => issue created
RFXCOM 2.0 not working even with the last distro snapshot => issue created
I will test the fix for Freebox binding 2.0 when a new snapshot including this fix is available.
After testing several 1.8 bindings, it looks like there is a general problem with 1.x binding compatibility in openHAB2.
The error is always the same, something like:
org.osgi.framework.BundleException: Could not resolve module: xxxxxxxxxx
Unresolved requirement: Import-Package: xxxxxxx
This prevents the bundle to be started.
In case it can be solved without fixing the 1.x binding themselves, I think that could be a real good idea to put all 1.8 bindings in the addons sub-directory and then start openHAB2 to see what are the ones not starting due to unresolved requirements. This would require someone who knows how to fix that.
Then, when at least the 1.x bindings are starting, we could continue to test binding per binding and provide detailed feedback.
Sounds like a good plan. As the fix is very simple, it would be great if you could simply send PRs instead of only entering issues. This way we can very quickly resolve the import-package problems and see what else might be in the way.
