FutureTense/keymaster

ISSUE: Notifications are rarely correct.

joeinaustin opened this issue · 6 comments

joeinaustin commented

Describe the bug
The notifications are still not correct. I do get notifications now (since last update) but they are rarely correct. It says "keypad unlock" when it is actually locked, it says keypad unlock when when locked manually from the inside. It references the last used code when no code is used. It is almost never correct. Last update did cause notifications to start working, but the are ususally incorrect. See logs from #317.

Environment (please complete the following information):

  • OS: [e.g. HassOS/Raspbian/CentOS]
  • Type of system that HA is running on: [e.g. RPi3/NUC/Synology]
  • Home Assistant version: [e.g. 0.105.5]
  • Hassio/Docker/Core?
  • Component version: [e.g. 0.1.2]
  • Z-Wave integration name: [e.g. zwave_js]
  • Lock make and model: [e.g. Schlage BE469]

Logs
Paste your error logs here.

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Add any other context about the problem here.
Please add emails in plain/text format if possible and applicable.

firstof9 commented

These are the codes that get translated:

keymaster/custom_components/keymaster/const.py

Lines 69 to 91 in a35388b

0: "No Status Reported",
9: "Lock Jammed",
16: "User Access", # FE599 code
17: "Keypad Lock Jammed",
21: "Manual Lock",
22: "Manual Unlock",
23: "RF Lock Jammed",
24: "RF Lock",
25: "RF Unlock",
26: "Auto Lock Jammed",
27: "Auto Lock",
32: "All Codes Deleted",
161: "Bad Code Entered",
167: "Battery Low",
168: "Battery Critical",
169: "Battery Too Low To Operate Lock",
16: "Keypad Unlock",
18: "Keypad Lock",
19: "Keypad Unlock",
162: "Lock Code Attempt Outside of Schedule",
33: "Code Deleted",
112: "Code Changed",
113: "Duplicate Code",

jsb5151 commented

Well, there seems to be an issue with the notifications code itself, as the constants line up with what is reported by the lock. I've been performing a few tests with my locks (Both Schlage BE469ZP with the same firmware), and I often get incorrect notifications.

One of the test cases I just did is to unlock and lock the deadbolt using Home Assistant, which normally reports event 25 and 24 respectively. The alarmType sensor reports the correct info, but the push notification says "Manual Lock (username)" in both cases. So there are two issues here: one is that event 24/25 are not reported correctly, and the other is that a manual lock/unlock notification should not report a username.

Also, hitting the Schlage button on the keypad does not trigger any notification; the alarmType goes to 18 with alarmLevel/access control to 0 meaning no user/keypad only.

I'm most likely going to have to write my own notifications scripts as the ones in Keymaster aren't working properly :-(

firstof9 commented

In the case that zwavejs is emitting events, those are used, so what you are seeing is coming from zwavejs.

cree8 commented

I also have the same lock and have been troubleshooting this issue for a few days. I'm not sure when exactly, but maybe at the end of last year, the manual lock and remote locking actions trigger the same "Manual Lock ([slot_1_user])" notification to be generated.

When viewing the lock debug log in ZwaveJS-UI, the correct values are being reported. 21 and 22 for the manual locking actions. Yet, keymaster still attaches a user pin to the notification, as seen here:

event_type: call_service
data:
  domain: notify
  service: mobile_app_parblue
  service_data:
    title: frontdoorlock
    message: Manual Lock (Sam)
origin: LOCAL
time_fired: "2023-08-20T20:59:31.644767+00:00"
context:
  id: 01H8ABXVCYAFENGKRBWC0QWG98
  parent_id: 01H8ABXVCFKQTJ9RQB8Z52M1PJ
  user_id: null

And here, we can see the offending event being fired from Keymaster:

event_type: keymaster_lock_state_changed
data:
  notification_source: entity_state
  lockname: frontdoorlock
  entity_id: lock.frontdoorlock_current_lock_mode
  state: locked
  action_code: 21
  action_text: Manual Lock
  code_slot: 1
  code_slot_name: Sam
origin: LOCAL
time_fired: "2023-08-20T20:59:31.599256+00:00"
context:
  id: 01H8ABXVCFKQTJ9RQB8Z52M1PJ
  parent_id: null
  user_id: null

So the question is why the event 21, which is correctly marked as a Manual Lock action, also referencing a code slot?

cree8 commented

I can also confirm what was said about events 24 and 25 (RF Lock/Unlock) never being reported. When initiating any locking action from within Home Assistant, many other values are refreshed for the lock within ZwaveJS debug; however, the action code remains the same as it was before. This leads to an incorrect manual locking notification being reported. That lock issue combined with the user pin bug make for some strange notifications. I initiated a lock action from within Home Assistant, and received a notification "Manual Lock (Sam)", which is entirely inaccurate.

I do suppose a manual, open loop type automation will be needed to get RF lock/unlock notifications.

firstof9 commented

So the question is why the event 21, which is correctly marked as a Manual Lock action, also referencing a code slot?

This is due to the lock reporting user slot 1. Feel free to watch the zwavejs events.