Thank you very much. What should I do to let it go? Maybe create an issue on Github?
I also have some other questions related to associations setup, which look like bugs. Should I create a separate thread for them, or I can post them here?
Yes, please raise a GH issue and I’ll take a look…
Sorry, I confused myself. Do you mean create issue for separating BASIC command class, or for association issues? As for associations, I want to process all items from the Inbox first (10 are left), then restart OpenHAB and check if the issues still persist.
I meant to separate out the basic class.
I don’t know what you mean about the associations and the inbox? What inbox are you talking about (the OH inbox?)?
Ok. Yes, OH indox, there are 10 Z-Wave things left. I will process (configure) all of them, then restart OpenHAB, then check the association issue again. I didn’t describe it yet, if it will not reproduce after restart, I even won’t do it.
You don’t need to process them before restarting - it doesn’t matter either way. The inbox is persistent, and the ZWave binding adds devices based on information from the stick, so you won’t loose them…
Ok, thanks.
Well, restarted.
The problems which persisted after restart are the following:
-
Association problem has gone for all z-wave things except one TZ65D Dual Paddle Wall Dimmer (before restart this problem was for all Z-Wave things) - there are no associations displayed neither in PaperUI:
nor in HABMin:
But in fact this node has associations group2 -> node 1 (controller), group 3 -> node 27, and works according to these associations, plus I can see it in /var/lib/openhab2/zwave/node58.xml:
Also this problem is actual for new Z-Wave things added from Inbox after restart. -
Whenever I save any Z-Wave thing after editing in PaperUI, the thing is updated (don’t know whether fully or partially), but I get the following message in UI: “500 Internal Server Error” and see the following in the main log:
2017-07-11 22:23:14.635 [ERROR] [ome.core.thing.internal.ThingManager] - Exception occurred while calling thing updated at ThingHandler 'org.openhab.binding.zwave.handler.ZWaveThing
Handler@1858789': java.lang.NullPointerException
java.util.concurrent.ExecutionException: java.lang.NullPointerException
at java.util.concurrent.FutureTask.report(FutureTask.java:122)[:1.8.0_131]
at java.util.concurrent.FutureTask.get(FutureTask.java:206)[:1.8.0_131]
at org.eclipse.smarthome.core.common.SafeMethodCaller.callAsynchronous(SafeMethodCaller.java:194)
at org.eclipse.smarthome.core.common.SafeMethodCaller.call(SafeMethodCaller.java:83)
at org.eclipse.smarthome.core.common.SafeMethodCaller.call(SafeMethodCaller.java:67)
at org.eclipse.smarthome.core.thing.internal.ThingManager.thingUpdated(ThingManager.java:524)
at org.eclipse.smarthome.core.thing.internal.ThingRegistryImpl.notifyTrackers(ThingRegistryImpl.java:221)
at org.eclipse.smarthome.core.thing.internal.ThingRegistryImpl.notifyListenersAboutUpdatedElement(ThingRegistryImpl.java:144)
at org.eclipse.smarthome.core.thing.internal.ThingRegistryImpl.notifyListenersAboutUpdatedElement(ThingRegistryImpl.java:1)
at org.eclipse.smarthome.core.common.registry.AbstractRegistry.updated(AbstractRegistry.java:177)
at org.eclipse.smarthome.core.common.registry.AbstractProvider.notifyListeners(AbstractProvider.java:57)
at org.eclipse.smarthome.core.common.registry.AbstractProvider.notifyListenersAboutUpdatedElement(AbstractProvider.java:82)
at org.eclipse.smarthome.core.common.registry.AbstractManagedProvider.update(AbstractManagedProvider.java:133)
at org.eclipse.smarthome.io.rest.core.thing.ThingResource.update(ThingResource.java:437)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)[:1.8.0_131]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)[:1.8.0_131]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.8.0_131]
at java.lang.reflect.Method.invoke(Method.java:498)[:1.8.0_131]
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)[161:org.glassfish.jersey.core.j
ersey-server:2.22.2]
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:144)[161:org.glassfish.jersey.core.jersey-
server:2.22.2]
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:161)[161:org.glassfish.jersey.core.jersey
-server:2.22.2]
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:160)[161:org.glass
fish.jersey.core.jersey-server:2.22.2]
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:99)[161:org.glassfish.jersey.core.jerse
y-server:2.22.2]
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:389)[161:org.glassfish.jersey.core.jersey-server:2.22.2]
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:347)[161:org.glassfish.jersey.core.jersey-server:2.22.2]
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:102)[161:org.glassfish.jersey.core.jersey-server:2.22.2]
at org.glassfish.jersey.server.ServerRuntime$2.run(ServerRuntime.java:326)[161:org.glassfish.jersey.core.jersey-server:2.22.2]
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)[160:org.glassfish.jersey.core.jersey-common:2.22.2]
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)[160:org.glassfish.jersey.core.jersey-common:2.22.2]
at org.glassfish.jersey.internal.Errors.process(Errors.java:315)[160:org.glassfish.jersey.core.jersey-common:2.22.2]
at org.glassfish.jersey.internal.Errors.process(Errors.java:297)[160:org.glassfish.jersey.core.jersey-common:2.22.2]
at org.glassfish.jersey.internal.Errors.process(Errors.java:267)[160:org.glassfish.jersey.core.jersey-common:2.22.2]
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)[160:org.glassfish.jersey.core.jersey-common:2.22.2]
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:305)[161:org.glassfish.jersey.core.jersey-server:2.22.2]
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1154)[161:org.glassfish.jersey.core.jersey-server:2.22.2]
at org.glassfish.jersey.servlet.WebComponent.serviceImpl(WebComponent.java:473)[158:org.glassfish.jersey.containers.jersey-container-servlet-core:2.22.2]
at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:427)[158:org.glassfish.jersey.containers.jersey-container-servlet-core:2.22.2]
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:388)[158:org.glassfish.jersey.containers.jersey-container-servlet-core:2.22.2]
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:341)[158:org.glassfish.jersey.containers.jersey-container-servlet-core:2.22.2]
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:228)[158:org.glassfish.jersey.containers.jersey-container-servlet-core:2.22.2]
at com.eclipsesource.jaxrs.publisher.internal.ServletContainerBridge.service(ServletContainerBridge.java:76)[12:com.eclipsesource.jaxrs.publisher:5.3.1.201602281253]
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:812)[84:org.eclipse.jetty.servlet:9.2.19.v20160908]
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:587)[84:org.eclipse.jetty.servlet:9.2.19.v20160908]
at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:71)[175:org.ops4j.pax.web.pax-web-jetty:4.3.0]
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)[83:org.eclipse.jetty.server:9.2.19.v20160908]
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)[82:org.eclipse.jetty.security:9.2.19.v20160908]
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)[83:org.eclipse.jetty.server:9.2.19.v20160908]
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)[83:org.eclipse.jetty.server:9.2.19.v20160908]
at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:287)[175:org.ops4j.pax.web.pax-web-jetty:4.3.0]
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)[84:org.eclipse.jetty.servlet:9.2.19.v20160908]
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)[83:org.eclipse.jetty.server:9.2.19.v20160908]
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)[83:org.eclipse.jetty.server:9.2.19.v20160908]
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)[83:org.eclipse.jetty.server:9.2.19.v20160908]
at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:80)[175:org.ops4j.pax.web.pax-web-jetty:4.3.0]
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)[83:org.eclipse.jetty.server:9.2.19.v20160908]
at org.eclipse.jetty.server.Server.handle(Server.java:499)[83:org.eclipse.jetty.server:9.2.19.v20160908]
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:311)[83:org.eclipse.jetty.server:9.2.19.v20160908]
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)[83:org.eclipse.jetty.server:9.2.19.v20160908]
at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:544)[74:org.eclipse.jetty.io:9.2.19.v20160908]
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)[86:org.eclipse.jetty.util:9.2.19.v20160908]
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)[86:org.eclipse.jetty.util:9.2.19.v20160908]
at java.lang.Thread.run(Thread.java:748)[:1.8.0_131]
Caused by: java.lang.NullPointerException
at org.openhab.binding.zwave.handler.ZWaveThingHandler.updateNodeProperties(ZWaveThingHandler.java:1403)[204:org.openhab.binding.zwave:2.1.0]
at org.openhab.binding.zwave.handler.ZWaveThingHandler.bridgeStatusChanged(ZWaveThingHandler.java:457)[204:org.openhab.binding.zwave:2.1.0]
at org.openhab.binding.zwave.handler.ZWaveThingHandler.initialize(ZWaveThingHandler.java:150)[204:org.openhab.binding.zwave:2.1.0]
at org.eclipse.smarthome.core.thing.binding.BaseThingHandler.thingUpdated(BaseThingHandler.java:192)[108:org.eclipse.smarthome.core.thing:0.9.0.b5]
at org.eclipse.smarthome.core.thing.internal.ThingManager$7.call(ThingManager.java:528)[108:org.eclipse.smarthome.core.thing:0.9.0.b5]
at org.eclipse.smarthome.core.thing.internal.ThingManager$7.call(ThingManager.java:1)[108:org.eclipse.smarthome.core.thing:0.9.0.b5]
at org.eclipse.smarthome.core.common.SafeMethodCaller$CallableWrapper.call(SafeMethodCaller.java:181)[101:org.eclipse.smarthome.core:0.9.0.b5]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_131]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_131]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_131]
... 1 more
Sorry, due to formatting errors will continue in the next post.
And the third problem which annoys me most out of these three is that all my Z-Wave items that are linked with motion-sensor channels, are not updated when motion is triggered. For example, I have the following items:
Contact Motion_Sensor_Hallway "Hallway Motion Sensor" <contact> (Hallway, All_Sensors) {channel="zwave:device:875a08ad:node37:alarm_motion"}
Contact Motion_Sensor_Kitchen "Kitchen Motion Sensor" <contact> (Kitchen, All_Sensors) {channel="zwave:device:875a08ad:node25:sensor_binary"}
When motion sensor is triggered I see it in the log:
2017-07-11 22:34:29.205 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 37: Application Command Request (ALIVE:DETAILS)
2017-07-11 22:34:29.206 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 37: Incoming command class SENSOR_BINARY
2017-07-11 22:34:29.207 [DEBUG] [dclass.ZWaveBinarySensorCommandClass] - NODE 37: Received SENSOR_BINARY command V1
2017-07-11 22:34:29.207 [DEBUG] [dclass.ZWaveBinarySensorCommandClass] - NODE 37: Sensor Binary report, type=Unknown, value=255
2017-07-11 22:34:29.208 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveBinarySensorValueEvent
2017-07-11 22:34:29.209 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 37: Got an event from Z-Wave network: ZWaveBinarySensorValueEvent
2017-07-11 22:34:29.209 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 37: Got a value event from Z-Wave network, endpoint = 0, command class = SENSOR_BINARY, value = 255
2017-07-11 22:34:29.210 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 37: Updating channel state zwave:device:875a08ad:node37:alarm_motion to ON [OnOffType]
...
2017-07-11 22:32:41.224 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 25: Application Command Request (ALIVE:DETAILS)
2017-07-11 22:32:41.225 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 25: Incoming command class SENSOR_BINARY
2017-07-11 22:32:41.225 [DEBUG] [dclass.ZWaveBinarySensorCommandClass] - NODE 25: Received SENSOR_BINARY command V1
2017-07-11 22:32:41.225 [DEBUG] [dclass.ZWaveBinarySensorCommandClass] - NODE 25: Sensor Binary report, type=Unknown, value=255
2017-07-11 22:32:41.225 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveBinarySensorValueEvent
2017-07-11 22:32:41.226 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 25: Got an event from Z-Wave network: ZWaveBinarySensorValueEvent
2017-07-11 22:32:41.226 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 25: Got a value event from Z-Wave network, endpoint = 0, command class = SENSOR_BINARY, value = 255
2017-07-11 22:32:41.227 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 25: Updating channel state zwave:device:875a08ad:node25:sensor_binary to ON [OnOffType]
but rules are not triggered and items remain CLOSED in UI.
Hi, the third problem has been solved by changing type of all sensor items from Contact to Switch.
Hi, I created an issue on GitHUB for the original problem: Create an option to set up a separate BASIC command class instead of mapping it to the specific one · Issue #637 · openhab/org.openhab.binding.zwave · GitHub
I also have one more issue exactly as described in this thread: Z-Wave rules with SCENE_ACTIVATION problem - #9 by dhde - I have two Z-Wave.Me KFOB2 devices, both configured to send SCENE_ACTIVATION commands.
I configured two items:
Number KFob_1 "KFob 1 Scene" (Home) {channel="zwave:device:875a08ad:node43:scene_number"}
Number KFob_2 "KFob 2 Scene" (Home) {channel="zwave:device:875a08ad:node34:scene_number"}
and when I press buttons on the key-fobs I can see the messages in logs:
2017-07-13 22:43:05.687 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 43: Application Command Request (ALIVE:DETAILS)
2017-07-13 22:43:05.687 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 43: Incoming command class SCENE_ACTIVATION
2017-07-13 22:43:05.688 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - Received Scene Activation for Node ID = 43
2017-07-13 22:43:05.688 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - Scene Activation Set
2017-07-13 22:43:05.688 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - Scene activation node from node 43: Scene 11, Time 255
2017-07-13 22:43:05.689 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveCommandClassValueEvent
2017-07-13 22:43:05.694 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 43: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2017-07-13 22:43:05.695 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 43: Got a value event from Z-Wave network, endpoint = 0, command class = SCENE_ACTIVATION, value = 11
2017-07-13 22:43:05.696 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 58: Transaction not completed: node address inconsistent. lastSent=58, incoming=255
but the items are not updated.
Update: the following action solved the problem:
Several problems have been discussed in this thread, several have been solved. To sum up, I’ll list unsolved problems again:
-
The original problem from the post number 1:
Z-Wave: BASIC command class channel is missing
I have raised a Github issue for this. -
Problems 1 and 2 described in this post:
Z-Wave: BASIC command class channel is missing
Hi @chris , any update on the problem number 1 in the post above, can it be fixed in the latest 4.1.x ZWave binding? I still cannot use the BASIC command class separately.
DUT: OpenSmartHouse Z-Wave Device Database
IIUC:
- Including a TZ66D creates only one channel:
COMMAND_CLASS_SWITCH_BINARY_V1
Switch switch_binary - This is in accordance with the device definition in the Z-Wave database.
- Pressing the top/bottom of the right switch sends a BASIC_SET to all devices associated with group 2.
- OP would like to have an additional channel that reflects the BASIC_SET commands from 3.
@apella12
Do you think that adding the Z-Wave controller to group 2 and adding a channel to
COMMAND_CLASS_BASIC_V1 (switch_binary or switch_dimmer) would do the trick?
When I saw, six years ago and reference to OH1, I kind of took a pass yesterday.
Since you asked, after some review I think I understand what OP was doing, but have to say (IMO) it is not the way these devices were intended to work. The left paddle is intended to send basic sets (0 or 255) to a non-controller devices. One tap for Assoc group 2 and two taps for Assoc group 3. It was kind of an early way to create scenes.
As to the idea, I’m not sure how the controller can distinguish getting both a switch binary message (37 3 255) or (37 3 0) in Assoc group 1 and a basic (32 3 255) or (32 3 0) in Assoc group 2 and run rule in one case and not another, but TBH, I really don’t know.
One random thought is if the intended rule does something with any other zwave device when someone leaves the house (Ideally turns a light on), put that light in group 2 or 3. If there are other elements of the rule trigger them on the light status.
Hi. The problem in my case is that the device which I need to control via the right paddle of this switch is the 2nd channel of a Fibaro double relay. So I could have done it via direct association without involving OpenHAB at all, but these switches do not support multi-instance associations, so I cannot add the 2nd channel of Fibaro relay to group 2 or 3. That’s why I need OpenHAB here.
And I could do the trick in Openhab 1, because I could associate one item with the switch_binary/switch_dimmer command class (which is sent by the switch to devices in group 1), and the other item with basic command class (which is sent by the switch to devices in groups 2 & 3).
But I can’t do it now any more in Openhab 2/3/4.
The Z-Wave controller doesn’t know the association group the message comes from, but it could map the switch binary command class to openHAB channel #1 and the basic command class to openHAB channel #2. Whether the Z-Wave binding does supports this, I don’t know either, but
must have some meaning. 
I really don’t know, but you could give it a try (say dimmer on one and switch on the other) and @roher could test. I think the “separate” has to do with this in the XML.
<!-- CHANNEL DEFINITIONS -->
<channels>
<channel id="switch_binary" typeId="switch_binary">
<label>Switch</label>
<properties>
<property name="binding:*:OnOffType">COMMAND_CLASS_SWITCH_BINARY,COMMAND_CLASS_BASIC</property>
</properties>
</channel>
</channels>
What a number of my switches do is send the Basic set to the controller when they are operated manually, but OH sends the switch binary command when operated with Zwave. Without the Basic tied to the channel OH will not update the status of my devices when operated manually. Don’t know about this device. It sounds like it sends switch_binary on the right (even when operated manually) and basic on the left.
Did some thinking on this and I’m not sure I understand are you talking about Multi-Channel Association? At least on the UI I get options on my devices to associate device endpoints. I do vaguely recall problems with Associating endpoint 2 between dual switches, but did get endpoint 1 to react (don’t remember any details anymore). That leads me to; can you switch the wires on the Fibaro in the box so the item you want to control is on the first EP and then just associate the device? Sometimes EP0 and EP1 are mirrors. You could test first with the current item on Ep1 before messing with the wires.
I cannot do it, because in my setup I need both relay endpoints to be associated with my TKB dimmer:
EP 1 (bathroom light) - single click of the right paddle - group 2.
EP 2 (bathroom fan) - double click of the right paddle - group 3.
So now I can control bathroom fan only via my smartphone or via the rules (by the humidity sensor for example). With Openhab 1 I could control it physically by putting the controller into group 3 and linking the item to BASIC command class.