OH2 Z-Wave refactoring and testing... and SECURITY

No, not only following successful pairing. Believe me, when I implemented the security code I had many unsuccessful pairings and I never did anything more than exclude the device and delete the thing.

Thank you all so much for your help!
Here’s how I figured things out, turns out I was being a little to anxious in my “redoing” things.
I followed your directions Chris, though with some modification that I’ll share just for giggles.

  1. I first started by deleting my Thing.
  2. I then shut down Openhab, removed ZStick and took it over and excluded the lock using the button, as watching the logs I couldn’t get exclusion mode to work in Habmin.
  3. Then I started openhab and let everything settle down to just normal traffic.
  4. Started inclusion mode and included the lock from its keypad.
  5. I then watched the log and for a minute or two and the binding had a constant output, I took a wild chance and flipped the deadbolt a few times and the logs settled back down in frequency. When I did this instead of it being in my inbox as just nodeX and unknown device, it said Yale Lock 220 blah blah.
  6. I went ahead in the PaperUI and added it as a thing and as of now I can lock and unlock the lock from openhab. Its still showing 0% battery but I’m betting that’s going to be fine.

I am going to see if I can save the log from this whole adventure but man, thanks again guys.
Also any of you guys take donations? I don’t think I am technically capable of contributing in any sort of meaningful way but I certainly wouldn’t mind buying a few beers, or whatever your particular vice may be!

Glad you got it working, the documentation of you resolving your issue will help everyone else in future in the same position as yourself, that’s all the help anyone will need :slight_smile: I’m in the same position as you - no working knowledge of openhab, just personal experience and an eager keyboard :slight_smile:

@chris could you tell me what the alarm function does? I turned it on in openhab, and it did nothing, will the alarm go off now if someone tries to break in?

I’m just wondering if it might be better to have a separate bundle for door lock items instead of having the z wave thing manage everything, as that is going to be quite the task to provide rich functionality for all devices…

Just remember that logs may contain security information, so be a little careful if you are planning on distributing anything :wink: .

I am always happy to receive donations - it helps cover some of my costs (eg buying USA locks to support testing which I can’t use in EU, devkit costs, test devices…). There is a button at the bottom of this page on my website if you like :slight_smile:

Can you tell me exactly what you are referring to? There are many different alarm functions - some are smoke alarms, some are entry alarms, some are water alarms… Some locks also (mis) use this function to provide alerts such as the door opening, user ID of the person who opened it etc but this tends to be less standard in most current locks.

I don’t understand what you are suggesting here - if it’s a zwave lock, then it must be managed by zwave. There is only a single zwave controller (unless you have a system with multiple controllers somehow?) and therefore all communications needs to be managed through this interface and through the ZWave binding (or am I really missing something?).

In any case, I don’t see the need to split zwave locks into a separate bundle - even if we could resolve the communications issues (somehow), it would still be easiest to keep it combined - locks are just one of 120 command classes that zwave supports.

My yale keyfree gets a “alarm” button, however don’t know what it’s for… I don’t get a notification when the door opens, and it doesn’t set the alarm off, was hoping someone might know…

Well I was thinking of there being an opportunity for a lot of functionality with regards to a lock, as simple as a lock is, a smart lock can offer quite a bit such as timed lock usage, scheduling, 1 time locks, notifications of who used the code, having to develop that as part of one class of the 120 just sounds like you are going to be swamped in requests for additional functionality… as a means to lighten your load, I was wondering if it would be more effective to split out classes into their own project, but yes, they all use z-wave so I guess it is easier to have all in one

I suspect that this is simply misconfigured in the database. The device sends alarms to notify of certain events - in my opinion it’s misused, but that’s what it does…

Most of this is not zwave functionality, and is not even binding functionality. Scheduling etc is handled outside the binding - the binding should provide the minimum functionality to support the devices and allow the system to interact with the items. Otherwise we end up with every binding developping such functions for their locks (BLE/ZWave/ZigBee/HomeMatic/…) and it’s not how the system is meant to work. Clearly passing information such as user codes is part of the binding (and it’s already implemented) but adding complex functions is not something I would recommend as part of a binding.

