The scope of Nuki Hub is to have an efficient way to integrate Nuki devices in a local Home Automation platform.

The Nuki Hub software runs on a ESP32 module and acts as a bridge between Nuki devices and a Home Automation platform.

It communicates with a Nuki Lock and/or Opener through Bluetooth (BLE) and uses MQTT to integrate with other systems.

It exposes the lock state (and much more) through MQTT and allows executing commands like locking and unlocking as well as changing the Nuki Lock/Opener configuration through MQTT.

Nuki Hub does not integrate with the Nuki mobile app, it can't register itself as a bridge in the official Nuki mobile app.

Feel free to join us on Discord: https://discord.gg/9nPq85bP4p

Supported ESP32 devices:

• Nuki Hub is compiled against all ESP32 models with Wi-Fi and Bluetooh Low Energy (BLE) which are supported by ESP-IDF 5.1.4 and Arduino Core 3.0.4.
• Tested stable builds are provided for the ESP32, ESP32-S3 and ESP32-C3.
• Untested builds are provided for the ESP32-Solo1.
• Support for the ESP32-C6 and ESP32-H2 is experimental. There could be more frequent crashes than on other ESP32 devices and connections with the Nuki device could be slower than on other ESP32 devices.

Not supported ESP32 devices:

• The ESP32-S2 has no BLE and as such can't run Nuki Hub.

Supported Nuki devices:

• Nuki Smart Lock 1.0
• Nuki Smart Lock 2.0
• Nuki Smart Lock 3.0
• Nuki Smart Lock 3.0 Pro (read FAQ below)
• Nuki Smart Lock 4.0
• Nuki Smart Lock 4.0 Pro (read FAQ below)
• Nuki Opener
• Nuki Keypad 1.0
• Nuki Keypad 2.0

Supported Ethernet devices:
As an alternative to Wi-Fi (which is available on any supported ESP32), the following ESP32 modules with built-in wired ethernet are supported:

• Olimex ESP32-POE
• Olimex ESP32-POE-ISO
• WT32-ETH01
• M5Stack Atom POE
• M5Stack PoESP32 Unit
• LilyGO-T-ETH-POE
• GL-S10 (Revisions 2.1, 2.3 / 1.0 is not supported)

In principle all ESP32 (and variants) devices with built-in ethernet port are supported, but might require additional setup using the "Custom LAN setup" option. See the "Connecting via Ethernet" section for more information.

• If WIFI6 is required: ESP32-C6

• If PoE is required: Any of the above mentioned devices with PoE or any other ESP device in combination with a SPI Ethernet module (W5500) and PoE to Ethernet and USB type B/C splitter

• If you want maximum performance and intend to run any or multiple of the following:

  • a Nuki Lock and Nuki Opener and/or
  • MQTT SSL and/or
  • HTTP SSL and/or
  • large amounts of keypad codes, timecontrol or authorization entries
  • Developing/debugging Nuki devices and/or Nuki Hub

  An ESP32-S3 with 2MB of PSRAM or more (look for an ESP32-S3 with the designation N>=4 and R>=2 such as an ESP32-S3 N16R8)

• In general when buying a new device when size and a couple of dollars more or less are not an issue: An ESP32-S3 with 2MB of PSRAM or more.
  

The ESP32-S3 is a dual-core CPU with many GPIO's, ability to enlarge RAM using PSRAM, ability to connect Ethernet modules over SPI and optionally power the device with a PoE splitter. The only functions missing from the ESP32-S3 as compared to other ESP devices is the ability to use some Ethernet modules only supported by the original ESP32 and the ability to connect over WIFI6 (C6)

If you haven't ordered your Nuki product yet, you can support me by using my referrer code when placing your order:
REFZDJ2QKXTG2
This will also give you a 10% discount on your order.

This project is free to use for everyone. However if you feel like donating, you can buy me a coffee at ko-fi.com:

Flash the firmware to an ESP32. The easiest way to install is to use the web installer using a compatible browser like Chrome/Opera/Edge:
https://technyon.github.io/nuki_hub/
NOTE: Webflash is not available for the ESP32-Solo1

Alternatively download the latest release for your ESP32 model from https://github.com/technyon/nuki_hub/releases
Unpack the zip archive and read the included how-to-flash.txt for installation instructions for either "Espressif Flash Download Tools" or "esptool".

Power up the ESP32 and a new Wi-Fi access point named "ESP32_(8 CHARACTER ALPHANUMERIC)" should appear.
Connect a client device to this access point and in a browser navigate to "https://192.168.4.1".
Use the web interface to connect the ESP to your preferred Wi-Fi network.

After configuring Wi-Fi, the ESP should automatically connect to your network.

To configure the connection to the MQTT broker, first connect your client device to the same Wi-Fi network the ESP32 is connected to.
In a browser navigate to the IP address assigned to the ESP32 via DHCP (often found in the web interface of your internet router).

Next click on "Edit" below "MQTT and Network Configuration" and enter the address and port (usually 1883) of your MQTT broker and a username and a password if required by your MQTT broker.

The firmware supports SSL encryption for MQTT, however most people and especially home users don't use this.
In that case leave all fields starting with "MQTT SSL" blank. Otherwise see the "MQTT Encryption" section of this README.

Enable pairing mode on the Nuki Lock or Opener (press the button on the Nuki device for a few seconds) and power on the ESP32.
Pairing should be automatic.

When pairing is successful, the web interface should show "Paired: Yes".
MQTT nodes like lock state and battery level should now reflect the reported values from the lock.

Note: It is possible to run Nuki Hub alongside a Nuki Bridge. This is not recommended (unless when using hybrid mode) and will lead to excessive battery drain and can lead to either device missing updates. Enable "Register as app" before pairing to allow this. Otherwise the Bridge will be unregistered when pairing the Nuki Hub.

