Fixes #12062.

TL;DR

HomeAssistantAdapter._handle_ha_event writes the per-entity cooldown timestamp before it knows whether the event will actually produce a forwarded message. A no-op state_changed event (old_state == new_state) therefore consumes the cooldown window and suppresses the next real state change.

Fix: keep the cooldown check early, but delay the cooldown write until after _format_state_change returns a non-empty message. Only events that forward consume the window.

Two lines effectively swapped; one comment added.

Root cause

gateway/platforms/homeassistant.py:286-299 (pre-fix):

# Apply cooldown
now = time.time()
last = self._last_event_time.get(entity_id, 0)
if (now - last) < self._cooldown_seconds:
    return
self._last_event_time[entity_id] = now      # ← advanced before we know
                                              #   whether the event forwards

old_state = event_data.get("old_state", {})
new_state = event_data.get("new_state", {})
message = self._format_state_change(entity_id, old_state, new_state)

if not message:                               # ← no-op / malformed → None,
    return                                    #   cooldown already burned

_format_state_change returns None in two cases (both legitimate non-forward paths):

• new_state missing/empty
• old_val == new_val — state didn't actually change

Fix

# Apply cooldown check — but do NOT record the timestamp yet.
# Unchanged or malformed events (where _format_state_change returns
# None below) must not consume the cooldown window and suppress the
# next real state change. See #12062.
now = time.time()
last = self._last_event_time.get(entity_id, 0)
if (now - last) < self._cooldown_seconds:
    return

old_state = event_data.get("old_state", {})
new_state = event_data.get("new_state", {})
message = self._format_state_change(entity_id, old_state, new_state)

if not message:
    return

# Only consume the cooldown window for events we actually forward.
self._last_event_time[entity_id] = now

Reproduction on clean origin/main (6fb69229)

Direct copy of reporter's repro:

ha = HomeAssistantAdapter(PlatformConfig(enabled=True, token='t', extra={
    'url': 'http://x', 'watch_all': True, 'cooldown_seconds': 60,
}))
ha.handle_message = AsyncMock()

await ha._handle_ha_event({'data': {
    'entity_id': 'sensor.temp',
    'old_state': {'state': '20'},
    'new_state': {'state': '20', 'attributes': {}},
}})
await ha._handle_ha_event({'data': {
    'entity_id': 'sensor.temp',
    'old_state': {'state': '20'},
    'new_state': {'state': '21', 'attributes': {}},
}})

assert ha.handle_message.await_count == 1   # fails on main: actual 0

Narrow scope — explicitly not changed

• Cooldown check placement. Still runs before _format_state_change. Not doing wasted format work on throttled events, and not widening the cooldown check semantics to "every non-None formatter output" (which would entangle the throttle policy with formatting logic).
• handle_message failure handling. If handle_message raises after the timestamp is recorded, the cooldown still counts — same behaviour as before the fix. Out of scope.
• Dict pruning. _last_event_time is not otherwise bounded. This fix happens to stop no-op entities from accumulating entries (side benefit, not the goal).
• _format_state_change semantics. Pure formatter, unchanged.

Behaviour matrix

Rows A, D, E match pre-fix behaviour. Rows B and C change from "consumes window" to "passes through without consuming".

Regression coverage

tests/gateway/test_homeassistant.py gets a new TestCooldownIssue12062 class with 5 cases:

• test_no_op_state_change_does_not_consume_cooldown — reporter's exact scenario.
• test_no_op_does_not_write_last_event_time — structural pin on _last_event_time.
• test_missing_new_state_does_not_consume_cooldown — covers the other _format_state_change → None branch.
• test_forwarded_event_still_consumes_cooldown — preserved-behaviour canary so the fix can't silently disable cooldown.
• test_no_op_then_real_change_across_entities — independent per-entity accounting.

4 of 5 fail on clean origin/main with symptoms like:

AssertionError: assert 0 == 1  (handle_message.await_count)
AssertionError: assert 'sensor.temp' not in {'sensor.temp': 1776522437.86081}

The 5th pins preserved behaviour.

Validation

source venv/bin/activate
python -m pytest tests/gateway/test_homeassistant.py -q
# 50 passed (45 pre-existing + 5 new)

Broader tests/gateway under -n auto → 13 pre-existing baseline failures (dingtalk card lifecycle, matrix encrypted upload, approve/deny E2E, whatsapp bridge runtime / xdist flakes). Zero in test_homeassistant.py or any touched code path. Happy to post the per-test baseline audit as a PR comment.

Pre-empted review questions

Q. Could this cause runaway forwarding if an entity emits thousands of no-ops?
No. _format_state_change still returns None for no-ops, so they don't forward regardless of cooldown state. Cooldown only throttles the stream of forwarded messages.

Q. Why not move the cooldown check itself later, past _format_state_change?
Two reasons:

1. Format work would run even for entities within the cooldown window — wasted CPU.
2. It would spread throttle policy into the formatter's return contract — the formatter is a pure function, not a throttling arbiter.

Q. Concurrency?
_handle_ha_event is async but there are no awaits between the cooldown read and the new self._last_event_time[entity_id] = now write (_format_state_change is synchronous and pure). Same atomicity as before.

Q. Was _last_event_time ever pruned?
No, and this PR doesn't add pruning — but the fix does stop unbounded growth from entities that only ever emit no-op events. Explicit pruning is a separate concern if long-lived deployments need it.

_{Co-authored via LLM assistance; I've reviewed every line and am responsible for correctness.}