Feature request: add what/who locked/unlocked a door to Home Assistant (lock entity, separate entities)

[bcutter]

Does the API provide information on who (Person A, Person B) or/and what (NukiHub, app, opener, KeyPad, button, manually, ...) locked/unlocked a door?

Currently the only - admittedly most important - status of the lock entity is locked/unlocked at a certain time.

Basically: can we have data for building something like the Nuki app function "protocol" with Nuki Hub?

That would for some cases be very handy information, especially for automations. Think at least about "Person A has unlocked the door, welcome home" notifications.

[technyon]

Please enable "Publish auth data"

[bcutter]

So this is already available? That would be awesome.

Any downsides on this?

Maybe I should have read the docs a fifth time... maybe the features and finally the documentation of which config setting does what exactly would be helpful (#71 !) ;-)

[bcutter]

Enabled on all locks. Can't check MQTT broker currently, but:

out of the box nothing has changed in HA.

What is supposed to happen after setting PUBAUTH to TRUE?

I really don't want to manually grab MQTT data and put it into entities (again, as for uptime).

---

I really was expecting / hoping to see "Person A unlocked by App", "Locked by button", "Unlocked by NukiHub" etc. in the logs of the lock entity.

---

[technyon]

You didn't say anything about home assistant. The last five log entries are published under mqtt in "lock/log" in json format.

[bcutter]

Sry. That's the only reason I use Nuki Hub for 😀

So I want to adjust this feature request to:

---

Please let's have this information out of the box in Home Assistant. As directly as possible, meaning:

1. Directly in the logbook of the lock entity.
2. At minimal as separate entity.

Basically like the last huge blast when button, led switch, led intensity and much more was provided by a firmware update. All that MQTT data was magically auto discovered by HA and nice entities were created. That was awesome.

---

[Dielee]

You didn't say anything about home assistant. The last five log entries are published under mqtt in "lock/log" in json format.

This would be nice! But nuki/lock/log only contains "--". Enable auth is on, is there something more to do ?

[technyon]

Did you configure the PIN under credentials?

[Dielee]

Oops! You mean nuki lock pin ? Which pin do I have to put in there ?

[technyon]

When you setup the lock you have the option to configure a PIN in the smartphone app. NUKI Hub needs this PIN to access certain functionality.

If that doesn't help, please post logs, either serial or mqtt logs.

[Dielee]

Okay, I will have a try later today. Do I have to update to 8.13 ? There is something with fixing pin...

[technyon]

If you're on 8.12 yes

[Dielee]

I'm on 8.11, so yes, thanks! Do I have to repair after the update ?

[technyon]

There's no need for pairing again.

[Dielee]

Logs are working! Thanks!!!

But my 2.0 Keypad isn't. I will open a new issue for this.

[alexdelprete]

Please let's have this information out of the box in Home Assistant. As directly as possible, meaning:

1. Directly in the logbook of the lock entity.
2. At minimal as separate entity.

HA logbook is created/managed by HA itself, as a result of state changes of the device/entity. It is a logbook of the state changes. If lock/log was an entity, when it changes state, you would see the changes in the logbook.

The problem of having lock/log as an entity is that it's a json of the last 5 entries, so it's actually a logbook in json format. :)

I would suggest to have lock/log as the last entry, and maybe having subtopics lock/log/1..lock/log/5 if you want a short history.

[bcutter]

Now I finally could have a brief look at the MQTT topics, it should actually by quite easy to create those sensors (I already created a template sensor for the uptime of the Nuki Hub) because simply everything needed for a "Latest lock action" entity is there:

