That makes sense to me Chris. I can only speak for Yale deadbolts, but you could also use a number with a decimal to separate the two pieces of data - (alarm type).(alarm level). Ie 19.1 would be a keypad unlock by user 1 for my YRD 220/240 deadbolts.
Would it also be possible to create a channel to set user codes? What I’m looking to do is set up a rule that enables a user code for only 1 day a week (or whatever other parameters I can think of to restrict another user code access).
I agree with @dicksteel - I’ve been working fairly solidly with your testing plugin. Minus my snafu at one point with actual control loss, but overall it’s been working perfectly. I’d also agree it’s been much faster than the Vera ever was in my previous home.
I like the idea with putting the field as an alarm-number.alarm-level. Only trick may be ensuring universal compatibility for the channel? Hoping all locks only use 2 digit codes for both.
I’d also love to see the scheduling type features for lock codes, but I know that was something planned for some future time. Honestly I’m in no rush. I’d rather see a solution to the issue for devices with too many PIN code slots, like my 200 or so!!
I think that there’s an issue with these locks, that require some sort of delay after the initial inclusion and the start of the secure inclusion but I’ve not been able to test this. Personally, my Yale lock works 100% every time as did the other devices I used for testing and as I don’t a device that doesn’t work, it’s tough to debug…
Unfortunately since they don’t seem to be available in the UK (as far as I can tell) I’m not sure what I can do to test this. I have a US frequency stick (somewhere) if someone had a spare they could lend me… (or if someone has a broken lock they want to get rid of - so long as the zwave side works…)
I guess that would be my only misgiving about making this more widely available. Given that I was unable to pair my Schlage Connect with this binding and had to use an OH 1.9 setup. But I guess you’ll get more hands and eyes on it so maybe that’ll help. It is an improvement over the mainline binding regardless.
What I’ve seen in some logs people have sent (including yours I think) is that the lock just doesn’t respond to the secure inclusion messages. I think I’ve only seen this with the Schlage locks, and I have some sort of recollection about a delay being needed for these locks - unfortunately I don’t have one, and can’t easily buy one as they don’t appear to be available in the EU.
It’s the sort of thing that’s nearly impossible to handle through logs as there’s just no reaction from the device. On the other hand it’s probably something I would find easily if I had access to a lock so I’ll see if I can find one on this side of the pond…
I’ve a medium-sized zwave network (33 devices, battery and mains powered). The refactored binding is working smoothly, save for the “offline device” issue discussed upthread. So, once that’s fixed, I’d say this is ready for primetime.
(Big caveat: I have no secure devices)
I spoke too soon - just checking, and most (but not all) of my battery devices are showing the battery level at 1%, which definitely isn’t right…
This is also known, but should now be fixed in the latest version (at least I think I’ve merged that in already).
@dan12345 - believe this is a known bug at this point. The error is that it’s saving the battery percentage as a decimal (0.67 = 67%). To the system, that means the battery is at 1% as it’s translating the decimal to a number, next full number being 1. If you use HABmin, you should be able to see the true value, or through the REST API interface you can pull the value.
cool - thanks
OK. I’m being that annoying person who posts multiple times instead of collecting his thoughts first, but…
A perhaps related bug with the SE812 Siren - BasicUI shows “Err” and the log shows:
[WARN ] [ui.internal.items.ItemUIRegistryImpl] - Exception while formatting value '0.40000000' of item FireEscapeSirenBattery with format '%d %%': java.util.IllegalFormatConversionException: d != java.math.BigDecimal
The item definition reads:
Number FireEscapeSirenBattery "Siren [%d %%]" { channel="zwave:device:zstick:node43:battery-level" }
Dan
After many failed attempts via OH, I tried this trick of using Domoticz to include one of my four Schlage BE469 locks and was very excited to have it pair immediately and have the lock controllable and queryable through Domoticz .
I then shut down Domoticz and started up OH running this latest binding, I searched for and found the Thing in Habmin and then had to wait a while for a refresh and OH to show the correct device type.
After all that I was sad to find that Habmin shows the device as NOT using security. This attributes display looks exactly the same as all of my failed attempts via OH directly.
Also when I linked the ‘Door Lock’ channel to an item and tried commanding it I just get: [nal.converter.ZWaveDoorLockConverter] - NODE 38: Command class COMMAND_CLASS_DOOR_LOCK not found in the OH log.
@5iver It was not clear to me if you had successfully added your Schlage door locks via this method or if you had only added other zwave devices. Did you have any luck with you door locks in OH after adding via Domoticz?
@chris I understand there is not much you can do without your hands on one of these devices, I could lend you one but they are very heavy and the shipping to the UK and back to the US would be very expensive. Since this seems to work in Domoticz using OpenZwave is there anything I/we can do to give you more info? Do you know why pairing the device to the controller in secure mode in Domoticz as above and then adding the Thing to OH is still not showing as ‘Using Security’?
Are you using the same key in OH2?
Yes. I successfully secure included three BE469s and two NGD00Z-4. First, I’d double check that you are using the same security key in OH that you configured in Domoticz (OZW). IIRC, I think I may have needed to reinitialize a couple times to get the security to come through. If security goes from grey to red then reinit. The initialization will check to see if the device has been securely included when it starts up. Sorry… I can’t remember exactly… maybe I deleted the thing and rediscovered it instead of reinit. Maybe Chris can confirm which would apply.
[quote=“mcqwerty, post:1198, topic:21653”]
Since this seems to work in Domiticz using OpenZwave is there anything I/we can do to give you more info?
[/quote]Not really I think. The protocol is pretty clear, and as it works really well with every other device I’ve got I don’t think there’s a problem with my implementation. I think there’s something about Schlages implementation - possibly timing - that’s different.
I’ll see if I can get myself one off eBay - the problem is since they aren’t available in the UK I can’t actually use it once I’m done testing which is making me think twice at the moment… Since these devices seem to be really popular in the US, it would be good to find out what’s up!
I’d love to offer up my Schlage BE469 as a loaner for testing, but just as your thought of how much it costs to procure off eBay, it’s going to cost close $75 just to ship it to you! 
Then we’d be stuck having to get it back here too.
Is it possible you have Amazon Prime and can pick one up off there? If it has prime shipping it’s free, “borrow” it for 30 days, then send it back with a response of something isn’t working? I don’t like doing it, but at times I will admit I’ve done it. Feels like I’m breaking rules so I only use that option when I must. Aka for the expensive stuff like this.
I did look on Amazon, but they only come from the US so I’m a bit worried that returns might not be possible (and given the price is twice that on eBay, I don’t wanna get stuck with it).
However, I like your thinking 
.
Ahhh, gotcha. I’m not aware how Amazon operates in other countries. That’s something I hadn’t considered.
The only other thought I had, was my last resort for trying to figure out my last issue. It’s possible I could set you up with a VPN access to a spare Pine64 I have running the latest OH snapshot (or whatever version). It has a separate ZWave module that I can use to separate from my regular running instance. This way you can remote in and get access to the actual OH interface if that helps and/or the low level communication with the ZWave module. The downside is any attempts at pairing activity, we’d have to try and co-ordinate a time that works best on both sides, and I can setup a remote session to work over with you.
Quite intricate, but putting it out there as an option to help out the binding. Obviously not something I could spin up overnight, but shouldn’t be too hard to get setup and available.
Thanks @Mike_Bagdanoff and @5iver I was not using the same security key. I added the key from Domoticz to OH and restarted.
Then I had to reinitialise the Thing as suggested by @5iver, it only took one reinitialisation and my BE469 now shows as using security!
I am now able to remotely lock and unlock by commanding a switch item linked to the ‘Door Lock’ channel. However the state of the item does not change when the lock is locked or unlocked at the device.
There are additional channels on the BE469 Thing that according to my experimentation behave as follows:
It seems logical that numbers 3 and 4 in 'Alarm (access) ’ and ‘Alarm (number)’ would represent locked remotely and unlocked remotely respectively but I have never seen either of these two numbers reported.
For fun I tried commanding these properties but it had no effect.
@5iver Are these findings consistent with what you are seeing?
Success!
Correct. You’ll need to use a rule to set the state based on the alarm notification. I use Alarm (number). My guess is that Alarm (access) is redundant and should be removed from the db, but I left it when I put in Alarm (number), which is how other locks were setup.
That is my understanding.
Here is a portion of my setup to show how I’m handling the alarm notifications to keep the lock states in sync. I used to run a script to poll the zwave log file in OH1 with security binding (which provided the alarm types you see in the comments… wonder why these changed) and the user that had entered a code. I’m still undecided what to do when jammed, as the lock may be locked or unlocked when jammed. To discuss further, we should start a new thread… this one is already over bloated!
Items:
Switch Lock_EntranceFront "Lock (Front Entrance) [MAP(lock.map):%s]" <lock> (gUS_EntranceFront,gLock,gSleep_Security) {channel="zwave:device:07cb40a2:node183:lock_door"}
Number Lock_EntranceFront_Battery "Lock (Front Entrance): Battery [%d%%]" <energy> (gUS_EntranceFront,gBattery) {channel="zwave:device:07cb40a2:node183:battery-level"}
Number Lock_EntranceFront_Alarm_Type "Lock (Front Entrance): Alarm Type [%d]" <shield> (gUS_EntranceFront) {channel="zwave:device:07cb40a2:node183:alarm_number"}
rule "Lock: Update lock states after alarm events (Lock_EntranceFront)"
when
Item Lock_EntranceFront_Alarm_Type received update
then
logDebug("Rules", "Lock: Alarm events: Lock_EntranceFront_Alarm_Type.state=[{}]",Lock_EntranceFront_Alarm_Type.state)
//21:locked manually, 22:unlocked manually, 18:locked with keypad, 19:unlocked with keypad, 16:wrong code entered too many times (#?), 5:tamper, 26:jammed, 161:failed user code attempt
//21=1, 22=2, 18=5, 19=6, 26=11
if (Lock_EntranceFront_Alarm_Type.state == 1 || Lock_EntranceFront_Alarm_Type.state == 5) {
Lock_EntranceFront.postUpdate(ON)
logDebug("Rules", "Lock: Alarm events: Lock_EntranceFront updated to ON (locked)")
}
else if (Lock_EntranceFront_Alarm_Type.state == 2 || Lock_EntranceFront_Alarm_Type.state == 6) {
if (Lock_EntranceFront_Alarm_Type.state == 6 && (Presence.state.toString == "Away" || Presence.state.toString == "Sleep")) {
Presence.sendCommand("Home")
val String textMessage = "Lock_EntranceFront unlocked with code, so Presence has been changed to Home"
logDebug("Rules", "Lock: " + textMessage)
SMS_Notification.sendCommand(textMessage)
}
Lock_EntranceFront.postUpdate(OFF)
US_HallwayEntrance_Dimmer.sendCommand("100")
logDebug("Rules", "Lock: Alarm events: Lock_EntranceFront updated to OFF (unlocked)")
}
else if (Lock_EntranceFront_Alarm_Type.state == 11) {
SMS_Notification.sendCommand("Lock_EntranceFront is jammed")
}
end