Hybrid mode allows you to use the official Nuki MQTT implemenation on a Nuki Lock 3.0 Pro, Nuki Lock 4.0 or Nuki Lock 4.0 Pro in conjunction with Nuki Hub.
See hybrid mode for more information.

ESP32 devices have a limited amount of free RAM available.

On version 9.01 of Nuki Hub with only a Nuki Lock connected the expected free amount of RAM/Heap available is around:

• ESP32: 60 kilobytes / 60.000 bytes
• Other variants (C3/S3/C6/H2): 90-120 kilobytes / 90.000-120.000 bytes

This free amount of RAM can be reduced (temporarily) by certain actions (such as changing Nuki device config) or continuously when enabling the following:

• Connecting both a Nuki opener and a Nuki lock to Nuki Hub
• Enlarging stack sizes of the Nuki and Network task to accommodate large amounts of keypad codes, authorization entries or timecontrol entries
• MQTT SSL (Costs about 30k RAM)
• HTTP SSL (Costs about 30k RAM)
• Developing/debugging Nuki devices and/or Nuki Hub, using WebSerial (Costs about 30k RAM)

The currently available RAM/Heap can be found on the info page of the Web configurator of Nuki Hub.

When the ESP32 runs out of available RAM this device can crash or otherwise unexpected behaviour can occur.

Nuki Hub does allow for the use of embedded PSRAM on the regular binaries whenever it is available.
PSRAM is usually 2, 4 or 8MB in size and thus greatly enlarges the 320kb of internal RAM that is available.
It is basically impossible to run out of RAM when PSRAM is available. You can check on the info page of the Web configurator if PSRAM is available.

Note that there are two build of Nuki Hub for the ESP32-S3 available.
One for devices with no or Quad SPI PSRAM and one for devices with Octal SPI PSRAM.
If your ESP32-S3 device has PSRAM but it is not detected please flash the other S3 binary.

In a browser navigate to the IP address assigned to the ESP32.

• Host name: Set the hostname for the Nuki Hub ESP
• MQTT Broker: Set to the IP address of the MQTT broker
• MQTT Broker port: Set to the Port of the MQTT broker (usually 1883)
• MQTT User: If using authentication on the MQTT broker set to a username with read/write rights on the MQTT broker, set to # to clear
• MQTT Password : If using authentication on the MQTT broker set to the password belonging to a username with read/write rights on the MQTT broker, set to # to clear

• Home Assistant discovery topic: Set to the Home Assistant auto discovery topic, leave empty to disable auto discovery. Usually "homeassistant" unless you manually changed this setting on the Home Assistant side.
• Home Assistant device configuration URL: When using Home Assistant discovery the link to the Nuki Hub Web Configuration will be published to Home Assistant. By default when this setting is left empty this will link to the current IP of the Nuki Hub. When using a reverse proxy to access the Web Configuration you can set a custom URL here.
• Set Nuki Opener Lock/Unlock action in Home Assistant to Continuous mode (Opener only): By default the lock entity in Home Assistant will enable Ring-to-Open (RTO) when unlocking and disable RTO when locking. By enabling this setting this behaviour will change and now unlocking will enable Continuous Mode and locking will disable Continuous Mode, for more information see the "Home Assistant Discovery" section of this README.
• MQTT SSL CA Certificate: Optionally set to the CA SSL certificate of the MQTT broker, see the "MQTT Encryption" section of this README.
• MQTT SSL Client Certificate: Optionally set to the Client SSL certificate of the MQTT broker, see the "MQTT Encryption" section of this README.
• MQTT SSL Client Key: Optionally set to the Client SSL key of the MQTT broker, see the "MQTT Encryption" section of this README.
• Network hardware: "Wi-Fi only" by default, set to one of the specified ethernet modules if available, see the "Supported Ethernet devices" and "Connecting via Ethernet" section of this README.
• Disable fallback to Wi-Fi / Wi-Fi config portal: By default the Nuki Hub will fallback to Wi-Fi and open the Wi-Fi configuration portal when the network connection fails. Enable this setting to disable this fallback.
• Connect to AP with the best signal in an environment with multiple APs with the same SSID: Enable to perform a scan for the Access Point with the best signal strenght for the specified SSID in a multi AP/Mesh environment.
• RSSI Publish interval: Set to a positive integer to set the amount of seconds between updates to the maintenance/wifiRssi MQTT topic with the current Wi-Fi RSSI, set to -1 to disable, default 60.
• MQTT Timeout until restart: Set to a positive integer to restart the Nuki Hub after the set amount of seconds has passed without an active connection to the MQTT broker, set to -1 to disable, default 60.
• Restart on disconnect: Enable to restart the Nuki Hub when disconnected from the network.
• Reconnect network on MQTT connection failure: Enable to force reconnection to the network when connection to the MQTT broker fails (after 15 tries).
• Enable MQTT logging: Enable to fill the maintenance/log MQTT topic with debug log information.
• Enable WebSerial logging : Enable to publish debug log information to https://NUKIHUBIP:81/webserial.
• Check for Firmware Updates every 24h: Enable to allow the Nuki Hub to check the latest release of the Nuki Hub firmware on boot and every 24 hours. Requires the Nuki Hub to be able to connect to github.com. The latest version will be published to MQTT and will be visible on the main page of the Web Configurator.
• Allow updating using MQTT: Enable to allow starting the Nuki Hub update process using MQTT. Will also enable the Home Assistant update functionality if auto discovery is enabled.
• Disable some extraneous non-JSON topics: Enable to not publish non-JSON keypad and config MQTT topics.
• Enable hybrid official MQTT and Nuki Hub setup: Enable to combine the official MQTT over Thread/Wi-Fi with BLE. Improves speed of state changes. Needs the official MQTT to be setup first. Also requires Nuki Hub to be paired as app and unregistered as a bridge using the Nuki app. See hybrid mode
• Enable sending actions through official MQTT: Enable to sent lock actions through the official MQTT topics (e.g. over Thread/Wi-Fi) instead of using BLE. Needs "Enable hybrid official MQTT and Nuki Hub setup" to be enabled. See hybrid mode
• Time between status updates when official MQTT is offline (seconds): Set to a positive integer to set the maximum amount of seconds between actively querying the Nuki lock for the current lock state when the official MQTT is offline, default 600.

