ESPHome Nuki Bridge

uriyacovy · June 4, 2022, 12:30pm

Hi,

Based on Nuki BLE API implementation for ESP32, I’ve built an ESPHome lock component for Nuki smart door lock.
The component acts as a bridge for the Nuki, and creates lock (and other) entities in HA. Notice that once paired to ESPHome, the existing Nuki bridge (if you have any) will be disconnected.

The configuration is quite simple:

esphome:

  libraries:
  - Preferences
  - https://github.com/nkolban/ESP32_BLE_Arduino/
  - https://github.com/I-Connect/NukiBleEsp32#v0.0.4

external_components:
  - source: github://uriyacovy/ESPHome_nuki_lock

lock:
  - platform: nuki_lock
    name: Nuki Lock
    is_paired: 
      name: "Nuki Paired"
    battery_critical:
      name: "Nuki Battery Critical"
    battery_level:
      name: "Nuki Battery Level"

Upon first run, the ESPHome will wait until it is paired to the Nuki. To pair, press the Nuki for about 5 seconds until the led turns constantly on.

See further details here: GitHub - uriyacovy/ESPHome_nuki_lock: ESPHome lock platform for Nuki Smartlock

Disclaimer: I’m not related to Nuki in anyway, and I created this as a quick learning project. I’ll be able to offer very little support, but PRs are always welcomed.

ohadbenita · June 5, 2022, 1:21pm

This is great! Thanks for your contribution

Psylou · July 27, 2022, 12:46pm

Holy moly. That’s exactly what I needed. Thank you so much!

giejay · October 12, 2022, 8:32am

Thanks so much for this component! It works very fast. However, it is a bit unstable for me for my 2 doors. Both esp32’s have excellent wifi but somehow, in HA it mentions it goes unavailable every x minutes. Someone recognize this? I will add a syslogger to it to be able to debug it a better.

uriyacovy · October 12, 2022, 10:01am

Thanks giejay.
Please try the dev repository as explained here, and let me know if this works for you:

github.com/uriyacovy/ESPHome_nuki_lock

Bootloop when out of Nuki's bluetooth range

opened 06:35PM - 21 Aug 22 UTC

closed 10:23AM - 13 Sep 22 UTC

crixionz

