No XML node file generated for Leviton RZI06-1L

I’ve got a few Leviton RZI06-1L switches that I’m trying to add. They are not in the database and unfortunately OH did not create node XML file when I tried to add one.

I’ve tried this with both stable and snapshot versions. It’s running on an RPi 3 using the aeon gen5 z-stick.

Can anyone tell from the portion of my log below why OH is not able to create the XML file?

Thanks

The Leviton is Node 13.

2018-07-15 20:15:59.086 [WARN ] [tocol.commandclass.ZWaveCommandClass] - NODE 13: Unknown command class 0x91
2018-07-15 20:15:59.387 [WARN ] [tocol.commandclass.ZWaveCommandClass] - NODE 13: Unknown command class 0x91
2018-07-15
 20:15:59.558 [WARN ] [wave.discovery.ZWaveDiscoveryService] - NODE 13: 
Device discovery could not resolve to a thingType! 001D:0401:0206::0.3
2018-07-15
 20:15:59.566 [INFO ] [g.discovery.internal.PersistentInbox] - Added new
 thing 'zwave:device:e6edcb03:node13' to inbox.
2018-07-15 
20:16:03.078 [ERROR] [nal.common.AbstractInvocationHandler] - An error 
occurred while calling method 'ThingHandler.dispose()' on 
'org.openhab.binding.zwave.handler.ZWaveThingHandler@138d1fd': null
java.lang.NullPointerException: null
   
 at 
org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeSerializer.SerializeNode(ZWaveNodeSerializer.java:97)
 [199:org.openhab.binding.zwave:2.4.0.201807141304]
    at 
org.openhab.binding.zwave.handler.ZWaveThingHandler.dispose(ZWaveThingHandler.java:478)
 [199:org.openhab.binding.zwave:2.4.0.201807141304]
    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.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:153)
 [94:org.eclipse.smarthome.core:0.10.0.201807081340]
    at 
org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:53)
 [94:org.eclipse.smarthome.core:0.10.0.201807081340]
    at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [?:?]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [?:?]
    at java.lang.Thread.run(Thread.java:745) [?:?]
2018-07-15
 20:16:03.083 [ERROR] [ome.core.thing.internal.ThingManager] - Exception
 occurred while disposing handler of thing 
'zwave:device:e6edcb03:node6': null
java.lang.NullPointerException: null
   
 at 
org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeSerializer.SerializeNode(ZWaveNodeSerializer.java:97)
 [199:org.openhab.binding.zwave:2.4.0.201807141304]
    at 
org.openhab.binding.zwave.handler.ZWaveThingHandler.dispose(ZWaveThingHandler.java:478)
 [199:org.openhab.binding.zwave:2.4.0.201807141304]
    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.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:153)
 [94:org.eclipse.smarthome.core:0.10.0.201807081340]
    at 
org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:53)
 [94:org.eclipse.smarthome.core:0.10.0.201807081340]
    at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [?:?]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [?:?]
    at java.lang.Thread.run(Thread.java:745) [?:?]
2018-07-15
 20:16:09.911 [ERROR] [nal.common.AbstractInvocationHandler] - An error 
occurred while calling method 'ThingHandler.dispose()' on 
'org.openhab.binding.zwave.handler.ZWaveThingHandler@1895b07': null
java.lang.NullPointerException: null
   
 at 
org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeSerializer.SerializeNode(ZWaveNodeSerializer.java:97)
 [199:org.openhab.binding.zwave:2.4.0.201807141304]
    at 
org.openhab.binding.zwave.handler.ZWaveThingHandler.dispose(ZWaveThingHandler.java:478)
 [199:org.openhab.binding.zwave:2.4.0.201807141304]
    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.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:153)
 [94:org.eclipse.smarthome.core:0.10.0.201807081340]
    at 
org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:53)
 [94:org.eclipse.smarthome.core:0.10.0.201807081340]
    at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [?:?]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [?:?]
    at java.lang.Thread.run(Thread.java:745) [?:?]
2018-07-15
 20:16:09.922 [ERROR] [ome.core.thing.internal.ThingManager] - Exception
 occurred while disposing handler of thing 
'zwave:device:e6edcb03:node7': null
java.lang.NullPointerException: null
   
 at 
org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeSerializer.SerializeNode(ZWaveNodeSerializer.java:97)
 [199:org.openhab.binding.zwave:2.4.0.201807141304]
    at 
org.openhab.binding.zwave.handler.ZWaveThingHandler.dispose(ZWaveThingHandler.java:478)
 [199:org.openhab.binding.zwave:2.4.0.201807141304]
    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.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:153)
 [94:org.eclipse.smarthome.core:0.10.0.201807081340]
    at 
org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:53)
 [94:org.eclipse.smarthome.core:0.10.0.201807081340]
    at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [?:?]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [?:?]
    at java.lang.Thread.run(Thread.java:745) [?:?]
