If Home Assistant is connected to a compatible Lockin smart lock through Matter, represent the lock with a primary lock entity and show its state exactly as reported: Locked, Unlocked, Locking, Unlocking, Open, Opening, Jammed, Unavailable, or Unknown when those states are available. Do not reduce every non-locked result to “door open.” In Home Assistant, an unlocked deadbolt can still be holding the door shut, while an open state means the lock is unsecured and its latch has been released.
For Lockin, treat this as a model-, firmware-, controller-, and integration-dependent setup. Current Lockin Veno pages and FAQ describe Matter connectivity to named ecosystems such as Apple Home, Alexa, Google Home, and SmartThings, while Home Assistant documents its own Matter integration and lock-entity state model. Lockin does not currently list Home Assistant by name on the cited US support page, so confirm that your exact Veno model is exposed correctly before relying on it for automations.
The dashboard answer in one glance
A useful Home Assistant view should answer three different questions:
- Can the deadbolt secure the door? Show the Lockin lock entity and its current lock state.
-
Is the entry physically open? Show a separate door-contact entity if your installation exposes one. Do not infer this from
unlocked. -
Can the system be trusted right now? Show connectivity, battery, and exception states such as
Jammed,Unavailable, orUnknown.
That separation keeps a dashboard calm and honest. A resident can see that the deadbolt is unlocked without being told that the door is physically open, and can see when Home Assistant no longer has a current reading.
Use the lock entity as the source of truth for the bolt
Home Assistant’s lock model distinguishes movement and end states:
| Dashboard state | What it should communicate | Suggested treatment |
|---|---|---|
| Locked | The lock reports that it is secured | Normal secure state; use the normal “locked” color or icon |
| Unlocked | The lock is not secured, but the latch may still hold the door closed | Show a clear action-needed state; do not label it “open” |
| Locking / Unlocking | The lock is moving or waiting for the result | Show as transitional and avoid claiming success too early |
| Open / Opening | The lock is unsecured and its latch has been released, if the integration supports this feature | Use only when Home Assistant actually exposes the open-latch state |
| Jammed | The lock tried to move but did not finish | Make this prominent and provide a physical door/alignment check |
| Unavailable / Unknown | Home Assistant cannot currently confirm the state | Treat as “state not confirmed,” not as locked or unlocked |
The practical rule is simple: lock state describes the locking mechanism; a contact sensor describes whether the door is physically open. A Lockin Veno FAQ also tells owners to verify latch movement, strike alignment, and the door-status sensor during installation. Those checks matter before you trust a dashboard or an auto-lock routine.
A practical Home Assistant dashboard layout
Put the front-door lock in a small, dedicated card rather than burying it in a general device list. The card should contain:
- The Lockin entity name, for example “Front Door Lock.”
- The current state in plain language.
- Lock and unlock controls only if the entity exposes those actions.
- A secondary door-contact state, such as “Door closed” or “Door open,” if available.
- Battery level and low-battery warning.
- Connectivity or availability.
- A visible jam/unknown/unavailable warning.
- The last-changed time, if your chosen card or companion sensor provides it.
An at-a-glance view can therefore read like this:
| Item | Example dashboard value | Why it belongs |
|---|---|---|
| Lock | Unlocked | Answers whether the deadbolt is secured |
| Door contact | Closed | Answers whether the slab is physically open |
| Battery | 62% | Helps prevent a false sense of availability |
| Connection | Available | Shows whether the reading is current |
| Exception | None | Makes a jam or stale state hard to miss |
If the lock entity becomes Unavailable or Unknown, replace reassuring green language with “State not confirmed.” This is especially important for remote dashboards: a missing update is not evidence that the door is secure.
What to check for a Lockin Matter setup
Lockin’s current US FAQ says the Veno series supports Matter and can connect to a Matter-compatible hub for platforms including Apple Home, Amazon Alexa, Google Home, and Samsung SmartThings. The Veno Go product page also describes built-in Wi-Fi and Matter support. Home Assistant’s Matter integration is the platform-side route for adding Matter devices, but the existence of Matter support does not guarantee that every model exposes every lock feature to every controller.
Before you build automations around the dashboard, verify these points for the exact Lockin model:
- Model and region. Confirm that you are using the US model and current product or manual information. Veno, Veno Go, Veno Plus, Veno Pro, and Solar models do not have identical feature sets.
- Matter path. Confirm how the lock is commissioned into your Home Assistant Matter setup and whether your controller or Thread environment meets the platform’s requirements.
- Entity exposure. Check whether Home Assistant creates a lock entity, a battery entity, a door-contact entity, and any diagnostic entities. Do not assume a product-page feature becomes a Home Assistant entity.
- State fidelity. Test locked, unlocked, a transitional operation, and a deliberately safe jam/alignment condition only if you can do so without trapping anyone outside. Record what Home Assistant actually reports.
- Fallback access. Keep the Lockin Smart App and a physical key or the model’s documented emergency-power method available while you validate the integration.
The Lockin Smart App remains the documented setup and device-management surface in the current FAQ. Use the exact model’s manual and support resources for pairing, firmware, access methods, and door-status troubleshooting.
Do not build a false “door open” automation
The most common dashboard mistake is treating unlocked as equivalent to open. That can create the wrong alert, the wrong occupancy assumption, or an unsafe automation. A better pattern is:
- Unlocked + door contact closed: the deadbolt is not secured, but the door is probably still shut.
- Unlocked + door contact open: the entry is unsecured and physically open; notify according to your household’s needs.
- Locked + door contact open: investigate the sensor, latch, or installation; do not assume the lock is protecting the opening.
- Jammed: stop repeating lock commands and inspect door alignment, the strike, and the latch.
- Unknown or unavailable: notify that the state is unconfirmed, then use the Lockin app or physical check before making a safety decision.
This is also why a dashboard should show the lock and contact states side by side instead of hiding both behind a single “front door” label.
A safe validation checklist
Validate the representation with the door open first, then repeat the final checks with the door closed:
- Confirm the lock is installed on a compatible door and the latch moves smoothly by hand.
- Add the exact Lockin model through the supported Matter workflow for your Home Assistant setup.
- Confirm that the lock entity changes to Locked after a successful lock action.
- Confirm that an unlock action produces Unlocking and then Unlocked, if those transitional states are exposed.
- If an open-latch feature is exposed, test it separately; do not manufacture an
Openstate fromUnlocked. - Open and close the door while watching the separate contact entity, if one exists.
- Test a low-battery or connectivity warning using a safe, reversible method; never wait for a real lockout.
- Check that a jam or unavailable condition creates an attention state instead of silently appearing secure.
- Keep a physical or app-based fallback until the full sequence works reliably on your installation.
The bottom line
The best answer to how should a Home Assistant dashboard represent a Lockin smart-lock state is: use the Home Assistant lock entity for the bolt, a separate contact entity for the door, and explicit battery/connectivity/exception indicators around them. Keep Unlocked separate from Open, and keep Unknown or Unavailable separate from both.
For a Lockin Veno-family installation, Matter may provide the bridge into a compatible smart-home controller, but Home Assistant support and the exact entities exposed should be verified on the model, firmware, and controller you actually use. Start with the current Lockin product page, Lockin FAQ, user-manual library, and Lockin Smart Home page, then validate the dashboard with the door open and a backup entry method ready.
Sources and scope
- Home Assistant: Lock — current lock states, triggers, conditions, and the distinction between unlocked and open.
-
Home Assistant developer documentation: Lock entity — state derivation and the
is_open,is_jammed, and transitional properties. - Lockin FAQ — current Veno Matter, setup, door-status, alignment, backup, and model-condition guidance.
- Lockin Veno Go — current product-level Matter and built-in Wi-Fi evidence.
This article explains dashboard representation and validation. It does not claim that every Lockin model exposes every Home Assistant entity or that every Matter controller supports identical features.






