First of all, thank you for this amazing component! It works really well when a …connection to the lock is possible. Couldn't wish for more. Now, I hope this finds you well rested **after** your summer vacation! Welcome back! It seems that if the bluetooth connection isn't available it makes the ESP fall in a bootloop. When I moved the Nuki out of reach of the ESP32, it bootlooped and eventually went into safemode. After bringing them closer together again and power cycling the ESP, it worked fine again. I don't have a clue whats really going on, so I'll just provide the logs and you can see for yourself. I've seen two types of errors: This one in [Log 1](https://pastebin.com/kCtx4Z8B) ``` [05:20:12][D][wifi:373]: Starting scan... [05:20:12][D][esp32.preferences:114]: Saving preferences to flash... [05:20:17]E (5956) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time: [05:20:17]E (5956) task_wdt: - loopTask (CPU 1) [05:20:17]E (5956) task_wdt: Tasks currently running: [05:20:17]E (5956) task_wdt: CPU 0: IDLE0 [05:20:17]E (5956) task_wdt: CPU 1: IDLE1 [05:20:17]E (5956) task_wdt: Aborting. [05:20:17]abort() was called at PC 0x4015b0e8 on core 0 [05:20:17] [05:20:17]ELF file SHA256: 0000000000000000 [05:20:17] [05:20:17]Backtrace: [...truncated by me] [05:20:17] [05:20:17]Rebooting... [05:20:17]ets Jun 8 2016 00:22:57 ``` 󠀡 and this one in [Log 2](https://pastebin.com/fSbGQm3g) ``` [12:32:32][D][esp32.preferences:114]: Saving preferences to flash... [12:32:32]Guru Meditation Error: Core 0 panic'ed (IllegalInstruction). Exception was unhandled. [12:32:32]Memory dump at 0x400f8200: ff0b0000 ffffffff ffffffff [12:32:32]Core 0 register dump: [12:32:32]PC : 0x400f8204 PS : 0x00060c30 A0 : 0x8012b9bc A1 : 0x3ffb7830 WARNING Decoded 0x400f8204: wifi_softap_stop [12:32:32]A2 : 0x0000000b A3 : 0x00000004 A4 : 0x00000000 A5 : 0x3ffbc040 [12:32:32]A6 : 0x00000000 A7 : 0x3ffb6760 A8 : 0x8010c546 A9 : 0x80000020 [12:32:32]A10 : 0x00000000 A11 : 0x3ffbc25c A12 : 0x00000005 A13 : 0x00000020 [12:32:32]A14 : 0x00000020 A15 : 0x00060023 SAR : 0x00000000 EXCCAUSE: 0x00000000 [12:32:32]EXCVADDR: 0x00000000 LBEG : 0x4000c2e0 LEND : 0x4000c2f6 LCOUNT : 0xffffffff [12:32:32] [12:32:32]ELF file SHA256: 0000000000000000 [12:32:32] [12:32:32]Backtrace: [...truncated by me] [12:32:33] [12:32:33]Rebooting... [12:32:33]ets Jun 8 2016 00:22:57 ``` I'm using a NodeMCU and a Nuki 1.0 In Log 1, the Nuki has not yet been paired at first, as you can probably tell. Also note that these two logs derive from different esphome configs. In Log 1 the lock is called 'Nuki Lock' and in Log 2 it's called 'Hardware Nuki' (and I set up a template lock with the name 'Nuki') Let me know when you need more info or this is an issue for [I-Connect/NukiBleEsp32](https://github.com/I-Connect/NukiBleEsp32)

giejay · October 18, 2022, 8:18pm

Thanks! Tried it but I got a compile error:

Compiling .pioenvs/sheddoor/libc13/NukiBleEsp/NukiLock.cpp.o
In file included from .piolibdeps/sheddoor/NukiBleEsp/src/NukiBle.cpp:13:0:
.piolibdeps/sheddoor/NukiBleEsp/src/NukiBle.h: In constructor 'Nuki::NukiBle::NukiBle(const string&, uint32_t, NimBLEUUID, NimBLEUUID, NimBLEUUID, NimBLEUUID, std::__cxx11::string)':
.piolibdeps/sheddoor/NukiBleEsp/src/NukiBle.h:323:14: error: 'Nuki::NukiBle::deviceId' will be initialized after [-Werror=reorder]
     uint32_t deviceId;            //The ID of the Nuki App, Nuki Bridge or Nuki Fob to be authorized.
              ^
.piolibdeps/sheddoor/NukiBleEsp/src/NukiBle.h:281:22: error:   'const NimBLEUUID Nuki::NukiBle::pairingServiceUUID' [-Werror=reorder]
     const NimBLEUUID pairingServiceUUID;
                      ^
.piolibdeps/sheddoor/NukiBleEsp/src/NukiBle.cpp:30:1: error:   when initialized here [-Werror=reorder]
 NukiBle::NukiBle(const std::string& deviceName,
 ^
Archiving .pioenvs/sheddoor/libc9d/libBleScanner.a
Compiling .pioenvs/sheddoor/libc13/NukiBleEsp/NukiLockUtils.cpp.o
Indexing .pioenvs/sheddoor/libc9d/libBleScanner.a
.piolibdeps/sheddoor/NukiBleEsp/src/NukiBle.cpp: In member function 'Nuki::PairingState Nuki::NukiBle::pairStateMachine(Nuki::PairingState)':
.piolibdeps/sheddoor/NukiBleEsp/src/NukiBle.cpp:677:78: warning: ignoring return value of 'int crypto_scalarmult_curve25519(unsigned char*, const unsigned char*, const unsigned char*)', declared with attribute warn_unused_result [-Wunused-result]
       crypto_scalarmult_curve25519(sharedKeyS, myPrivateKey, remotePublicKey);
                                                                              ^
Compiling .pioenvs/sheddoor/libc13/NukiBleEsp/NukiOpener.cpp.o
cc1plus: some warnings being treated as errors
*** [.pioenvs/sheddoor/libc13/NukiBleEsp/NukiBle.cpp.o] Error 1
===================================================================== [FAILED] Took 170.79 seconds

This is my yaml:

esphome:
  name: sheddoor
  libraries:
  - Preferences
  # - https://github.com/nkolban/ESP32_BLE_Arduino/
  - https://github.com/uriyacovy/NukiBleEsp32#dev

external_components:
  - source: github://uriyacovy/ESPHome_nuki_lock@dev

lock:
  # Required:
  - platform: nuki_lock
    name: Shed Door Lock
    is_connected: 
      name: "Shed Door Connected"
    is_paired: 
      name: "Shed Door Paired"
  # Optional:
    battery_critical:
      name: "Shed Door Battery Critical"
    battery_level:
      name: "Shed Door Battery Level"
    # door_sensor:
    #   name: "Shed Door Sensor"
    # door_sensor_state:
    #   name: "Shed Door Sensor State"

# esp32:
#   board: az-delivery-devkit-v4
#   framework:
#     type: arduino

esp32:
  board: az-delivery-devkit-v4
  framework:
    type: arduino

# Enable logging
logger:

# Enable Home Assistant API
api:
  password: ""

ota:
  password: ""

I did a esphome clean command and removed the temp folders but still no luck. Any idea?

Edit: After also changing the esp32 block to the one you posted, it works. I thought that should just remain as is and point to my az-delivery-devkit-d4 but I guess I was wrong:)

esp32:
  board: esp32dev
  framework:
    type: arduino
    version: 2.0.3
    platform_version: 4.4.0

giejay · October 19, 2022, 2:54pm

@uriyacovy

After running the dev branch for a day, this is the result:

I see a similar behavior in the logs:

Oct 19 14:12:08 sheddoor api: [D][api:102]: Accepted ::FFFF:192.168.2.15
Oct 19 14:12:08 sheddoor api.connection: [D][api.connection:861]: Home Assistant 2022.8.6 (::FFFF:192.168.2.15): Connected successfully
Oct 19 14:20:00 sheddoor api: [D][api:102]: Accepted ::FFFF:192.168.2.15
Oct 19 14:20:00 sheddoor api.connection: [D][api.connection:861]: Home Assistant 2022.8.6 (::FFFF:192.168.2.15): Connected successfully
Oct 19 14:20:07 sheddoor api.connection: [W][api.connection:078]: Home Assistant 2022.8.6 (::FFFF:192.168.2.15): Connection reset
Oct 19 14:24:30 sheddoor api.connection: [W][api.connection:080]: Home Assistant 2022.8.6 (::FFFF:192.168.2.15): Connection closed
Oct 19 14:24:31 sheddoor api: [D][api:102]: Accepted ::FFFF:192.168.2.15
Oct 19 14:24:31 sheddoor api.connection: [D][api.connection:861]: Home Assistant 2022.8.6 (::FFFF:192.168.2.15): Connected successfully
Oct 19 14:33:30 sheddoor api.connection: [W][api.connection:078]: Home Assistant 2022.8.6 (::FFFF:192.168.2.15): Connection reset
Oct 19 14:33:30 sheddoor api: [D][api:102]: Accepted ::FFFF:192.168.2.15
Oct 19 14:33:30 sheddoor api.connection: [D][api.connection:861]: Home Assistant 2022.8.6 (::FFFF:192.168.2.15): Connected successfully
Oct 19 14:35:45 sheddoor api.connection: [W][api.connection:080]: Home Assistant 2022.8.6 (::FFFF:192.168.2.15): Connection closed
Oct 19 14:35:45 sheddoor api: [D][api:102]: Accepted ::FFFF:192.168.2.15
Oct 19 14:35:45 sheddoor api.connection: [D][api.connection:861]: Home Assistant 2022.8.6 (::FFFF:192.168.2.15): Connected successfully
Oct 19 14:41:23 sheddoor api.connection: [W][api.connection:080]: Home Assistant 2022.8.6 (::FFFF:192.168.2.15): Connection closed
Oct 19 14:41:24 sheddoor api: [D][api:102]: Accepted ::FFFF:192.168.2.15
Oct 19 14:41:25 sheddoor api.connection: [D][api.connection:861]: Home Assistant 2022.8.6 (::FFFF:192.168.2.15): Connected successfully
Oct 19 14:45:53 sheddoor api.connection: [W][api.connection:080]: Home Assistant 2022.8.6 (::FFFF:192.168.2.15): Connection closed
Oct 19 14:45:54 sheddoor api: [D][api:102]: Accepted ::FFFF:192.168.2.15
Oct 19 14:45:54 sheddoor api.connection: [D][api.connection:861]: Home Assistant 2022.8.6 (::FFFF:192.168.2.15): Connected successfully
Oct 19 14:57:10 sheddoor api: [D][api:102]: Accepted ::FFFF:192.168.2.15
Oct 19 14:57:10 sheddoor api.connection: [D][api.connection:861]: Home Assistant 2022.8.6 (::FFFF:192.168.2.15): Connected successfully
Oct 19 14:57:20 sheddoor api.connection: [W][api.connection:080]: Home Assistant 2022.8.6 (::FFFF:192.168.2.15): Connection closed

The wifi should be pretty stable and I’m also seeing the same behavior for my other lock which is just next to the router. Can’t seem to figure out why there might be a reset or disconnect happening every hour for x seconds.

Edit:
Tried to add the power_save_mode: none option after reading through some GitHub issues. Unfortunately that prevents the API port from being accessible, “not able to connect” messages. The device is pingable so wifi works fine.

mbk_med · February 20, 2023, 3:23pm

Hello,
Thank you for the dev, I have a question is it possible to have the “open door” command, because the behavior I have is just to lock/unlock ?

thanks

uriyacovy · February 20, 2023, 6:24pm

Hi,
This is already implemented, see here: Option to unlatch the door · Issue #1 · uriyacovy/ESPHome_nuki_lock · GitHub

mbk_med · March 5, 2023, 12:59pm

Great, thank you.
I added an ‘Open’ button to the Yaml and did a reinstall.
it works very well

button:
  - platform: template
    name: "Nuki Open"
    on_press:
      - lock.open: nuki

mbk_med · March 5, 2023, 1:04pm

I have another question, is it normal that the “bridge” refuses to connect if the wifi is hidden?
thanks

uriyacovy · March 6, 2023, 8:32am

I’m not sure it is related to the this bridge implementation, since it does not change the default wifi behavior. Does it work for you in general?

mbk_med · March 8, 2023, 12:04pm

Thank you for your reply.
This is the only device that cannot connect to the hotspot when it is hidden. Prior to installing your firmware (with the base firmware installed via the web tool), it was able to connect to the same access point (hidden). I may be wrong, but I think it is related to a version of library that handles WiFi or something like that.

Edit:
Ok, I solved the problem by adding the variable hidden set to true, based on the documentation found at WiFi Component — ESPHome.

Here’s wifi part in my yaml:

wifi:
  networks:
  - ssid: !secret wifi_2g_ssid
    bssid: !secret wifi_2g_bssid
    password: !secret wifi_2g_password
    hidden: true
  - ssid: !secret wifi_5g_ssid
    bssid: !secret wifi_5g_bssid
    password: !secret wifi_5g_password
    hidden: true

ladaowner · April 2, 2023, 6:41pm

does this support the jammed status for us European cousin who have lift to lock handles?

Tefi · September 28, 2023, 9:07am

I use the following code but recieve an error message.

esphome:
  name: $device_name
  libraries:
  - Preferences
  - https://github.com/uriyacovy/NukiBleEsp32#dev
  comment: "ciPIR with NUKI"

external_components:
  - source: github://uriyacovy/ESPHome_nuki_lock@dev

esp32:
  board: esp32dev
  framework:
    type: arduino
    version: 2.0.3
    platform_version: 4.4.0

Where is the crc16.h file

Compiling .pioenvs/bwm-korridor-ug-eingang/lib0e3/NukiBleEsp/NukiLockUtils.cpp.o
.piolibdeps/bwm-korridor-ug-eingang/NukiBleEsp/src/NukiBle.cpp: In member function 'Nuki::PairingState Nuki::NukiBle::pairStateMachine(Nuki::PairingState)':
.piolibdeps/bwm-korridor-ug-eingang/NukiBleEsp/src/NukiBle.cpp:698:35: warning: ignoring return value of 'int crypto_scalarmult_curve25519(unsigned char*, const unsigned char*, const unsigned char*)', declared with attribute warn_unused_result [-Wunused-result]
       crypto_scalarmult_curve25519(sharedKeyS, myPrivateKey, remotePublicKey);
       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Compiling .pioenvs/bwm-korridor-ug-eingang/lib0e3/NukiBleEsp/NukiOpener.cpp.o
Compiling .pioenvs/bwm-korridor-ug-eingang/lib0e3/NukiBleEsp/NukiOpenerUtils.cpp.o
Compiling .pioenvs/bwm-korridor-ug-eingang/lib0e3/NukiBleEsp/NukiUtils.cpp.o
.piolibdeps/bwm-korridor-ug-eingang/NukiBleEsp/src/NukiUtils.cpp:4:10: fatal error: Crc16.h: No such file or directory

***************************************************************
* Looking for Crc16.h dependency? Check our library registry!
*
* CLI  > platformio lib search "header:Crc16.h"
* Web  > https://registry.platformio.org/search?q=header:Crc16.h
*
***************************************************************

 #include "Crc16.h"
          ^~~~~~~~~
compilation terminated.
*** [.pioenvs/bwm-korridor-ug-eingang/lib0e3/NukiBleEsp/NukiUtils.cpp.o] Error 1

Ferdytao · September 28, 2023, 6:35pm

Is it possible to use another door sensor status like aqara to update the nuki “door_sensor_state:” inside the card?

Tefi · September 30, 2023, 7:22am

The Aqara FP2 sensor has an esp32 and espHome should by pssoible to flash.

Ferdytao · September 30, 2023, 10:50am

I mean the aqara door sensors

drdino · October 4, 2023, 7:15am

hello,

just include Crc16 in the libs part:

libraries:

Preferences
Crc16
GitHub - uriyacovy/NukiBleEsp32
comment: “ciPIR with NUKI”

Tefi · October 5, 2023, 12:04pm

many thanks, this was the solution.