proto_timing.h

Go to the documentation of this file.

#pragma once
 
/// @file proto_timing.h
/// @brief Physical-layer radio and timing parameters for the IO-Homecontrol protocol.
/// @ingroup hioc_protocol
 
#include <cstdint>
 
namespace esphome {
namespace home_io_control {
 
// ============================================================================
// Physical Layer — Radio Parameters
// ============================================================================
 
/// The protocol uses 3 frequency channels in the 868 MHz ISM band.
/// IO-Homecontrol uses 3 channels in the 868 MHz SRD band. In 1W (one-way) mode,
/// only CH2 is used. In 2W (two-way) mode, the controller hops across all three
/// channels every ~2.7ms when idle. Commands are sent on CH2; responses may arrive
/// on any channel within the exchange wait window.
static constexpr uint32_t FREQ_CH1 = 868250000;  ///< Channel 1: 868.25 MHz (2W only)
static constexpr uint32_t FREQ_CH2 = 868950000;  ///< Channel 2: 868.95 MHz (1W and 2W, TX channel)
static constexpr uint32_t FREQ_CH3 = 869850000;  ///< Channel 3: 869.85 MHz (2W only)
 
/// Length of one discovery answer slot. A discovery request opens a window of N such slots; the
/// key-extraction responder answers once, in a random slot from 1 to N, so it never answers at
/// once; the controller collects answers for the whole window before it confirms one.
///
/// Evidence: in our corpus's discovery captures, devices answer a 32-slot search between 13 and
/// 1353 ms after it, inside 33 × 41 ms; a Freebox Delta repeats its 128-slot search about every
/// 5.3 s, which is 128 × 41 ms plus its own turnaround (issue #215).
static constexpr uint32_t DISCOVERY_SLOT_MS = 41;
 
/// Preamble is a sequence of 0xAA bytes that precedes every frame.
/// Any start frame carrying `CTRL1_LOW_POWER` — a directed frame to a low-power target, or the
/// SPE roll-call's low-power frame shape — uses the long preamble (1024 bytes = 8192 bits) as a
/// wake-up burst for a duty-cycled receiver; every other start frame uses the runtime-tunable
/// `normal_start_preamble`, which an always-listening receiver detects fine. Every continuation
/// frame (a reply, our challenge or challenge answer, a status-update ACK) uses the radio driver's
/// `response_preamble()`, since both sides are already on the same channel; SHORT_PREAMBLE is that
/// value's protocol default and the tuning floor. The exchange engine derives all of this from the
/// frame (exchange_engine.cpp).
static constexpr uint16_t LONG_PREAMBLE = 1024;  ///< 1024 bytes: wake-up burst for a low-power start frame
static constexpr uint16_t SHORT_PREAMBLE = 8;    ///< Protocol default and floor for continuation frames
 
/// Default for `TuningConfig::cold_broadcast_reply_preamble` — preamble for a *broadcast* reply to
/// a frame the peer caught via a rotating/hopping listen (currently: only the key-extraction
/// responder's 0x29, the sole `start=true` frame any device-role builder in this codebase
/// produces) — long enough to be reliably caught by a hopping receiver, short enough that
/// sending it doesn't block the loop the way LONG_PREAMBLE does.
///
/// Sized above the ~13.9 ms real-device discovery-reply preamble this project's own SX1262/LR1121
/// discovery hop-slice tuning was measured against (issue #65 SDR analysis) — that measurement is
/// what "reliably caught by a hopping receiver" is calibrated to here. 80 bytes ≈ 16.7 ms at the
/// protocol's 38400 bps line rate (soft_phy_air_time_us()),
/// budgeted as a starting point, not yet hardware-validated for this exact chip/scenario
/// combination. Runtime-tunable via `cold_broadcast_reply_preamble` for exactly that reason.
static constexpr uint16_t COLD_BROADCAST_REPLY_PREAMBLE = 80;
 
/// Default for `TuningConfig::normal_start_preamble` — the preamble in front of a directed *start*
/// frame whose target is **not** a low-power / duty-cycled device (`CTRL1_LOW_POWER` clear). An
/// always-listening receiver does not need the ~213 ms `LONG_PREAMBLE` wake-up burst, and some
/// receivers never lock onto one that long; a normal start frame gets this shorter preamble
/// instead, matching what a reference hub sends to an always-alive device.
///
/// 32 bytes = 256 bits is well above the ~12-byte response preamble a
/// short-turnaround chip uses, ~6.7 ms of air time, and two orders of magnitude below the 1024-byte
/// burst. 8 bytes is a proven lower bound against paired always-alive devices but nothing bounds
/// where a start frame stops being heard, so 32 is the defensible middle — and `normal_start_preamble`
/// is a live tuning knob so a wrong guess costs a number change, not a rebuild.
static constexpr uint16_t NORMAL_START_PREAMBLE = 32;
 
/// How hard a transmission has to work to be heard: the wake-up level the receiver needs. A radio
/// that wakes receivers by preamble length gets the same information from
/// `RadioTxConfig::preamble_len` and may ignore this; a radio that wakes them some other way (a
/// train of frames, for example) reads it instead of guessing from a preamble length.
enum class TxWake : uint8_t {
  NONE,   ///< The receiver is already listening on this channel: the frame continues an exchange.
  SHORT,  ///< The receiver is awake, but may be scanning channels.
  LONG,   ///< The receiver may be duty-cycling.
};
 
/// True when a preamble this long is the wake-up burst for a duty-cycled receiver. Every preamble
/// tunable except `pairing_discovery_preamble` is capped well below `LONG_PREAMBLE`, and that one
/// is capped at it (an explicit opt-in to the wake-up burst for discovery), so only a real wake-up
/// burst reaches the threshold. The discovery preamble has no compiled default: it follows
/// `normal_start_preamble` (see `effective_discovery_preamble()` in tuning_config.h).
constexpr bool is_wake_preamble(uint16_t len) { return len >= LONG_PREAMBLE; }
 
/// The wake-up level of a frame, from the two facts that decide it: whether it starts an exchange
/// (a continuation reaches a receiver that is already listening) and whether its preamble is the
/// wake-up burst.
constexpr TxWake tx_wake_for(bool start, uint16_t preamble) {
  if (!start)
    return TxWake::NONE;
  return is_wake_preamble(preamble) ? TxWake::LONG : TxWake::SHORT;
}
 
/// Preamble/sync linger extension for a rotating listen (`ListenSpec::linger_dwell_ms`): how much
/// longer to stay on a channel once a frame is visibly incoming, so a hop doesn't cut it off
/// mid-reception. Sized to a frame's air time, not to a hop slice, so it does not need to change
/// when a chip's hop slice does. Shared by every rotating listen (pairing discovery, broadcast
/// roll-call): both wait for the same class of short protocol frame, so there is no measured
/// reason for them to differ.
static constexpr uint32_t PREAMBLE_LINGER_DWELL_MS = 15;
 
/// Base of how long a node acting as a device holds the session's channel after answering a
/// controller, before it scans all channels again. The full hold adds the turnaround time the node
/// advertises in its `0x29` (att_class_ms()), so a controller that waits out that turnaround still
/// finds the node listening. 35 ms is our margin, not a measured device timer: with the default
/// advertised turnaround the hold is 75 ms, above the 16-52 ms in which third-party controllers
/// answered a device's challenge in our corpus (`somfy_oximo40_statuspoll_sx1262`,
/// `somfy_rs100_statuspoll_kig300_sx1276`).
static constexpr uint32_t SESSION_HOLD_BASE_MS = 35;
 
// Chip-specific defaults (response preamble, post-TX settle, per-chip discovery hop slices
// for SX1262 and LR1121) live beside their TuningConfig fields in tuning_config.h; the
// SX1262/LR1121 exchange dwell constants live in radio_sx1262.h / radio_lr1121.h respectively.
// Kept out of the generic protocol layer per the radio-timing layering cleanup — this header
// holds only chip-neutral protocol values.
 
/// Timing constants for frequency hopping and response waiting.
static constexpr int32_t HOP_TIME_US = 2700;      ///< Time per channel when hopping (2.7ms)
static constexpr int32_t RESPONSE_WAIT_MS = 500;  ///< Wait for response to non-start frame
 
/// Wait for a response to a start frame — the first frame of an exchange, and the one a sleeping
/// device has just been woken by.
///
/// This device class replies within a few milliseconds of the carrier dropping, or not at all —
/// it is fast-or-never, not slow. A failure therefore shows up as `saw_challenge=0` with no frame
/// received at all, rather than as a late arrival, so a longer window cannot fix a device that
/// genuinely fails to answer.
///
/// 400 ms sits comfortably above every directly measured reply while keeping a failed exchange
/// inside EXCHANGE_TOTAL_BUDGET_MS, so a dead device does not block the ESPHome loop past its own
/// warning threshold (ADR 0013). Raise `exchange_start_response_wait_ms` from YAML if a device ever
/// genuinely answers late — but check `wait_ms` in the logs first, since a fast-or-never device is a
/// turnaround problem that a longer window cannot fix.
static constexpr int32_t RESPONSE_START_WAIT_MS = 400;
 
static constexpr int32_t RESPONSE_AUTH_WAIT_MS =
    RESPONSE_WAIT_MS;                                    ///< Wait for final response after challenge response
static constexpr int32_t EXCHANGE_RETRY_DELAY_MS = 250;  ///< Gap between retries within one HA command
/// Attempts per exchange for every caller that has not asked for an attempt plan
/// (decisions::attempt_plan()): a command that is not repeat-safe (decisions::is_repeat_safe_command()),
/// heater registers, management actions and the pairing loops. It is also the ceiling of the
/// `max_tries` overload of ExchangeEngine::send_and_receive(), and the most copies a challenged
/// request that never closes is followed by, whatever its plan.
static constexpr uint8_t EXCHANGE_RETRY_COUNT = 3;
/// Most attempts any exchange makes, whatever the budget allows: a plan with a long
/// `exchange_total_budget_ms` still stops here, so a dead device is not hammered with 25 copies of
/// a read.
static constexpr uint8_t EXCHANGE_MAX_ATTEMPTS = 9;
/// Attempts a settling read makes to a low-power receiver. Each one leads with the wake-up
/// preamble (~0.24 s on air), so three already fill the exchange budget.
static constexpr uint8_t LOW_POWER_SETTLING_ATTEMPTS = 3;
/// How long the short lead attempt of a read to a low-power receiver in an unknown state listens after
/// the end of its own transmission (decisions::WakeBelief::UNKNOWN, ADR 0079).
///
/// The lead attempt is aimed at a receiver that is travelling: such a VELUX screen answered a short
/// start frame 41 to 47 ms after it (issue #114), and a resting one does
/// not answer it at all, so a longer wait is spent on silence. 100 ms is about twice the slowest of
/// those answers, and keeps the cost of the lead (its transmission, this window and
/// EXCHANGE_ATTEMPT_OVERHEAD_MS) near 0.12 s.
static constexpr uint16_t LOW_POWER_SHORT_LEAD_WINDOW_MS = 100;
/// How long a read listens for a low-power receiver's reply after the end of its own transmission,
/// on every attempt.
///
/// Of the 93 low-power-flagged requests this hub transmitted in the corpus (83 captures, see
/// scripts/corpus/reply_latency.py), the median answer came 248 ms after the end of the request,
/// the 90th percentile 299 ms, the 95th 354 ms; 89 came within 400 ms, and the four slower ones took
/// 647 ms (a third-party gateway's pairing), 819 ms and 1639 ms (an RS100 io motor's key exchange)
/// and 4375 ms (a stalled key extraction). 550 ms sits about 1.5 times above the 95th percentile and
/// below every slower sample, so one attempt's window covers a reply that arrives late without
/// waiting for the outliers. Three such attempts with their wake-up preambles still fit
/// EXCHANGE_TOTAL_BUDGET_MS when nothing is waited between them.
static constexpr uint16_t LOW_POWER_RESPONSE_WAIT_MS = 550;
/// How long an attempt listens for a mains device's reply when another attempt follows it, after
/// the end of its own transmission.
///
/// A mains-powered device answers within a few tens of milliseconds or not at all. Across the
/// corpus, 47 of the 52 start requests this hub sent to a device that is not declared low-power drew
/// their first reply within 98 ms (median 66 ms, scripts/corpus/reply_latency.py --mains); the other
/// five are a stalled key extraction and replies that belong to a later request. On the bench, an
/// Izymo dimmer answered 36 to 42 ms after the start of the hub's transmission (400 exchanges, none
/// retried), its carrier coming up within about 0.1 ms of the end of our frame; a Sunea awning, on
/// every radio the hub drives, answered its challenged status reads 33 to 49 ms after it.
/// 200 ms is twice the slowest of those corpus replies and about four times the bench maximum, and
/// the largest round value for which nine attempts still fit EXCHANGE_TOTAL_BUDGET_MS: the early
/// attempts listen this long and the last one listens the whole start window, so a device that does
/// answer late still gets one full-length listen. Used by decisions::attempt_plan() for mains
/// targets only (a low-power target keeps one window for every attempt).
static constexpr uint16_t EXCHANGE_EARLY_RESPONSE_WAIT_MS = 200;
/// Time an attempt costs beyond its transmission and its listen: the channel-busy check, the
/// frequency hop and the SPI traffic around each transmit. Measured on the bench boards, one per
/// radio the hub drives: a read to an address no device answers made attempts 422 ms apart where the
/// transmit estimate and the 400 ms window add up to 412 ms. The budget guard and the attempt plan
/// both add it to every attempt (decisions::attempt_fits()), so the plan promises exactly the
/// attempts the guard admits.
static constexpr uint32_t EXCHANGE_ATTEMPT_OVERHEAD_MS = 10;
/// Re-sends allowed for a CMD_EXECUTE the target accepted without a closing reply, within the same
/// exchange and its retry budget. One: a second silent try says the loss is not a one-off, and a
/// third copy of a movement command would only lengthen the blocked loop. See
/// decisions::retry_after_unconfirmed_accept_is_safe().
static constexpr uint8_t UNCONFIRMED_EXECUTE_MAX_RESENDS = 1;
/// Re-sends allowed for a CMD_SUBSCRIBE_EVENT the target accepted without a closing reply. The
/// answer carries the reading (an RS100 Solar io answers the subscription with the event's current
/// value), so a lost answer is worth one more copy; the device accepts repeated subscriptions
/// (issue #156). One, as for an EXECUTE: a second silent try is not a one-off. See
/// decisions::retry_after_unconfirmed_accept_is_safe().
static constexpr uint8_t UNCONFIRMED_SUBSCRIBE_MAX_RESENDS = 1;
/// Gap before that re-send, in place of the plan's retry gap (decisions::AttemptPlan::gap_ms). A
/// device that did act on the first copy is often deaf for about a second while its motor or load
/// switches: on a Somfy awning, a re-send 0.77 s after the first copy drew no challenge at all in
/// 3 of 14 cases. With this gap the re-send goes out about 1.3 s after the first copy, and the
/// whole exchange still fits EXCHANGE_TOTAL_BUDGET_MS. The gap is the total wait: the engine sleeps
/// only the part the plan's own gap does not already cover, so a plan without a gap still re-sends
/// at 750 ms.
static constexpr uint32_t UNCONFIRMED_EXECUTE_RESEND_DELAY_MS = 750;
static_assert(UNCONFIRMED_EXECUTE_RESEND_DELAY_MS >= EXCHANGE_RETRY_DELAY_MS,
              "the re-send gap extends the default retry gap, it never shortens it");
 
/// How long evidence that a low-power receiver is moving keeps it believed awake enough to hear the
/// short start preamble first. A moving VELUX solar receiver ignores the 1024-byte wake-up
/// preamble but answers the short one, so a command, STOP or poll sent mid-travel must lead with
/// the short one. Sized above the longest cover travel this project has measured; a first estimate
/// that field logs will correct. Past it the receiver is presumed to have finished and fallen back
/// asleep.
static constexpr uint32_t LOW_POWER_MAX_TRAVEL_MS = 120000;
 
/// Tries for pairing's phase-3 SetConfig1 (0x6F). One: no device on record accepts it (a Somfy
/// Izymo answers `FE 28`, a VELUX SSL solar roller shutter stays silent) and no real controller
/// sends it, so a retry only adds 0.7–0.9 s of blocking and a frame of airtime to every pairing
/// with a silent device. A challenged try still completes its 0x3C/0x3D round within the one try.
static constexpr uint8_t PAIRING_SET_CONFIG1_MAX_TRIES = 1;
 
/// Exchange tries for a status poll the scheduler owns that only looks at a device that is probably
/// still busy: every poll of a tracked device that is not a settling read
/// (decisions::scheduled_poll_read_kind()).
///
/// Such a poll's failure is re-armed by the backoff ladder (STATUS_RETRY_AFTER_FAIL_MS and its
/// successors), so the ladder *is* its retry mechanism; stacking blocking in-exchange tries on top
/// of it buys no freshness and costs blocked loop() time while a device is unresponsive (e.g. an
/// actuator mid-manoeuvre). The progress poll fires seconds after a command, squarely inside the
/// manoeuvre, so keeping it a single try is what lets a STOP a user presses mid-move dispatch
/// promptly, and it spares the air a burst of requests the device cannot answer yet. This is a
/// deliberate airtime choice, not a default. A heater's poll takes this count outside the ladder
/// band too (decisions::scheduled_poll_max_tries()).
static constexpr uint8_t SCHEDULED_POLL_MAX_TRIES = 1;
 
/// Ladder positions at which a scheduler-owned status poll is a settling read again.
///
/// The single try above is right at both ends of the backoff ladder and wrong in the middle. At the
/// first slot after a command the device is still executing the manoeuvre: its silence is expected,
/// retries cannot change that, and blocking loop() would delay a STOP the user presses mid-move.
/// Once a device has missed several slots in a row it is unreachable rather than merely asleep, and
/// retries are just as pointless. In between sits the slot where the manoeuvre has just ended and
/// the device is awake again but duty-cycled: one listen samples its receive window once, while a
/// settling read (decisions::attempt_plan() with decisions::ReadKind::SETTLING) samples it as often
/// as the exchange budget allows, and a success there also clears the failure streak and ends the
/// backoff.
///
/// Counted in consecutive silent failures already recorded when the poll is dispatched, so 0 is the
/// post-command settle poll and 1..3 are the ~5 s / ~15 s / ~30 s ladder slots after it, roughly
/// t+8 s to t+53 s, spanning every cover travel time this project has measured. For a device
/// believed travelling the ladder, and so this band, starts only after its first
/// MOVING_POLL_MISSES_SKIPPED misses, which keep the normal cadence. An auth-shaped streak is
/// excluded entirely: a device that answers with a 0x3C challenge is awake, so extra attempts buy no
/// wake-up, and an auth try is the most expensive shape the engine runs.
///
/// The poll after an accepted STOP and the poll confirming a stop off target are settling reads
/// whatever the counters say: nothing is moving then, and the user's next action waits on exactly
/// that reading.
static constexpr uint8_t SCHEDULED_POLL_RETRY_GRACE_FIRST_FAILURE = 1;
static constexpr uint8_t SCHEDULED_POLL_RETRY_GRACE_LAST_FAILURE = 3;
 
/// Delay before polling after overheard remote traffic: another controller's frame to a registered
/// device, and, by default, a linked-remote press (its `remote_activity_poll_delay_ms` tuning
/// default; ADR 0080).
static constexpr uint32_t REMOTE_ACTIVITY_STATUS_POLL_DELAY_MS = 2000;
 
/// Wall-clock ceiling on one whole exchange, retries included.
///
/// The attempt count times (long preamble + response window + retry gap) is what determines how
/// long a failing command blocks the ESPHome loop, and that blocking also starves the receive path
/// the rest of the exchange depends on. ESPHome itself warns when one operation takes longer than
/// 2550 ms (ADR 0013); this budget must stay under that threshold.
///
/// So the attempt count is a maximum, not a promise: an attempt only starts if it can finish inside
/// the budget. Elapsed time, plus the gap before the attempt, plus the radio's estimate of its
/// transmit time (`RadioDriver::tx_air_time_us()`), plus the window it then listens, plus the final
/// reply window when the target has already challenged in this exchange, must stay below the
/// budget. Counting the window and the final wait keeps a slow listen from running an exchange past
/// the ceiling; counting the transmission keeps a radio with a long wake-up from starting an
/// attempt it cannot finish in time. At the default 400 ms window three attempts with the retry gap
/// still fit (~2.3 s); an exchange the target challenges does not always (ADR 0073). A request to a
/// mains device that makes several attempts with no gap listens EXCHANGE_EARLY_RESPONSE_WAIT_MS on
/// all but the last and fits nine (decisions::attempt_plan(), ADR 0075).
static constexpr uint16_t EXCHANGE_TOTAL_BUDGET_MS = 2500;
 
/// One-way (1W) transmit cadence.
///
/// A 1W command is fire-and-forget: nothing replies, so there is no acknowledgement to retry on
/// and no way to learn a frame was missed. Repetition *is* the reliability mechanism — real
/// remotes send the same frame four times, and a receiving device treats the set as one command
/// because all four carry the same sequence. These are protocol values shared by every 1W
/// transmitter, not radio tuning: they do not vary by chip and must not be moved into a driver or
/// a TuningConfig field.
///
/// Both values are assumed, not measured on this project's hardware: four copies, 40 ms apart.
/// Receive-side timestamps of consecutive copies in a capture log can show a smaller gap (roughly
/// 25 ms), which is not a contradiction: they measure when the receiver heard each copy, not the
/// configured gap. Do not "correct" 40 down to 25 on the strength of them.
///
/// Erring long would in any case be the safe direction — a device needs only one of the four
/// copies to land, so a wider spacing costs nothing and leaves more room on a shared band.
///
/// The resulting burst duration — see ONEWAY_BURST_INTERVAL_MS's own comment and send_burst()'s
/// doxygen (oneway_transmitter.h) for what it decomposes into per power class — is what
/// ONEWAY_QUIET_PERIOD_MS (status_poll_policy.h) is sized against when it holds background polls
/// back during 1W activity.
static constexpr uint8_t ONEWAY_BURST_REPEATS = 4;  ///< Copies of each 1W command sent per press.
/// Gap between those copies. Three gaps between four copies is 3 * 40 = 120 ms of pure *delay*,
/// fixed regardless of the identity's power class. What that adds up to on the wire depends on
/// each copy's own airtime, which is a per-identity, per-copy choice (`OneWayPowerClass`,
/// oneway_controller.h; ADR 0038): a burst with the long preamble on every copy runs well over a
/// second, one with the short preamble on every copy a few hundred ms. send_burst()'s doxygen
/// (oneway_transmitter.h) has both real shapes.
static constexpr uint32_t ONEWAY_BURST_INTERVAL_MS = 40;
 
/// How long a status reply that named the rain sensor as the last commander stays usable as
/// evidence that rain protection is active (see decisions::is_rain_limited(), rule b). It is the
/// memory for recognising a *clamped* position command: while it is fresh, a stopped device that
/// ended up somewhere other than the commanded target is labelled as limited by rain. Too short,
/// and a long shower is no longer recognised for the second and later `open` attempts; too long,
/// and an unrelated clamp (end stop, obstacle, another protection) after the rain has stopped is
/// mislabelled. A first estimate: the window's own rain-limitation timer is not known, so this
/// is 2 hours.
static constexpr uint32_t RAIN_EVIDENCE_HOLD_MS = 2UL * 60UL * 60UL * 1000UL;
 
/// Listen-before-talk (LBT) parameters: conservative defaults that keep the hub from opening an
/// exchange over traffic it can hear.
/// Before transmitting a frame that opens a session (START set), the radio checks
/// that the channel RSSI is below the threshold. If the channel is busy, TX is
/// deferred by LBT_RETRY_DELAY_MS up to LBT_MAX_RETRIES times. A frame without
/// START answers within a session and is sent at once, unchecked.
static constexpr int16_t LBT_RSSI_THRESHOLD_DBM = -90;  ///< Channel-free threshold
static constexpr uint8_t LBT_MAX_RETRIES = 5;           ///< Max carrier-sense attempts before TX anyway
static constexpr uint8_t LBT_RETRY_DELAY_MS = 5;        ///< Backoff between LBT checks
 
/// Canonical defaults for the chip-neutral runtime-tunable pairing/discovery parameters.
///
/// These are the single source of truth for the diagnostics tuning layer: `TuningConfig`
/// initializes its fields from them, and the ESPHome YAML schema falls back to them when a
/// key is omitted. Adjust a value here and both the compiled default and the documented
/// YAML default follow. Chip-specific tuning defaults live in tuning_config.h instead.
/// See @ref hioc_tuning.
static constexpr uint16_t PAIRING_DISCOVERY_WAIT_MS = 2000;  ///< Wait window after sending each discovery command.
static constexpr uint16_t PAIRING_DISCOVERY_INITIAL_DWELL_MS = 300;  ///< Dwell on CH2 before discovery hopping begins.
static constexpr uint8_t PAIRING_KEY_EXCHANGE_RETRIES = 3;  ///< Retries for the authenticated key-exchange phase.
 
/// Default for `TuningConfig::pairing_key_init_delay_ms` — pause after the discover-confirm step
/// (whether it was ACKed, refused, or silent) and before CMD_KEY_INIT (0x31). No capture
/// precedent for 300 ms specifically: real hubs take several seconds longer here, and appear to
/// spend that time re-broadcasting 0x28 to look for more devices, which this project's
/// single-device discovery phase has no equivalent of. 300 ms is the short end: a Somfy Izymo
/// dimmer pairs with both 300 ms and 5000 ms here, so the default keeps pairing fast, and
/// `pairing_key_init_delay_ms` can lengthen it for a device that needs a later 0x31.
static constexpr uint16_t PAIRING_KEY_INIT_DELAY_MS = 300;
 
}  // namespace home_io_control
}  // namespace esphome