NUKI Hub firmware for the ESP32

It’s all working then.

YESSS… many many thanks @technyon

How is possible to show all Nuki data?

  • 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/state: Reports the current lock state as a string. Possible values are: uncalibrated, locked, unlocked, unlatched, unlockedLnga, unlatching, bootRun, motorBlocked

  • lock/trigger: The trigger of the last action: autoLock, automatic, button, manual, system

  • lock/completionStatus: Status of the last action as reported by NUKI lock (needs bluetooth connection): 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

  • battery/level: Battery level in percent

  • battery/critical: 1 if battery level is critical, otherwise 0

  • battery/charging: 1 if charging, otherwise 0

  • battery/voltage: Current Battery voltage (V)

  • battery/drain: The drain of the last lock action in Milliwattseconds (mWs)

  • battery/maxTurnCurrent: The highest current of the turn motor during the last lock action (A)

  • configuration/autoLock: enable or disable autoLock (0 = disabled; 1 = enabled). Maps to “Auto lock enabled” in the bluetooth API.

  • configuration/autoUnlock: enable or disable autoLock in general (0 = disabled; 1 = enabled). Maps to “Auto unlock disabled” in the bluetooth API.

  • configuration/buttonEnabled: enable or disable the button on the lock (0 = disabled; 1 = enabled)

  • configuration/ledBrightness: Set the brightness of the LED on the lock (0=min; 5=max)

  • configuration/ledEnabled: enable or disable the LED on the lock (0 = disabled; 1 = enabled)

  • configuration/singleLock: configures wether to single- or double-lock the door (1 = single; 2 = double)

Well, some of it you already have via auto discovery. Other things have still to be implemented in autodiscovery, but it should be possible to access those values from scripts - it’s all there in MQTT. What’s missing are all the more specific lock states. Home assistant only supports locked and unlocked in the lock device class. Representing for example unlatch is unfortunately not possible. Again, you can possible access this via custom scripts.

Ok, thank you, at this moment I’m very satisfied from data your firmware can show me

We could define separate binary sensors for these things, e.g. binary_sensor.nuki_is_unlatched. The corresponding action is already available via HA’s lock integration.

Good idea. That still wouldn’t allow to actually send an unlatch command to the lock though. Does it make sense to define another “lock” device that toggles between unlatch und unlock states? Would quite confusing I think.

lock.open (unlatch) is a standard HA service.

OK it seems it seems I read the wrong part of the documentation … I only saw lock and locked. Should be easy to add then.

hi @technyon it could be interesting to show last user open or closed the lock with the function…
“lock/authorizationName”

The original app have the commands… ‘open’, ‘lock’, ‘unlock & open’
Instead your integration permit only… ‘lock’ and ‘unlock’

It already works. I am not sure if there is a corresponding open state (as opposed to the service), the HA documentation is a bit confusing in that regard.

Edit: Ah, I think there is currently no third state for locks, but there is an architecture discussion waiting for more feedback from interested parties. There are currently at least states for the “locking”, “unlocking” and “jammed”.

ok … so sending the command is supported, but it’d not yet reflected in the state. Which doesn’t really matter, since unlatching is usually only a few seconds.

1 Like

Hi @technyon I wish to make an alternative to the original fob.
Is it possible to use a smart tag to lock and unlock Nuki?

That’s a question too general to answer, “smart tag” is a whole category of devices. I’d say yes, but you have to pick a hardware and protocol, and see how exactly the device works.

Possible scenarios:

  • Put an ESP32 into an enclosure with a battery. Wake it from from deep sleep via button press and send a command to the lock.
  • Use some bluetooth beacon with a button. Have an ESP32 receive the broadcast from the beacon and send a command to the lock (very unsafe because anyone could just copy the beacon)
  • Use some other protocol (e. g. zigbee) and use a remote to have home assistant send the command to the ESP32 which sends it to the lock.

This topic is very interesting and deserves to be developed well, because the Fob costs a lot (39 eur) and on Amazon many users complain that it doesn’t work well.

  • using an ESP32 with battery requires a suitable push-button case … it would have to be built with a 3D printer.
  • it would be nice to use a smart tag like the Tile, small and compact, but obviously securing the communication.
  • the smallest zigbee switch I know is the Aqara MIni Switch WXKG11LM which uses the zigbee protocol and is immediately usable but is quite bulky to keep in your pocket (45 x 45 x 12 mm)

Thingiverse is your friend with such projects. You can order prints online if you don’t have a printer … or use it as an excuse to buy one :).

There are zigee remotes like this:

But considering the price, maybe it’s easier to just buy the fob. On the hand, the remote has four buttons, so there are a few left for other functions.

it’s too expensive, 31.06 eur (to Italy)
the smallest zigbee Aqara device is the door and windows sensor MCCGQ11LM. I have already modified one making it become a switch to switch on and off lights. It is small, compact and light but does not have a button. Could it be modified in some way and made it become like a Fob?

I found this project but it is a bit complicated… Add and use DIY Zigbee remote in Home Assistant with 32 actions - YouTube

This one seem a good solution…
Tuya ZigBee 3.0 interruttore di scena del telecomando portatile senza fili compatibile con Smart Life Home Assistant zigbe2mqtt SmartThings|Interruttori| - AliExpress?
…but from China…long time expeditions

I ordered the Aqara Mini Switch https://www.amazon.it/Aqara-WXKG11LM-interruttore-dispositivi-compatibile/dp/B07D19YXND/ref=sr_1_1_sspa?
it will arrive today

but until your firmware does not allow the “unlock and open” command I will not be able to use them

My firmware supports all the commands the NUKI has to offer, just the auto discovery is missing. I’ll add the unlatch when I have some time, but you can still manually write to the MQTT “action” node to trigger the action you want.

sorry I do not know mqtt commands to trigger an action
may you help me to write it for Home Assistant?

just to be sure, you mean unlocking and then unlatching the nuki lock?

- service: lock.open
  entity_id: lock.nuki

unlocks my door directly from home assistant. When you look in HA there is only lock and unlock inside the entity, but using the service it opens the door.
Since the ring sensor is now there i am trying to use this instead of the bridge and my doors opens every time it should (from locked and unlocked state).

Instead of the knob i use also nfc tags (something like this, but you need your smartphone). These can in conjunction with your phone start an automation. Since this works only on phones which have you homeassistant log-in it’s pretty safe.

EDIT:
Doing the same with an MQTT (as @technyon mentioned) command from ha would be:

- service: mqtt.publish
  data:
    topic: nuki/lock/action
    payload: unlatch

But it does the same as the lock.open service.

1 Like

As noted by @madface further down, that already works, no need to implement any additional service (except maybe a binary sensor to indicate the unlatched state for use as a trigger in automations).