A failed operation-log read discards an already-successful state read, so the lock entity never refreshes

[marianogoldman]

Summary

In coordinator._async_poll, the operation-log fetch runs after the state
query and before the return. If it raises, the state and battery values that
were already read successfully are thrown away, and _async_update_data
substitutes {"locked": None, "battery_level": None}.

Reading the operation log is auxiliary — it feeds the event entity. It should
not be able to invalidate the lock's state.

async def _async_poll(self, connection):
    result = await connection.async_query_state()
    if result is None:
        return {"locked": None, "battery_level": None}
    raw_state, battery = result              # <-- state already in hand
    await connection.async_get_operation_log()   # <-- raises
    return {                                 # <-- never reached
        "locked": _parse_lock_state(raw_state),
        "battery_level": battery,
    }

Why it matters

With DEFAULT_SCAN_INTERVAL_SECONDS = 3600 this is the only mechanism that
refreshes the entity from the device. When it is broken, the entity's state
only ever changes from HA's own optimistic writes in lock.py.

Everything done outside HA — fingerprint, PIN, NFC card, the TTLock app, the
keypad long-press — becomes invisible, not for an hour but indefinitely.

Measured on my install: I unlocked from the TTLock app and HA still reported
locked 40+ minutes later, including after a forced
homeassistant.update_entity.

That is worse than an unavailable entity, because it reports a confident wrong
value. A state-based automation such as "lock the door if it isn't locked when
everyone leaves" silently does nothing: the condition reads a stale locked
and the automation aborts without acting and without warning. I hit exactly
this before tracing it back here.

Environment

ha-ttlock-ble	3.4.0
ttlock-ble	0.1.10
Home Assistant	2026.7.2 (Docker)
Lock	LL609, DLock-XP V3

Suggested fix

Isolate the auxiliary read:

    raw_state, battery = result
    try:
        await connection.async_get_operation_log()
    except Exception:
        LOGGER.debug("Operation log fetch failed for %s", connection.mac, exc_info=True)
    return {
        "locked": _parse_lock_state(raw_state),
        "battery_level": battery,
    }

The lock state stays fresh; only the event entity lags.

Secondary: the failure is reported as a success

_async_update_data catches the exception and returns a None state, so the
coordinator logs:

WARNING [custom_components.ttlock_ble] Failed to poll <MAC>: The length of the provided data is not a multiple of the block length.
DEBUG   [custom_components.ttlock_ble] Finished fetching ttlock_ble data in 39.262 seconds (success: True)

success: True on a poll that produced no data hides the problem in exactly
the log a user would check. Worth flagging the update as failed so HA's own
coordinator machinery reflects it.

Related, but not duplicates

• FrameReassembler splits frames on CRLF found inside AES ciphertext, permanently breaking get_operation_log ttlock-ble#55 — the SDK framing bug that triggers this for me.
  It's deterministic per lock, so on affected locks the entity state is
  permanently stale rather than occasionally. The two are independent
  though: any failure of async_get_operation_log, transient BLE included,
  currently invalidates a good state read.
• Why does the state change after the device is disconnected? #52 — same user-visible symptom (locked shown while the door is open), but
  a different mechanism: there the state changes on disconnect, and those logs
  show Fetched 1 log entr(ies), so the log read is working.
• State not updating due to connection cool down #42 — also stale state, caused by the connection cooldown skipping queries.

Three different paths to "HA reports the wrong lock state" may be worth
triaging together, since the consequence is the same and it's a bad one: a
confidently wrong locked silently disables any state-based automation built
on it.

[roquerodrigo]

Thank you for splitting this out from the SDK report — it deserved its own issue, and your framing of why it matters was the most useful part. A confidently wrong locked really is worse than an unavailable entity, and the point that a state condition silently aborts the automation without any warning is what made this a priority rather than a cosmetic fix.

Fixed and released. Your suggested change was right, and tracing it turned up that it needed to go one layer deeper than either of us wrote:

• async_get_operation_log documents that it returns an empty list on failure, but only caught TTLockError. The SDK's log path reaches aes_decrypt unwrapped, so the ValueError you hit — "not a multiple of the block length" — went straight past it. Catching TTLockError in the coordinator, which is what I first wrote, would have fixed nothing for your case.
• The coordinator now guards the poll as well, so the invariant holds regardless of what the connection layer lets through. That came out of a test that failed and proved the coordinator had no protection of its own.

Both are covered by tests, including the exact exception from your log.

The release also pins ttlock-ble 0.1.11, which carries the framing fix from roquerodrigo/ttlock-ble#55, so on your LL609 the log read itself should stop failing rather than merely failing harmlessly.

You also flagged that a poll producing no data still logs success: True. That is a fair criticism and it is not addressed here — the poll now genuinely succeeds in the case you hit, so the misleading line should not appear for this path anymore, but the underlying reporting is still too optimistic when a state read really does fail. Worth its own issue if you want to see it tracked.

Your note about #52 and #42 reaching the same symptom by different routes is well taken and they are on the list to triage together. If any of this still misbehaves after upgrading, please reopen.

[marianogoldman]

Confirming the fix on my side, and thank you for going deeper than what I proposed.

After upgrading to 3.5.0, an operation performed outside Home Assistant is now reflected in the entity. I unlocked the door outside HA and the next successful poll picked it up:

lock.puerta_de_entrada_lock: locked → unlocked

Before, that never happened at all: the state only ever changed when HA itself issued a command and set it optimistically.

Your point about TTLockError not being enough was the crux — the try/except I suggested in the report would have caught nothing in my case, since the ValueError from aes_decrypt came through unwrapped. Good catch, and the defence-in-depth at both layers is the right call given the SDK can raise anything.

On the success: True reporting you invited as its own issue: I've written up the analysis and will file it separately. One thing worth flagging early — there are two paths, and the quieter one is the common one. When _async_ensure_connected_locked fails, async_query_state returns None without raising, so _async_poll returns a None snapshot normally and no Failed to poll warning is emitted at all. At default log levels that path is completely silent, and it's the dominant failure mode here (cold-start GATT connects). I'll include the captures.