• Enable DHCP: Enable to use DHCP for obtaining an IP address, disable to use the static IP settings below
• Static IP address: When DHCP is disabled set to the preferred static IP address for the Nuki Hub to use
• Subnet: When DHCP is disabled set to the preferred subnet for the Nuki Hub to use
• Default gateway: When DHCP is disabled set to the preferred gateway IP address for the Nuki Hub to use
• DNS Server: When DHCP is disabled set to the preferred DNS server IP address for the Nuki Hub to use

• Nuki Smartlock enabled: Enable if you want Nuki Hub to connect to a Nuki Lock (1.0-4.0)
• MQTT Nuki Smartlock Path (Lock only): Set to the preferred MQTT root topic for the Nuki Lock, defaults to "nuki". Make sure this topic is not the same as the setting for the opener and is unique when using multiple Nuki Hub devices (when using multiple Nuki Locks)
• Nuki Opener enabled: Enable if you want Nuki Hub to connect to a Nuki Opener
• MQTT Nuki Opener Path (Opener only): Set to the preferred MQTT root topic for the Nuki Opener, defaults to "nukiopener". Make sure this topic is not the same as the setting for the lock and is unique when using multiple Nuki Hub devices (when using multiple Nuki Openers)

• Query interval lock state: Set to a positive integer to set the maximum amount of seconds between actively querying the Nuki device for the current lock state, default 1800.
• Query interval configuration: Set to a positive integer to set the maximum amount of seconds between actively querying the Nuki device for the current configuration, default 3600.
• Query interval battery: Set to a positive integer to set the maximum amount of seconds between actively querying the Nuki device for the current battery state, default 1800.
• Query interval keypad (Only available when a Keypad is detected): Set to a positive integer to set the maximum amount of seconds between actively querying the Nuki device for the current keypad state, default 1800.
• Number of retries if command failed: Set to a positive integer to define the amount of times the Nuki Hub retries sending commands to the Nuki Lock or Opener when commands are not acknowledged by the device, default 3.
• Delay between retries: Set to the amount of milliseconds the Nuki Hub waits between resending not acknowledged commands, default 100.
• Lock: Nuki Bridge is running alongside Nuki Hub: Enable to allow Nuki Hub to co-exist with a Nuki Bridge by registering Nuki Hub as an (smartphone) app instead of a bridge. Changing this setting will require re-pairing. Enabling this setting is strongly discouraged as described in the "Pairing with a Nuki Lock or Opener" section of this README, unless when used in Hybrid mode (Official MQTT / Nuki Hub co-existance)
• Opener: Nuki Bridge is running alongside Nuki Hub: Enable to allow Nuki Hub to co-exist with a Nuki Bridge by registering Nuki Hub as an (smartphone) app instead of a bridge. Changing this setting will require re-pairing. Enabling this setting is strongly discouraged as described in the "Pairing with a Nuki Lock or Opener" section of this README
• Restart if bluetooth beacons not received: Set to a positive integer to restart the Nuki Hub after the set amount of seconds has passed without receiving a bluetooth beacon from the Nuki device, set to -1 to disable, default 60. Because the bluetooth stack of the ESP32 can silently fail it is not recommended to disable this setting.
• BLE transmit power in dB: Set to a integer between -12 and 9 to set the Bluetooth transmit power, default 9.

• Publish Nuki configuration information: Enable to publish information about the configuration of the connected Nuki device(s) through MQTT.
• Publish keypad entries information (Only available when a Keypad is detected): Enable to publish information about keypad codes through MQTT, see the "Keypad control" section of this README
• Also publish keypad codes (Only available when a Keypad is detected): Enable to publish the actual keypad codes through MQTT, note that is could be considered a security risk
• Add, modify and delete keypad codes (Only available when a Keypad is detected): Enable to allow configuration of keypad codes through MQTT, see the "Keypad control" section of this README
• Publish timecontrol information: Enable to publish information about timecontrol entries through MQTT, see the "Timecontrol" section of this README
• Add, modify and delete timecontrol entries: Enable to allow configuration of timecontrol entries through MQTT, see the "Timecontrol" section of this README
• Publish authorization information: Enable to publish information about authorization entries through MQTT, see the "Authorization" section of this README
• Modify and delete authorization entries: Enable to allow configuration of authorization entries through MQTT, see the "Authorization" section of this README
• Publish auth data: Enable to publish authorization data to the MQTT topic lock/log. Requires the Nuki security code / PIN to be set, see "Nuki Lock PIN / Nuki Opener PIN" below.

• Enable or disable executing each available lock action for the Nuki Lock and Nuki Opener through MQTT. Note: GPIO control is not restricted through this setting.

• Enable or disable changing each available configuration setting for the Nuki Lock and Nuki Opener through MQTT.
• NOTE: Changing configuration settings requires the Nuki security code / PIN to be set, see "Nuki Lock PIN / Nuki Opener PIN" below.

• User: Pick a username to enable HTTP Basic authentication for the Web Configuration, Set to "#" to disable authentication.
• Password/Retype password: Pick a password to enable HTTP Basic authentication for the Web Configuration.

