Request to add device to the Z-wave DB - New version of ID Lock

Tags: #<Tag:0x00007faee06a8038> #<Tag:0x00007faee06afe78>


I have the new version, 150, of ID Lock. Today I got my hands of the new Z-wave module that just was released, but I noticed that there is no entry for this new version in the Z-wave database. There is one for the older version, 101, which you can find here. The Z-wave manual for the new lock can be found here.

I would now need help to add also this newer lock to the database. I don’t even know if I’m placing the request in the right place or even under the right topic in the forum. So please point me into the right direction in case I’m in the wrong place.

If there is someone out there who is willing to create this I’m more than happy to support in testing.


1 Like

You can find information on adding devices to the database here.

Thanks Chris!

When I included the lock it didn’t create an XML file, seems like the same thing happened when the the previous model was added to the DB, check this topic. So I check z wave alliance’s homepage for the locks (or actually the z wave modules) and found both, ID Lock 150 and ID Lock 101 to start adding it manually.

When I checked Device ID and Device Type for the 150 and compared it to the exiting device 101 in the DB it looks like they are identical, but the Manufacturer ID differs.
From the DB: References (Type:Id) 0003:0001

ID Lock 101 - from Z wave alliance "Download Product Data in XML Format"

  • Manufacturer Id 0x0230
  • Product Type Id 0x0030
  • Product Id 0x0001

ID Lock 150 - from Z wave alliance "Download Product Data in XML Format"

  • Manufacturer Id 0x0373
  • Product Type Id 0x0003
  • Product Id 0x0001

To me it seems like the Device Type is misconfigured in the 101 model that exists in the DB. However, I’m a total noob and don’t even know if the data on z wave alliance is trustworthy.

Could you please advise me on how to move forward?

If it’s not creating an XML, then there are more problems than potentially incorrect database as it means the binding is not able to communicate properly with the device. The binding should always generate an XML, even without the database entry (99% of the time anyway).

Are you using the development version of the binding?

I just installed whatever version is available from the paper UI, so most probably not the development version. I’m new to Linux (running Raspbian on a RPi3) and don’t even know how to install a development version of a bindind :s

Have a read of the first 5 or 6 messages in the thread I linked above - this should tell you how to install it, and if you have any problems, just ask…

I was able to try this out now and I got the new binding working and added the lock, it was easier than I thought :smiley:

I now have the lock among my things in PaperUI and can change codes and label them, but that’s it I can’t lock/unlock it or do other actions. Is this where the database comes in place? In that case I’m back at my original question that this is missing in the DB but has the same Device Type and ID as the exsiting one has. What should I do?

Thanks for all the help and sorry for my stupid questions :slight_smile:

Was the device correctly identified? If not, check for the XML. If it was created, follow the link in the second post for instruction on how to add the device to the database, and add your lock. Since the 101 and 150 have different manufacturer IDs, they will need separate entires in the device db. If they are identical, or the 150 just adds functionality, there is an option to copy an existing device, then you can upload the XML and add the new stuff rather than starting from scratch. If you run into problems, just ask. There are no stupid questions!

Yes, it was correctly identified and I found the xml. But as I wrote in the first post it looks like the device type and id are the same for the existing one and the one I want to add. Is that not a problem if the manufacture ids are different?

Devices in the db can’t have multiple manufacturer IDs, so there’s no problem there. But it sounds like it was identified and initialized if you can add codes. But I don’t see any channel for codes in the device you linked to. What do you see in Habmin> Things> select your lock> Attributes?

What is the difference? Is it just the name, or are there other technical differences such as configuration parameters, command classes etc?

If it’s just the name, then we can deal with that by putting an X in the name. If there are changes in parameters, then we need to add a new database entry for this version.

Are you saying rebranded devices no longer need to be added in for each manufacturer?! In this case though, the manuals show some configuration parameter differences between the 101 and 150.

No - I’m not saying that :wink:

I missed that the manufacturer ID had changed - I assumed it would be the same manufacturer, and just the version number had changed.

You’re right though, as the manufacturer ID is different, it will need to have a new entry.

1 Like

Ok, thanks for clearing this out. I’m away now until Wednesday and will add the xml to the db when I’m back home. I’ll let you know when (not if) something is unclear :smiley:

So, I couldn’t wait until Wednesday and have added the device now based on the node XML. I think I only have the classes left to define, but I don’t have access to Openhab until I’m home so that has to wait. Or are they the same as for the Endpoint that were populated automatically?

Meanwhile I think I’ve sent it for review. At least I pressed the button, but I didn’t get any feedback (that could be something to improve on the website Chris :wink: ). So I don’t know if it was sent for review or if it requires the classes to be added.

I ticked which command classed are available in Sec and UnSec, but I have no idea which ones are sent out by the node at the start of the initialization (the NIF option as I understood it). Is this required or is it just for information?

Also, do I need to add anything about the notifications or is that handled automatically, formatting etc.?

Finally, as I understand it the command classes that has green boxes under them with a “+” are the channels that will be available for Items. The Battery and Power level command classes does not have the box so how should I get that information if not through a channel? Or have I missed something?

EDIT: Remembered one last comment/question. After I’ve done some reading I strongly suspect that the lock was not added securely, but I will check that when I come home as well. Does this have any impact on the node XML file or is it just a matter which commands classes that will be available? Also, to my understanding the secure inclusion can only happen when the controller is connected to the hardware (RPi in my case) and inclusion is triggered from OpenHab? My RPi is located on the top floor in my house and the lock is attached to the front door on the bottom floor. Is the distance a problem when wanting to include a device securely? I’ve tucked away the RPi and all the wires nicely now and want to avoid wrecking it just for the short inclusion. I don’t feel like taking the door down from it’s hinges and dragging it to the top floor either :joy:

My understanding is that these are just informational, until you add a channel.

The channel for the battery will be added automatically (not added through db), and Power Level is more of an internal CC for the device (it does not report the power level).

Once securely included, there may be some additional CCs added into the XML. Better for @chris to answer this one. But updating the info in the db would only be informational and should not affect the functionality of the lock when used with the binding.


Yes. You will need to be within about 10ft. Closer is better. You could uninstall the lock and take it to the Pi, or shutdown OH, unplug the controller, and use another software to do the inclusion, or setup another temporary instance of OH on a laptop to do the inclusion. Be sure to exclude it first.

Last night I updated the classes and sent it for review. This time it actually showed a record in the “log” that is displayed at the top of the device page. However, it seems like the rest of the log was cleared when I asked for review the previous time so now it just says that it’s asking for review of the update of the classes. Is that a problem?

Hopefully tonight I will have time to include the lock from a shorter distance. But where in habmin (or other place) can I check if the device has been included securely?

I don’t believe this is an issue. The log will be displayed after a change is requested. After the request is published, the log is cleared. Your previous changes must have been published.

Look under the Thing’s attributes in Habmin. If securely included, there will be a green check mark.

I must have missed your answer Scott. I was able to get the RPi very close to the lock and when I included it in habmin I got the notification in the top right corner that it was securely included. However I thought the security check box was just for informing that the device supports secure inclusion, but this means that it’s been securely included from day 1 :smiley:

So I guess I’m now just waiting for the final review of my DB entry and then I’m good to go. Do I need to reinclude/heal it after it’s available in the DB or should openhab update the device automatically?

You won’t need to reinclude it, but you may need to delete the Thing and rediscover. That will load the new Thing definition. It’s possible that you may not need to do anything though, once it is correctly identified. Hopefully, @chris will approve the changes and get a build out this weekend!