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

Thank you both - I was indeed being dense. I’d grep’d NODE 26, which is the one causing the trouble. I’ve now uploaded the full log

Dan

I don’t see anything obviously wrong here - at least not with the binding. The only thing to note is that it’s getting to the point where it’s updating neighbours which can take a while - maybe this is what you’re seeing?

What is very strange is that I see the same information in your log multiple times - ie exactly the same data, with the same timestamps… Maybe this is something to do with your logging configuration - it just seems a bit strange…

well… when you’re on bleeding edge, its bound to be broken sometimes :slight_smile:

@chris, on the latest 988 version and development binding z-wave seems to be broken.
Log files show a lot of this:

2017-07-23 19:18:24.540 [ERROR] [l.serialmessage.SendDataMessageClass] - NODE 21: Sent Data was not placed on stack.
2017-07-23 19:18:24.545 [ERROR] [l.serialmessage.SendDataMessageClass] - NODE 21: Sent Data was not placed on stack.
2017-07-23 19:18:26.553 [ERROR] [lmessage.RequestNodeInfoMessageClass] - Request node info not placed on stack due to error.
2017-07-23 19:18:32.882 [ERROR] [lmessage.RequestNodeInfoMessageClass] - Request node info not placed on stack due to error.
2017-07-23 19:18:34.461 [ERROR] [l.serialmessage.SendDataMessageClass] - NODE 21: Sent Data was not placed on stack.
2017-07-23 19:18:34.466 [ERROR] [l.serialmessage.SendDataMessageClass] - NODE 21: Sent Data was not placed on stack.
2017-07-23 19:18:37.968 [ERROR] [lmessage.RequestNodeInfoMessageClass] - Request node info not placed on stack due to error.
2017-07-23 19:18:39.900 [ERROR] [l.serialmessage.SendDataMessageClass] - NODE 2: Sent Data was not placed on stack.
2017-07-23 19:18:39.907 [ERROR] [l.serialmessage.SendDataMessageClass] - NODE 2: Sent Data was not placed on stack.

It looks like there were big changes to ESH according to:

I doubt it’s related to the changes in ESH, and I’m not even sure it’s a binding issue - I suspect it’s more likely to be an issue with your system.

This error isn’t coming from the binding - it’s coming from the controller (ie the stick) and normally this sort of thing means the controller needs to be reset (ie removed from the PC and plugged back in).

really funny, I had restarted the computer several times before hand.
But removing the stick from the computer physically when it was running and then putting it back in did the trick.
Thanks

I found that the computer I run OH on does not kill power to the USB ports during a restart, so my zstick didn’t reset during a restart. This required me to power down completely or unplug/plug in the zstick to actually do a clean startup.

1 Like

@chris, can you shed any light on adding new channels to openhab? Is that permitted? Or can you only use predefined channel names? When I attempted to add the channel alarm_event, paperui errored out attempting to link the channel to an item.

I’m asking because I thought I might help code the changes and submit a pull request but I’m just learning ESH et all.

Thanks.

One other thing, I find that when I lock and unlock the Yale YRD120 a few times in quick session some of those signals get lost and never make it to the controller. However, in normal operation, my hack of changing the alarm_general channel to DecimalType has given me exactly what I need and has proven to be reliable.

Thanks.

@chris, this has been discussed in several threads.
But probably not regarding development binding.
My Fibaro eye (Motion Sensor FGMS-001) gives me:
Motion
Luminance
Temperature

However, alarm_tamper does not work.
Looking at the logs I can see that the command is sent but no “state is written”.

02:08:30.798	26	
RX REQ ApplicationCommandHandler SENSOR_BINARY_REPORT=255
02:08:30.801	26	
STATE UPDATE zwave:device:e25d115d:node26:alarm_motion ON [OnOffType]
02:08:31.357	26	
RX REQ ApplicationCommandHandler SENSOR_ALARM_REPORT GENERAL=255
02:08:34.717	26	
RX REQ ApplicationCommandHandler SENSOR_MULTI_LEVEL_REPORT LUMINANCE=10
02:08:34.720	26	
STATE UPDATE zwave:device:e25d115d:node26:sensor_luminance 7 [DecimalType]
02:09:01.670	26	
RX REQ ApplicationCommandHandler SENSOR_BINARY_REPORT=0
02:09:01.672	26	
STATE UPDATE zwave:device:e25d115d:node26:alarm_motion OFF [OnOffType]
02:09:01.831	26	
RX REQ ApplicationCommandHandler SENSOR_ALARM_REPORT GENERAL=0

