Ahhh.
I see…Then it is in fact still running.
openhab> list | grep serial
25 │ Active │ 80 │ 3.12.0.OH │ nrjavaserial
Thank you for clearing up that misunderstanding
1 Like
Whoa… hold up. I only meant to suggest to add the id and type to an existing xml. My lock had an xml that looked pretty much complete, but was missing the id/type. I didn’t realize yours hadn’t been created yet for your device. Are you sure your lock is in range of the controller, or has other devices with beaming available to route through? Getting the lock to complete secure inclusion is the first hurdle… the next is to get it to communicate with the controller once it’s mounted!
How can nrjavaserial be installed without the serial binding? Or is this a new change where the serial binding is not needed? When I first setup the development zwave binding, I had to manually install the serial binding to get things working.
Node 2 xml already exists. It looks like the correct deviceID and deviceType is already in place.
The lock is directly on top of the controller. Cannot get it any closer until matter phasing tech is created 
Secure inclusion is already complete.
I’ve tried using the alpha z-wave binding via the marketplace instead of directly in the addons folder, but similar results. I deleted Node2.xml, then re-added. It will not add it securely. When I replace Node2.xml, then it comes through securely. I had thought that removing Node2.xml and restarting the service would force the binding to recreate the xml file. I think I may need to exclude the device from the network, delete the xml, restart the service and try re-adding it. I’m away from home, so I cannot trigger the exclusion on the lock until I get back. I don’t know why the xml would not get created correctly in the first place, and I am unsure how to “fix” the xml so it is properly imported.
Also possible I just don’t understand something, or missing a component in my mind. Device should be added, show up in Secure inclusion mode. I was expecting it to Not be an Unknown Device, and thought I would see some Channels for it that I could assign to a Item. I believe there were channels before when included but not secure. I have other devices to add tonight once I acquire some 14GA wire.
nrjavaserial was always there on my installation, I didn’t have to do anything extra for that. I was always looking for openhab-transport-serial, thought this was the serial installation required.
I’m just back from holiday so haven’t read the large number of messages here, but in general, you shouldn’t ever need to edit the XML that OH creates. There are some exceptions, but this file is used internally by the binding - you also shouldn’t need to delete it if you exclude the device - it will be deleted automatically, and should be recreated for the new node id when added again.
Why do you need to edit the file?
Hi Chris. Happy holidays.
I am trying out the security binding for a Yale YRD210.
I originally just included the lock using the mainstream z-wave binding. There were channels etc that I could access, lock position, battery. But had no access to the secure functionality.
Trying the alpha binding, but have been unsuccessful getting it to work. When I add the lock, it adds it in secure inclusion mode, but detects the lock as an “Unknown Device”. Logs show up as
[warn] wave.discovery.ZWaveDiscoveryService - Node 11: Device discover could not resolve to a thingType! 0129:0004:0209::83.32
I have completely removed/reinstalled OpenHab from mainstream source. Did not install any default bindings. Added the z-wave binding to the Addons folder (and now am trying the Alpha stream in Marketplace). It was suggested that serial was needed, but apparently that is already there as “nrjavaserial”.
So, currently have an issue getting the device to be recognized in the database securely, while having access to the channels available by the lock for battery status, lock status, etc.
I removed the device (not exclude, just remove), but the xml did not get removed, even after service restart. So I moved the xml out of the folder and then tried re-adding, but then the device does not get imported securely. So put the xml back in place, and I can import it securely, but it is an unknown device. Cannot resolve thingType. Most likely Operator error somewhere.
I am running the mainstream Openhab 2.2, not the Snapshot 2.3. I am not sure if Snapshot 2.3 is required? Or is just using the Alpha release of the new z-wave binding sufficient?
Not that I am aware of.
Maybe just a kind of coincidence. I have never had it installed and all is working fine.
This is the same development/security binding … either download the jar and put in in your addons folder or install it through the marketplace.
Installing the openhab-transport-serial feature installs the “driver” - ie the serial library, not the serial binding. You shouldn’t need to install the serial binding…
This is now in the database and I’ll be doing an update tonight if jetlag doesn’t get me first! 
The export is already done - once this is used, it should solve this issue.
No - 2.3 is not required
I’m not sure what you mean by this - you need the dev version of the zwave binding which is currently 2.2 as per the link at the top of this thread.
Thanks Chris.
I was looking at the database at cd-jackson.com, and the device list under Z-Wave Binding information in openHAB, and it was listed there. So I thought I had to be missing some step somewhere…but I now see the “Last Exported On” date on the web database that I had missed.
Looking forward to the update sir!
Since I switched to the Dev binding some of switch plugs are throwing:
14:29:21.592 [INFO ] [smarthome.event.ItemCommandEvent ] - Item 'PLUG8_switch' received command ON
14:29:21.623 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 29: Command received zwave:device:15348538564:node29:switch_binary --> ON
14:29:21.628 [DEBUG] [dclass.ZWaveBinarySwitchCommandClass] - NODE 29: Creating new message for application command SWITCH_BINARY_SET
14:29:21.630 [INFO ] [marthome.event.ItemStateChangedEvent] - PLUG8_switch changed from OFF to ON
14:29:21.634 [DEBUG] [ommandClassTransactionPayloadBuilder] - At build null
14:29:21.638 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 29: Encapsulating message, endpoint 0
14:29:21.643 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 29: SECURITY NOT required on COMMAND_CLASS_SWITCH_BINARY
14:29:21.647 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 29: Command Class COMMAND_CLASS_SWITCH_BINARY is NOT required to be secured
14:29:21.651 [DEBUG] [dclass.ZWaveBinarySwitchCommandClass] - NODE 29: Node doesn't support get requests
14:29:21.655 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 29: Encapsulating message, endpoint 0
14:29:21.660 [WARN ] [converter.ZWaveBinarySwitchConverter] - NODE 29: Generating message failed for command class = COMMAND_CLASS_SWITCH_BINARY, endpoint = 0
14:29:21.664 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 29: No messages returned from converter
not sure if it related to the binding or if its related to the fact I deleted and readded the things and something in the db was changed some time ago…?
This will likely be caused a setting in the database to disable these requests. There’s no error here though?
Generating the Message fails completely. :-/
NODE 29: Generating message failed for command class = COMMAND_CLASS_SWITCH_BINARY, endpoint = 0
14:29:21.664 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 29: No messages returned from converter
No, it didn’t fail - it’s disabled - there’s a difference
Ok i will have a Look at the DB when i am Home later.
Strange it Happens on Devolo and philio switches. So i guessed its Binding related.
Seems Like Somebody played too much in the DB.
Well, be careful. These things are not normally added randomly - especially this setting (this setting is normally added by me only). It’s likely there for a reason and if it is, and you remove it, then it will stop the device initialising.
mhhh
so the device worked flawlessy before I readded it and got the new DB definiton.
there is indeed a NOGET in the DB.
Since the device wont react to any command currently I think the NOGET must be deleted?
Can you check if you added the NOGET for
http://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/177#endpoints
and if you see a reason why it should be there? (initialization was no problem in the past)
thanks!
edit: same for:
http://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/1#endpoints
Maybe not for you, but maybe others?
Is this another device you have that worked ok?
I see there is a bug in the binding that stops both messages being sent when the NOGET is set.
Note that I’ve fixed this now - please let me know if it’s working…
thanks for fixing it.
I will test asap 
edit:
@chris can confirm it works now ! thanks for the quick fix!