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.
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 . 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?
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 … the pages split the title and the underscore threw off the search… Access Control Alarm.
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
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!
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.
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.
. 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.
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.