As mentioned already, this version handles the offline state differently than the master version. It uses the controller to decide the node state but the controller reports offline too often so I will change this back when I get a chance.
The reason I’m hesitant to use separate channels for this sort of thing is you then need to correlate the information from different channels, and this is likely to be unreliable. If you have 2 channels - one with the user and one with the open closed state for example, how do you combine these reliably? They could come in different order due to threading so you can’t for example just assume that each time you receive the user, that the current status is the status from that user as the status may not have changed yet.
I think it’s better to keep all attributes for an event together to avoid any ambiguity. Unfortunately ESH doesn’t have a way to do this - I tried to start a discussion on the ESH forum, but had no response! From other discussions the best option seems to be to create items using strings and put all the information in the string.
I agree it would be best to keep them together to avoid confusion.
1 Like
So I had a disk crash here about a week ago and finally got the computer up and running again. Having some problems including my lock securely. Went very good at first try last time with the lock 5+ meters away. Now I have tried everything it feels like, including moving the lock 1 cm from my UZB-stick in my server. Tried hard resetting my controller a few times as well as reseting the lock and reinstalling openHAB.
Getting this error right now. Installed unstable build from repo a few days ago along with the binding from 26th or 27th of June. Any suggestions?
Lock is a Danalock V2, worked perfectly before my setup crashed.
2017-07-02 22:29:12.557 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'zwave:device:d70bfb6a:node2' to inbox.
2017-07-02 22:29:13.834 [INFO ] [mmandclass.ZWaveSecurityCommandClass] - NODE 2: Using Scheme0 Network Key for Key Exchange since we are in inclusion mode.
2017-07-02 22:30:23.241 [ERROR] [alization.ZWaveNodeInitStageAdvancer] - NODE 2: SECURITY_INC State=FAILED
UPDATE: The bug fix for this was apparently that I needed to type a long forum post explaining my problems and try again for the 54th time the third day of having problems. Just in case someone else gets the same problem. Literally worked 5 seconds after doing these simple steps…
1 Like
Hmm, I think I understand this now. Interesting as I have I think a similar case or two in some of my rules where I use this methodology and it has worked. But your point makes me think so far I’ve been in good shape, but it’s possible this could fail me at some point! 
So for that reason, I guess I would agree, it would be good to keep them together. I guess I won’t be able to see who’s opening the door anytime soon … 
Oh well - I’ll have to suffice with camera review if I need to know who it is 
I haven’t had to do a secure inclusion for a while. When I was setting up my secure devices, I tried everything over and over without any success. I had even put OH on my laptop so that I could walk around with my zstick attached (same security settings) and pair my locks without taking them off the door and garage openers off the ceiling. Nothing worked, literally, for weeks. I was very frustrated, so I finally setup Domoticz (uses OpenZwave) on my laptop and BAM had three locks paired on their first try. Took the laptop into the garages and BAM paired up the door openers. No retries, no resets, just worked. Popped the zstick into the OH server and all was golden. I’m not suggesting this is the best long term solution (using something other than OH) for secure pairing, but it worked very well for me. I’m very hesitant to send this post out as I don’t want to offend Chris or anyone else who has worked on this binding by offering an alternative for secure inclusion. But knowing how frustrating it was, maybe this info will help someone who’s ready to give up on OH.
If secure inclusion is still as difficult as it was, there could be a lot of unhappy campers if this rolled out to a larger audience. Maybe I just lucked out with secure devices that are finicky with timing during inclusion. I have a couple uninstalled BE469s that I’ll test the secure inclusion on this week, using the current binding, and see if it goes any smoother.
For me, the answer is absolutely YES. I have a small z-wave network - 3 deadbolt - plus a thermostat and repeater added so there were neighbour nodes to improve the reachability of my garage deadbolt.
I have been using the security version of the binding on one deadbolt to trial it since March and my opinion is Zwave through OpenHAB is more reliable and it functions my locks much quicker than my Vera Lite setup. Once you added the lock alarm codes so i could get lock status updates, I transferred my entire z-wave network over to OpenHAB and have unplugged my Vera with no regrets.
Thanks for all the work you put into this Chris.
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?