• PIN Code: Fill with the Nuki Security Code of the Nuki Lock and/or Nuki Opener. Required for functions that require the security code to be sent to the lock/opener such as setting lock permissions/adding keypad codes, viewing the activity log or changing the Nuki device configuration. Set to "#" to remove the security code from the Nuki Hub configuration.

• Type [4 DIGIT CODE] to confirm unpair: Set to the shown randomly generated code to unpair the Nuki Lock or Opener from the Nuki Hub.

• Type [4 DIGIT CODE] to confirm factory reset: Set to the shown randomly generated code to reset all Nuki Hub settings to default and unpair Nuki Lock and/or Opener. Optionally also reset Wi-Fi settings to default (and reopen the Wi-Fi configurator) by enabling the checkbox.

• Gpio [2-33]: See the "GPIO lock control" section of this README.

• lock/action: Allows to execute lock actions. After receiving the action, the value is set to "ack". Possible actions: unlock, lock, unlatch, lockNgo, lockNgoUnlatch, fullLock, fobAction1, fobAction2, fobAction3.
• lock/statusUpdated: 1 when the Nuki Lock/Opener signals the KeyTurner state has been updated, resets to 0 when Nuki Hub has queried the updated state.
• lock/state: Reports the current lock state as a string. Possible values are: uncalibrated, locked, unlocked, unlatched, unlockedLnga, unlatching, bootRun, motorBlocked.
• lock/hastate: Reports the current lock state as a string, specifically for use by Home Assistant. Possible values are: locking, locked, unlocking, unlocked, jammed.
• lock/json: Reports the lock state, lockngo_state, trigger, current time, time zone offset, night mode state, last action trigger, last lock action, lock completion status, door sensor state, auth ID and auth name as JSON data.
• lock/binaryState: Reports the current lock state as a string, mostly for use by Home Assistant. Possible values are: locked, unlocked.
• lock/trigger: The trigger of the last action: autoLock, automatic, button, manual, system.
• lock/lastLockAction: Reports the last lock action as a string. Possible values are: Unlock, Lock, Unlatch, LockNgo, LockNgoUnlatch, FullLock, FobAction1, FobAction2, FobAction3, Unknown.
• lock/log: If "Publish auth data" is enabled in the web interface, this topic will be filled with the log of authorization data. By default a maximum of 5 logs are published at a time.
• lock/shortLog: If "Publish auth data" is enabled in the web interface, this topic will be filled with the 3 most recent entries in the log of authorization data, updates faster than lock/log.
• lock/rollingLog: If "Publish auth data" is enabled in the web interface, this topic will be filled with the last log entry from the authorization data. Logs are published in order.
• lock/completionStatus: Status of the last action as reported by Nuki Lock: success, motorBlocked, canceled, tooRecent, busy, lowMotorVoltage, clutchFailure, motorPowerFailure, incompleteFailure, invalidCode, otherError, unknown.
• lock/authorizationId: If enabled in the web interface, this node returns the authorization id of the last lock action.
• lock/authorizationName: If enabled in the web interface, this node returns the authorization name of the last lock action.
• lock/commandResult: Result of the last action as reported by Nuki library: success, failed, timeOut, working, notPaired, error, undefined.
• lock/doorSensorState: State of the door sensor: unavailable, deactivated, doorClosed, doorOpened, doorStateUnknown, calibrating.
• lock/rssi: The signal strenght of the Nuki Lock as measured by the ESP32 and expressed by the RSSI Value in dBm.
• lock/address: The BLE address of the Nuki Lock.
• lock/retry: Reports the current number of retries for the current command. 0 when command is successful, "failed" if the number of retries is greater than the maximum configured number of retries.

• lock/action: Allows to execute lock actions. After receiving the action, the value is set to "ack". Possible actions: activateRTO, deactivateRTO, electricStrikeActuation, activateCM, deactivateCM, fobAction1, fobAction2, fobAction3.
• lock/state: Reports the current lock state as a string. Possible values are: locked, RTOactive, open, opening, uncalibrated.
• lock/hastate: Reports the current lock state as a string, specifically for use by Home Assistant. Possible values are: locking, locked, unlocking, unlocked, jammed.
• lock/json: Reports the lock state, trigger, ring to open timer, current time, time zone offset, last action trigger, last lock action, lock completion status, door sensor state, auth ID and auth name as JSON data.
• lock/binaryState: Reports the current lock state as a string, mostly for use by Home Assistant. Possible values are: locked, unlocked.
• lock/continuousMode: Enable or disable continuous mode on the opener (0 = disabled; 1 = enabled).
• lock/ring: The string "ring" is published to this topic when a doorbell ring is detected while RTO or continuous mode is active or "ringlocked" when both are inactive.
• lock/binaryRing: The string "ring" is published to this topic when a doorbell ring is detected, the state will revert to "standby" after 2 seconds.
• lock/trigger: The trigger of the last action: autoLock, automatic, button, manual, system.
• lock/lastLockAction: Reports the last lock action as a string. Possible values are: ActivateRTO, DeactivateRTO, ElectricStrikeActuation, ActivateCM, DeactivateCM, FobAction1, FobAction2, FobAction3, Unknown.
• lock/log: If "Publish auth data" is enabled in the web interface, this topic will be filled with the log of authorization data.
• lock/completionStatus: Status of the last action as reported by Nuki Opener: success, motorBlocked, canceled, tooRecent, busy, lowMotorVoltage, clutchFailure, motorPowerFailure, incompleteFailure, invalidCode, otherError, unknown.
• lock/authorizationId: If enabled in the web interface, this topic is set to the authorization id of the last lock action.
• lock/authorizationName: If enabled in the web interface, this topic is set to the authorization name of the last lock action.
• lock/commandResult: Result of the last action as reported by Nuki library: success, failed, timeOut, working, notPaired, error, undefined.
• lock/doorSensorState: State of the door sensor: unavailable, deactivated, doorClosed, doorOpened, doorStateUnknown, calibrating.
• lock/rssi: The bluetooth signal strength of the Nuki Lock as measured by the ESP32 and expressed by the RSSI Value in dBm.
• lock/address: The BLE address of the Nuki Lock.
• lock/retry: Reports the current number of retries for the current command. 0 when command is successful, "failed" if the number of retries is greater than the maximum configured number of retries.

