I wanted to establish if the failure-to-communicate problem was part of my config or not.
I’ve also since confirmed that the BRG controller is not supported under openzwave with the same kind of problems.
Well it certainly didn’t happen under the old z-wave binding, but if you like I can switch back to it and try for awhile to ensure it certainly is something in this one. I’ve just had a kid and my time to work on this stuff is a little lacking right now. 
But probably (??) the zwave binding isn’t the only thing that’s changed in your system?
Looking at the log, the errors are coming from another binding, so I just think that this would be the first place to look?
Even if the problem is with zwave binding, it’s not reported by others, and there’s absolutely nothing in the logs that points to anything in ZWave - pretty much all logging just stops from all bindings except the homekit one which reports errors. Unless you can find a bit more to go on, I’m afraid I can’t help much - sorry.
Just following up on my earlier reports of a fresh device not secure including properly. I finally was able to manage to get it to work, but it required a full reset on the ZStick. So if you’re running into issues with the Secure inclusion not succeeding, it may be that you need to check the possibility of resetting the ZWave controller in use. At least that solved it for me. Now successfully transmitting.
@chris One issue I have found though, and perhaps this hasn’t been fully fixed/implemented - User Codes are not making it to the device. I tried to add in 3 user codes, but none of them appear to have successfully been transmitted to the device. Should I open a ticket and try to get some logs of the transmission? And/or is there a way to “force” the transmission and watch it? I tried to watch DEBUG logs as I put the codes in, but didn’t see any specific transmissions.
Yes - feel free to raise a ticket with some logs and I’ll have a look.
Cheers
Chris
Just wondering if anyone has successfully used the latest test version with the Yale keyless connected lock?
thanks,
Dan
Yes - I use this device and it’s working fine. I might not be using the 100% latest version on my production system, so I can’t say “yes” if your question is really about the “latest” but otherwise it’s ok.
cool - thanks, Chris. Out of interest, does the binding let openHAB change the PIN code? Or is it just unlock and notifications?
Dan
It should, but someone did say recently that this might have a problem, but it was working in the past - I’ve just not tested it recently.
Chiming in, I just recently added a Yale keyless touchscreen lock. Mine is slightly different than what was linked above. But I’d imagine it’s operating a similar firmware inside. I had some trouble getting it included originally, but was resolved by fully resetting my ZWave controller (Aeon Stick Gen5). Once that was done, I was able to get it securely included.
The PIN code was not working for me though. I opened a ticket and sent some logs to @chris to review this and see if there is an issue or if something is just causing me grief again. 
But it does successfully provide the lock/unlock function. I’m working on the User Code function and the Alarm notifications for status of manual lock/unlock. It’s slow going lately due to real world work.
I’ve not look at your code issue yet - this should be simple as it was definitely working in the past. I should have time on this next week.
Alarm notifications are easy to add if you want to update the database? There is already functionality in the binding to manage this.
However, I don’t plan to link these alarms to the lock status though - this will need to be done in a rule for now as I don’t want to hardcode device specific code into the binding. If that’s what you’re working on, then I almost certainly wouldn’t be happy to merge that into the master codebase and I’d recommend writing it as a rule that others can use (I hope that makes sense?).
thanks both!
I believe the alarm channel is already in there for my device, so assuming I shouldn’t have to add anything.
Forgive my ignorance as I haven’t delved into this yet. What type of rule would need to be written here? Wouldn’t it simply be something that reports back when the lock is manually changed? Or am I misunderstanding what the Alarm channel does provide. I haven’t monitored the updates yet to see the various item states that are reported on this channel.
EDIT: I was just thinking, perhaps what you are thinking is I would need to do similar to my Garage Door item, where the status and actual state need to be kept in sync. Aka 2 items that I have to use the postUpdate mechanism in a rule to make sure the 2 items stay in sync?
Yes - if you wanted to have a consolidated item that is updated when the lock status changes, then you would need to combine different bits of information from different channels (ie the lock status, and the alarm channels). I thought that this is what you meant you were doing when you were working on the status of manual unlock/lock.
Maybe I read too much into what you said?
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”.