Diverse connection problems on Karaf-based runtime

[openhab]

Diverse connection problems on Karaf-based runtime

[maggu2810]

I assume this one looks better 😉

15:45:39.049 [INFO ] [ng.zwave.internal.ZWaveActiveBinding] - Update config, port = /dev/ttyUSB0
15:45:39.052 [INFO ] [b.core.service.AbstractActiveService] - ZWave Refresh Service has been started
15:45:39.063 [INFO ] [ve.internal.protocol.ZWaveController] - Starting Z-Wave controller
15:45:39.063 [INFO ] [ve.internal.protocol.ZWaveController] - Z-Wave timeout is set to 5000ms. Soft reset is false.
15:45:39.063 [INFO ] [ve.internal.protocol.ZWaveController] - Connecting to serial port /dev/ttyUSB0
15:45:39.077 [INFO ] [ve.internal.protocol.ZWaveController] - Serial port is initialized
15:45:42.170 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 1: Node found
15:45:42.171 [INFO ] [age.SerialApiGetInitDataMessageClass] - ZWave Controller using Controller API
15:45:42.171 [INFO ] [age.SerialApiGetInitDataMessageClass] - ZWave Controller is Primary Controller
15:45:42.171 [INFO ] [age.SerialApiGetInitDataMessageClass] - ------------Number of Nodes Found Registered to ZWave Controller------------
15:45:42.172 [INFO ] [age.SerialApiGetInitDataMessageClass] - # Nodes = 1
15:45:42.172 [INFO ] [age.SerialApiGetInitDataMessageClass] - ----------------------------------------------------------------------------

diff --git a/bundles/binding/org.openhab.binding.zwave/OSGI-INF/activebinding.xml b/bundles/binding/org.openhab.binding.zwave/OSGI-INF/activebinding.xml
index 1716bf3..a37e144 100644
--- a/bundles/binding/org.openhab.binding.zwave/OSGI-INF/activebinding.xml
+++ b/bundles/binding/org.openhab.binding.zwave/OSGI-INF/activebinding.xml
@@ -9,7 +9,7 @@
     http://www.eclipse.org/legal/epl-v10.html

 -->
-<scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0" activate="activate" deactivate="deactivate" name="org.openhab.binding.zwave.activebinding">
+<scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0" activate="activate" deactivate="deactivate" immediate="true" name="org.openhab.binding.zwave.activebinding">
    <implementation class="org.openhab.binding.zwave.internal.ZWaveActiveBinding"/>

    <service>
diff --git a/bundles/binding/org.openhab.binding.zwave/OSGI-INF/genericbindingprovider.xml b/bundles/binding/org.openhab.binding.zwave/OSGI-INF/genericbindingprovider.xml
index 4568107..e926210 100644
--- a/bundles/binding/org.openhab.binding.zwave/OSGI-INF/genericbindingprovider.xml
+++ b/bundles/binding/org.openhab.binding.zwave/OSGI-INF/genericbindingprovider.xml
@@ -9,7 +9,7 @@
     http://www.eclipse.org/legal/epl-v10.html

 -->
-<scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0" name="org.openhab.binding.zwave.genericbindingprovider">
+<scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0" immediate="true" name="org.openhab.binding.zwave.genericbindingprovider">
    <implementation class="org.openhab.binding.zwave.internal.ZWaveGenericBindingProvider"/>
    <service>
       <provide interface="org.openhab.model.item.binding.BindingConfigReader"/>
diff --git a/bundles/binding/org.openhab.binding.zwave/OSGI-INF/openhabconfiguration.xml b/bundles/binding/org.openhab.binding.zwave/OSGI-INF/openhabconfiguration.xml
index 93bc660..82acdf8 100644
--- a/bundles/binding/org.openhab.binding.zwave/OSGI-INF/openhabconfiguration.xml
+++ b/bundles/binding/org.openhab.binding.zwave/OSGI-INF/openhabconfiguration.xml
@@ -9,7 +9,7 @@
     http://www.eclipse.org/legal/epl-v10.html

 -->