• configuration/buttonEnabled: 1 if the Nuki Lock/Opener button is enabled, otherwise 0.
• configuration/ledEnabled: 1 if the Nuki Lock/Opener LED is enabled, otherwise 0.
• configuration/ledBrightness: Set to the brightness of the LED on the Nuki Lock (0=min; 5=max) (Lock only).
• configuration/singleLock: 0 if the Nuki Lock is set to double-lock the door, otherwise 1 (= single-lock) (Lock only).
• configuration/autoLock: 1 if the Nuki Lock is set to Auto Lock, otherwise 0 (Lock only).
• configuration/autoUnlock: 1 if the Nuki Lock is set to Auto Unlock, otherwise 0 (Lock only).
• configuration/soundLevel: Set to the volume for sounds the Nuki Opener plays (0 = min; 255 = max) (Opener only).
• configuration/action: Allows changing configuration settings of the Nuki Lock/Opener using a JSON formatted value. After receiving the action, the value is set to "--". See the "Changing Nuki Lock/Opener Configuration" section of this README for possible actions/values
• configuration/commandResult: Result of the last configuration change action as JSON data. See the "Changing Nuki Lock/Opener Configuration" section of this README for possible values
• configuration/basicJson: The current basic configuration of the Nuki Lock/Opener as JSON data. See Nuki Smart Lock API and Nuki Opener API for available settings. Please note: Longitude and Latitude of the Lock/Opener are not published to MQTT by design. These values can still be changed though.
• configuration/advancedJson: The current advanced configuration of the Nuki Lock/Opener as JSON data. See Nuki Smart Lock API and Nuki Opener API for available settings.

• lock/query/lockstate: Set to 1 to trigger query lockstate. Auto-resets to 0.
• lock/query/config: Set to 1 to trigger query config. Auto-resets to 0.
• lock/query/keypad: Set to 1 to trigger query keypad. Auto-resets to 0.
• lock/query/battery: Set to 1 to trigger query battery. Auto-resets to 0.
• lock/query/lockstateCommandResult: Set to 1 to trigger query lockstate command result. Auto-resets to 0.

• battery/level: Battery level in percent (Lock only).
• battery/critical: 1 if battery level is critical, otherwise 0.
• battery/charging: 1 if charging, otherwise 0 (Lock only).
• battery/voltage: Current Battery voltage (V).
• battery/drain: The drain of the last lock action in Milliwattseconds (mWs) (Lock only).
• battery/maxTurnCurrent: The highest current of the turn motor during the last lock action (A) (Lock only).
• battery/lockDistance: The total distance during the last lock action in centidegrees (Lock only).
• battery/keypadCritical: 1 if the battery level of a connected keypad is critical, otherwise 0.
• battery/doorSensorCritical (only available in hybdrid mode): 1 if the battery level of a connected doorsensor is critical, otherwise 0.
• battery/basicJson: The current battery state (critical, charging, level and keypad critical) of the Nuki Lock/Opener as JSON data.
• battery/advancedJson: : The current battery state (critical, batteryDrain, batteryVoltage, lockAction, startVoltage, lowestVoltage, lockDistance, startTemperature, maxTurnCurrent and batteryResistance) of the Nuki Lock/Opener as JSON data.

• See the "Keypad control" section of this README.

• See the "Time Control" section of this README.

• info/nukiHubVersion: Set to the current version number of the Nuki Hub firmware.
• info/firmwareVersion: Set to the current version number of the Nuki Lock/Opener firmware.
• info/hardwareVersion: Set to the hardware version number of the Nuki Lock/Opener.
• info/nukiHubIp: Set to the IP of the Nuki Hub.
• info/nukiHubLatest: Set to the latest available Nuki Hub firmware version number (if update checking is enabled in the settings).

• maintenance/networkDevice: Set to the name of the network device that is used by the ESP. When using Wi-Fi will be set to "Built-in Wi-Fi". If using Ethernet will be set to "Wiznet W5500", "ETH01-Evo", "Olimex (LAN8720)", "WT32-ETH01", "M5STACK PoESP32 Unit", "LilyGO T-ETH-POE" or "GL-S10".
• maintenance/reset: Set to 1 to trigger a reboot of the ESP. Auto-resets to 0.
• maintenance/update: Set to 1 to auto update Nuki Hub to the latest version from GitHub. Requires the setting "Allow updating using MQTT" to be enabled. Auto-resets to 0.
• maintenance/mqttConnectionState: Last Will and Testament (LWT) topic. "online" when Nuki Hub is connected to the MQTT broker, "offline" if Nuki Hub is not connected to the MQTT broker.
• maintenance/uptime: Uptime in minutes.
• maintenance/wifiRssi: The Wi-Fi signal strength of the Wi-Fi Access Point as measured by the ESP32 and expressed by the RSSI Value in dBm.
• maintenance/log: If "Enable MQTT logging" is enabled in the web interface, this topic will be filled with debug log information.
• maintenance/freeHeap: Only available when debug mode is enabled. Set to the current size of free heap memory in bytes.
• maintenance/restartReasonNukiHub: Only available when debug mode is enabled. Set to the last reason Nuki Hub was restarted. See RestartReason.h for possible values
• maintenance/restartReasonNukiEsp: Only available when debug mode is enabled. Set to the last reason the ESP was restarted. See RestartReason.h for possible values

