Preserve button events on camera endpoints and avoid silence-only push faults

[copystring]

LANLink currently infers failed forwarding from five minutes without device reports. A live G4 continued forwarding physical button presses after 38 minutes of silence while push_stalled was active. Event-driven devices have no verified periodic-report contract, so silence alone cannot distinguish an idle device from failed forwarding.

Remove the silence-only subscription retries and Repair escalation. Retain the transport watchdog: when no frames, including keepalive replies, arrive for more than three keepalive intervals, the tunnel closes and the coordinator reconnects. Subscription re-arming on session-up and topology growth and standalone-device topology recovery also remain. The forwarding diagnostic stays available independently of the monitored connection and reports off when disconnected, on after a recent real report in the current session, and unknown when connected without recent forwarding evidence. Reconnection does not inherit positive evidence from the previous session.

The G4 also exposes Doorbell.ButtonEvent on a Camera endpoint. The datatype fallback classified it as an enum sensor, so repeated identical press codes did not represent separate events. Give ButtonEvent trait semantics priority over endpoint type, using the same factories as native Doorbell and Button endpoints. Preserve zero-valued ring codes, additional press types, ordinary switches, and writable configuration traits.

Compatibility: This also changes Button.ButtonEvent on Switch endpoints from sensor entities to event entities. Existing automations referencing those sensor entities need to be updated to the event entity and its event_type; automatic migration is not claimed. Ordinary Output.OnOff switches and writable configuration keep their control paths. The documentation explains the domain change.

Validation: 209 focused tests passed against the Home Assistant 2026.10.0 Python package. Coverage includes every catalogued ButtonEvent, all 145 affected Switch endpoints (76 model identifiers), real catalogue switch on/off writes and report routing independently of button reports, and the actual HA EventEntity implementation. The repeated-zero-code regression uses two explicit UTC times five seconds apart instead of relying on wall-clock resolution or HA-version-specific handling of sub-millisecond bursts. Paired tunnel tests verify that a responding but report-quiet tunnel stays open and a transport-silent tunnel forces reconnect. The diagnostic test verifies that disconnection is an available off state and reconnect starts without positive report evidence.

The live G4 produced two separate recorded ring events after the initial deployment and restart. After more than 350 seconds without a report, its tunnel remained connected and the diagnostic became unknown without silence-only retries or a Repair. These live checks cover the initial deployment; the subsequent diagnostic availability adjustment and shared Button factory have been unit-tested, not redeployed for another hardware test. No physical switch hardware test was performed.

Limits: A hub that still answers keepalives but no longer forwards unsolicited device reports cannot be identified reliably by this generic watchdog. Successful read or cloud-subscription responses do not prove push delivery. Detecting that narrower failure requires a known event or a verified periodic-report contract for a specific source; this PR does not claim to solve it. The full HA pytest harness could not start on Windows because its runner imports fcntl; the added integration setup regression remains unexecuted locally. Coordinator retry unit tests mock mDNS discovery so their network-free setup does not perform a real three-second discovery inside a one-second deadline.

[absent42]

Thanks for your PR. The principal looks good. My main concern is that it completely removes the check for wedged hubs, and that the forwarding sensor can never show "off" state.

Also have you tested the impact this will have on functionality of switches since this would also cause Button.ButtonEvent traits on switch endpoints to change from sensor to events?

Plus the new test test_camera_doorbell_repeated_zero_reports_are_distinct_events fails periodically because HA stores event state with a millisecond timestamp, so two back to back reports can get the same value.

[copystring]

Thanks for the review! I’ve pushed the follow-up changes: deterministic event-test timing, switch control and report-routing coverage, and an available “off” state when disconnected. The transport watchdog remains intact. All 209 focused tests pass.

Detecting stalled device reports while keepalives still arrive remains an explicit limitation. The PR description now documents this, the automation migration implications, and the remaining test gaps. Ready for another review.