adds code

l

Quick answer: Commercial smart locks with MQTT or documented bridge APIs publish lock state and battery level to a topic your broker already watches. Node-RED subscribes, then automates: auto-lock at a set hour, push notifications when the door unlocks while nobody is home, and lock-before-arm interlocks with your alarm system. The hardware stays certified and inspected; you only wire the logic.

Why smart locks are different from every other device

Relays on lights, plugs, and sensors are fine. A relay on a door strike is not. Locks are the one device class in home automation where you should never DIY the hardware — a hobbyist relay on a door strike can fail locked (you are locked in during a fire) or fail unlocked (anyone walks in). Building codes in most jurisdictions treat door hardware as life-safety equipment, and for good reason. NFPA 101, the Life Safety Code, requires that egress paths remain unobstructed and operable; a smart lock that cannot be opened from inside without power, a key card, or a working app fails that test. Use certified, commercially manufactured locks. ANSI/BHMA grading (Grade 1 is the highest) is the benchmark in the US; equivalent certifications exist in the EU. If a lock does not carry a certification mark, it does not go on your entry door.

How lock state reaches Node-RED

The chain is the same as any MQTT device — lock publishes, broker transports, Node-RED reacts — but the lock's half of that chain varies by manufacturer and protocol:

  • Dedicated MQTT API. Nuki's Smart Lock 3.0 Pro and 4th-generation devices expose an official MQTT API that publishes state directly to a broker on your LAN. Nuki's documentation describes it as a local-only integration — no remote MQTT servers, no substitution for Nuki's own cloud services. The MQTT API spec is versioned (1.6 as of 2026) and published on the Nuki developer portal.
  • Bridge HTTP API with callbacks. The Nuki Bridge forwards commands over Bluetooth to connected locks and can call a local HTTP callback whenever the lock reports a state change — lock state, battery charge, door sensor. That callback endpoint is trivially a Node-RED HTTP-in node. Home Assistant's Nuki Bridge integration works exactly this way, and the same pattern works in standalone Node-RED.
  • Zigbee locks via Zigbee2MQTT. Zigbee smart locks (Aqara U100/U400, some Yale and Schlage models) pair with a Zigbee coordinator running Zigbee2MQTT, which bridges them onto your MQTT bus. Lock state, battery, and error codes all arrive as standard MQTT topics. No vendor bridge hardware needed — a single coordinator covers every Zigbee device.
  • Matter over Thread. Newer locks with Matter support (Aqara U100/U200/U400, Level Lock Pro, SwitchBot Lock Pro) expose lock state through the Matter fabric. A Thread border router plus a Matter-to-MQTT bridge puts the same topics on your broker. Protocol choice here is less about automation capability and more about which ecosystem you already run.

Reading lock and battery state

Whatever the transport, the Node-RED side looks the same: an mqtt in node subscribes to the lock's state topic, a JSON or function node parses the payload, and the output branches into automations. Typical payload fields are lock state (locked, unlocked, unlocked with timeout, motor blocked), battery level (percentage or critical flag), and door sensor state (door open, door closed, unknown) if the lock supports one.

Battery is worth watching closely. Unlike a sensor that simply stops reporting, a smart lock with a dead battery still physically locks — it just will not unlock remotely or report state. Set a Node-RED alert when battery drops below 20%, not 5%. The Shelly and Tasmota MQTT tutorial covers the retain and last-will pattern in detail; the same technique works for locks — set the lock's state topic to retained so Node-RED knows the last state after a broker restart, and configure a last-will message so a dead lock is not silently reported as "locked."

Three practical automations

Auto-lock at night

Subscribe to the lock's state topic. If the state is "unlocked" and the clock is past your bedtime, send a lock command. Add a condition: only if the door sensor reports "closed" — locking a door that is physically open can damage the mechanism or trap someone outside. Test with the door open first; the lock command should be rejected or the automation should abort.

Unlock-while-away notification

Maintain a simple "home" state in a flow variable or a separate presence topic (phone Wi-Fi, Home Assistant device tracker, whatever you use). If the lock transitions to "unlocked" and nobody is home, send a push notification. This is the automation that justifies the whole setup — a notification in under two seconds is faster than any cloud camera alert.

Lock-before-arm interlock

Before your alarm system arms, check the lock state. If the door is unlocked, either lock it first or abort the arm command and notify. The implementation is a sequence node: read lock state, if unlocked send lock command, wait for confirmation, then arm. The lock's state topic carries the confirmation you need — no polling, no guessing.

Choosing a lock: specs, not stars

App-store ratings tell you whether the setup wizard was smooth. They do not tell you whether the lock will still work when the vendor's cloud goes down, whether the battery lasts six months or six weeks, or whether the mechanism meets ANSI/BHMA Grade 1. For that you need a spec sheet. If you are comparing smart locks on battery and protocol specs, look for battery life (measured in months on real-world use, not theoretical), protocol stack (Wi-Fi drains faster than Zigbee or Thread; Matter locks tend to have newer hardware), and certification grade. BHMA-verified models — Schlage Encode, Level Lock Pro, Ultraloq U-Bolt Pro, Yale Assure 2, Wyze Bolt v2 — carry that mark on CompareSmartDevice's verified listing. Retrofit locks (Aqara U200, SwitchBot Lock Pro, Level Bolt, August Wi-Fi) skip installation entirely and work for renters, but check that the retrofit's motor can handle your specific deadbolt — some older or stiff bolts need more torque than a retrofit can supply.

If you buy through links on the sites we recommend, we may earn a small commission.

For the broader architecture of where this fits, the 2026 local smart home build shows how MQTT devices, flows, and dashboards connect.

Frequently asked questions

Can I control a lock remotely over the internet?

Yes, but the safe way is through your own VPN or wireguard tunnel to your Node-RED instance, not through a vendor cloud. Nuki's own MQTT API is LAN-only by design. If you expose MQTT or your Node-RED editor to the public internet without authentication, that is a security problem you created, not one the lock vendor can fix.

What happens if the broker or Node-RED crashes?

The lock keeps working. Smart locks are physically self-contained — the motor, battery, and keypad or fingerprint reader operate independently of any software. You lose automations and notifications until the broker comes back, but you do not lose the ability to lock and unlock the door.

Do I need a Nuki Bridge if my lock supports MQTT directly?

No. Nuki's 3.0 Pro and 4th-gen locks with integrated Wi-Fi or Thread publish to MQTT without a bridge. The Bridge HTTP API is for older Nuki locks that communicate only over Bluetooth — the bridge translates BLE to HTTP, and a small callback-to-MQTT adapter (a Node-RED flow or a dedicated script) closes the gap.

Sources

Tags
Previous Post Next Post