-<scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0" name="org.openhab.binding.zwave.configuration">
+<scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0" immediate="true" name="org.openhab.binding.zwave.configuration">
    <implementation class="org.openhab.binding.zwave.internal.config.ZWaveConfiguration"/>

 <!--   <property name="openhabconfig.bundle" type="String" value="org.openhab.binding.zwave"/>

[maggu2810]

As you stated in #96 immediate have to be set to true.
If immediate is not set to true, so service is not started if it is not required by any other service (as you know).

[kaikreuzer]

Looks indeed much better (@cdjackson: FYI!).
But know this brings up the same question as in #85:
Shall we accept that the currently existing add-ons are all broken and we need to come up with fixes and new 1.9 versions of them or shall we make the DS mechanism work the same way as before?
Do you know the exact reason for the difference? Is it Equinox DS vs. Felix SCR or is it merely a different configuration option?

[maggu2810]

OSGi Compendium 5.0.0
112.2.3
Delayed Component
A delayed component specifies a service, is not specified to be a factory component and does not have the immediate attribute of the component element set to true. If a delayed component configuration is satisfied, SCR must register the component configuration as a service in the service registry but the activation of the component configuration is delayed until the registered service is requested. The registered service of a delayed component looks like a normal registered service but does not incur the overhead of an ordinarily registered service that require a service’s bundle to be initialized to register the service.

[maggu2810]

If I read this correctly "the activation of the component configuration is delayed until the registered service is requested" I would say, that the activation should not be done and if this is done, the DS implementation is not compliant with the spec.

[maggu2810]

I don't know if there is a configuration parameter that all delayed components are interpret as immediate components.

[maggu2810]

The org.eclipse.equinox.ds bundle of the target platform seems to be not the newest one (1.4.200.v20131126-2331) have to look at the compendium spec this implementation is using.

[kaikreuzer]

I just tried the immediate=true on KNX, but at startup I now have 3 calls to KNXConnection.setProcessListener - I can imagine that the binding isn't too happy about that and runs into problems...

[maggu2810]

I have no KNX hardware at home, so I assume I cannot test this one.

[kaikreuzer]

But you have seen the same effect on other components already - they are started multiple times at system startup. This is definitely something that needs to be solved... Will try to find the reason in this specific case (but I actually think you do not need any KNX hardware for testing, you only have to start the bundle).

[maggu2810]

I am not an OSGi expert but perhaps the configuration admin triggers the activation of the component once. After that the component is no longer required and get's deactivated.
If immediate is set to true, it keeps activated.

Sure, I have seen this a long time ago (you solved that for me as I run the first time into it), but I never complained that a non-immediate component gets deactivated.

I see that this is a problem now, as the most bundles does not declare themselves to be an immediate one. I just want to help you to find the reasons for the error.

[kaikreuzer]

Regarding your ZWave fix: I actually do not understand, why the immediate should be necessary there:

• activebinding.xml provides ManagedService and thus should be activated by CM once config is distributed
• genericbindingprovider.xml: provides BindingConfigReader and is thus also used as a service and should thus be started up
• openhabconfiguration.xml: afaik, only required for HABmin and not relevant here

[maggu2810]

I added it to all of three to see if this changes something at all. Perhaps it is not need for all / just for one.

Does what you stated about the activebinding.xml fit to my previous post?
The CM triggers the activation, but as long as the service is now not needed by any one, it get's deactivated again.
Do you think that could be correct?

[kaikreuzer]

Don't know, will have to investigate further

If immediate is set to true, it keeps activated.

No, my observation of the 3 calls in KNX to the same setter of a component was AFTER setting immediate to true. So it might rather

• start immediate
• get a configuration and hence restart
• get new optional services and restart again

Something like this...

[kaikreuzer]

Some interesting stack which I caught when shutting down the runtime:

