Brainstorm ways to simplify Z-wave device setup process

when a device is discovered and the device is not in the device list database, the device will be shown as ‘unknown device’. in most case, node.xml will be generated by openhab2. the device will not be working until it is added to the database offline with Chris’s help.

what can be done to simplify this process?

if z-wave binding is able to compose the node.xml, what stops it create temporary channels so that the device can be immediately working?

You are able to do that on your own … just register on the database site and ask for edit rights.

I don’t think it is that complicated (just my 2c)

Please take a look here -:

The ESH framework did.

When I first wrote the ZWave binding the ONLY way to define things was in the XML files. There was no ability to have anything defined directly in the binding, or externally other than through the XML thing definition files. Since then features have been added to ESH to allow dynamic channels to be defined by the binding - this is what some other bindings now use, and it’s what I do in the ZigBee binding.

The plan is to move this into ZWave as well, but we have over 400 devices now in use in ZWave and migrating to a completely new system of defining channels etc without breaking things will be a bit of a challenge. I’ve already coded up some command classes to use this system, but to get all command classes done will again take some time.

The other thing I’ve not yet worked out is how to handle things where we define a channel in the database. Quite often devices are not compliant to the ZWave standards (despite being approved!!!). In this case we have to work around their problems and this is handled with flags in the database. Somehow we need to merge the database into the dynamic definitions - maybe not too hard, but it will need some thought yet.

As @sihui said - it’s not that hard to add devices to the database and I try and get things merged across in a day or two. For now, this is the way to work.

I just started working with openhab 3 weeks ago, although have read a lot of documentation, but still not in the stage to understand what dynamic channel means. openhab is quite flexible, but somehow I feel it is harder for end-user to use. I agree with you all, it might not be hard to make it easier to use, but it might take some time. in my case, I only has a simple on/off wall-plug switch (even not battary operated), but the system failed to automatically ‘configure’ it.

there might be a lot of command-classes that the switch support. some of them might be used among z-wave network between controller and the device. to the end-user, I feel the ultimate functionality are 1) to turn it on/off; 2) view the current on/off status, 3)view battery status if it is battery operated. so I am wondering is it possible for openhab to automatically configure those ‘normal’ functionalities? if a device supports unusual specific command-class, it can be configured mannualy. but I think most end-users will be good without using the specific command class…

Well, the answer is what I already said. It’s possible, and it’s something I will implement, but it’s not so simple. It doesn’t matter if it’s a simple, specific, or whatever you want to call it, command class - the answer is still the same.

For now you just need to update the database - it is relatively easy, and once it’s done once by one person, it’s available for everyone. We currently have around 415 devices in the database and it’s increasing daily so the issue will reduce if people just update the data.

@Chris, I have already signed up in your device list database site. but I don’t see an option to ‘upload’ the node.xml. could you provide the access? my account was under Name: “PeterZ”, userName:

BTW, I posted another topic earlier in the community forum two days ago with the device’s node xml. you can either provide me the access to the database, or you can help to upload the xml. thanks.

Ok - I need to manually update your access (it does say this in the instructions) - I’ll do this shortly.

thanks. let me know when you if the update access has granted, so that I can upload the xml to get my device working.

It’s done…

thank you Chris!. just uploaded the xml, but there is a minor problem. it complained on the thing-id containing invalid characters. here is the thing id: “geplug-insmartswitch”, which does contain a dash. what can be done?

No problem - I’ll fix that when I publish it.


Chris, thanks! when reviewing the ‘exported’ thing setting, it seems the thing-type id was composed by using the ‘device name’, which I entered the word “plug-in” as it shows on the product label. I check the .java code in the Eclipse/smarthome repository, the id does not allow ‘-’. I tried to fix it by uploading new node xml, and also tried to edit the ‘device name’ field, however, it did not help. I guess that might be by design as the changing of thing-type id must affect existing users who have the same device. one other option is to trip-off the un-wanted characters in ‘device name’ field when adding a new device, or add a comment to let user know to only use [0-1][a-z] characters. let me know when you fix it in the database, I am eager to test my device and openHab. :slight_smile:

my comment might not be correct as I do see java code support id segment regex as [A-Za-z0-9_-]*, which does include dash.

The thing type is made up of 4 parts - the main id can’t contain some characters but it’s easily editable and I’ll sort it out before it’s approved.


Chris, I now see the unique id field, and is able to remove the dash. I have also added the configurable parameter. it is in ready to review state. I have requested the review. please review. thanks

thank you for approving the uploaded device configuration. however, the device still show as ‘unknown’ after I deleted all “things” and restarted openhab2. what else do I need to do to make it working? the current manufature id and devicetype/id are hex # in your database, should they be changed to decimal value?

here is more details
snippet of the exported xml for openhab2 in your device list site:

  <property name="vendor">Jasco Products</property>
  <property name="modelId">GE Plug in Smart Switch</property>
  <property name="manufacturerId">0063</property>
  <property name="manufacturerRef">5052:3033</property>
  <property name="dbReference">517</property>

the device information shown in openhab2 paper UI after it is discovered:
Z-Wave Node 2 (0063:5052:3033:5.7)

