Any possibility of accessing the keypad input for other automation (e.g. a code that opens the electronic side gate instead)

[mutasim]

Is it possible to set a code that doesn't open the door but rather I can use as an automation trigger to do something else with?

Or perhaps another creative way of using the keypad input to trigger an automation.

I'm thinking about my electronic side gate lock.

[technyon]

Unfortunately no this is not possible. The keypad is paired to the lock, and whatever happens is between the lock and the keypad. The ESP is only notified about state changes as a result.

[iranl]

Also presumably rather than a very time limited code you could also use a code where enabled = 0 (?)

Haven't tested this, but might work. Question is whether Nuki logs this as an unknown code or a disabled code

Is this same capability also required for the following use case? Or can that be handled in a different way?

This could possibly be made to work. Keypad codes or fingerprint would unlock the Nuki on the outer door independently from Nuki Hub.

Nuki Hub would pick up the changed lock state and publish the state change and authorizing user to MQTT.

Some smarthome automation (e.g. nodered/Home Assistant) would then unlock the inner door if the authorizing user is on a certain list.

[mutasim]

Thanks for the reply.

Ok +1 from me on both uses case please 🙏.

The double door unlock is definitely a more common/important scenario in my opinion. I didn’t lead with that question as I had wrongly presumed this was already possible somehow.

[iranl]

Authorization log is fixed in #368

[mutasim]

Wow that was quick! Great work.

Does this expose the code ID from keypad attempts?

[iranl]

It should be able to show anything the official app can show.
I haven't tested it by entering some known (disabled/timelimited) codes with this latest fix at this time yet.
It might just work, but it might need some work still.
Atleast the log now shows the 5 latest log entries instead of entry 2-6 since the lock/opener was put in use.

[propi62]

as i understand this conversation, at the moment, it is not possible to enter a different code on the keypad to trigger a homeassisant action to unlock another door? (garagedoor opener

[technyon]

@propi62 Correct, this is due to limitations in the Nuki bluetooth API.

[mutasim]

I thought @iranl latest fixes to the auth logs mean that you might be able to query the lock for the details of a failed attempt and use that for a suitable automation.

(I don’t yet have the hardware so can’t test)

[technyon]

@mutasim Yes you could do that, but it's a workaround and it depending on your use case, and may or may not work well.

[mutasim]

Would be great if someone in the community could test disabled/time-limited codes as triggers for automations and report back on speed/reliability etc.

[mundschenk-at]

Well yes, please report 😅

[propi62]

the nukihub shows the last entered keypad user. so its possible to use different keys for different automatisations. thank you very much.

[mutasim]

Great - was there any time lag?

Could you perhaps test disabled/time-limited codes? That allows for the keypad to be used for other doors/use cases without unlocking the Nuki lock.

[propi62]

it works with disabled keys (lock disabled). (its possible to trigger different actions without locking/unlocking the nukilock.)
homeassistant trigger with (Keypad) needed. (video attached)

vid_fLomcPqQ.mp4

[mutasim]

Thanks for sharing! That looks great 👍 👍

[iranl]

The new rollingLog topic that will be introduced in #384 should make for the best topic to base your automation on. It will also be automatically exposed to home assistant discovery as a sensor with all properties shown below as JSON properties in the sensor.

See below for how disabled / timelimited (while used out of the allowed time) / future codes show up in te log.
They will show the name of the authorization, authorizationId and the completion state and value.
This value is 9 for known codes that don't allow access at the time they are used (because they are disabled, timelimited etc.)
I need to add this value to the list of possibilities so the state does not show as undefined but as something like notallowed or notauthorized, but you can already use completionStatusVal in your automations

{
    "index": 3347,
    "authorizationId": 80405,
    "authorizationName": "Test",
    "timeYear": 2024,
    "timeMonth": 5,
    "timeDay": 31,
    "timeHour": 6,
    "timeMinute": 29,
    "timeSecond": 30,
    "type": "KeypadAction",
    "action": "Unlatch",
    "completionStatus": "undefined",
    "completionStatusVal": 9
  }

[iranl]

Auth log should be fully implemented with 8.35

[propi62]

after many hours of testing, i cant make it work properly. (with homeassistant)
Triggering actions with keypad works, but after nukehub reboot, the last action triggers again.
I think the sensor.nuki_garage_rolling_authorization_log attribute: index changes after reboot for a milisecond?
I dont know how to solve it.

alias: Nuki Keypad Garage
description: ""
trigger:
  - platform: state
    entity_id:
      - sensor.nuki_garage_rolling_authorization_log
    enabled: true
    for:
      hours: 0
      minutes: 0
      seconds: 1
    attribute: index
condition: []
action:
  - choose:
      - conditions:
          - condition: state
            entity_id: sensor.nuki_garage_rolling_authorization_log
            attribute: authorizationName
            state: haustuer (Keypad)
        sequence:
          - service: lock.unlock
            target:
              entity_id: lock.lock_hausture
            data: {}
            enabled: false
          - service: notify.mobile_app_frederic_mobile
            data:
              title: haustur (Keypad) wurde ausgelöst
              message: ""
        alias: Haustuer

[mutasim]

Have you tried the latest build (from master)? I believe there's been some work to address the repeats on reboot. I haven't managed to test it yet.

[propi62]

no, i never figured out how to build from master. i always use releases for updates. atm im using: 8.35

[mutasim]

Here you go:

https://github.com/technyon/nuki_hub/actions/runs/9845748890

(The builds are all listed under artefacts)

I believe these builds need to be flashed using USB/serial for the first time because of changes to the partition table. (I can't tell you more than that.. I'm just repeating what I've read!)

[propi62]

i flashed nuki_hub_esp32.bin over webinterface.
still triggers on nukihub reboot: (garagedoor is wide open in the morning if nukihub reboots at night ;)

platform: state
entity_id:
  - sensor.nuki_garage_rolling_authorization_log
enabled: true
for:
  hours: 0
  minutes: 0
  seconds: 1
attribute: index
not_from:
  - unavailable
  - unknown
not_to:
  - unavailable
  - unknown

[iranl]

Remove the attribute line, it is not necessary in the current version and could probably mess with your not_from and not_to lines.

Also updating to versions >8.35 using ota is strongly disencouraged and ota will be blocked to any other firmware if it does succeed. Flash using usb/serial as soon as possible.

[propi62]

i flashed my two ESP32 asap over USB with Espressif Flash Download Tools.
Settings persisted and the automation is now working as expected. nukihub reboot not triggering anything.

[iranl]

Good to hear