What is the device?
Linear GD00Z-3 - but keep in mind I had these same issues with Kwikset locks (a handful of models), so I am 99.9% sure this issue isn’t device specific.
So, to be clear, on all your devices you only have 1 channel? That is strange as I’m sure that this is not the case with most people (and not the case here that’s for sure).
If that is the same as the NGD00Z-4 that’s in the database, then there is only 1 channel so what you see is correct based on the database definition. It doesn’t look like the device supports a lot of functions so I’m not sure what you think is missing?
It actually shows up as a NGD00Z-4. I have two though - one I included via OH2 after my accidental hard reset, the other I just did. The one I did early on shows 17 channels:
Again, not a big deal. If there is only one channel, then maybe this solution works for other secure devices as well.
Someone added a lot of random channels to this device a while ago and it looks like they have been removed now. Your old device probably still has the old definition.
Clearly devices can have moe than one channel so this is fine.
Delete the Thing and then rediscover to remove those extra channels, which the device does not support. I went through the same confusion when I added my second one. You can find more details here on the history of that device, item definitions, and some example rules (I’m using lambdas now, so let me know if you’d like me to share them)…
Yep, fixed it! I wish there were a way to know when a Node needs that.
@nolan_garrett - thanks for the info on the ZenSys. I’d seen approaches like this before, and as I think you’ve indicated and realized - it’s a bit annoying to do just to get a secure inclusion. But at least it’s a workaround. The problem for me, I’m a Mac shop at home, so trying to get a portable device running windows is annoying. VM’s off the ESX server to run locally on a laptop, then fiddle with USB passthrough, gets a bit ugly! 
I wish we could identify what is different about our setups though that is causing this issue that isn’t seen by @chris. He’s gone a lot of good work digging into the core of things, I just can’t help but feel like we’re all overlooking something minute. Is there some type of like a “full report” we can output somewhere or some way to see all the nitty gritty settings on the ZSticks or something?
I’d also agree with @nolan_garrett about the device updates. Maybe there is a way to auto-refresh the devices at some type of set interval? Perhaps a component to the binding that can force a refresh of the XML files? Perhaps its just something to be added in HABmin vs the binding? I’ve found this on occasion that I needed to manually delete and re-add to update XMLs in the past, and as you’ve seen Nolan - I had the same issue initially with the Garage controller that showed a ton of channels that were useless.
1 Like
Update: I’m actually going to explore this docker container for OpenZWave to securely include as a workaround. Theoretically, this should let me quickly/easily spin up an OpenZWave container to do this, then scrap it when done. My only worry is the lack of ability to backup my ZStick (windows only it seems from Aeon).
It’s pretty easy to get running. But, the startup command doesn’t work as shown.
docker run -p 8008:8008 --device /dev/ttyUSB0 openzwave-control-panel
To get it running, I needed to change it to this
docker run -p 8008:8008 --device /dev/ttyUSB0 openzwave/openzwave-control-panel
When I included my lock I just grabbed my older Pi that was running OH1.9, plugged the zstick in and did the secure include there. No problems with the 1.9 secure binding, and I have 66 devices and could not get it to include with this binding.
Quick question: Can I use newest (Octoberish/Novemberish) 2.2.0 binding (development snapshot from @chris post)with my standard distribution (raspbian) packaged openhab 2.1.0 ?
I’ll ofcourse uninstall default zwave binding from openhab 2.1.0. My question is about usage of current dev binding with older openhab 2.1.
I’m not sure. I suspect that there have been some changes to ESH since 2.1 was released that might stop it working. You can try - if it throws errors, then the answer is no
2.2 binding works with openhab 2.1 - at least logs looks normal.
However it didnt resolve my problem I’m trying to debug for half a day already:
I did clean install from scratch, openhab 2.1. I also did full reset (20 seconds button press) of my usb aeotec serial controller). But I can not include any devices (they worked more less ok few months ago). It’s only controller which is visible. even gets some frames, and logs dont show any problems. The only thing I notices suspicious is that in zwave debug log I see both node1 and node255 messages.
Just to be clear: this is not related with 2.2.0 development snapshot. I just tried it to be sure, but the very same problem is with stock openhab 2.1.0
Any clues/suggesstions?
I’m not sure why you think that’s suspicious, but it sounds normal to me.
Not really - sorry. Inclusion is largely handled by the controller - the binding just sets the mode. Can you include using the button on the stick instead?
I noticed that I’ve quit getting updates from my locks. When I ran a debug test I got the following error messages:
04-Nov-2017 16:48:31.126 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 108: Application Command Request (ALIVE:DYNAMIC_VALUES)
04-Nov-2017 16:48:31.129 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 108: Incoming command class COMMAND_CLASS_ALARM, endpoint 0
04-Nov-2017 16:48:31.132 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 108: SECURITY required on COMMAND_CLASS_ALARM
04-Nov-2017 16:48:31.134 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 108: Command Class COMMAND_CLASS_ALARM was required to be security encapsulation but it wasn't! Message dropped.
04-Nov-2017 16:48:31.137 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 108: Commands processed 0.
How could I loose secure communication with these nodes?
Call me old fashioned. I have one controller on my network. So I don’t get why it uses simultaneously both node1 and node255 in logging? 
No. I can not include using button on the stick either. I does not include those two battery operated thermostats. It does react to exclusion with them though: Upon moving stick close the thermostat, and putting stick in exclusion mode, immedietaly after pressing button on the thermostat, I see exclusion confirmation on the stick. But If I’d like to include the device in similar fashion, it does not work. They did work before reinstall. I also replaced batteries in them. THey are different brand (Comet and Stella) so I’m reluctant to blame them.
Whats more interesting: inclusion problems happen only with those two battery operated thermostats. All other power operated devices, can be included within both openhab and stick alone.
It doesnt make sens 
Of course, I completely rebooted the thermostats, or so I hope I did. Also with completly removing batteries etc.
There are two functions in the controller though - one uses node 1, and one uses node 255 for logging.
My locks all of a sudden quit sending me status changes on the lock_door channel. I still get the raw alarm code updates but even when the door reports through the alarm code that it was unlocked the lock_door channel still reports it as locked.
Here are what I think are all the relative debug log entries to the unlock event:
https://drive.google.com/open?id=19Dom49uwJAS9XzmDg1xj7HvyjINbLzpr
Let me know if I missed any or any other testing you want me to pull logs for. This is for a Kwikset 914TRL
Have you checked the battery level? I had a similar situation happen a little bit back. I was boggled as suddenly the lock would no longer operate via ZWave and I wasn’t getting updates. Turns out that somehow, the battery was low and it was no longer communicating properly. Replaced the batteries and got it back up to 100%, restarted OH for good measure, and suddenly it was communicating again.
1 Like