I am still getting the ‘unknow’ device issue even after you published the switch in database. I am using openhab2. what else do I need to do to get it working. your help is appreciated! while waiting for your input, I have tried the following but so far no success:

  1. I tried to add the .xml file into the existing zwave.jar file, but it did not work as I don’t what is the mechanism to get the proper sha1 file, or if I can use a self-signed certificate for signing the jar.
  2. I am trying to setup the openhab2 IDE and try to re-build all. but I am getting many errors on windows 10 system (64 bit). my 20+ years of development experience in C/C++/C# but it does not help in the java world, especially with eclipse JDE/OSGI stuff. so this might take some time for me get a proper build.

Are you using the snapshot version of the runtime, or a release version? Are you sure that the binding is updating on your system and you’re running the version from the 8th Feb? This will be the only version with this device included.

Chris, thanks for replying. yes I was using Release version. today I installed the lastest snapshot, and I double checked my device xml is in the zwave jar file.

the first time I add the device, it shows the correct label which is defined in the thing type xml file. :slight_smile: however, it is showing as ‘uninitized’ and ‘unknown device’.

when I restart the openhab again, the device is showing ‘online’ with the proper ‘switch_binary’ channel. I linked the channel to an switch item, and added the item to my sitemap. this time although everything looks good on the surface, but the switch never worked.

here is the error log:

2017-02-10 11:50:26.700 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing ‘zwave:device:e1ef6c50:node2’ to inbox.
2017-02-10 11:51:12.130 [WARN ] [.core.thing.binding.BaseThingHandler] - Error while applying configuration changes: ‘IllegalArgumentException: Invalid type ‘{org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveSwitchAllCommandClass.SwitchAllMode}’ of configuration value!’ - reverting configuration changes on thing ‘zwave:device:e1ef6c50:node2’.
2017-02-10 11:51:12.134 [ERROR] [ome.core.thing.internal.ThingManager] - Exception occured while initializing handler of thing ‘zwave:device:e1ef6c50:node2’: java.lang.IllegalArgumentException: Invalid type ‘{org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveSwitchAllCommandClass.SwitchAllMode}’ of configuration value!
java.util.concurrent.ExecutionException: java.lang.IllegalArgumentException: Invalid type ‘{org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveSwitchAllCommandClass.SwitchAllMode}’ of configuration value!
at Source)[:1.8.0_121]
at java.util.concurrent.FutureTask.get(Unknown Source)[:1.8.0_121]
at org.eclipse.smarthome.core.common.SafeMethodCaller.callAsynchronous([98:org.eclipse.smarthome.core:]
at org.eclipse.smarthome.core.thing.internal.ThingManager$[105:org.eclipse.smarthome.core.thing:]
at java.util.concurrent.Executors$ Source)[:1.8.0_121]
at Source)[:1.8.0_121]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(Unknown Source)[:1.8.0_121]
at java.util.concurrent.ScheduledThreadPoolExecutor$ Source)[:1.8.0_121]
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)[:1.8.0_121]
at java.util.concurrent.ThreadPoolExecutor$ Source)[:1.8.0_121]
at Source)[:1.8.0_121]
Caused by: java.lang.IllegalArgumentException: Invalid type ‘{org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveSwitchAllCommandClass.SwitchAllMode}’ of configuration value!
at org.eclipse.smarthome.config.core.ConfigUtil.normalizeType([94:org.eclipse.smarthome.config.core:]
at org.eclipse.smarthome.config.core.ConfigUtil.normalizeType([94:org.eclipse.smarthome.config.core:]
at org.eclipse.smarthome.config.core.Configuration.setProperties([94:org.eclipse.smarthome.config.core:]
at org.eclipse.smarthome.core.thing.binding.BaseThingHandler.updateConfiguration([105:org.eclipse.smarthome.core.thing:]
at org.eclipse.smarthome.core.thing.binding.ConfigStatusThingHandler.updateConfiguration([105:org.eclipse.smarthome.core.thing:]
at org.openhab.binding.zwave.handler.ZWaveThingHandler.updateNodeProperties([183:org.openhab.binding.zwave:]
at org.openhab.binding.zwave.handler.ZWaveThingHandler.bridgeStatusChanged([183:org.openhab.binding.zwave:]
at org.openhab.binding.zwave.handler.ZWaveThingHandler.initialize([183:org.openhab.binding.zwave:]
at org.eclipse.smarthome.core.thing.internal.ThingManager$9$[105:org.eclipse.smarthome.core.thing:]
at org.eclipse.smarthome.core.thing.internal.ThingManager$9$[105:org.eclipse.smarthome.core.thing:]
at org.eclipse.smarthome.core.common.SafeMethodCaller$[98:org.eclipse.smarthome.core:]
at Source)[:1.8.0_121]
… 3 more

This is a problem with today’s snapshot that affects all switch_binary channels, see my post and if you could add your info to it as well that would be helpful:

I don’t think it will be all channels of this type - it’s devices that support the switch_all command class that are likely to have the problem.

As said, check the other thread and I’ll reply there.