A failure that told you nothing, and a documented quirk of the hardware.
An all-digit lock ID has to be quoted
Many Lockly device IDs are entirely digits — 250021003033471231363531. Home Assistant's YAML editor parses that in JavaScript, which has no integer type wide enough to hold it, so an unquoted ID above 2⁵³ arrives as 2.5002100303347123e+23. The digits are gone before this integration runs, and nothing can recover them.
Every service takes a lock_id, so this affected all of them, and the symptom was silence: no lock matched, refresh_door_state logged door_open=None, and the owner was told neither what was wrong nor that anything was.
It is now reported as an error naming the mistake and the fix. Quoting avoids it entirely:
action: lockly.refresh_door_state
data:
lock_id: "250021003033471231363531"Every lock_id field description says so now, and so does the README. Found by @Dei381rcr while testing 0.7.11 — the kind of thing only real use turns up.
The Lockly app's Auto-Detection toggle can lie
Documented in docs/api.md, in the reporter's words and with his permission:
On my PGK728WRHK hardware, a settings value of 0x0A corresponded with the lock performing its native automatic locking behavior even when the Lockly app showed Auto-Detection as off. Changing the settings value from 0x0A to 0x02 stopped that native automatic locking behavior.
That is bit 0x08 — the Auto-Lock master switch — set in the lock's own settings byte while the app displayed the opposite. The lock was enforcing what its byte said.
This matters if a lock is throwing its bolt at an open door: the app's switch is not evidence, and lockly.disable_native_auto_lock is how to be sure, because it reads the byte, clears the bit and reads it back. It is also why that write has always been a read-modify-write rather than a blind set. Scoped to the PGK728WRHK hardware it was observed on, as the reporter asked — nothing here establishes how other models behave.
Also settled: a status query wakes the lock
Tested on a Visage — the lock audibly chirps when queried. So no automatic door-state polling will be added. lockly.refresh_door_state stays a service you call when you need a reading, which is what 0.7.10 shipped it as.
Unchanged
No frame, transport or state-parsing changes. v0.7.11's magnet and battery fixes are confirmed working on two PGK728WRHK locks, both now reporting a real percentage with source: reported.