Feature request: Keypad codes

[AlternativeBoi]

Hello!

First of all, thank you for creating this integration. It solved a fairly big problem with the Nuki, I appreciate it.

I would love to see you integrate the addKeypadEntry, updateKeypadEntry and deleteKeypadEntry functions of the library you are using into a service. No other custom bridge that I found has the keypad features integrated, so this would be really helpful.

Thanks a lot.

Cheers, AlternativeBoi

[AlternativeBoi]

My use case would be (amongst other things) to create temporary pincodes that expire after a certain timeout, now that I have looked at the code a bit better it seems Nuki uses unique identifiers for the keypad codes that can only be found out via the retrieveKeypadEntries function.

Maybe you can implement a service for temporary pincodes as well, that would be awesome!

[uriyacovy]

Hi @AlternativeBoi, Sorry for the late reply. First, I don't have or use the keypad, so it would be hard for me to test any development in this domain, but we can try :) The component is intended to act mostly as a native replacement for the bridge, while what you are asking is more in the domain of the mobile application itself. Also, esphome is not very good at abstracting services, and I assume you don't want to recompile a new yaml with every code change. What I can suggest, is to implement a switch that would enable/disable existing keypad entries. This way you can configure the keyopad entries once from the mobile app, and control them from this component. Would that work for your use case?

[haseat]

What I can suggest, is to implement a switch that would enable/disable existing keypad entries. This way you can configure the keyopad entries once from the mobile app, and control them from this component. Would that work for your use case?

I'm not the OP, but I would love this feature.

[uriyacovy]

Hi @AlternativeBoi , @haseat, Sorry it took so long, but I finally had some time to implement keypad services. I did eventually implemented the services (and not switches) as OP suggested. Since I don't use the nuki keypad, I would love and appreciate your help in testing the new services.

The services are implemented in the dev branch. Note that you need to have some changes in the yaml (and maybe update esphome) as explained in the readme.

4 new services (callable from HA developer tools, scripts, automations, etc.) are implemented: _print_keypadentries - prints available keypad entries stored on the lock. _add_keypadentry - adds a new entry with "name" and "code". _update_keypadentry - updates entry "id" with new "name", "code", and "enabled" (boolean) status. _delete_keypadentry - deletes entry "id".

[haseat]

@uriyacovy I'm happy to help testing starting next week, as I'm currently abroad. I'll post here if I have any questions/remarks.

[denissp]

Hi

Thank you for you great job !

When I'm trying to call service : service: esphome.nuki_print_keypad_entries data: {}

I'm getting error in logs: [14:19:29][E][nukilock.lock:304]: keypad is not paired to Nuki

Keypad 2.0 connected to lock and could be managed through phone

[uriyacovy]

Thanks @denissp.

1. Can you post the full log?
2. Can you try to lock/unlock and call nuki_print_keypad_entries service again? (and post the full log).

[denissp]

Something strange happens, before I enable logging lock and unlock works without problem Now it lock or unlock once and then failed with other commands:

[D][api:102]: Accepted ::FFFF:192.168.1.21 [22:43:46][D][api.connection:917]: Home Assistant 2022.12.7 (::FFFF:192.168.1.21): Connected successfully [22:43:57][I][nukilock.lock:145]: Nuki paired [22:43:57][I][nukilock.lock:063]: Bat state: 0xc8, Bat crit: 0, Bat perc:100 lock state: 3 20:43:57 [22:43:57][D][lock:055]: 'Nuki Lock': Sending state UNLOCKED [22:43:57][D][binary_sensor:036]: 'Nuki Connected': Sending state ON [22:43:57][D][binary_sensor:036]: 'Nuki Battery Critical': Sending state OFF [22:43:57][D][sensor:127]: 'Nuki Battery Level': Sending state 100.00000 % with 0 decimals of accuracy [22:43:57][D][binary_sensor:036]: 'Nuki Door Sensor': Sending state ON [22:43:57][D][text_sensor:067]: 'Nuki Door Sensor State': Sending state 'unavailable' [22:43:58][D][binary_sensor:036]: 'Nuki Paired': Sending state ON [22:44:10][D][lock:055]: 'Nuki Lock': Sending state LOCKED [22:44:29][E][nukilock.lock:194]: lockAction failed: 3 [22:44:29][D][binary_sensor:036]: 'Nuki Connected': Sending state OFF [22:44:29][D][lock:055]: 'Nuki Lock': Sending state UNKNOWN [22:44:38][E][nukilock.lock:075]: requestKeyTurnerState failed: 3 INFO nuki.local: Ping timed out! INFO Disconnected from ESPHome API for nuki.local WARNING Disconnected from API