LOG: https://www.dropbox.com/s/6adodsvs0vg2x94/openhab.log?dl=0
Development XML: https://www.dropbox.com/s/i8rbce8org4j0vh/network_d90b1add__node_26.xml?dl=0
OLD openhab 1.9 XML: https://www.dropbox.com/s/mddc72rbbb6vglo/node11.xml?dl=0

Cheers!

In your message I don’t see any alarm notifications :confused:. The channels are linked to notifications, so unless these are received, the tamper won’t fire.

The “SENSOR_ALARM_REPORT GENERAL=255” is the alarm_tamper firing when tamper is made and going “ON”.
And subsequently “SENSOR_ALARM_REPORT GENERAL=0” is firing again when going “OFF”.

Would I link these to a channel? And how would that be in items?
I tried “alarm_general” but that did not work.

Sorry - I’ve just realised you have an old device so it’s using the old command classes.

For this version, it should use the old sensor_alarm class. In the database it’s configured for type=BURGLAR - I guess you’re saying this is incorrect and it should be GENERAL. It’s hard to know from the logs which messages are related to which events so I can’t really tell.

This log is with only tamper going ON/OFF, node 26.
I have not edited it, this is the actual log.

I tried this item but it did not work

{channel="zwave:device:e25d115d:node26:sensor_alarm"}

This is the log when I did a wakeup.
It looks indeed it uses “General” for “sensor_alarm”. What that means, I do not know :slight_smile:

What do you need me to do to be able to troubleshoot this?

There is no such channel defined for the device :confused:. The required channel is alarm_tamper.

Nothing - I just need to update the database now.

Sorry - to be clearer… I’ve already updated the database, I need to update the binding…

1 Like

This is now updated - let me know if it’s any better/different (note that you’ll need to delete and add the thing back again to pick up the new definition).

It works exactly as it should!
And with this updated JAR now my Schuko Plug Switch that you edited the database for as well, works now :slight_smile:
Thanks a lot :heart:

1 Like

Sorry - I missed this one…

Not through the UI - the binding defines all the channels.

Can you provide a debug log showing the response you want to process and I’ll take a look at adding this. It’s probably quite simple. It’s probably best to provide the log via a ticket on my website as I need to see the unencrypted data…

@shawnmix, @nolan_garrett and @chris I am experiencing the same issue when attempting to securely pair my kwikset 914 lock. I just built the development branch yesterday evening and installed it into my add-ins folder. I am sure I am using the development branch (…zwave-2.1.0-SNAPSHOT.jar):

In the paper UI it shows that a release zwave binding has been not been installed and I’ve had to execute:
feature:install openhab-transport-serial
to get the development branch working.

I have noticed that if I remove all nodes from my zstick-Gen5 controller (verified via zensys-tool) and then try to pair the lock, it will pair securely. If I add a few nodes and try the same thing the lock will not pair securely. I’ve spent at least 5 hrs trying numerous variations of this. Securely pairing the lock only seems to work if I remove all nodes from the controller or reset the controller. The only error I get in my log is that secure inclusion failed.

2017-07-30 02:37:10.092 [INFO ] [mmandclass.ZWaveSecurityCommandClass] - NODE 26: Using Scheme0 Network Key for Key Exchange since we are in inclusion mode.
2017-07-30 02:37:41.813 [ERROR] [alization.ZWaveNodeInitStageAdvancer] - NODE 26: SECURITY_INC State=FAILED

On the bright side, secure pairing works and I can operate the lock w/o issue. On the downside, I’d also like to securely pair a garage door controller someday.

I hope this saves someone else a few hours of trial and error, or a solution is found. The above tests were done w/ the 2.1.0 release runtime

1 Like

If you use debug logging, there will be more information…

Unless there’s a reason not to use it, there’s already a prebuilt version linked from the top of this thread. I would prefer that people use this unless there’s some reason not to as it means there is some traceability against versions…

Anyway, I would certainly be interested to see the logs. Logs that I’ve seen in the past mostly have no other communications with other nodes, so it’s a bit unclear to me why the existance of other nodes in the controller would impact this - or more to the point, what I can do to resolve it…

Personally I’ve not seen this issue which is a pain from a diagnostics perspective! This is with a Yale Keyfree lock - I’ve also now got a Schlage BE469, but that also worked fine but as it’s my only US device, that’s probably not surprising given these reports :frowning: .