@chris I was following the Qubino status thread, and was looking around when I found something that I consider rather strange; on one of my Qubinos, I have a node neighbour list that simply cannot be true - it is listing a device that has not been around for about 18 months - node 2. Node two is probably still on the stick though (Aeon Gen5), since I have not been successful in removing it. I know there’s a generic zwave tool that is supposedly able to remove ghost nodes, but I haven’t got around finding it. Node two are currently in the “inbox” after I have tried to add it and delete it about a month ago. Also node two was long gone when I added this Qubino, so I guess this is the stick doing bad stuff?

It also says that it was healed last night - shouldn’t the heal deal with these kind of issues?

1 Like

So as the fates would have it I spoke to soon.
I restarted openhab this morning and now the lock is back to its non functioning state, all the same log entries as before and nothing is working. So I guess my next set of questions is how to proceed?

So what things should I keep in mind when posting my logs?
What logs would be helpful, the setup? From startup now that it doesn’t work?

Repeat your steps that got it working.

What does openhab say on boot?

The heal won’t remove any devices - it’s not in the business of deciding that a node is removed from the network and then deleting it. If the neighbours shows a node in the list, then chances are the controller said that the node was a neighbour. The binding doesn’t do any processing of this information - it simply displays the information from the controller. If you have a debug log showing the heal I can take a look, but I would be surprised if this isn’t the case.

The first question I would ask is what changed? It shouldn’t just stop working. Did you change any configuration in the controller or something?

So long as the key hasn’t changed, the device should sort itself out.

I would recommend to open a ticket on my website and post me the full log.

I would stop the binding, delete the XML and restart the binding. Once the device has initialised (or at least once the binding has been communicating with the device for a bit) send the log.

Sorry, was in Italy for a few weeks and limited access to things. Mostly my home environment!! TL;DR - VPN wasn’t working.

Anyhow, I believe what dezito posted was what I did. But I think it might have actually been the serial plugin for me. For some reason, OH said it was installed in the UI, but somehow it wasn’t really. So I had to manually manipulate it at the Karaf console to remove it. Then install it. And I think again had to drop the ZWave plugin back in after this. I think you’ve got it solved now though.

No worries at all. I followed the suggestions and was able to get rid of the error. Thanks

Registered for the sole reason of saying thank you, Chris, for the work you’re doing. I’m really looking forward to the day I am clever enough or this is easy enough to use with my Yale Keyfree (not ‘Keyless’) system.

1 Like

I use the keyfree, works fine :slight_smile: you are referring to the door lock with handle and keypad yes? works for me :slight_smile:

If that’s the case, Stevenazari, I will migrate to OH2 and give this a go.

I will need to take a good backup first as I still consider myself a
relative n00b. Setting all this up with things like cctv, weather station,
plugs lights zones heating etc has been a painfully slow process for me
editing text files.

I would like to give a management gui a go sometime if you can recommend

Well you gotta bare in mind it’s still in test phase, chris is doing all he can to help everyone but can’t give you assurance, but we can help you get up to speed :slight_smile:

I used paperUI to setup, but you get more feedback from habmin :slight_smile:

I understand the binding cannot remove a node, but to me this is a controller bug - adding a node that has been long gone to a new-ish node. But I guess it could also be (more likely) that the new-ish node wrongly got the assumption that a broken message came from a ‘node 2’, and putting it into its neighbour list. Perhaps this is a problem with the zwave protocol - I think I read some time ago, that it has a very simple checksum on the messages.

Maybe - I don’t know without more information (ie the logs) to see what happened. I agree it doesn’t look right, but in any case I doubt I can do much about it.

I don’t think it’s “very simple”. Maybe you are thinking about the messages over the serial API (between the PC and the stick) which do use a simple checksum since it’s a reasonably reliable serial/USB link. The radio packets use something a bit better than this.