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

Sorry to be dense, but what’s a filtered log?

Are you doing a grep for NODE 26? That would filter out a lot of other stuff.

Exactly what @5iver said - you’ve used something like grep to filter out messages to a specific node, and this has removed most of the information I need…

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