To change Nuki Lock/Opener settings set the configuration/action topic to a JSON formatted value with any of the following settings. Multiple settings can be changed at once. See Nuki Smart Lock API Basic Config, Nuki Smart Lock API Advanced Config, Nuki Opener API Basic Config and Nuki Opener API Advanced Config for more information on the available settings.
Changing settings has to enabled first in the configuration portal. Check the settings you want to be able to change under "Nuki Lock/Opener Config Control" in "Access Level Configuration" and save the configuration.

Example usage for changing multiple settings at once:

• { "buttonEnabled": "1", "lockngoTimeout": "60", "automaticBatteryTypeDetection": "1" }
• { "fobAction1": "Unlock", "fobAction2": "Intelligent", "nightModeImmediateLockOnStart": "1" }

The result of the last configuration change action will be published to the configuration/commandResult MQTT topic as JSON data.

The JSON data will include a node called "general" and a node for every setting that Nuki Hub detected in the action.
Possible values for the "general" node are "noValidPinSet", "invalidJson", "invalidConfig", "success" and "noChange".
Possible values for the node per setting are "unchanged", "noValueSet", "invalidValue", "valueTooLong", "accessDenied", "success", "failed", "timeOut", "working", "notPaired", "error" and "undefined"

Example:

• {"advertisingMode":"success","general":"success"}

If Home Assistant discovery is enabled (see the Home Assistant Discovery section of this README) Nuki Hub will create entities for almost all of the above settings.

After the initial installation of the Nuki Hub firmware via serial connection, further updates can be deployed via OTA update from a browser.
In the configuration portal, select "Firmware update" from the main page.

The easiest way to upgrade Nuki Hub, if Nuki Hub is connected to the internet, is to select "Auto Update".
This will download the latest Nuki Hub and Nuki Hub updater and automatically upgrade both applications.
Nuki Hub will reboot 3 times during this process, which will take about 5 minutes.
If you have enabled "Allow updating using MQTT" you can also use the Home Assistant updater or write "1" to the nukihub/maintanance/reset topic to start the update process.

Alternatively you can select a binary file from your file system to update Nuki Hub or the Nuki Hub updator manually
You can only update Nuki Hub from the Nuki Hub updater and update the updater only from Nuki Hub
You can reboot from Nuki Hub to the updater and vice versa by selecting the reboot option from the "Firware update" page
When you are on the right application you can upload the new binary by clicking on "Browse" and select the new "nuki_hub[board].bin" or "nuki_hub_updater[board].bin" file and select "Upload file".
After about a minute the new firmware should be installed afterwhich the ESP will reboot automatically to the updated binary.
Selecting the wrong binary will lead to an unsuccessfull update

Note for users upgrading from Nuki Hub 8.35 or lower:
Updating to version 9.00 requires a change to the partition table of the ESP32.
Please follow the instructions for the First time installation once when updating to Nuki Hub 9.00 from an earlier version.
Your settings will not be affected when updating using the above instructions (do not select erase device when updating using Webflash).

The communication via MQTT can be SSL encrypted.
To enable SSL encryption, supply the necessary information in the MQTT Configuration page.

The following configurations are supported:
CA, CERT and KEY are empty -> No encryption
CA is filled but CERT and KEY are empty -> Encrypted MQTT
CA, CERT and KEY are filled -> Encrypted MQTT with client vaildation

Example certificate creation for your MQTT server:

# make a ca key
openssl genpkey -algorithm RSA -out ca.key

# make a CA cert
openssl req -new -x509 -days 3650 -key ca.key -out ca.crt -subj "/C=US/ST=YourState/L=YourCity/O=YourOrganization/OU=YourUnit/CN=YourCAName"

# make a server key
openssl genpkey -algorithm RSA -out server.key

# Make a sign request, MAKE SURE THE CN MATCHES YOUR MQTT SERVERNAME
openssl req -new -key server.key -out server.csr -subj "/C=US/ST=YourState/L=YourCity/O=YourOrganization/OU=YourUnit/CN=homeserver.local"

# sign it
 openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days 3650

This software supports MQTT Discovery for integrating Nuki Hub with Home Assistant.
To enable autodiscovery, supply the discovery topic that is configured in your Home Assistant instance (If you have not changed this setting in Home Assistant the default is "homeassistant") in the MQTT Configuration page.
Once enabled, the Nuki Lock and/or Opener and related entities should automatically appear in your Home Assistant MQTT devices.

The following mapping between Home Assistant services and Nuki commands is setup when enabling autodiscovery:

NOTE: MQTT Discovery uses retained MQTT messages to store devices configurations. In order to avoid orphan configurations on your broker please disable autodiscovery first if you no longer want to use this software. Retained messages are automatically cleared when unpairing and when changing/disabling autodiscovery topic in MQTT Configuration page.
NOTE2: Home Assistant can be setup manually using the MQTT Lock integration, but this is not recommended

If a keypad is connected to the lock, keypad codes can be added, updated and removed. This has to enabled first in the configuration portal. Check "Add, modify and delete keypad codes" under "Access Level Configuration" and save the configuration.

Information about current keypad codes is published as JSON data to the "keypad/json" MQTT topic.
This needs to be enabled separately by checking "Publish keypad codes information" under "Access Level Configuration" and saving the configuration. For security reasons, the code itself is not published, unless this is explicitly enabled in the Nuki Hub settings. By default a maximum of 10 entries are published.

To change Nuki Lock/Opener keypad settings set the keypad/actionJson topic to a JSON formatted value containing the following nodes.

Examples:

