Challenges with Nuki 2.0 smart lock

Configuration
1

Last week I installed a Nuki 2.0 smart lock because of the existing HA platform integration and because they seem to be pretty open and have lots of APIs (local as well as web). Initial configuration worked without problems, but during testing I noticed the lock became unavailable if there are to many requests in a short period of time.

Unfortunately the platfom: nuki doesn’t support the battery charge and more importantly the door state yet. So I researched a bit and implemented those myself with REST sensors. Boy, querying door state every 30sec (HA standard) and battery every 15min basically killed the local bridge API:

2021-01-31 19:38:51 WARNING (SyncWorker_8) [homeassistant.components.nuki.lock] Network issues detect with Keller
2021-01-31 19:38:51 WARNING (SyncWorker_8) [homeassistant.components.nuki.lock] Network issues detect with Keller
2021-01-31 19:39:21 WARNING (SyncWorker_11) [homeassistant.components.nuki.lock] Network issues detect with Keller
2021-01-31 19:39:21 WARNING (SyncWorker_11) [homeassistant.components.nuki.lock] Network issues detect with Keller
2021-01-31 19:39:51 ERROR (MainThread) [homeassistant.components.rest.data] Error fetching data: http://192.168.23.30:8080/list?token=[redacted] failed with can't handle event type ConnectionClosed when role=SERVER and state=SEND_RESPONSE
2021-01-31 19:40:21 WARNING (SyncWorker_12) [homeassistant.components.nuki.lock] Network issues detect with Keller
2021-01-31 19:40:21 WARNING (SyncWorker_12) [homeassistant.components.nuki.lock] Network issues detect with Keller
2021-01-31 19:40:51 ERROR (MainThread) [homeassistant.components.rest.data] Error fetching data: http://192.168.23.30:8080/list?token=[redacted] failed with can't handle event type ConnectionClosed when role=SERVER and state=SEND_RESPONSE
2021-01-31 19:41:21 WARNING (SyncWorker_9) [homeassistant.components.nuki.lock] Network issues detect with Keller

The lock and the sensors where unavailable more or less all the time or changing every 30sec:
chart
chart

I removed the REST sensors and everything is well again. From the Nuki dev community I understand that two queries at a time are a problem, but I don’t know how to manage the process so that doesn’t happen. It also appears rasing the topic with Nuki doesn’t help as the limitation appears to be accepted by them:

No. No functional changes to the API. This was just the proposed rewrite of the code which prevents erroneous 503 responses on rev 2. The basic limitation (only one http request at a time) did not change, which means that 503 replies can still happen if parallel requests are sent to the bridge.

Worakround: I implemented it using the Nuki WebAPI and it works just fine. The latency of > 1sec is not an issue, but of course for something like a smart lock I would really appreciate to do everything locally and disconnect the HW bridge from the internet.

@pschmitt: Unfortunately I can’t do anything in Python (HA has me this close to learning it just to be able to contribute…), but I guess it is pretty simple to add battery charge, door state and maybe a couple of extra fields to the main platform. That should lead to it being queried togther with what you are doing anyway, so it might be the most elegant solution. Would it be possible to have a look at that?

1 Like
2

Hi Daniel,

You’ve got the 2.0 working with the nuki integration? I seem to hit an error for which I have opened up an issue https://github.com/home-assistant/core/issues/41827

Even in a VM I get that error, it is Python related, so for me I cannot use the Nuki in HA at all :frowning:

3

For anyone looking this up and having similar problems to mine, here is what worked for me:

Setup the locks using the Nuki integration -> This will give you the lock state and necessary services to operate the lock. I have only tested lock / unlock so for, but I would expect lock & open to also work. If not this can be done using the HubAPI or the WebAPI (which is very well documented).

To also have the door state, battery charge and more recently added information in HA I now query the WebAPI:

- platform: rest
  name: Nuki 
  resource: https://api.nuki.io/smartlock/##id##
  headers:
    Authorization: Bearer ##TOKEN##
  scan_interval: 30
  json_attributes:
    - state
  value_template: 'OK' #Circumvent 255 character limit
  
- platform: template
  sensors:
    nuki_battery:
      friendly_name: 'Nuki'
      unit_of_measurement: '%'
      value_template: '{{ state_attr("sensor.nuki", "state")["batteryCharge"] }}'
      icon_template: 'mdi:battery'

Please refer to the Nuki API documenation on how to setup your account, bearer token, etc.

It appears @pschmitt is not working on HA / Nuki anymore and I don’t know Python, so this appears to be the workaround until someone is updating the Nuki integration in HA. Best case would be to integrate the additional fields in one singular API call to the Bridge and show it as attributes on the lock entity in HA. I understand that the changes have been made upstream…

4

That’s not true.

5

I apologize if I judged prematurely due to 8 month of silence. Good to know!

6

Great tip @NamCisum.
Can you please share how you retrieve door state please using WebAPI?
I am currently using local access like this:

  - platform: rest
    name: "Door Position"
    device_class: door
    resource: !secret nuki_bridge_info_url
    value_template: "{{ value_json[0]['lastKnownState']['doorsensorStateName'] }}"

This is convenient because state is named (“Open” or “Closed”).
However, using your code, door position is a code. Seem to be “2” when closed in my case. Are you using a template to get the sate name?

7

Sure:


# Nuki door via WebAPI
- platform: template
  sensors:
    sensor_nuki_door:
      device_class: door
      friendly_name: "Door"
      value_template: >
        {{ state_attr("sensor.nuki", "state")["doorState"] == 3 }}

sensor.nuki = REST sensor for WebAPI as described above…

1 Like
8

Working great, thanks!

  - platform: template
    sensors:
      sensor_nuki_door:
        friendly_name: 'Door Position'
        unique_id: nuki_door_position
        device_class: door
        value_template: >
          {{ state_attr("sensor.nuki", "state")["doorState"] == 3 }}

Added unique_id so that entity can be assigned to an area in UI.

9

By the way for anyone finding this topic: There seems to be a new integration (“Nuki NG”) around - I haven’t tried it (yet), but as it appears that using it you don’t have to create REST sensors yourself anyore:

Can be installed via HACS, there seems to be some dynamic around that, so decide for your self if you feel it’s ready for production…

1 Like