"Framework stop" #2366 daemon prio=5 os_prio=31 tid=0x00007ff213554800 nid=0xa607 at breakpoint[0x000070000393b000]
   java.lang.Thread.State: RUNNABLE
    at org.openhab.binding.knx.internal.connection.KNXConnection.setProcessListener(KNXConnection.java:138)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:497)
    at org.apache.felix.scr.impl.helper.BaseMethod.invokeMethod(BaseMethod.java:222)
    at org.apache.felix.scr.impl.helper.BaseMethod.access$500(BaseMethod.java:37)
    at org.apache.felix.scr.impl.helper.BaseMethod$Resolved.invoke(BaseMethod.java:615)
    at org.apache.felix.scr.impl.helper.BaseMethod.invoke(BaseMethod.java:499)
    at org.apache.felix.scr.impl.helper.BindMethod.invoke(BindMethod.java:41)
    at org.apache.felix.scr.impl.manager.DependencyManager.doInvokeBindMethod(DependencyManager.java:1660)
    at org.apache.felix.scr.impl.manager.DependencyManager.invokeBindMethod(DependencyManager.java:1636)
    at org.apache.felix.scr.impl.manager.SingleComponentManager.invokeBindMethod(SingleComponentManager.java:370)
    at org.apache.felix.scr.impl.manager.DependencyManager$SingleDynamicCustomizer.removedService(DependencyManager.java:819)
    at org.apache.felix.scr.impl.manager.DependencyManager$SingleDynamicCustomizer.removedService(DependencyManager.java:700)
    at org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:1241)
    at org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:1136)
    at org.apache.felix.scr.impl.manager.ServiceTracker$AbstractTracked.untrack(ServiceTracker.java:996)
    at org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:1175)
    at org.apache.felix.scr.impl.BundleComponentActivator$ListenerInfo.serviceChanged(BundleComponentActivator.java:120)
    at org.eclipse.osgi.internal.serviceregistry.FilteredServiceListener.serviceChanged(FilteredServiceListener.java:109)
    at org.eclipse.osgi.internal.framework.BundleContextImpl.dispatchEvent(BundleContextImpl.java:914)
    at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
    at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148)
    at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEventPrivileged(ServiceRegistry.java:862)
    at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEvent(ServiceRegistry.java:801)
    at org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:222)
    at org.apache.felix.scr.impl.manager.AbstractComponentManager$3.unregister(AbstractComponentManager.java:883)
    at org.apache.felix.scr.impl.manager.AbstractComponentManager$3.unregister(AbstractComponentManager.java:857)
    at org.apache.felix.scr.impl.manager.RegistrationManager.changeRegistration(RegistrationManager.java:140)
    at org.apache.felix.scr.impl.manager.AbstractComponentManager.unregisterService(AbstractComponentManager.java:925)
    at org.apache.felix.scr.impl.manager.AbstractComponentManager.doDeactivate(AbstractComponentManager.java:774)
    at org.apache.felix.scr.impl.manager.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:757)
    at org.apache.felix.scr.impl.manager.AbstractComponentManager.dispose(AbstractComponentManager.java:550)
    at org.apache.felix.scr.impl.config.ConfigurableComponentHolder.disposeComponents(ConfigurableComponentHolder.java:725)
    at org.apache.felix.scr.impl.BundleComponentActivator.dispose(BundleComponentActivator.java:530)
    at org.apache.felix.scr.impl.Activator.disposeComponents(Activator.java:414)
    at org.apache.felix.scr.impl.Activator.access$300(Activator.java:53)
    at org.apache.felix.scr.impl.Activator$ScrExtension.destroy(Activator.java:273)
    at org.apache.felix.utils.extender.AbstractExtender$2.run(AbstractExtender.java:290)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at org.apache.felix.utils.extender.AbstractExtender.destroyExtension(AbstractExtender.java:312)
    at org.apache.felix.utils.extender.AbstractExtender.bundleChanged(AbstractExtender.java:186)
    at org.eclipse.osgi.internal.framework.BundleContextImpl.dispatchEvent(BundleContextImpl.java:902)
    at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
    at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148)
    at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEventPrivileged(EquinoxEventPublisher.java:165)
    at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:75)
    at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:67)
    at org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor.publishModuleEvent(EquinoxContainerAdaptor.java:102)
    at org.eclipse.osgi.container.Module.publishEvent(Module.java:466)
    at org.eclipse.osgi.container.Module.doStop(Module.java:624)
    at org.eclipse.osgi.container.Module.stop(Module.java:488)
    at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.decStartLevel(ModuleContainer.java:1623)
    at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1542)
    - locked <0x00000007b07a0970> (a java.lang.Object)
    at org.eclipse.osgi.container.SystemModule.stopWorker(SystemModule.java:248)
    at org.eclipse.osgi.internal.framework.EquinoxBundle$SystemBundle$EquinoxSystemModule.stopWorker(EquinoxBundle.java:145)
    at org.eclipse.osgi.container.Module.doStop(Module.java:626)
    at org.eclipse.osgi.container.Module.stop(Module.java:488)
    at org.eclipse.osgi.container.SystemModule.stop(SystemModule.java:186)
    at org.eclipse.osgi.internal.framework.EquinoxBundle$SystemBundle$EquinoxSystemModule$1.run(EquinoxBundle.java:160)
    at java.lang.Thread.run(Thread.java:745)