• Delete: { "action": "delete", "codeId": "1234" }
• Add: { "action": "add", "code": "589472", "name": "Test", "timeLimited": "1", "allowedFrom": "2024-04-12 10:00:00", "allowedUntil": "2034-04-12 10:00:00", "allowedWeekdays": [ "wed", "thu", "fri" ], "allowedFromTime": "08:00", "allowedUntilTime": "16:00" }
• Update: { "action": "update", "codeId": "1234", "enabled": "1", "name": "Test", "timeLimited": "1", "allowedFrom": "2024-04-12 10:00:00", "allowedUntil": "2034-04-12 10:00:00", "allowedWeekdays": [ "mon", "tue", "sat", "sun" ], "allowedFromTime": "08:00", "allowedUntilTime": "16:00" }

The result of the last configuration change action will be published to the configuration/commandResultJson MQTT topic.
Possible values are "noValidPinSet", "keypadControlDisabled", "keypadNotAvailable", "keypadDisabled", "invalidConfig", "invalidJson", "noActionSet", "invalidAction", "noExistingCodeIdSet", "noNameSet", "noValidCodeSet", "noCodeSet", "invalidAllowedFrom", "invalidAllowedUntil", "invalidAllowedFromTime", "invalidAllowedUntilTime", "success", "failed", "timeOut", "working", "notPaired", "error" and "undefined".

If a keypad is connected to the lock, keypad codes can be added, updated and removed. This has to enabled first in the configuration portal. Check "Add, modify and delete keypad codes" under "Access Level Configuration" and save the configuration.

Information about codes is published under "keypad/code_x", x starting from 0 up the number of configured codes. This needs to be enabled separately by checking "Publish keypad codes information" under "Access Level Configuration" and saving the configuration. By default a maximum of 10 entries are published.

For security reasons, the code itself is not published, unless this is explicitly enabled in the Nuki Hub settings. To modify keypad codes, a command structure is setup under keypad/command:

• keypad/command/id: The id of an existing code, found under keypad_code_x
• keypad/command/name: Display name of the code
• keypad/command/code: The actual 6-digit keypad code
• keypad/command/enabled: Set to 1 to enable the code, 0 to disable
• keypad/command/action: The action to execute. Possible values are add, delete and update

To modify keypad codes, the first four parameter nodes have to be set depending on the command:

• To add a code, set name, code, enabled **
• To delete a code, set id
• To update a code, set id, name, code, enabled

** Note: Rules for codes are:

• The code must be a 6 digit number
• The code can't contain 0
• The code can't start with 12

After setting the necessary parameters, write the action to be executed to the command node. For example, to add a code:

• write "John Doe" to name
• write 111222 to code
• write 1 to enabled
• write "add" to action

Timecontrol entries can be added, updated and removed. This has to enabled first in the configuration portal. Check "Add, modify and delete timecontrol entries" under "Access Level Configuration" and save the configuration.

Information about current timecontrol entries is published as JSON data to the "timecontrol/json" MQTT topic.
This needs to be enabled separately by checking "Publish timecontrol entries information" under "Access Level Configuration" and saving the configuration. By default a maximum of 10 entries are published.

To change Nuki Lock/Opener timecontrol settings set the timecontrol/actionJson topic to a JSON formatted value containing the following nodes.

Examples:

• Delete: { "action": "delete", "entryId": "1234" }
• Add: { "action": "add", "weekdays": [ "wed", "thu", "fri" ], "time": "08:00", "lockAction": "Unlock" }
• Update: { "action": "update", "entryId": "1234", "enabled": "1", "weekdays": [ "mon", "tue", "sat", "sun" ], "time": "08:00", "lockAction": "Lock" }

Authorization entries can be updated and removed. This has to enabled first in the configuration portal. Check "Modify and delete authorization entries" under "Access Level Configuration" and save the configuration. It is currently not (yet) possible to add authorization entries this way.

Information about current authorization entries is published as JSON data to the "authorization/json" MQTT topic.
This needs to be enabled separately by checking "Publish authorization entries information" under "Access Level Configuration" and saving the configuration. By default a maximum of 10 entries are published.

To change Nuki Lock/Opener authorization settings set the authorization/actionJson topic to a JSON formatted value containing the following nodes.

Examples:

• Delete: { "action": "delete", "authId": "1234" }
• Update: { "action": "update", "authId": "1234", "enabled": "1", "name": "Test", "timeLimited": "1", "allowedFrom": "2024-04-12 10:00:00", "allowedUntil": "2034-04-12 10:00:00", "allowedWeekdays": [ "mon", "tue", "sat", "sun" ], "allowedFromTime": "08:00", "allowedUntilTime": "16:00" }

The lock can be controlled via GPIO.

To enable GPIO control, go the the "GPIO Configuration" page where each GPIO can be configured for a specific role:

• Disabled: The GPIO is disabled
• Input: Lock: When connect to Ground, a lock command is sent to the lock
• Input: Unlock: When connect to Ground, an unlock command is sent to the lock
• Input: Unlatch: When connect to Ground, an unlatch command is sent to the lock
• Input: Lock n Go: When connect to Ground, a Lock n Go command is sent to the lock
• Input: Lock n Go and unlatch: When connect to Ground, a Lock n Go and unlatch command is sent to the lock
• Input: Electric strike actuation: When connect to Ground, an electric strike actuation command is sent to the opener (open door for configured amount of time)
• Input: Activate RTO: When connect to Ground, Ring-to-open is activated (opener)
• Input: Activate CM: When connect to Ground, Continuous mode is activated (opener)
• Input: Deactivate RTO/CM: Disable RTO or CM, depending on which is active (opener)
• Input: Dectivate RTO: When connect to Ground, Ring-to-open is deactivated (opener)
• Input: Dectivate CM: When connect to Ground, Continuous mode is deactivated (opener)
• Output: High when locked: Outputs a high signal when the door is locked
• Output: High when unlocked: Outputs a high signal when the door is unlocked
• Output: High when motor blocked: Outputs a high signal when the motor is blocked (lock)
• Output: High when RTO active: Outputs a high signal when ring-to-open is active (opener)
• Output: High when CM active: Outputs a high signal when continuous mode is active (opener)
• Output: High when RTO or CM active: Outputs a high signal when either ring-to-open or continuous mode is active (opener)
• General input (pull-down): The pin is configured in pull-down configuration and its state is published to the "gpio/pin_x/state" topic
• General input (pull-up): The pin is configured in pull-up configuration and its state is published to the "gpio/pin_x/state" topic
• Genral output: The pin is set to high or low depending on the "gpio/pin_x/state" topic

