Z-Wave: BASIC command class channel is missing

Hi, I need help.

I switched to Openhab2, but kept using zwave-1 binding, switching other bindings to 2-nd version step-by-step. Everything worked well on zwave-1, but now it’s turn for this binding to be upgraded. So, yesterday I uninstalled zwave-1 binding and intalled the latest stable zwave-2.1.0.

I have several TZ66D Dual Paddle Wall Switches. They have two paddles - the left one is for swithing on/off the locally connected load, the right one is for switching remote devices via BASIC command class associations. In my setup the right paddle group is associated with the controller in order to trigger some rules on switching them. But at the same time I of course need to know the state of the switch itself (which is controlled by the left paddle).

With z-wave version 1 binding I solved this problem in the following way:

Switch Light_Hall "Hall Light" {zwave="7:command=switch_binary,refresh_interval=30"}
Switch Somebody_At_Home "Somebody At Home" {zwave="7:command=basic"}

The “Light_Hall” item is for the switch state itself (left paddle) - I can see in UI and use in rules the actual state of the switch.
Somebody_At_Home” item is for the right paddle state - when I “switch it off” (tap down), the leave home rule is triggered, when I “switch it on” (tap up), the return home rule is triggered.

In z-wave version 2 binding I see the only channel “zwave:device:875a08ad:node7:switch_binary”, and it’s pretty clear that if I do like this:

Switch Light_Hall "Hall Light" {channel="zwave:device:875a08ad:node7:switch_binary"}
Switch Somebody_At_Home "Somebody At Home"
 {channel="zwave:device:875a08ad:node7:switch_binary"}

My leave home/return home rules will be triggered each time I switch my Hall light on/off using its left paddle.

So, I cannot figure out how to solve this quiz using 2-nd version of the binding. And it’s the critical part of my system, as I have several switches of this kind, and in all of them the right paddle is associated with the controller to trigger different rules. Does anybody know?

In general, for most devices, the BASIC class maps to another command class. In this case I would expect this to be the SWITCH_BINARY class, although I’ve not checked. It’s pretty rare for a device to only support the BASIC class.

So, I would expect that it works ok with the SWITCH_BINARY, and if not, and the device is sending BASIC messages, then the database should be updated to map the BASIC class to the SWITCH_BINARY class (this is a simple tick in the database).

http://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/157

You are right, BASIC is being mapping to SWITCH_BINARY, and I see it in logs and in behaviour of my system:

I click on the right paddle -> BASIC report comes to the controller -> zwave:device:875a08ad:node7:switch_binary channel is being updated.

My problem is that in my case I don’t need this update, I need a separate BASIC channel, otherwise there is no way to distinguish between left and right paddle states in Openhab when the report comes. And, as I’ve written above, my leave home/return home rules are triggered each time I switch my Hall light on/off using its left paddle. But they should be triggered ONLY when I use the right paddle. Maybe there is another way to distinguish between these two events, rather than by command classes, about which I don’t know. Otherwise, I will have to switch back to not supported zwave-1 binding, which I don’t want of course :frowning:

@chris, any comments? I really don’t want move back to version 1 of the binding.

We can add this as a separate channel. It’s a bit messy really - effectively the device doesn’t support this sort of notification, but for now at least we an continue to exploit this to differentiate.

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:

  1. 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.

  2. 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: https://github.com/openhab/org.openhab.binding.zwave/issues/637

I also have one more issue exactly as described in this thread: Z-Wave rules with SCENE_ACTIVATION problem - 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:

  1. The original problem from the post number 1:
    Z-Wave: BASIC command class channel is missing
    I have raised a Github issue for this.

  2. 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:

  1. Including a TZ66D creates only one channel:
    COMMAND_CLASS_SWITCH_BINARY_V1
    Switch switch_binary
  2. This is in accordance with the device definition in the Z-Wave database.
  3. Pressing the top/bottom of the right switch sends a BASIC_SET to all devices associated with group 2.
  4. 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.