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

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
one?

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.

Just upgraded to 2.2.0-Snapshot and the 2.2.0.201710241752 ZWave binding.

In binding from 20171012 these errors were gone, but they are back in abundance now:

2017-10-31 23:32:48.205 [ERROR] [lmessage.RequestNodeInfoMessageClass] - Request node info not placed on stack due to error.
2017-10-31 23:32:48.221 [ERROR] [lmessage.RequestNodeInfoMessageClass] - Request node info not placed on stack due to error.
2017-10-31 23:32:48.226 [ERROR] [lmessage.RequestNodeInfoMessageClass] - Request node info not placed on stack due to error.
2017-10-31 23:32:48.248 [ERROR] [lmessage.RequestNodeInfoMessageClass] - Request node info not placed on stack due to error.
2017-10-31 23:32:48.251 [ERROR] [lmessage.RequestNodeInfoMessageClass] - Request node info not placed on stack due to error.
2017-10-31 23:32:48.254 [ERROR] [lmessage.RequestNodeInfoMessageClass] - Request node info not placed on stack due to error.
2017-10-31 23:32:48.258 [ERROR] [lmessage.RequestNodeInfoMessageClass] - Request node info not placed on stack due to error.
2017-10-31 23:32:48.261 [ERROR] [lmessage.RequestNodeInfoMessageClass] - Request node info not placed on stack due to error.
2017-10-31 23:32:48.264 [ERROR] [lmessage.RequestNodeInfoMessageClass] - Request node info not placed on stack due to error.
2017-10-31 23:32:48.267 [ERROR] [lmessage.RequestNodeInfoMessageClass] - Request node info not placed on stack due to error.
2017-10-31 23:32:48.270 [ERROR] [lmessage.RequestNodeInfoMessageClass] - Request node info not placed on stack due to error.
2017-10-31 23:32:48.273 [ERROR] [lmessage.RequestNodeInfoMessageClass] - Request node info not placed on stack due to error.
2017-10-31 23:32:48.277 [ERROR] [lmessage.RequestNodeInfoMessageClass] - Request node info not placed on stack due to error.
2017-10-31 23:32:48.285 [ERROR] [lmessage.RequestNodeInfoMessageClass] - Request node info not placed on stack due to error.
2017-10-31 23:32:48.288 [ERROR] [lmessage.RequestNodeInfoMessageClass] - Request node info not placed on stack due to error.
2017-10-31 23:32:48.300 [ERROR] [lmessage.RequestNodeInfoMessageClass] - Request node info not placed on stack due to error.
2017-10-31 23:32:48.306 [ERROR] [lmessage.RequestNodeInfoMessageClass] - Request node info not placed on stack due to error.
2017-10-31 23:32:48.309 [ERROR] [lmessage.RequestNodeInfoMessageClass] - Request node info not placed on stack due to error.
2017-10-31 23:32:48.312 [ERROR] [lmessage.RequestNodeInfoMessageClass] - Request node info not placed on stack due to error.
2017-10-31 23:32:48.315 [ERROR] [lmessage.RequestNodeInfoMessageClass] - Request node info not placed on stack due to error.
2017-10-31 23:32:48.318 [ERROR] [lmessage.RequestNodeInfoMessageClass] - Request node info not placed on stack due to error.
2017-10-31 23:33:03.300 [ERROR] [lmessage.RequestNodeInfoMessageClass] - Request node info not placed on stack due to error.
2017-10-31 23:33:03.305 [ERROR] [lmessage.RequestNodeInfoMessageClass] - Request node info not placed on stack due to error.
2017-10-31 23:33:03.313 [ERROR] [lmessage.RequestNodeInfoMessageClass] - Request node info not placed on stack due to error.
2017-10-31 23:33:03.322 [ERROR] [lmessage.RequestNodeInfoMessageClass] - Request node info not placed on stack due to error.
2017-10-31 23:33:03.330 [ERROR] [lmessage.RequestNodeInfoMessageClass] - Request node info not placed on stack due to error.
2017-10-31 23:33:03.340 [ERROR] [lmessage.RequestNodeInfoMessageClass] - Request node info not placed on stack due to error.
2017-10-31 23:33:03.376 [ERROR] [lmessage.RequestNodeInfoMessageClass] - Request node info not placed on stack due to error.
2017-10-31 23:33:03.379 [ERROR] [lmessage.RequestNodeInfoMessageClass] - Request node info not placed on stack due to error.
2017-10-31 23:33:03.384 [ERROR] [lmessage.RequestNodeInfoMessageClass] - Request node info not placed on stack due to error.
2017-10-31 23:33:03.387 [ERROR] [lmessage.RequestNodeInfoMessageClass] - Request node info not placed on stack due to error.
2017-10-31 23:33:03.391 [ERROR] [lmessage.RequestNodeInfoMessageClass] - Request node info not placed on stack due to error.
2017-10-31 23:33:03.400 [ERROR] [lmessage.RequestNodeInfoMessageClass] - Request node info not placed on stack due to error.

The biggest bursts were 1-2min after service restart. Settled down after some time. (5-10min)

Everything seems to be working OK. Just clutters up the log a bit …

Someone said it was only a one byte LRC or possibly one byte CRC, on the messages aired (pre gen 5). This may all be wrong though.