I only have 3 userids and it’s a seldom used lock. I didn’t do any restarts until last night when I upgraded to the latest one and zwave snapshots. I’ll watch it the next few days and see if I can setup a persistence graph to observe the rate of loss. I know Vera did something to their code base last year that took them from an ok drain to almost no drain (unfortunately I have no idea what they did so not that much help…)
Really - even my lock has 20.
Ok, if your lock only has 3 codes available, then disregard this as it will happen quickly.
@rgerrans
I’m going to take a shot here and guess what you mean is you only have 3 UserID’s that are programmed or in use? Not just 3. 1 because I don’t think any lock has that few, and 2 you had referenced above for the UserID/Label returning User 1-30. I think you had indicated a Kwikset lock previously. Which I’m pretty sure their standard is 30 code slots.
What I understood from @chris as he pointed out, was that when the device starts up, it has to go through EACH of those slots to find out what the current entry is. This is necessary to ensure both manually entered codes and OH entered codes are properly “synced”. There isn’t a way to shortcut this that I’m aware, as someone could choose to use code 1 and 30 for example. No rhyme or reason to why, but if they did if we assumed after finding code 2 was empty, that the rest were empty, we’d have a problem.
So the process I imagine is the ZWave controller has to say: What do you have for Code 1? Lock replies. What do you have for Code 2? Lock replies. And so on, for me 200 times, for you only 30. This can definitely hit the battery due to the communication. Based on the ZWave version, I’d imagine it could have more/less hit on battery due to efficiencies in the underlying protocol. I know I had a Kwikset in the last house, and the battery life was never great to begin with. I also found that their reporting of battery % was really bad. I had times where it was at 40% inside my Vera, then 2-3 days later I’d be running out and just use the lock button outside to lock up. I’d hear the dreaded multiple beeps with the keypad lighting up to indicate the batteries are too low, the lock could be dead when you attempt to unlock, so we won’t let you lock the door, sound. Come to find out the battery was really around 10-15% suddenly.
First off, as a point of reference, the last code I wrote was php 20 years ago… I would propose at least two items, the alarm notification and the userid label. Then I can setup a rule using the alarm notification # for when the lock is unlocked with a valid userid to send me a notification of which userid label unlocked it. That’s basically what I’m doing now using the Mios binding.
Does that make sense/give you enough idea to work with?
Thanks.
Correct, using 3 out of 30. I use to have similar battery drain any kwikset where a set of batteries would last maybe two months. Then middle of last year Vera made a change to their code and mine now hardly drain.
The other interesting thing about vera is that any user code changes push out almost instantly vs. I noticed on OH that it takes a while before the lock recognizes the new user codes.
though I know that without a copy of their code that is about useless information…
Ok, but I guess my question is sort of conceptual. How will you ensure that these correlate properly as a single event when you have multiple items.
For example, with the lick you will often get multiple alarms sent from the lock when you change a code or perform some other function. If each alarm updates 2 or 3 items (depending on the alarm some may provide a user if, or not) they could come out in a different order so you would somehow need to correlate this information in your rule. I’m not sure this is very easy to do reliably?
User codes in oh should push out nearly instantly. It will take a second for the lock to wake up, and a few hundred milliseconds for the secure exchange. These are not going to be any different with Vera I’m sure since this is set by the protocol (FLIRS and security).
If it’s taking longer than that please provide a log as it shouldn’t and it would be good to understand why.
I have a Schlage Lock, labeled as “BE469 Touchscreen Deadbolt” in the database.
Is there a way to get status updates when manually locking/unlocking. Currently i’m able to lock/unlock which works great, but manually changing it didn’t give me any updates.
II haven’t been following the topic that closely lately, but I remember way early back in the beginning of this topic its discussed the need to include the lock status channels for different states of when a lock is locked/unlocked and then with a rule we can update a sitemap on a manual lock/unlock.
It was discussed way… back in the topic, probably around the 100 mark.
Thanks, i’m not 100% following, my lock only shows 3 channels door_lock, alarm_general and battery-level. I’ll scroll up and see if i can find the topics discussing the status/states of a lock.
Now you are above my pay grade, but I see what you are getting at. The way I’m doing it currently with the Mios binding is just firing the rule when ever the UserID entered gets an update because in that case it’s unique to specific actions. I can see from the Alarm Notification #'s that there are multiple ones that would update the UserID. That said, I assume the binding code would update both the notification # and the userid near simultaneously since they come out in the same string from the lock? I could always put a short sleep in place at the start of the rule to give it a little extra time to finish updating the userid before triggering the notification?
I was seeing a “waiting to update” for quite a bit in Habmin but will retest with more detailed logging turned on to verify (going to be a few days before I can do that).
Thanks.
Ron
Chris just added the ability to add an Alarm # channel so the database needs to be updated for your lock. Then you need to find the documentation of what alarm # corresponds to what event type to setup your rule.
Thanks! I was in the right direction when goofing around. I configured an item for both alarm_general and notification_access_control but neither are returning values when locking/unlocking which i assume is related to the database.
What’s entailed/needed on my end to get the database updated for my lock so the alarm channel works.
You can go to his site (http://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-database-guide) and register to edit the database using one of the ones that have been identified above as having the new channel, or flag which lock in the database needs the channel and see if Chris will do it when he has a chance.
Using this very latest version (April 16th) and the latest OH2 snapshot via apt, I am getting this in the logs now for my locks. Should I expect to need to exclude and reinclude the locks whenever an upgrade is performed?
2017-04-18 13:25:57.691 [INFO ] [mmandclass.ZWaveSecurityCommandClass] - NODE 111: setupNetworkKey useSchemeZero=false
2017-04-18 13:25:57.957 [ERROR] [curityCommandClassWithInitialization] - NODE 111: SECURITY_ERROR Invalid state! Secure inclusion has not completed and we are not in inclusion mode. Aborting
No - you do not need to redo secure inclusion - unless of course you change the key.
I would suggest to simply click the reinitialise button although it’s hard to know why this happened without seeing logs.
Thanks Chris, will do. I don’t have my logs in debug by default, so even if I posted them there wouldn’t be much of interest.
Interesting note, maybe - this option doesn’t exist. It looks like these nodes are trying to reinitialize right now. This wasn’t binding related, it didn’t change, but I did upgrade OH2 to the latest snapshot today. Next time I do this I’ll set debug options first so I can capture whatever is occuring, in case it is a bug.