Skip to content

v0.6.0 — Access log, door sensor, MQTT reconnect fix

Choose a tag to compare

View all tags
@Forcky Forcky released this 25 Aug 18:57
· 39 commits to main since this release
v0.6.0
b7e5b33

Follow-up to v0.5.0, which made unlock work. This release is mostly about what happens after the lock responds: who opened the door, and not hammering Lockly's servers while finding out.

Upgrade recommended if you are on v0.5.0, primarily for the MQTT fix below.

Fixes

  • MQTT reconnect storm. When the broker refused the connection (rc=5), paho retried on its own — up to seven attempts in seventy seconds, indefinitely, against Lockly's infrastructure. The client now gives up on an authentication refusal instead of retrying. If your log showed repeated Lockly MQTT connection refused rc=5, this is the fix.
  • A refused MQTT subscription was logged as success. A SUBACK of 0x80 means refused; it was being reported as "subscription confirmed".
  • Last Access reported Unknown for every keypad and fingerprint entry. Operator names now resolve against the lock's credential list.
  • The credential list double-counted every entry — four credentials were reported as eight, because paginated pages were re-fetched and appended.
  • Locks were being woken every few minutes, which is audible on models with the beep enabled. Reading the access log from the lock now happens once per session and on demand, never on a timer.
  • Credentials with user_type 2 were parsed with the wrong field layout.

New

  • Access log read directly from the lock (0x78), with a paged query (0x7C) as a fallback for locks whose bulk read returns nothing. This is what makes Last Access work on locks whose cloud history is empty or stale.
  • Readable event types — "keypad unlock", "physical key", "one-time code" and so on, instead of raw codes.
  • A lockly.read_access_log service to refresh the log on demand, since it is deliberately no longer polled.
  • Door sensor entity. Reports open/closed for locks with a sensor fitted.

About the door sensor

Worth reading if you have sensor-equipped locks, because the behaviour is deliberate and looks like a bug otherwise.

The lock reports a door circuit, not a door sensor. A shut door completes the circuit; an open door breaks it — and a lock with no sensor fitted is a broken circuit permanently. So "open" is ambiguous between a genuinely open door and no sensor at all, while "closed" can only come from a real sensor.

The entity therefore stays unavailable until the lock reports a closed door at least once, then remains available. In practice it appears on the first poll for any lock whose door is shut. If it stays unavailable, shut the door and restart HA or send any lock command. This is re-learned after each restart.

Verified by physically opening a sensor-equipped door and watching the bit change.

What is tested

All of the above on PGD628FN locks (firmware 4.03.15) behind PGH220 Secure LINK hubs — four locks, two hubs, two of them sensor-equipped. Unlock is physically confirmed.

Still unverified: lock.lock, guest PIN activation on the hardware, and every other lock and hub model. If you are on different hardware, a log paste on an issue is genuinely useful.

Unchanged limitations

  • Real-time push does not work. Every avenue found is closed — the broker accepts the connection and refuses the subscription. rc=5 in your log is expected. State updates at startup and after commands from HA.
  • Silent polling needs hub firmware ≥ build 422 on major-version-2 hubs.
  • Locks with no hub are not supported.
  • Battery is a low/normal flag, not a real percentage.
logger:
  default: warning
  logs:
    custom_components.lockly: debug

Protocol documentation: docs/api.md

Assets 2
Loading