Because unknown is not a lock result. It means Home Assistant does not currently know whether the Lockin lock is locked, unlocked, open, or jammed. If an automation treats that missing information as a normal state, it can send a false “secure” message, skip a necessary warning, or issue another command without knowing what happened to the previous one.

For a Lockin smart lock connected to Home Assistant through a supported Matter path, the safe rule is: only take a security-sensitive action when the entity reports the exact state the action requires. Treat unknown and unavailable as “state not confirmed,” then recover and verify. The exact model, firmware, controller, and entities exposed still need to be checked on your installation.

What unknown means in Home Assistant

Home Assistant’s lock integration lists Locked, Locking, Unlocked, Unlocking, Open, Opening, Jammed, Unavailable, and Unknown as possible lock states. Unknown means the state is not yet known. Unavailable means the entity cannot currently be reached. Neither one is evidence that the door is locked or unlocked.

That distinction matters because a lock state answers a narrower question than a door sensor. Locked describes the lock’s reported security state; it does not by itself prove that the door is physically closed. A separate contact sensor, when the installation exposes one, can report whether the door is open or closed. Do not manufacture a “closed” result from a lock entity that is unknown.

Why a security automation should fail closed

Consider an automation that locks the front door at bedtime or when the last person leaves. Its action may be harmless when Home Assistant has a current Unlocked state and the door contact is closed. It is a different situation when the entity is unknown:

This is a risk boundary, not a claim that every unknown event means the lock is physically open. The honest statement is narrower: the automation lacks the evidence needed to say that the lock is secure.

unknown is not the same as unlocked

An automation that checks only for “not locked” can accidentally collapse several different situations into one branch. That is unsafe for a Lockin lock because Unlocked, Jammed, Unknown, and Unavailable have different next steps.

Use exact state checks for decisions. For example, a notification or bedtime routine can require a usable lock state and a confirmed locked result:

conditions:
  - condition: template
    value_template: >-
      {{ has_value('lock.front_door')
         and is_state('lock.front_door', 'locked') }}

has_value() is useful here because it rejects unknown and unavailable. is_state() then requires the exact locked value. If your routine also depends on the door being shut, add a separately verified contact entity rather than assuming the lock state contains that information:

conditions:
  - condition: template
    value_template: >-
      {{ has_value('lock.front_door')
         and is_state('lock.front_door', 'locked')
         and has_value('binary_sensor.front_door_contact')
         and is_state('binary_sensor.front_door_contact', 'off') }}

Replace the example entity IDs with the entities that Home Assistant actually creates for your installation. If no verified contact entity exists, omit that part and keep the limitation visible; do not infer it.

Why recovery needs its own branch

Home Assistant’s automation documentation notes that most entity-targeted triggers do not fire when an entity recovers from unknown or unavailable. In other words, an automation that noticed the lock became unknown should not assume that a later recovery event will automatically replay the lock action or the “all clear” notification.

Use the unknown branch to create an explicit handoff:

alias: Front door lock state needs verification
triggers:
  - trigger: state
    entity_id: lock.front_door
    to: "unknown"
    id: unknown
  - trigger: state
    entity_id: lock.front_door
    to: "unavailable"
    id: unavailable
actions:
  - action: notify.mobile_app_phone
    data:
      title: "Front door state not confirmed"
      message: >-
        Home Assistant cannot confirm the Lockin lock state. Check the Lockin
        Smart App or the door in person before treating the entry as secure.

After the entity returns, use a separate time-, event-, or user-triggered check that requires has_value() and the exact expected state. Do not rely on the recovery itself as proof that the previous lock command completed.

What to check on a Lockin installation

Lockin’s US FAQ describes Veno-series Matter integration through a Matter-compatible hub for named smart-home ecosystems. Home Assistant has its own Matter integration and Matter Server path. That establishes a possible integration route, not a blanket promise that every Lockin model exposes the same entities or that every Home Assistant setup reports every lock feature.

Before trusting a Home Assistant automation, check the exact model and setup:

1. Confirm that the Lockin model is paired through the supported Matter workflow used by your Home Assistant installation.
2. Identify the actual lock entity and record which states it reports during a safe test: Locked, Unlocked, transitional states, Jammed, Unknown, and Unavailable where applicable.
3. Check whether a separate door-contact, battery, or diagnostic entity exists. Do not assume a Lockin product feature becomes a Home Assistant entity.
4. Test the automation with the door open first, then with the door closed. Keep the Lockin Smart App and a physical key or documented emergency-power method available.
5. If the lock becomes unknown or unavailable, pause unattended lock commands until the cause is understood and a fresh state is verified.

For Lockin Veno models, the FAQ specifically calls out door-status cable routing and strike-plate/sensor alignment when automatic locking behaves abnormally. It also directs owners to check power, the app, Wi-Fi conditions, and the physical key or emergency power when access is at risk. Those are practical recovery checks; they are not a substitute for confirming what Home Assistant reports.

The decision rule to keep

Use a positive, current state for a positive claim:

• Locked can support “the lock reports locked,” subject to any separate door/contact requirement.
• Unlocked can support “the lock reports unlocked,” not “the door is open.”
• Jammed supports an exception path and a physical check.
• Unknown or Unavailable supports “state not confirmed,” not “secure” and not “open.”

That is why a Home Assistant automation should treat an unknown Lockin state differently: the automation has lost the evidence that its safety decision depends on. Notify, diagnose, and verify the exact model’s current state before allowing a security-sensitive action to proceed.

For the product and setup boundary, see the Lockin FAQ, Lockin user-manual library, and Veno Go product page. For the broader state model, see how a Home Assistant dashboard should represent a Lockin smart-lock state.

Sources and scope

• Home Assistant Lock integration — lock states, triggers, conditions, and actions.
• Home Assistant automation triggers — unavailable and unknown trigger behavior.
• Home Assistant working with states — unknown, unavailable, and has_value().
• Home Assistant Matter integration — Matter Server and Matter device setup boundary.
• Lockin FAQ — Matter, door-status/alignment, app, power, and fallback-access guidance.
• Lockin Veno Go — model-specific Matter and built-in Wi-Fi evidence.

This article explains a safe automation decision boundary. It does not claim universal Home Assistant compatibility for every Lockin model, firmware, or controller, and it does not independently test a physical lock.