v0.7.11 — the door sensor can open again, and the battery is a real number
Two fixes and a documentation correction, all out of @Dei381rcr's testing on a Lockly Visage.
The door sensor could close but never open
A WiFi-native lock sends magnet: opened and magnet: closed. This integration accepted open. So every door closing was recorded and every door opening was dropped — on the affected hardware the door entity could reach closed and stay there.
It was reported as missed callbacks, which is exactly what it looked like from the outside. The warning about an unrecognised state value had been sitting in the debug log the whole time; nobody went and read it, me least of all.
Both word forms are accepted now, and close/closed alongside them.
The lock does not push door state — it answers when asked
Worth stating plainly, because two places in the README said the opposite in each direction.
With every refresh automation disabled and no status queries running, opening and closing a door by hand produced no callback at all, in either direction. The same lock answers a status query with the correct magnet state every time.
So the door sensor updates when something asks, not when the door moves, and lockly.refresh_door_state from 0.7.10 is the mechanism rather than a workaround. The README now says so.
Battery is a real percentage where the lock sends one
The same callback carries a numeric battery level — seen on a PGD728FG25 and two PGK728WRHK. The sensor now prefers it over everything else, and a new source attribute says where the current reading came from:
source |
Meaning |
|---|---|
reported |
the lock's own percentage, as the Lockly app shows it |
voltage |
a live wakeup-voltage reading through our 4×AA curve |
low battery flag |
not a measurement — 10 % and 90 % standing in for "low" and "not low" |
Check that attribute before setting a low-battery alert. A lock that only reports the binary flag will show 90 % until the day it shows 10 %, and nothing in between. That has always been true; until now nothing on the entity said so.
A value outside 0–100 is refused rather than clamped — a lock reporting 255 is saying something other than "full".
Unchanged
No frame or transport changes. Hub-attached locks behave exactly as in 0.7.10, including the battery sentinels, which are still all their cloud data supports.