I repair lock, erase esp flash nothing helps

[denissp]

Additional logs

[D][api:102]: Accepted ::FFFF:192.168.1.21 [23:03:08][D][api.connection:917]: Home Assistant 2022.12.7 (::FFFF:192.168.1.21): Connected successfully [23:03:14]sendEncryptedMessage: connectBle success after 9 ms [23:03:14]sendEncryptedMessage: connectBle success after 0 ms [23:03:14][D][lock:055]: 'Nuki Lock': Sending state LOCKED [23:03:30][I][nukilock.lock:025]: event notified 0 [23:03:30][I][nukilock.lock:025]: event notified 0 [23:03:30]connectBle retry 0 [23:03:31]sendEncryptedMessage: connectBle success after 1325 ms [23:03:31][I][nukilock.lock:063]: Bat state: 0xb0, Bat crit: 0, Bat perc:88 lock state: 1 21:3:32 [23:03:31][D][sensor:127]: 'Nuki Battery Level': Sending state 88.00000 % with 0 decimals of accuracy [23:03:31][D][text_sensor:067]: 'Nuki Door Sensor State': Sending state 'unavailable' [23:03:31]sendEncryptedMessage: connectBle success after 1 ms [23:03:32]sendEncryptedMessage: connectBle success after 0 ms [23:03:34]sendEncryptedMessage: connectBle success after 3 ms [23:03:34]sendEncryptedMessage: connectBle success after 0 ms [23:03:34][D][lock:055]: 'Nuki Lock': Sending state UNLOCKED [23:03:46]sendEncryptedMessage: connectBle success after 6 ms [23:03:56][E][nukilock.lock:194]: lockAction failed: 3 [23:03:56][D][binary_sensor:036]: 'Nuki Connected': Sending state OFF [23:03:56][D][lock:055]: 'Nuki Lock': Sending state UNKNOWN [23:03:56]sendEncryptedMessage: connectBle success after 1 ms [23:04:07][E][nukilock.lock:075]: requestKeyTurnerState failed: 3 [23:04:07]sendEncryptedMessage: connectBle success after 1 ms [23:04:17][E][nukilock.lock:087]: print_keypad_entries: requestConfig failed (result 3) [23:04:17]sendEncryptedMessage: connectBle success after 1 ms [23:04:27][E][nukilock.lock:075]: requestKeyTurnerState failed: 3 [23:04:27]sendEncryptedMessage: connectBle success after 1 ms [23:04:37][E][nukilock.lock:087]: print_keypad_entries: requestConfig failed (result 3) [23:04:37]sendEncryptedMessage: connectBle success after 1 ms [23:04:47][E][nukilock.lock:075]: requestKeyTurnerState failed: 3 [23:04:47]sendEncryptedMessage: connectBle success after 0 ms

[uriyacovy]

@denissp, how did you enable logging? Are you connected to the esp directly (usb) or via wifi? Does it work when logging is disabled?

[denissp]

Looks like it's not related to debug ( I enabled debug in esphome yaml file)

It's somehow related to BT communication If I send second command right after first command completes execution I get this error(mentioned in previous post) and only esp reboot helps

As a workaround I added simple semaphore into code which prevent command execution until i get status update from lock: void NukiLockComponent::update_status() after that everything works very stable, except keypad codes :)

also I added small hack into else clause in void NukiLockComponent::update_status(), this helps recover from crashes, but after adding semaphore everything works without this this hack.

 if (result == 3)
   this->nukiLock_->initialize();

I could share code and additional logs a little bit later

[uriyacovy]

1. NukiBleEsp32 lib should be quite protected with semaphores, but maybe there are a few fixes that are not included in my fork. You can change the dependency in libraries to https://github.com/I-Connect/NukiBleEsp32 and see if it works without additional semaphores (if it compiles).
2. Feel free to open a PR if you have stability fixes. The change you describe might be more relevant for NukiBleEsp32 though.
3. Back to the keypad - can you comment out the test of keypad_paired_ at the beginning print_keypad_entries (lines 303-306) and see if you do get the keypad entries?

