Events not showing ?

[s00500]

Hey There, Super awesome project!

Everything seems to work, lock is paired and functional, but listenting to esphome.nuki does not give me any events. I am using the config like in the readme with event: "nuki"

Am I missing any thing ?

I am actually trying to catch if the user triggers a double press action, is that possible ? I am firering a LockNGo and it would be great to have that trigger an automation...

Maybe you know where I am going wrong, or have a better solution...

[AzonInc]

Does the Last Lock User entity show Something?

[s00500]

Uh, this one shows unknown, but the last lock Action is helpful!

Still, I am a bit confused that I dont get any events when listening to esphome.nuki
Should I get events in case of a lock or lockngo there ?

[AzonInc]

As far as I remember, I only send events after retrieving the events from the lock.

When changing the lock state (lock, unlock,...) logs should be retrieved and then sent to Home Assistant via events.

But it seems that this didn't happen at all, as the last unlock user is unknown as well (which should actually change after retrieving logs).

Is there anything in the ESPHome Webserver logs/console logs with debug logging?

Which Nuki Lock do you own?

[s00500]

Not really anything in the logs, except for the "Retrieving logs" line

I have a smartlock 3.0 pro (the build in wifi is too unstable for me and also uses unencrypted mqtt so I switched to this project)

[s00500]

But meanwhile I made an automation that checks for the lock state becoming locked and checks the "Last Action" to have been LockNgo

This works very well now! =D So my original issue is solved, just confused about the events part still

[AzonInc]

Weeeell, I completely forgot about that and ended up spending quite a bit of time on it.
Did you set the security PIN? Accessing the logs is only possible after setting the security PIN.

[s00500]

AHHH understood, yes that solves it... still feels like this is quite a slow way to get infos, check this:

event_type: esphome.nuki
data:
device_id: X
action: Unlock
authorizationId: "XXX"
authorizationName: Nuki ESPHome
completionStatus: success
index: "10128"
timeDay: "7"
timeHour: "21"
timeMinute: "48"
timeMonth: "1"
timeSecond: "29"
timeYear: "2025"
trigger: system
type: LockAction
origin: LOCAL
time_fired: "2025-01-07T21:49:05.425545+00:00"

You can see the event fired much later than it actually happened...

Also I am not sure I like my security pin being conserved as entity state in homeassistant =P... I rather like secrets in esphome configs

But wathing ast action does 98% of what I need so I am quite happy so far, thanks for the awesome component

(did I miss the logs thing about the security pin in the docs ? cause I think it is not noted there...)

[s00500]

Check some of my logs here:

