Here is a list of all related documentation pages:

[detail level 1234]

Documentation
Getting started
Hardware
Supported devices
Somfy Izymo IO dimmer
Somfy Sunea IO
VELUX INTEGRA and the KLR/KLF/KUX family
Somfy RS100 IO
Somfy White LED Receiver io
Pairing
Key extraction
Configuration reference
Covers
Lights, locks and switches
Heating and climate
Home Assistant actions
Linked remotes and sender events
Sending 1W commands
Radio tuning
Diagnostic entities
Tips and tricks
Troubleshooting
FAQ
Diagnostic probes
LR1121 firmware update
Architecture Overview
Architecture Decision Records
ADR 0001: Layered protocol / radio-driver / hub architecture
ADR 0002: Direct SPI radio drivers instead of ESPHome's built-in radio components
ADR 0003: Shared software PHY and IRQ orchestration base for SX1262/LR1121
ADR 0004: Hub responsibilities split into single-purpose collaborators
ADR 0005: Pure decision logic kept separate from I/O
ADR 0006: Hub-level admin operations as native API actions, not permanent entities
ADR 0007: Self-contained AES-128 implementation
ADR 0008: `io_device_id`, not `device_id` — and an `io_` prefix for protocol keys
ADR 0009: Companion entity IDs are declared during schema validation
ADR 0010: Real captured frames are the regression-test source of truth
ADR 0011: Key material is masked wherever frames are logged, unconditionally
ADR 0012: Key-extraction responder for recovering credentials from an owned installation
ADR 0013: Radio work is blocking, on the ESPHome loop, with no FreeRTOS tasks
ADR 0014: Host unit tests build against stubbed ESPHome headers
ADR 0015: Table-driven tuning registry, guarded by a cross-language sync gate
ADR 0016: Sender events are opt-in, by explicit allowlist
ADR 0017: A device's settle hint may shorten the poll interval, never stretch it
ADR 0018: YAML is the source of truth; the hub persists no state of its own
ADR 0019: What the protocol cannot report is declared, not guessed
ADR 0020: Flash LR1121 transceiver firmware, not the bootloader
ADR 0021: Flash the LR1121 bootloader, behind an arming switch
ADR 0022: Unauthenticated status frames are never applied to device state
ADR 0023: `reference-material` as a fourth corpus origin, for real devices this project doesn't own
ADR 0024: Diagnostic probes are gated, paired-devices-only, and isolated from the status decoder
ADR 0025: Monotonic counters are the one thing the hub persists
ADR 0026: 1W enrollment is required, and its safety comes from a physical interlock
ADR 0027: Controller identities replace node addressing for 1W
ADR 0028: Channel policy is a property of the frame, not of the chip
ADR 0029: The start preamble is a property of the target's power class, not of the frame's position
ADR 0030: A hub prediction is kept apart from a device observation
ADR 0031: 1W vendor wire behaviour is driven by `manufacturer:`, and `execute_broadcast` is a remote-shape axis
ADR 0032: 1W enrollment follows the gesture the target's `manufacturer:` expects
ADR 0033: The heating send path bypasses the cover status/optimistic machinery
ADR 0034: Doxygen page syntax is generated at staging time, never committed
ADR 0035: FEM support is a behaviour profile; boards always supply their own pins
ADR 0036: Hub-level entities come from `home_io_control:` flags, never a platform entry
ADR 0037: The roll-call sweeps both power classes
ADR 0038: 1W bursts follow the identity's power class, not a hard-coded preamble
ADR 0039: Pairing sends a discover-confirm (0x2C) and tolerates no answer
ADR 0040: A low-power device's start preamble follows its wake belief
ADR 0041: An unset 1W `low_power:` resolves from the manufacturer profile
ADR 0042: The directed start preamble's default comes from the radio driver
ADR 0043: An unconfirmed movement command is re-sent once to a device that normally confirms
Contributing
Development setup
Documentation map
Todo List