2018-07-15
 20:16:17.325 [WARN ] [wave.discovery.ZWaveDiscoveryService] - NODE 10: 
Device discovery could not resolve to a thingType! 0005:4841:0018::10.0
2018-07-15
 20:16:17.349 [WARN ] [wave.discovery.ZWaveDiscoveryService] - NODE 13: 
Device discovery could not resolve to a thingType! 001D:0401:0206::0.3

I don’t think anything here is linked to it not generating the XML. Please enable debug mode so that we can see what is happening. The log will be long so you will need to put it somewhere like dropbox and then link back to it here.

Hi Chris. Thanks for looking at this.

I’m not sure if I’m getting the debug mode right. I used “log:set debug org.openhab.binding.zwave” to set it and it seemed to survive a reboot, but I didn’t get any new DEBUG level messages in the log when I added another switch (Node 14). Could I be skipping a step? Are the DEBUG messages in the same file?

openhab> log:get
Logger                                             │ Level
───────────────────────────────────────────────────┼──────
ROOT                                               │ WARN
javax.jmdns                                        │ ERROR
org.apache.karaf.jaas.modules.audit                │ INFO
org.apache.karaf.kar.internal.KarServiceImpl       │ ERROR
org.apache.karaf.shell.support                     │ OFF
org.apache.sshd                                    │ WARN
org.eclipse.smarthome                              │ INFO
org.jupnp                                          │ ERROR
org.openhab                                        │ INFO
org.openhab.binding.zwaveM                         │ DEBUG
org.ops4j.pax.url.mvn.internal.AetherBasedResolver │ ERROR
org.ops4j.pax.web.pax-web-runtime                  │ OFF
smarthome.event                                    │ INFO
smarthome.event.InboxUpdatedEvent                  │ ERROR
smarthome.event.ItemAddedEvent                     │ ERROR
smarthome.event.ItemRemovedEvent                   │ ERROR
smarthome.event.ItemStateEvent                     │ ERROR
smarthome.event.ThingAddedEvent                    │ ERROR
smarthome.event.ThingRemovedEvent                  │ ERROR
smarthome.event.ThingStatusInfoEvent               │ ERROR

This is a link to a copy of the log.
I restarted to add the switch around “2018-07-17 07:27:12.160”.

Thanks again!

Well, the command does look ok, but there is no debug in the log so it’s not so helpful. It should really be as simple as sending the command so I’m not sure what else to suggest :frowning: .

Got it now. I had a typo (org.openhab.binding.zwaveM instead of org.openhab.binding.zwave )!

Here’s the new logs: log log2

I removed the two switches that I added yesterday from OH. I then excluded them from the z-wave network with my z-stick and added one of them back. When I re-started OH for some reason it saw two new nodes (13 and 15) instead of one. I’m not sure why. Maybe I accidentally turned on another switch while my z-stick was still in include mode.

Hopefully there will be something in those logs that will explain the failure to create the XML file. Thanks again for your help!

Thanks. This is the same issue we’ve seen with other Leviton devices not properly supporting a command class. I will create a dummy database entry that should get it to step past the point at which it’s stuck - I’ll then need to delete the dummy entry before you can add a new device to the database.

Thanks for doing that. Will that eventually get into the snapshot version or is there a better way for me to incorporate the new XML files?

It will be in the next snapshot - I’ve just updated the binding and will do a build in the next hour assuming there’s no problems.

Chris - Thanks for pushing that though.

I got the snapshot but unfortunately I’m still not getting an XML file for the new node. It does behave differently. When I add the thing it names it “Z-Wave Node 13: RZ106-1L Temp” and calls it a “RZ106-1L Temp” instead of unknown.

Something else that I noticed was that all of the other nodeXX.xml files in /var/lib/openhab2/zwave where dated the same time earlier today. I’m not sure but I probably did that same experiment earlier.

Also, I’m not sure that this is important but I thought that I should mention that I’m not excluding then re-including the Leviton from the z-wave network. I’m just deleting the thing then using the Inbox to re-discover the thing from the z-stick.

The new log file is here. The new nodes are 13 and 15.

Thanks

The link to the log doesn’t work… I’ll take a look at this tomorrow though.

Sorry. Copy/Paste error. Here it is.

Thanks. In this case it’s also not responding to the VERSION request of the BASIC class… I’ll do another database update later.

Thanks Chris. I just tried it with build #1316 and still no luck getting an XML file. Any clues here?

The nodes are now 13 and 18. I’m not sure why one went from 15 to 18.

I noticed in another Leviton device over the weekend that they weren’t responding to the VERSION class - this seems to be the same so I’ll do a bulk change for all classes to fix this :frowning: .

Hi Chris. Were you able to do this?

I tried with build 1317 but didn’t get an XML file with that either.

I still need to update the binding itself - I’ll try and do this tonight as I was away over the past day or so.

1 Like

Chris - The Levitons worked with the last snapshot. Thanks for your help!

1 Like