[denissp]

OK, I figure out where was my problem related to keypad entries I have configured pin code for data protection and library assumes that if no pincode stored in preferences than it uses default one - 000000 NuliBle.cpp if (pinCode == 0) { log_w("Pincode is 000000"); }

After defining pincode I successfully retrieve all keypad entries.

I assume that there should be ability to define pincode either through HA services or through esphome configuration

I will look into my stability issue little bit later.

[Pe-MaKer]

@uriyacovy Thank you very much for your effort building the missing link between the Nuki and ESPHome. By having your integration, I was able to harmonize my ESP-driven door opener with Nukis lock state.

I'm glad to read that you have the keypad capabilities developed already in the DEV branch. Would you mind to merge the commit to the main branch?

What makes me curious: beside the keypad, I also paired two Nuki Key Fobs to the lock. Would it be possible to see them in ESPHome as well?

Again, many thanks for all of your work bringing the loose ends together. 👏🏻

[uriyacovy]

Hi @Pe-MaKer, The keypad support is part of the dev branch because it caused some instability to the ESPHome in some cases. You can try it yourself and update if you experience any instability. Just change: - source: github://uriyacovy/ESPHome_nuki_lock to - source: github://uriyacovy/ESPHome_nuki_lock@dev

Regarding the support for multiple locks, it was discussed here: https://github.com/uriyacovy/ESPHome_nuki_lock/issues/2

[Pe-MaKer]

Thanks @uriyacovy, I've tested the dev-branch and it looks quite stable on my ESP32-Mini so far. I can call the HA service to list all keypad_entities on the ESPHome serial console but I have no clue on how to represent this output to HA.

Looking at Hass Nuki NG (https://github.com/kvj/hass_nuki_ng), the individual passcodes are managed as switch.entities in HA, which can be activated or deactivated. I would like to see this for ESPHome Nuki lock as well.

Regarding the Nuki Fob, I might have misunderstood: They are BT key fobs, which are managed in the Nuki lock as additional authorisation entities besides the PIN codes. Also with the possibility to activate and deactivate them as switches.

So it is not about controlling another lock, as in the topic you linked to.

To put it briefly: ESPHome Nuki Lock should offer the possibility to read all Nuki Auth entries (passkeys, key fobs and accounts) at least as sensor or ideally as switch. https://developer.nuki.io/page/nuki-smart-lock-api-2/2/#heading--authorization-entry @I-Connect is showing the usage of the method in this example:

The cherry on the cake: Which Nuki Auth entry has triggered the last open or close command what tells me who is coming home?

[uriyacovy]

Sorry for the late reply. Few answers:

1. ESPHome does not support creating dynamic keys (sensors, switches, etc.). That's the reason keypad controls are implemented through services. However, it should be fairly easy to create whatever switch or automation you'd like using the services directly in HA.
2. Regarding the FOB - I don't have one, so it would be hard for me to adapt the code. Nevertheless, what kind of control would you like? Just the option to enable or disable lock/unlock using the FOB?

[Pe-MaKer]

Don't worry, I'm glad you're still sticking to the topic.

After a few days of productive use of ESPHome Nuki Lock together with a door opener relay and a R503 fingerprint reader, my requirements have changed. I can still configure and activate/deactivate the passcodes and KeyFobs via the Nuki app. So there is no urgent need to manage the permission config in ESPHome.

However, what I would like to know from the Nuki integration is which key triggered the last opening or if an incorrect PIN was sent to the lock.

It is important for me to know if someone is trying out PINs on a lucky chance at night.

[uriyacovy]

I reviewed the Nuki API documentation and I'm not sure there's a way to get this information. Is it available in the Nuki app?

[Pe-MaKer]

Yes, it is available on the App.

Other integrations as like "Nuki Hub" and the "Hass_Nuki_NG" provide something like "lock/authorizationName" or "sensor.nuki_haustur_last_unlock_user".

[Pe-MaKer]

@uriyacovy are there any plans to continue developing ESPHome Nuki Lock?

[uriyacovy]

Unfortunately, due to lack of time, I'm trying to just maintain the current module. If anyone else would implement the feature, I'll gladly pull.

[Pe-MaKer]

I'm so happy about PR59 It promises to bring all the improvements I'm waiting for eagerly.

Kudos to @AzonInc and @uriyacovy