Home Assistant integration for Onesti/Nimly smart locks via ZHA.
Manages PIN codes, identifies who unlocked the door and how (keypad, RFID, fingerprint), and gives you full local control — no cloud, no hub, no subscription.
- User identification — "Kari låste opp med kode", "Fredrik låste opp med RFID"
- PIN code management — set, change and clear codes via HA UI or services
- Name any slot — RFID tags, fingerprints, PINs — all get human-readable names
- Activity sensor — real-time events for automations and notifications
- Slot sensors — see who has access at a glance (10 sensor entities)
- Auto-wake — automatically wakes sleepy locks before sending commands
- Progress feedback — spinner UI while PIN commands are sent to the lock
- Blueprints included — connectivity alerts, goodnight lock, unlock notifications
- 100% local — no cloud, no internet, no extra hardware
- 4 languages — Norwegian, English, Swedish, Danish
All Onesti Products AS locks with Zigbee Connect Module (ZMNC010):
| Zigbee model | Product | Verified |
|---|---|---|
| NimlyPRO | Nimly Touch Pro | Yes — tested with PIN, RFID, fingerprint |
| NimlyPRO24 | Nimly Touch Pro (2024) | Supported |
| NimlyCode | Nimly Code | Supported |
| NimlyTouch | Nimly Touch | Supported |
| NimlyIn | Nimly InDoor | Supported |
| NimlyShared | Nimly Shared | Supported |
| easyCodeTouch_v1 | EasyAccess EasyCodeTouch | Supported |
| EasyCodeTouch | EasyAccess EasyCodeTouch | Supported |
| EasyFingerTouch | EasyAccess EasyFingerTouch | Supported |
These are all the same hardware by Onesti Products AS — different branding, identical Zigbee module. Sold under Nimly, EasyAccess, Keyfree, Salus, Homely, Forebygg, and other brands.
- HACS → Integrations → ⋮ → Custom repositories
- Add
https://github.com/fredrik-lindseth/onesti-lockas Integration - Install "Onesti Lock"
- Restart Home Assistant
- Copy
custom_components/onesti_lockto yourconfig/custom_components/ - Restart Home Assistant
- Pair the lock with ZHA (the lock's Zigbee Connect Module must be installed). Zigbee2MQTT is not supported.
- Settings → Devices & Services → Add Integration → Onesti Lock
- Select your lock from the list
- Done — slot sensors and activity sensor appear automatically
Settings → Devices & Services → Onesti Lock → Configure
- Sett PIN-kode — select slot, enter name and 4-8 digit code
- Fjern PIN-kode — select user to remove
- Navngi bruker — assign a name to any slot (for RFID, fingerprint, etc.)
- Vis brukerslots — overview of all slots
service: onesti_lock.set_pin
data:
slot: 3
name: "Kari"
code: "5478"| Service | Description |
|---|---|
onesti_lock.set_pin |
Set PIN code with name for a slot |
onesti_lock.clear_pin |
Remove PIN code from a slot |
onesti_lock.set_name |
Set name without changing credentials |
onesti_lock.clear_slot |
Remove all credentials and name |
RFID tags and fingerprints must be enrolled via the physical lock (using master code + keypad sequences — see your lock's manual). Once enrolled, you can name the slot via this integration so events show "Fredrik" instead of "Slot 1".
From the Nimly/EasyAccess manual:
| Slots | Purpose |
|---|---|
| 000 | First master code (factory: 123 — change immediately) |
| 001-002 | Additional master codes (optional) |
| 003-999 | User codes, RFID tags, fingerprints |
Per configured lock:
sensor.*_slot_3throughsensor.*_slot_12— slot occupant name,has_pin/has_rfidattributessensor.*_siste_aktivitet— last activity ("Kari låste opp med kode", "Auto-lås")
The activity sensor also exposes these attributes when the lock reports them:
last_pin_code— actual PIN digits from the last keypad unlock (attribute 0x0101)num_pin_users— number of PIN user slots supportedmin_pin_length/max_pin_length— PIN length bounds
The activity sensor fires onesti_lock_activity events for use in automations.
Privacy note: last_pin_code contains the actual digits typed, including the master code if it was used. HA's recorder persists sensor attributes to its SQLite history, so recent PINs are retrievable by anyone with history.read access. If this is a concern, exclude the activity sensor from the recorder:
recorder:
exclude:
entity_glob:
- sensor.*_siste_aktivitetThree automation blueprints are included:
- Connectivity alert — notify when the lock goes offline or comes back
- Goodnight lock — lock the door automatically at a set time
- Unlock notification — notify when someone unlocks, with user and method
This integration requires ZHA (Zigbee Home Automation). It does not work with Zigbee2MQTT. The lock's custom attribute 0x0100 is decoded via ZHA cluster events, which Z2M does not expose in the same way.
-
ZHA only — Zigbee2MQTT is not supported. Z2M has partial support via the
onesti.tsconverter but cannot provide user identification. -
PIN verification — the lock returns a malformed ZCL response. The command reaches the lock, but we can't confirm success programmatically. Always test the code on the keypad.
-
Sleepy device — the lock sleeps aggressively to save battery. Commands may timeout on first attempt. The integration auto-wakes and retries, but place a Zigbee router right next to the door. The metal casing acts as a Faraday cage.
-
Attribute reporting after battery change — the lock may stop sending activity events after a battery change. Try "Reconfigure" in ZHA (wake the lock first by entering a code). If that fails, remove and re-pair the lock.
-
RFID/fingerprint enrollment — can only be done via the physical keypad or BLE app, not via Zigbee.
-
Slot state drift — if PINs are changed via the physical keypad or another app, the integration's slot data may be out of sync. Use "View slots" to check.
-
No OTA firmware updates — the Zigbee module does not support over-the-air updates.
| Nimly App + Hub | This integration | |
|---|---|---|
| Extra hardware | Connect Bridge (~1500 kr) | Any Zigbee coordinator |
| Cloud dependency | Yes — iotiliti.cloud (AWS) | None — 100% local |
| Automations | Requires "PRO Hub" upsell | Full HA automations |
| User identification | Cloud event history | Real-time in HA |
| Privacy | All events to AWS | Everything stays local |
| Cost | Hub + cloud account | Free and open source |
If you don't already own a Nimly/Onesti lock, consider a Matter over Thread lock instead. HA 2026.4 has native PIN management for Matter locks directly in the UI, which makes custom integrations like this one unnecessary.
Matter lock support in HA is still maturing (as of April 2026), but the direction is clear: standardized user management, reliable Thread communication without sleepy device workarounds, and no custom integration to maintain.
For Scandinavian doors, look at Nuki Smart Lock Ultra Nordics, Aqara U200, or Tedee GO2 with Scandinavian adapter.
If you already have a Nimly/Onesti lock, this integration is the best option available. It works today on stable ZHA.
Z2M has an onesti.ts converter that supports these locks. This integration decodes the same Onesti attributes and aims for feature parity. The key differences:
| Feature | This integration (ZHA) | Z2M onesti.ts |
|---|---|---|
| Decode attrid 0x0100 (user/source/action) | Yes | Yes |
| Last used PIN code (attrid 0x0101) | Yes — attribute on activity sensor | Yes — last_used_pin_code state |
| Lock capabilities (max users, min/max PIN length) | Yes — read at setup | Yes |
| Set / clear PIN codes | Yes — via HA UI and services | Yes — via MQTT |
| Name any slot (for RFID/fingerprint) | Yes — persisted in HA | No |
| Activity sensor with human-readable messages | Yes | No — raw fields only |
| HA events for automations | Yes — onesti_lock_activity |
Via MQTT events |
| Auto-wake for sleepy device | Yes — send lock command before retry | No |
| Blueprints included | Yes (connectivity, goodnight, notifications) | No |
| Protocol | ZHA only | Zigbee2MQTT only |
Both integrations hit the same firmware-level issues:
- PIN set confirmation — the lock returns a malformed ZCL response. Both silently treat the command as successful. Neither can confirm the code was stored; test on the keypad.
- Sleepy device timeouts — the lock sleeps aggressively. Z2M handles retries generically; this integration explicitly wakes the lock via the lock entity before retrying.
If you already use Z2M, use the Z2M converter directly. If you use ZHA, use this integration. We don't support cross-protocol setups.
If you're researching how to integrate these locks, here's what we've tried:
- Standard ZHA — shows lock/unlock state, but cannot identify who unlocked or how. Custom attribute 0x0100 is not decoded.
- Nimly Connect app — requires Connect Bridge hub, routes through iotiliti cloud, no HA automations without PRO Hub.
- Nimly BLE app — direct BLE to lock, but no Home Assistant integration and must be near the lock.
- Cloud API (iotiliti) — we've reverse-engineered the full REST API, but device listing is blocked (see
docs/cloud-api-status.md).
| Document | Content |
|---|---|
| Debugging guide | LED indicators, troubleshooting, debug logging |
| Technical details | Event decoding, coordinator, auto-wake |
| Slot numbering | Zigbee vs BLE vs cloud slot mapping |
| Cloud API status | Reverse engineering progress and next steps |
MIT License