• Who ➡ authorizationName (e. g. NukiHub - when there's no name it must have been locally triggered by button or manually so even that could be replaced by a default string "Local/Button" or sth. like that)
• What ➡ type (e. g. LockAction, KeypadAction) and action (e. g. Lock, Unlock, Unlatch) which could result in e. g. Unlatched by Username via Keypad or Locked by NukiHub
• When ➡ create HA valid timestamp based on

  "timeYear": 2023,
  "timeMonth": 3,
  "timeDay": 11,
  "timeHour": 16,
  "timeMinute": 38,
  "timeSecond": 38,

• Extras (e. g. for attributes) ➡ completionStatus (e. g. success) for result of action

Maybe the trigger´ (which sometimes containsbuttonnext tosystem`) could be interesting for the local control actions (non-personalizable).

While I actually don't have an opinion or final proposal on how this should look like...

• everything in a single entity? Which data as state, which as attributes?
• separate entities for every data
• ...

... I'm very conviced this is something one should not create on his/her own but instead should natively be provided as default entity/entities by Nuki Hub. That would be such a smart additional feature (even it's "just" exposing already existing data to HA) 😃

[technyon]

authorizationName and authorizationId only work if you don't have a door sensor. If you have one, the last action usually is doorOpened or doorClosed, not lock or unlock.

[bcutter]

So this/these entity/entities would need some variation depending on what hardware constellation exists.

• with door sensor
• without door sensor

Nothing impossible, isn't it?

[technyon]

If it were that easy, I had already done it. The data has to be polled from the lock, and by the this happens the door sensor event is reported.

[alexdelprete]

The presence of a doorSensor (and other accessories) should be cached, once you install it you don't remove it every day. It could have a TTL pretty long...and you can refresh it for example at reboot time, or with a configurable TTL. Same with keypads and accessories in general. It can't be polled every time, it would be slow via BLE.

[technyon]

It's not about the presence of a door sensor, it's about polling to the authorization data. For example:

• An unlock is detected
• The ESP starts to request the lock state
• The user unlatches the door
• door opens
• lock state comes back
• The ESP polls authorization data from the lock
• door closes
• authorization date comes back

What the esp now has as events with authorization date:

• unlock
• unlatch
• door sensor open
• door sensor closed

Which of those events to publish? To make it easy, door sensor events could just be filtered out, going back to the last unfiltered event, which would be unlatch. Unlock is missed and won't appear in the log.

... unless I keep track of all the events wether they have been published or not. Then I could play them back and publish via mqtt with a small delay. Now

• I have to have an array of events already published.
• Add a queue of events to play back

This could work, but is complicated. Also, what about reboots? Does the list of already published events have to be persisted?

I'm not saying it can't be done, but just publishing the last five log entries so far seems a lot easier to me.

The API actually made for displaying the log in the smartphone. You can get tell the lock to send a list of entries starting at an index. You'll notice this if using the smartphone app: When scrolling, the app has to query new entries from the lock which takes a moment.

[mundschenk-at]

An example YAML configuration for adding a sensor for the user authorizing the last lock action:

    - name: "Last Lock Action Authorization"
      unique_id: '<some unique ID>'
      state_topic: "<prefix>/lock/log"
      value_template: "{{ (value_json|selectattr('type', 'eq', 'LockAction')|selectattr('action', 'in', ['Lock', 'Unlock'])|first).authorizationName }}"
      qos: 1
      device:
        identifiers: <lock device identifier>
      entity_category: diagnostic

[mundschenk-at]

Has anyone besides me tried out that sensor? (It's not very useful for me since I don't use the official app much.) Making a full log entry (PersonX unlocked Front Door at hh:mm:ss) would be easy, but I am not sure it is worthwhile as all that data already exists in other entities.

[technyon]

I'm actually trying to add the discovery topic, somehow I only get "Unknown" as a result. This is the JSON, I put it under "sensor":

{
  "dev": {
    "ids": [
      "nuki_3424edec"
    ],
    "mf": "Nuki",
    "mdl": "SmartLock",
    "name": "Tst"
  },
  "~": "nukitstx",
  "name": "Tst Last action authorization",
  "unique_id": "3424edec_last_action_authorization",
  "stat_t": "~/lock/log",
  "ent_cat": "diagnostic",
  "value_template": "{{ (value_json|selectattr('type', 'eq', 'LockAction')|selectattr('action', 'in', ['Lock', 'Unlock', 'Unlatch'])|first).authorizationName }}"
}

[mundschenk-at]

Mhm. You don't don't need to repeat the complete device information in every entity, just including the ids should be enough. value_template can be abbreviated as val_tpl. I'll try publishing an auto discovery message to see where things go wrong.

[mundschenk-at]

Not sure what went wrong in your test set up (did you check the MQTT debug logs?). This discovery message works for me (topic: homeassistant/sensor/<lockid>/last_action_authorization/config):

{
  "dev": {
    "ids": ["nuki_<lockid>"] 
  }, 
  "~": "<prefix>", 
  "name": "<lockname> Last action authorization", 
  "unique_id": "<lockid>_last_action_authorization", 
  "stat_t": "~/lock/log", 
  "ent_cat": "diagnostic", 
  "val_tpl": "{{ (value_json|selectattr('type', 'eq', 'LockAction')|selectattr('action', 'in', ['Lock', 'Unlock', 'Unlatch'])|first).authorizationName }}"
}

[technyon]

Check release 8.19

[mundschenk-at]

@technyon I think this issue can be closed.

[technyon]

Yes, thanks.