If you prefer to connect to via Ethernet instead of Wi-Fi, you either use one of the supported ESP32 modules with built-in ethernet (see "Supported devices" section) or wire a seperate SPI Ethernet module.
Currently the Wiznet W5x00 Module (W5100, W5200, W5500), DN9051 and KSZ8851SNL chips are supported.
To use a supported module, flash the firmware, connect via Wi-Fi and select the correct network hardware in the "MQTT and Network Configuration" section.

To wire an external W5x00 module to the ESP, use this wiring scheme:

• Connect W5x00 to ESP32 SPI:
  
  • W5x00 SCK to GPIO 8
    
  • W5x00 MISO to GPIO 9
    
  • W5x00 MOSI to GPIO 10
    
  • W5x00 CS/SS to GPIO 5
    Optional:
  • W5x00 RST to GPIO 4
    
  • W5x00 INT/IRQ to GPIO 3
    

Now connect via Wi-Fi and change the network hardware to "Generic W5500".

If Ethernet hwardware isn't detected, Wi-Fi is used as a fallback, unless this is disabled in the settings.

Note: LAN8720 modules are only supported on the ESP32 and ESP32-Solo1, not on the ESP32-S3, ESP32-C3 or ESP-C6

Unfortunately the ESP32 has problems with some access points and reconnecting fails.
As a workaround you can navigate to "MQTT and Network Configuration" and enable "Restart on disconnect".
This will reboot the ESP as soon as it gets disconnected from Wi-Fi.
Also, this reduces the config portal timeout to three minutes to prevent the ESP being stuck in config mode in case an access point is offline temporarily.
If this still doesn't fix the disconnects and the ESP becomes unreachable, the "Restart timer" option can be used as a last resort.
It will restart the ESP after a configured amount of time.

First, make sure the firmware version of the Nuki device is up-to-date, older versions have issues pairing.
Next, try erasing the ESP32 flash and then (re-)flash the firmware.
To erase the flash, use the espressif download tool and click the "Erase" button.
Afterwards flash the firmware as described in the "how-to-flash.txt" file or using Webflash.

Also, check that pairing is allowed. In the Nuki smartphone app, go to "Settings" --> "Features & Configuration" --> "Button & LED" and make sure "Bluetooh Pairing" is enabled.
Next press the button for several seconds untill the LED light remains lit.

A note about the M5Stack PoESP32 Unit. Here the initial Bluetooth reception is very poor (range less than one meter). The reason is that the module does not have an antenna on the PCB, but only an IPEX connector. By retrofitting an external SMA antenna (IPEX, or other names U.FL, IPAX, IPX, AMC, MHF, UMCC), Bluetooth/Wi-Fi works over several meters.

Make sure you are using at least version 2023.8.0 of Home Assistant.
The Home Assistant developers have made changes to MQTT auto discovery which break support for older version and Nuki Hub has adopted these changes.
This unfortunately means that older versions of Home Assistant are not supported by the Nuki Hub discovery implemenation anymore.

According to Nuki this is by design and part of the specification of the Pro lock.
You can use either the built-in Wi-Fi or a Bridge (which Nuki Hub registers as).
Or use Nuki Hub in Hybrid mode using Wi-Fi or Thread, see hybrid mode
Using both at the same time is not supported.

Some functionality is restricted by the Lock (or Opener) firmware and is only accessible when the PIN is provided.
When setting up the lock (or opener), you have to set a PIN in the Nuki smartphone app.
Navigate to the Nuki Hub Credentials page, enter this PIN and click save.
Check the main page of the configurator to see if the entered PIN is valid

See the previous point, this functionality needs the correct PIN to be configured.

Make sure the "Unlatch" option is checked under "Access Level Configuration".

Unlatching can be triggered using the lock.open service.

Alternatively an "Unlatch" button is exposed through Home Assistant discovery.
This button is disabled by default, but can be enabled in the Home Assistant UI.

When using multiple Nuki devices, different paths for each device have to be configured.
Navigate to "Nuki Configuration" and change the "MQTT Nuki Smartlock Path" or "MQTT Nuki Opener Path" under "Basic Nuki Configuration" for at least one of the devices.

This often is a result of enabling "Register as app" when not using Hybrid mode (Official MQTT / Nuki Hub co-existance).
Doing so will cause Nuki Hub to constantly query the lock and as such cause excessive battery drain.
To prevent this behaviour, unpair Nuki Hub, disable "Register as app", and re-pair.

Never enable "Register as app" unless you intend to use a Nuki Bridge in addition to Nuki Hub or you are using Hybrid mode!

Docker (Preferred)
See the README in the Docker directory for instructions on building using Docker.

Platform IO, instructions for Debian-based Linux distro (e.g. Ubuntu)

apt-get update
apt-get install -y git python3 pip make
python3 -m venv .venv
source .venv/bin/activate

git clone https://github.com/technyon/nuki_hub --recursive
cd nuki_hub

# install tools platformio and esptool
make deps

# build all binary boards
make updater
make release

This is third party software for Nuki devices.
This project or any of it's authors are not associated with Nuki Home Solutions GmbH.
Please refer for official products and support to the Nuki official website:
https://nuki.io/

For further license details, check the included LICENSE file.