[22:48:38][I][nuki_lock.lock:711]: lockAction Unlock (1) has resulted in success (1)
[22:48:38][W][component:237]: Component nuki_lock.lock took a long time for an operation (2275 ms).
[22:48:38][W][component:238]: Components should block for at most 30 ms.
[22:48:41][I][nuki_lock.lock:1156][nimble_host]: event notified 0
[22:48:41][I][nuki_lock.lock:1156][nimble_host]: event notified 0
[22:48:41][I][nuki_lock.lock:1156][nimble_host]: event notified 0
[22:48:41][D][nuki_lock.lock:871]: Update present, getting data...
[22:48:42][I][nuki_lock.lock:286]: Bat state: 0x54, Bat crit: 0, Bat perc: 42 lock state: unlocked (3) 21:48:31
[22:48:42][D][lock:054]: 'A18 Main Lock': Sending state UNLOCKED
[22:48:42][D][sensor:094]: 'A18 Nuki Battery Level': Sending state 42.00000 % with 0 decimals of accuracy
[22:48:42][D][text_sensor:064]: 'A18 Nuki Door Sensor: State': Sending state 'closed'
[22:48:42][D][text_sensor:064]: 'A18 Nuki Last Lock Action': Sending state 'Unlock'
[22:48:42][D][text_sensor:064]: 'A18 Nuki Last Lock Action Trigger': Sending state 'system'
[22:48:42][W][component:237]: Component nuki_lock.lock took a long time for an operation (1134 ms).
[22:48:42][W][component:238]: Components should block for at most 30 ms.
[22:48:44][D][nuki_lock.lock:878]: Update present, getting config...
[22:48:45][D][nuki_lock.lock:345]: requestConfig has resulted in success (1)
[22:48:45][D][select:015]: 'A18 Nuki Timezone': Sending state Europe/Berlin (index 37)
[22:48:45][D][select:015]: 'A18 Nuki Advertising Mode': Sending state Slow (index 2)
[22:48:45][W][component:237]: Component nuki_lock.lock took a long time for an operation (1321 ms).
[22:48:45][W][component:238]: Components should block for at most 30 ms.
[22:48:46][D][nuki_lock.lock:884]: Update present, getting advanced config...
[22:48:46][E][nuki_lock.lock:431]: requestAdvancedConfig has resulted in failed (2)
[22:48:46][W][component:237]: Component nuki_lock.lock took a long time for an operation (75 ms).
[22:48:46][W][component:238]: Components should block for at most 30 ms.
[22:48:48][D][nuki_lock.lock:884]: Update present, getting advanced config...
[22:48:49][D][nuki_lock.lock:395]: requestAdvancedConfig has resulted in success (1)
[22:48:49][D][select:015]: 'A18 Nuki Button: Single Press Action': Sending state Intelligent (index 1)
[22:48:49][D][select:015]: 'A18 Nuki Button: Double Press Action': Sending state Lock n Go (index 5)
[22:48:49][W][component:237]: Component nuki_lock.lock took a long time for an operation (1880 ms).
[22:48:49][W][component:238]: Components should block for at most 30 ms.
[22:48:51][D][nuki_lock.lock:890]: Update present, getting auth data...
[22:48:51][D][nuki_lock.lock:444]: Retrieve Auth Data
[22:48:51][D][nuki_lock.lock:444]: Retrieve Auth Data
[22:48:53][W][component:237]: Component nuki_lock.lock took a long time for an operation (2285 ms).
[22:48:53][W][component:238]: Components should block for at most 30 ms.
[22:48:54][D][nuki_lock.lock:896]: Update present, getting event logs...
[22:48:54][D][nuki_lock.lock:491]: Retrieve Event Logs
[22:48:54][W][component:237]: Component nuki_lock.lock took a long time for an operation (225 ms).
[22:48:54][W][component:238]: Components should block for at most 30 ms.
[22:48:58][D][nuki_lock.lock:474]: Authorization entry[XX] type: 0 name: Lukas
[22:48:58][D][nuki_lock.lock:474]: Authorization entry[XX] type: 0 name: X
[22:48:58][D][nuki_lock.lock:474]: Authorization entry[XX] type: 0 name: X
[22:48:58][D][nuki_lock.lock:474]: Authorization entry[XX] type: 0 name: X
[22:48:58][D][nuki_lock.lock:474]: Authorization entry[XX] type: 0 name: X
[22:48:58][D][nuki_lock.lock:896]: Update present, getting event logs...
[22:48:58][D][nuki_lock.lock:491]: Retrieve Event Logs
[22:49:00][W][component:237]: Component nuki_lock.lock took a long time for an operation (1793 ms).
[22:49:00][W][component:238]: Components should block for at most 30 ms.
[22:49:05][D][nuki_lock.lock:673]: Send event to Home Assistant on esphome.nuki
[22:49:05][D][text_sensor:064]: 'A18 Nuki Last Unlock User': Sending state 'Nuki ESPHome'
[22:49:12][D][api:103]: Accepted 192.168.0.213
[22:49:12][W][api.connection:093]: : Socket operation failed: HANDSHAKESTATE_READ_FAILED errno=11
[22:50:12][D][api:103]: Accepted 192.168.0.213
[22:50:13][W][api.connection:093]: : Socket operation failed: HANDSHAKESTATE_READ_FAILED errno=11
[22:51:13][D][api:103]: Accepted 192.168.0.213
[22:51:13][W][api.connection:093]: : Socket operation failed: HANDSHAKESTATE_READ_FAILED errno=11
[22:52:13][D][api:103]: Accepted 192.168.0.213
[22:52:13][W][api.connection:093]: : Socket operation failed: HANDSHAKESTATE_READ_FAILED errno=11
[22:53:13][D][api:103]: Accepted 192.168.0.213
[22:53:13][W][api.connection:093]: : Socket operation failed: HANDSHAKESTATE_READ_FAILED errno=11
[22:54:13][D][api:103]: Accepted 192.168.0.213
[22:54:13][W][api.connection:093]: : Socket operation failed: HANDSHAKESTATE_READ_FAILED errno=11

[AzonInc]

You're right, it is slow. Unfortunately, I'm not aware of a faster way to request the data, especially since it sometimes fails multiple times and requires retries before successfully fetching the logs.

One potential improvement could be dynamically adjusting the request order based on incoming events.

For instance, after the first boot, we could prioritize fetching the config and advanced config as quickly as possible. However, once that's done, the focus could shift to retrieving log updates as fast as possible. This way, we can better prioritize requests depending on the situation. @uriyacovy what do you think about this idea?

Regarding the pin configuration:
You're correct that there's no indication about needing the pin to be set, so I'll make sure to add that.

As for the configuration itself, we could introduce a fixed fallback pin YAML option alongside the entity. This would allow for a runtime configuration option in addition to the compiled one. Alternatively, we could save the pin whenever it changes but avoid restoring it to the entity. That way, it wouldn't be displayed in Home Assistant anymore.

[s00500]

Oh yes that all sounds awesome!!!
I was wondering about the many times auth and config is fetched and if it is 100% needed...

But yes, for now I am not relying on the timing of the events...