Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Diverse connection problems on Karaf-based runtime #96

Closed
kaikreuzer opened this issue Jan 18, 2016 · 35 comments
Closed

Diverse connection problems on Karaf-based runtime #96

kaikreuzer opened this issue Jan 18, 2016 · 35 comments

Comments

@kaikreuzer
Copy link
Member

We have multiple bindings that work smoothly on the alpha2, but not anymore on the Karaf-based beta1, which all show some connectivity problems:

In all cases, the reason for the problem is completely unknown and there are no helpful log entries.
I tested it with the KNX binding myself: Running exactly the same code and configuration from within the IDE is fine, but running it on Karaf results in no events being received from KNX.
Does anybody have any idea, what might cause such things? What is potentially different in Karaf handling sockets or other connections?

@maggu2810
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Member Author

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

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

@maggu2810
Copy link
Contributor

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
Copy link
Member Author

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
Copy link
Contributor

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

@kaikreuzer
Copy link
Member Author

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
Copy link
Contributor

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
Copy link
Member Author

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
Copy link
Contributor

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
Copy link
Member Author

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
Copy link
Member Author

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

@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
Copy link
Member Author

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
Copy link
Contributor

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 notifications@github.com 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
Copy link
Member Author

@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
Copy link
Contributor

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

@maggu2810
Copy link
Contributor

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

@maggu2810
Copy link
Contributor

Will send you a mail...

@SuperOok
Copy link

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
Copy link
Contributor

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

@cdjackson
Copy link
Contributor

openhab/openhab1-addons#3837

(thanks @maggu2810)

@lewie
Copy link

lewie commented Jan 18, 2016

@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
Copy link
Contributor

@lewie Thank you, will try it...

@kaikreuzer
Copy link
Member Author

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

@kaikreuzer
Copy link
Member Author

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
Copy link

lewie commented Jan 19, 2016

@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
Copy link
Member Author

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
Copy link
Member Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants