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

Ok, sorry, I thought you meant a change to alarm_raw…

So are you suggesting then to redefine some of the values? ie you want value 2 to be a different value? If so, I don’t really want to do this if it’s device specific unless we can find a generic way to define it and then add it to the database. I really want to avoid device specific kludges in the binding if possible.

I’ll add in that I know different locks will provide different numbers it seems for different functions. So I’d vote on not adjusting because as a number, we can define it ourselves. If we try and make specifics for each device, universal use becomes much more difficult and more work in the DB just to make different locks work. Also, if something was to miraculously change (don’t think it would) - but imagine a firmware update changes the numbers by adding a new number in, bumping the others - you could end up with problems due to the difference in firmwares as well. Another layer of complexity.

This in theory should only be true for V1. For V2 and above, the definitions of the functions are defined in the standard and the locks should follow this if they are compliant to Z-Wave standards.

Hmm ok good to know. I didn’t realize there was a standard as different locks may have different features. I wasn’t sure how they’d “organize” that in a specific way. I guess perhaps my statement can be retracted then.

I’m suggesting that the events reported through the alarm_number and notification_access_control channels be filtered on type Alarm, for ALARM CC v2 and NOTIFICATION V3+ events.

Oh look, there are more worms in this can :stuck_out_tongue_winking_eye:. Having both of these channels available always confused me… aren’t they basically the same? Couldn’t alarm_number be removed? Also, I don’t see ACCESS_CONTROL (used in alarm_raw) as a type in the specification. Should this be ALARM?

For ALARM V1 you can use the filter already - that’s always been there.

For NOTIFICATION V2 and above it is currently removed as it interacts with the handling of the commands. I might look to change this, but at the moment the filter isn’t used.

No - it’s defined as ACCESS_CONTROL -:

image

At least for now people with alarms in their locks will hopefully be informed that it may not be someone unlocking their door, but a burglar kicking it in! But the alarm_raw channel can be used to correct this.

Lol… you yelled at me because I’m so blind :flushed:… the pages split the title and the underscore threw off the search… Access Control Alarm.

:wink:

I have a lot of “loud” code when it comes to defining constants :slight_smile:

1 Like

Note that the notification names will change to use the full name in the notification - so instead of ACCESS__KEYPAD_UNLOCK you’ll see ACCESS_CONTROL__KEYPAD_UNLOCK. If your rule uses this, then it will stop working

(and no yelling intended :wink: ).

No… by yelling I wasn’t referring to your loud constants but the image 3 posts up! I don’t exactly know why that transaction was so hilarious for me, but it still makes me giggle! :slight_smile:

Thank you for the heads up. My rules are parsing the NOTIFICATION value for LOCK and UNLOCK, so this change will not affect them.

You already provide the TYPE separately. IMO, it would be cleaner to remove the TYPE from NOTIFICATION so that it would just be the human readable EVENT name. Sorry to have not suggested this sooner, but I wasn’t actually planning on using alarm_raw until I was testing it out and realized that the EVENT numbers could be the same for different TYPEs.

Does it still make sense to have both the notification_access_control and alarm_number channels?

What do you think of a raw event channel, similar to alarm_raw but rawer? This could be provided for all devices, even ones not in the db. Then rules could be used to interpret the event, and perform actions or update Item states. Having the channels packaged up in the binding is very handy, but at times the purist in me just wants the raw data so I can shape it myself, without having to mess around in the binding.

Yes, you might be right - I thought I’d provide as much info so it can cater for any need…

No - probably not… I might leave it there for the time being to avoid screwing thing up, but will stop it’s future use.

That’s not currently possible as the channels are defined in the database - no thing definition, no thing, no channels.

I’ve marked this channel deprecated in the database, so it generates a ‘warning’ -:

I’m having the same issue as some others here adding a new secure device into my network. I got a second kwikset 910 lock. If I include it, it fails at security. Let me know what, if anything, I can do to help figure this out. I also seem to have an issue getting exclude to work from within habmin and paperui. It acts like it works, but will continue to find the device when I start discovery before I actually include the device again.

I also have an issue where my garage door quit working. It no longer reports as using security. It quite a while ago. Any ideas here? Could it just be the device acting up?

I don’t follow. The TYPE is provided separately, so there would be no loss of information if it wasn’t appended to the event name.

:+1:. Is notification_access_control filtered on events of type ACCESS_CONTROL, or is it deprecated too?

After thinking on this, I don’t see much use in it. If a device is sending events that are not available through a channel, then the db should be updated. The raw event is also displayed in the log, so it could be scraped. A raw event channel for the controller would make sense, but I don’t have a use case for it ATM.

It’s just the way it was implemented. If you recall, I first added the event type etc, and I later added the enum value (ie the string) thinking this might be more useful. I know there’s no loss of information, but it’s just the way the information is presented.

Only if the filter is added to the database - there’s no filtering by default, but I think this can be added to any notification.

Yes, I have marked it as deprecated.

Hi there,
I am running a version of this binding that is a couple of months old.
I just received Sensative Strips (door contacts) and was wondering whether this Z-Wave binding is recommended and what the best way of upgrading to the latest version is.
Many thanks,
Jonas

The device you are adding looks to have been in the database for a while, so it should be available in whatever version you are currently running.
http://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/251

So… did you install your current binding from the link at the top of this thread, or is your current binding from somewhere else? If the former, just drop the latest version in your addons folder.

Yes, it is the version from this threat so the update will be easy. Thanks for the quick reply!

Depending on your OH version, this might make the update slightly less easy :slight_smile:

Ok, so I will update to the latest Openhab snapshot via apt-get first. Thanks for the hint.