Not at all!! 
I hadn’t actually gotten that far was all. I knew the function was there, but I never got into the weeds of checking it out, seeing that I would need a rule to focus on a single item, just like I did with the Garage door. I was forgetting that for that I needed to “sync” the status, not that the alarm would update the actual lock item status. Hopefully i’ll get that squared away this week, then when you’re able to check the user codes I can get that squared away and be done with lock chaos! 
Not sure about other locks, but for the Kwikset I have, there would need to be more alarm channels. Current the AlarmCommandClass supports alarms 0-13 I think with 0 being the general alarm. The Kwikset (and I think Yale locks from the documentation) report Alarams of type 18 (Outside lock button pushed), 19 (Outside unlock), 21 (Manual Lock), 22 (Manual Unlock), 24 (RF Lock) and 25 (RF Unlock) among others. Some of these like outside unlock report multiple different values for the alarm that correspond with the user code that was used.
I currently have some code that works for reporting all of these under the general alarm type (though, that is just a hack). I’ve been going back and looking into adding alarm types to the ENUM to support at least these 6 alarms. @Chris, when I get this working I can send you what I have if you want.
The problem with the alarms is that for V1, they are non standard - the lock suppliers made them up (as is allowed in the spec, as they weren’t defined). I would probably look in future to remove this support for V1 alarm naming as we move toward a compliant binding.
We have a channel that can simply return the alarm report and this is what we should use here I think. This means you don’t need to add more alarm channels.
Sweet! I didn’t notice this before. I’ll have to take a look at it. Do you have any examples of making use of this channel? If you do, I’ll look at the rules to get it working 
I’m in the same boat here, I’d love to see an example or any documentation that could exist on what format this will look like? Am I guessing based on what you’ve mentioned that we can read a single string that will be returned from the Alarm channel that will have a format maybe: 13 - Message allowing us to parse the first 2 characters as the code and the subsequent info as the message from the alarm? Or am I totally misreading the explanation?
EDIT: If it wasn’t already apparent, I’m not quite an expert here on the ZWave tech side, but I’m interested in helping out as well if it’s something I can start to pick apart and understand.
Ok coming back to add a sideline question as I’m not sure if this is ZWave binding or something else. But I do remember having a similar type of issue with some devices after one of the ZWave binding updates came across and I had added in some newer devices. I also have isolated it to only 1 specific type of my ZWave devices.
Steps to Produce:
- Include new ZWave device
- Open HABmin to add the new device
- Device possibly not fully recognized at first, delete
- Scan for new devices, find newly proper recognized device this time
- Add device
- Once added, attempt to rename aka change the Label under the Properties section - will not change
- Attempt renaming other new ZWave devices of different Thing Type, no problem
The device in question is the HomeSeer Technologies HS100+ (the switch variant). Device is listed in the ZWave DB and as far as I was aware nothing has changed there. I have also noticed that that these devices also don’t like to show up properly the first time around often when adding new devices. It sometimes takes one or two deletes before it comes back with the full detail, or requires using the Reinitialise option in the Advanced Features section to find the right info recognized and the channels to populate.
Unfortunately there is nothing showing up in the ZWave debug logs, and consequently no apparent log anywhere. But I’m not sure what log I may need to tune up to DEBUG to see what my issue is if it’s a “general internal error”.
@Chris,
I uninstalled the ZWave binding and did:
cd /usr/share/openhab2/addons
wget http://www.cd-jackson.com/downloads/openhab2/org.openhab.binding.zwave-2.1.0-SNAPSHOT.jar
I deleted all things, including the Z-Stick and restarted OpenHAB2, then, through paper UI, i started a discovery process of wave and found the Z-Stick; i added it but it stays offline.
Console shows:
214 | Active | 80 | 2.1.0.201704062305 | ZWave Binding
I am a bit lost, what can cause this, how can i get the Z-Stick online?
br,
Raymond
Probably through:
It’s a number - I’ll dig out some information over the weekend.
I think there’s an issue with synchronising the inbox - it’s something I need to look into.
Probably you haven’t installed the serial dependancy - take a look at the top of this thread where the installation is explained (a few posts down).
@chris, @sihui,
i forgot to mention, i did:
ssh -p 8101 openhab@localhost
and then in the console:
feature:install openhab-transport-serial
So the serial dependency should be installed.
And i restarted OH2 after this.
What else could cause this?
br,
Raymond
I would suggest to look at the logs and see what it shows…
I´m seeing a NullPointer on the binding when updating the properties of a network node:
2017-04-08 21:27:25.276 [ERROR] [ome.core.thing.internal.ThingManager] - Exception occured during notification about bridge status change on thing 'zwave:device:9f8f9f9f:node12': null
java.lang.NullPointerException
at org.openhab.binding.zwave.handler.ZWaveThingHandler.updateNodeProperties(ZWaveThingHandler.java:1396)[184:org.openhab.binding.zwave:2.1.0.201704062305]
at org.openhab.binding.zwave.handler.ZWaveThingHandler.bridgeStatusChanged(ZWaveThingHandler.java:488)[184:org.openhab.binding.zwave:2.1.0.201704062305]
at org.eclipse.smarthome.core.thing.internal.ThingManager$12.run(ThingManager.java:851)[106:org.eclipse.smarthome.core.thing:0.9.0.201703201701]
This is after a completely clean install of the system, but where the UZB-controller had the nodes in its memory and I updated the name of one of them.
Thanks - hopefully it will go away once a device initialises further. I’ve found the problem and will do an update of this binding tomorrow.
The binding has succesfully identified and included my IdLock - lock (pun intended) to my network.
However I am not able to control it. When I command it to switch the lock it gives me the following entries in the log:
==> /var/log/openhab2/openhab.log <==
2017-04-09 17:33:04.838 [WARN ] [nal.converter.ZWaveDoorLockConverter] - NODE 19: Command class COMMAND_CLASS_DOOR_LOCK not found
==> /var/log/openhab2/events.log <==
2017-04-09 17:33:04.841 [ItemCommandEvent ] - Item 'Lock_IdLock' received command OFF
2017-04-09 17:33:04.848 [ItemStateChangedEvent ] - Lock_IdLock changed from ON to OFF
Nothing happens on the lock end at all.
This probably means the binding thinks secure inclusion did not happen, see OH2 Z-Wave refactoring and testing... and SECURITY
Did you get a message in habmin that secure inclusion was successful?
You are right Olav. Inclusion must have gone wrong somehow. Seems Using security is marked no (and same error when trying to control it).
Excluded it and did a new inclusion with the network set to use security for all types of devices. Got a new NodeID (22), but still did not mark Using security:
There is another thread with ppl also having trouble with this for the idlock. I did an exclude, removed all the batteries, and then included again with the controller close (20cm or so). That did the trick for me.
I`ll give it a try it. Extremely impractical to move the device close to the controller. The lock sure cannot be moved, but I will get a long network cable and keep it close.