The bundle event is about the knx binding bundle - it hence tries to do org.apache.felix.scr.impl.Activator.disposeComponents. So far so good. But why on earth does this result in a call to a setter method of my component? One thought was that FelixSCR might set it to null before deactivating the component, but the passed parameter is not null, but a valid instance...

[maggu2810]

The knx.config DS is the only one that only provides CM and nothing else.

166 |             | org.openhab.binding.knx.config
167 | ACTIVE      | org.openhab.binding.knx
168 | ACTIVE      | org.openhab.binding.knx.typemapper
169 | ACTIVE      | org.openhab.binding.knx.genericbindingprovider

After setting this one to immediate, all are active

170 | ACTIVE      | org.openhab.binding.knx.config
171 | ACTIVE      | org.openhab.binding.knx
172 | ACTIVE      | org.openhab.binding.knx.typemapper
173 | ACTIVE      | org.openhab.binding.knx.genericbindingprovider

But I still don't know, how I can test this binding without hardware.
Could you give me some instructions?

[maggu2810]

If I set ip=127.0.0.1 I get this one (it is clear that establish connection failed)...

17:37:42.373 [DEBUG] [org.openhab.binding.knx             ] - BundleEvent UNRESOLVED - org.openhab.binding.knx
17:37:42.375 [DEBUG] [org.openhab.binding.knx             ] - BundleEvent UPDATED - org.openhab.binding.knx
17:37:42.398 [DEBUG] [org.openhab.binding.knx             ] - BundleEvent RESOLVED - org.openhab.binding.knx
17:37:42.406 [DEBUG] [org.openhab.binding.knx             ] - BundleEvent STARTING - org.openhab.binding.knx
17:37:42.409 [DEBUG] [ab.binding.knx.internal.KNXActivator] - KNX binding has been started.
17:37:42.411 [DEBUG] [org.openhab.binding.knx             ] - BundleEvent STARTED - org.openhab.binding.knx
17:37:42.416 [DEBUG] [org.openhab.binding.knx             ] - ServiceEvent REGISTERED - {org.openhab.binding.knx.config.KNXTypeMapper}={component.name=org.openhab.binding.knx.typemapper, component.id=176, service.id=291, service.bundleid=155, service.scope=bundle} - org.openhab.binding.knx
17:37:42.441 [DEBUG] [org.openhab.binding.knx             ] - ServiceEvent REGISTERED - {org.openhab.model.item.binding.BindingConfigReader, org.openhab.binding.knx.config.KNXBindingProvider}={component.name=org.openhab.binding.knx.genericbindingprovider, component.id=177, service.id=292, service.bundleid=155, service.scope=bundle} - org.openhab.binding.knx
17:37:42.442 [DEBUG] [org.openhab.binding.knx             ] - ServiceEvent REGISTERED - {org.osgi.service.event.EventHandler, tuwien.auto.calimero.process.ProcessListener}={event.topics=openhab/*, component.name=org.openhab.binding.knx, component.id=175, service.id=294, service.bundleid=155, service.scope=bundle} - org.openhab.binding.knx
17:37:42.446 [TRACE] [.binding.knx.internal.bus.KNXBinding] - allBindingsChanged() msg received.
17:37:42.447 [DEBUG] [.binding.knx.internal.bus.KNXBinding] - Calimero library version 2.2.0-alpha
17:37:42.448 [TRACE] [.binding.knx.internal.bus.KNXBinding] - KNXBinding: activating
17:37:42.450 [TRACE] [x.internal.bus.KNXBusReaderScheduler] - Starting auto refresh scheduler
17:37:42.450 [DEBUG] [x.internal.bus.KNXBusReaderScheduler] - Starting reader task.
17:37:42.451 [DEBUG] [x.internal.bus.KNXBusReaderScheduler] - Starting schedule executor.
17:37:42.451 [DEBUG] [al.bus.KNXBindingDatapointReaderTask] - Autorefresh: Waiting for new item in reader queue
17:37:42.453 [TRACE] [.binding.knx.internal.bus.KNXBinding] - KNXBinding: deactivating
17:37:42.453 [TRACE] [x.internal.bus.KNXBusReaderScheduler] - Stopping auto refresh scheduler
17:37:42.453 [TRACE] [x.internal.bus.KNXBusReaderScheduler] - Clearing all items from the refresher queue
17:37:42.453 [DEBUG] [x.internal.bus.KNXBusReaderScheduler] - Terminating schedule executor.
17:37:42.453 [DEBUG] [x.internal.bus.KNXBusReaderScheduler] - Auto refresh scheduler successfully terminated
17:37:42.453 [TRACE] [x.internal.bus.KNXBusReaderScheduler] - Stopping reader task
17:37:42.456 [DEBUG] [org.openhab.binding.knx             ] - ServiceEvent REGISTERED - {org.osgi.service.cm.ManagedService}={service.pid=org.openhab.knx, component.name=org.openhab.binding.knx.config, component.id=174, service.id=295, service.bundleid=155, service.scope=bundle} - org.openhab.binding.knx
17:37:42.456 [TRACE] [.binding.knx.internal.bus.KNXBinding] - allBindingsChanged() msg received.
17:37:42.456 [DEBUG] [.binding.knx.internal.bus.KNXBinding] - Calimero library version 2.2.0-alpha
17:37:42.456 [TRACE] [.binding.knx.internal.bus.KNXBinding] - KNXBinding: activating
17:37:42.457 [TRACE] [x.internal.bus.KNXBusReaderScheduler] - Starting auto refresh scheduler
17:37:42.457 [DEBUG] [x.internal.bus.KNXBusReaderScheduler] - Starting reader task.
17:37:42.457 [DEBUG] [al.bus.KNXBindingDatapointReaderTask] - Autorefresh: DatapointReaderTask wait on blockingqueue interrupted: null
17:37:42.457 [DEBUG] [al.bus.KNXBindingDatapointReaderTask] - Autorefresh: DatapointReaderTask interrupted.
17:37:42.460 [DEBUG] [al.bus.KNXBindingDatapointReaderTask] - Autorefresh: Waiting for new item in reader queue
17:37:42.461 [DEBUG] [x.internal.bus.KNXBusReaderScheduler] - Starting schedule executor.
17:37:42.462 [DEBUG] [nx.internal.connection.KNXConnection] - KNXBinding configuration present. Setting up KNX bus connection.
17:37:42.463 [DEBUG] [nx.internal.connection.KNXConnection] - Not connected yet. Trying to connect.
17:37:52.491 [ERROR] [tuwien.auto.calimero                ] - [CM Configuration Updater (ManagedService Update: pid=[org.openhab.knx])] KNXnet/IP Tunneling 127.0.0.1:3671: establishing connection failed
tuwien.auto.calimero.exception.KNXTimeoutException: timeout connecting to control endpoint /127.0.0.1:3671
    at tuwien.auto.calimero.knxnetip.ClientConnection.connect(ClientConnection.java:172)[155:org.openhab.binding.knx:1.9.0.201601181633]
    at tuwien.auto.calimero.knxnetip.KNXnetIPTunnel.<init>(KNXnetIPTunnel.java:117)[155:org.openhab.binding.knx:1.9.0.201601181633]
    at tuwien.auto.calimero.link.KNXNetworkLinkIP.<init>(KNXNetworkLinkIP.java:180)[155:org.openhab.binding.knx:1.9.0.201601181633]
    at org.openhab.binding.knx.internal.connection.KNXConnection.connectByIp(KNXConnection.java:285)[155:org.openhab.binding.knx:1.9.0.201601181633]
    at org.openhab.binding.knx.internal.connection.KNXConnection.connect(KNXConnection.java:172)[155:org.openhab.binding.knx:1.9.0.201601181633]
    at org.openhab.binding.knx.internal.connection.KNXConnection.updated(KNXConnection.java:438)[155:org.openhab.binding.knx:1.9.0.201601181633]
    at org.apache.felix.cm.impl.helper.ManagedServiceTracker.updated(ManagedServiceTracker.java:189)[7:org.apache.felix.configadmin:1.8.8]
    at org.apache.felix.cm.impl.helper.ManagedServiceTracker.updateService(ManagedServiceTracker.java:152)[7:org.apache.felix.configadmin:1.8.8]
    at org.apache.felix.cm.impl.helper.ManagedServiceTracker.provideConfiguration(ManagedServiceTracker.java:85)[7:org.apache.felix.configadmin:1.8.8]
    at org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceUpdate.provide(ConfigurationManager.java:1444)[7:org.apache.felix.configadmin:1.8.8]
    at org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceUpdate.run(ConfigurationManager.java:1400)[7:org.apache.felix.configadmin:1.8.8]
    at org.apache.felix.cm.impl.UpdateThread.run0(UpdateThread.java:143)[7:org.apache.felix.configadmin:1.8.8]
    at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:110)[7:org.apache.felix.configadmin:1.8.8]
    at java.lang.Thread.run(Thread.java:745)[:1.8.0_66]
17:37:52.492 [ERROR] [nx.internal.connection.KNXConnection] - Error connecting to KNX bus: timeout connecting to control endpoint /127.0.0.1:3671
17:37:52.496 [WARN ] [nx.internal.connection.KNXConnection] - Inital connection to KNX bus failed!

[cdjackson]

I'm not quite sure of the link to Zwave here but Zwave does connect to the port and data is received so the connection is working briefly.

If I can work out how to replace a bundle under karaf I'll do some further testing tonight (with the latest build, putting a file in the addons folder it wasn't picked up).

[maggu2810]

@cdjackson
This issue mixes different bundles. The last messages has been about the KNX binding. I assume Kai want to show you, that it is possible to run Z-Wave 1 (modified DS) under OH 2 beta1.
I can help you with your bundle update stuff using Karaf.

[kaikreuzer]

I assume Kai want to show you, that it is possible to run Z-Wave 1 (modified DS) under OH 2 beta1

At least I hope this is what @maggu2810 demonstrated in #96 (comment) - so this should be the patch to make the ZWave binding work; would be great if @cdjackson could test and confirm this!

[cdjackson]

Ok. I've not read through all the messages as am on my phone but will take a look when I get home in an hour or so.

Thanks.

Sent from my iPhone

On 18 Jan 2016, at 17:10, Kai Kreuzer [email protected] wrote:

I assume Kai want to show you, that it is possible to run Z-Wave 1 (modified DS) under OH 2 beta1

At least I hope this is what @maggu2810 demonstrated in #96 (comment) - so this should be the patch to make the ZWave binding work; would be great if @cdjackson could test and confirm this!

—
Reply to this email directly or view it on GitHub.

[kaikreuzer]

@maggu2810 Is there any way to replace Apache SCR with Equinox DS in Karaf? I would like to give it a try to see if the problems are resolved then or if I am digging at the wrong place.

[maggu2810]

I would assume you can remove the scr bundle and install equinox ds instead.
Have done it month ago...

[maggu2810]

The Equinox DS implementation does need org.eclipse.equinox.internal.util.event, so you have also to use Equinox Event Manager

[maggu2810]

Will send you a mail...

[SuperOok]

Just set up my Raspi2 with Raspbian and the Build 84 of the openhab distro karaf beta. I'm also experiencing this issue that with KNX Binding 1.9.SNAPSHOT I can switch switches but do not receive any events. Just let me know If I could test anything to help.

[cdjackson]

Ok - so it seems that for zwave, if I add immediate=true to the activebinding.xml, it works.

[cdjackson]

openhab/openhab1-addons#3837

(thanks @maggu2810)

[lewie]

@maggu2810,
you need no Hardware to test KNX Binding.

Setup a second openHAB 1.8 with KNX Binding, use config like:

knx:busaddr=15.15.249
knx:type=ROUTER

The other openHAB2 KNX1.8 Binding, change busaddr or do not set:

knx:busaddr=15.15.248  (optional here, because if not set 0.0.0 is used. New KNX2 binding uses fixed *busaddr = 0.0.0*)
knx:type=ROUTER

Do not set any other configuration parameters of KNX1.8!
The two openHAB communicate over the default KNX mulicast address: 224.0.23.12:3671 now.

After that, define a Item and add it to a Sitemap too, like this in both obenHAB:

Switch  testknx     { knx="<1/1/1" }

[maggu2810]

@lewie Thank you, will try it...

[kaikreuzer]

@maggu2810, no need, I think I just have it working in this second!

[kaikreuzer]

Fix for KNX is here: openhab/openhab1-addons#3839

Both ZWave and KNX fixes should be included in https://openhab.ci.cloudbees.com/job/openHAB-Distribution/90/ already - @lewie, would be great if you could test!

[lewie]

@kaikreuzer,
Now knx 1.9 binding works as expected in OH2 AND OH1!

Yeah, well done! :-)

In OH2 I get these other abnormalities:

first line in log: 
2016-01-19 05:45:28.119 [ERROR] [org.eclipse.smarthome.core.transform] - [org.eclipse.smarthome.action.transformation.action(78)] Circular reference detected, getService returning null

third line: 
2016-01-19 05:45:30.701 [INFO ] [sistence.rrd4j.internal.RRD4jService] - Removing invalid defintion component = null heartbeat = 0 min/max = 0.0/0.0 step = 0 0 archives(s) = [] 0 items(s) = []

later:
2016-01-19 05:45:40.428 [WARN ] [nce.extensions.PersistenceExtensions] - There is no queryable persistence service registered with the name 'rrd4j'
2016-01-19 05:45:40.435 [WARN ] [nce.extensions.PersistenceExtensions] - There is no queryable persistence service registered with the name 'rrd4j'

I'm really glad that it now works with karaf, all its Framework features, webconsole and so on. I do a lot with MQTT / ActiveMQ, therefor karaf is extremely helpful.

[kaikreuzer]

Thanks @lewie, that's good news!

2016-01-19 05:45:28.119 [ERROR] [org.eclipse.smarthome.core.transform] - [org.eclipse.smarthome.action.transformation.action(78)] Circular reference detected, getService returning null

Already reported: eclipse-archived/smarthome#870

2016-01-19 05:45:40.428 [WARN ] [nce.extensions.PersistenceExtensions] - There is no queryable persistence service registered with the name 'rrd4j'

Already reported: #84

2016-01-19 05:45:30.701 [INFO ] [sistence.rrd4j.internal.RRD4jService] - Removing invalid defintion component = null heartbeat = 0 min/max = 0.0/0.0 step = 0 0 archives(s) = [] 0 items(s) = []

Never seen. But it indeeds points to a bug in the rrd4j bundle. Created openhab/openhab1-addons#3845.

[kaikreuzer]

Closing this issue as there does not seem to be a general problem as initially guessed.