20260910-0727-air-key-product-specifications Define the Air and Key product specifications

status: completed
createdAt: 2026-09-10 07:27
approvedAt: 2026-09-10 08:23 (user requested supplier-document implementation)
relatedTask: 20260910-0724-air-key-product-specifications

Context

Delivery completed on 2026-09-10: Air supplier requirements and Key supplier requirements, six rewritten specifications/design appendices, governing P5/P6 summaries and affected navigation/integration notices. The following investigation and comparison sections preserve the discussion that preceded implementation; current supplier requirements are in the linked controlled documents. Hardware/transport freeze and physical qualification remain supplier engineering gates, not completed hardware work.

The user requested a review of the current Air and Key products followed by collaborative specification definition. This is a full-tier cross-product discussion. Existing controlled specifications are draft targets, not measured hardware capabilities. The current scope includes three products:

The user requires Europe, China and North America coverage, two-way encrypted Air communication, resistance to copying/replay and a simple product line. The user explicitly excludes CAN encryption: security work should prevent malicious control through Air's wireless interface. Gateway primarily pairs with owned Air devices; battery replacement interval and a four-conductor CAN switch are part of the comparison. Recommend wired Key where a cable can be installed, wireless Air for positions where wiring is difficult, and Gateway as the local Air-to-CAN bridge. Recommend one BLE-only Air platform under the simplicity priority, subject to installed coverage, energy and latency tests; retain Europe/China 433.92 MHz plus North America 902-928 MHz as the coverage-driven alternative. These are product recommendations, not approved transport or hardware selections. Owned Air does not require an 868 MHz variant; 818 MHz is not an active proposal.

Third-party intake and Matter remain possible expansion directions from the earlier discussion, rather than mandatory first-release roles or mandatory radios. Gateway complexity should follow the selected owned Air transport. The clarification does not itself remove the historical standalone N2K/Modbus business proposition; its release priority remains a separate decision. Exact channels, national profiles and RF population remain engineering decisions.

Product	Current draft baseline	Open launch decisions
Air Switch	Air 2 / Air 4; replaceable CR2450; BLE plus a regional sub-GHz profile; indoor IP54; approximately 60 x 60 mm, thickness at most 12 mm; at least two years advertised battery-life target under the declared use profile	Replace the mixed radio lineup with one selected route: recommended BLE-only, or Europe/China 433.92 MHz plus North America 915 MHz; authenticated two-way commands and results; no owned 868 MHz variant proposed
Air Hub	System and standalone modes; YBO CAN FD, NMEA 2000, RS-485 server, Wi-Fi and USB; EU BLE/433/868 radio matrix; 32 switches / 128 keys; future Tag reception; IP54	Prioritize secure owned-Air pairing and local CAN bridge; size hardware for the selected Air transport; stage Matter, third-party intake, Tag, standalone output and PoE separately
Key	Key 4 / Key 8; CAN FD primary, RS-485 variant; 8-32 V; RGB state feedback and dimmable legends; IP67 front / IP54 rear; direct Core control without Hub	Evaluate the requested four functional conductors: V+, GND, CANH, CANL; retain the existing Key family rather than create a second wired family; connector, topology and any expanded keypad count remain open; CAN encryption is not required

Governing sources: product plan, open questions, and each product's linked Level-2 appendix. Supplier research is available through the Air/Key catalog; it is a candidate landscape, not evidence of plug-and-play compatibility.

The separately owned Core proposal changes the output family and keeps bus protocol roles open. Air/Key must not inherit the old Core HD Modbus-master assumption or bind dimming to channels without a declared PWM capability. That task and the active yacht research task remain untouched.

Findings to reconcile before freezing specifications

Air battery feedback is event-driven: Level-2 budgets two 50 ms LED pulses and a brief receive slot. Level-1 separately allows five seconds for confirmed readback. Specify scheduled receive/retry behavior, pending/unknown indication, and energy cost for delayed third-party replies. Continuous status indication is not established by the existing battery budget.
Kinetic switches require a separate capability contract. The PTM 216B manual, sections 5 and 9.2 describes press/release advertising and QR/NFC commissioning with a security key. Do not inherit battery-SKU acknowledgements, LEDs, heartbeat, OTA or the no-key-in-QR assertion without a compatible implementation. The module is still an evaluation option.
Gateway standalone Modbus support currently requires an existing host to poll requests, operate the target and write status back. A server-only gateway cannot directly command another server. This follows Modbus Serial Line V1.02, sections 1.2 and 2.1. Direct actuator support requires an explicitly selected client role and bus ownership policy.
Gateway supply claims conflict: Level-1 allows YBO or N2K supply, but its LEN assumption and Level-2 supply only the N2K transceiver from that port. Freeze whole-device power sources and specify current at the external input voltage, separately from internal 3.3 V rail current.
Gateway deep sleep disables radio reception; Level-2 adds a listening standby target of at most 8 mA at 12 V. State which product modes accept wireless commands, which support Tag monitoring, and how the first press wakes the system.
Key independence from Hub still requires bus power, communication and an operating Core. Define those failure boundaries and preserve the separate physical bypass. The RS-485 variant has different host dependencies.
Key Level-2 uses white-only legend LEDs while Level-1 requires red-only legends in night mode. LED channel allocation, night behavior and the 60 mA at 12 V full-backlight target need one consistent design.
A single gateway covering the vessel is an unvalidated installation assumption. Define the coverage qualification environment and whether multiple receivers, overlap deduplication and regional installations are in scope before claiming whole-vessel coverage.
Matter is an application protocol over IP using Wi-Fi, Ethernet or Thread; BLE can assist commissioning and is also a separate device-integration path. A Matter controller/commissioner, Matter bridge and Thread border router have distinct responsibilities. See the CSA Matter FAQ and Espressif Matter controller documentation. A bridge alone does not provide the requested intake of arbitrary third-party Matter devices.
The existing C5 candidate shares a single 2.4 GHz radio among Wi-Fi, BLE and 802.15.4. Its coexistence documentation identifies unsupported BLE-scanning/Thread-router combinations and recommends separate radios for a Wi-Fi Thread border router. Adding Matter cannot be treated as a software-only change to the existing continuous BLE receiver design.
A frequency label is not a device protocol. Sub-GHz compatibility must identify frequency, modulation, timing, payload format, pairing/security and receive/transmit capability. Multiple supported protocols can still compete for a receiver when their channel/modulation settings differ. Preserve this distinction in capacity and concurrent-operation claims.
The requested powered four-conductor CAN panel already matches Key's role: V+, GND, CANH and CANL. The existing connector sketch separately includes a shield; four functional conductors do not settle connector pole count or shielding. The user does not require CAN encryption.
X01 section 7 currently specifies selected command authentication with a shared bus key, no payload encryption, and unauthenticated STATE/TELEM/HB/DIAG. The clarified scope treats the installed CAN network as trusted and protects Air <-> Gateway wireless traffic. It does not require an X01 encryption or state-authentication revision. Preserve existing CAN authentication; describe encrypted replies as Gateway-authenticated reports of trusted CAN readback, not end-to-end cryptographic proof from Core.

Proposal

Use Key as the preferred wired control where installation permits a cable, Air for cable-free comfort control, and Gateway primarily for secure owned-Air pairing and local CAN translation. Share labels, interaction conventions, configuration concepts and selected mechanical parts where practical; wired and wireless electrical designs need not use one populated PCB. Preserve the multi-protocol idea as a staged expansion without letting it determine every first-release component. Historical standalone output compatibility remains separate from owned-Air pairing.

Freeze the primary local routes as a proposal: Key -> CAN -> Core, and Air -> selected encrypted wireless link -> Gateway -> CAN -> Core. Name the command initiator, target and verified readback source, including operation without Hub or internet. Size the initial gateway for owned Air; treat the expansion matrix below and standalone N2K/Modbus output as separate release choices.
Select the panel family: provisionally retain Air 2 / Air 4 battery models sharing one selected radio platform and Key 4 / Key 8 CAN models. Propose deferring kinetic and outdoor Air variants to keep the initial Air line small and consistently bidirectional. Decide Key 12, RS-485 and Key N2K separately. Verify that each selected SKU has a clear use case and no inherited unsupported feedback or supervision features.
Define user-visible behavior and measurable targets: gestures, labels/backlight, response percentiles, unknown/fault state, battery replacement interval and use profile, offline operation and installed protection. Use the maintenance and power proposal below, including wireless gateway-outage behavior. Verify each target under stated test conditions; separate link ACK from confirmed load state.
Cover Europe, China and North America using the regional matrix below. Evaluate a shared host with BLE connection and scanning capacity, an independent 802.15.4 path if Thread is included, and separate sub-GHz paths only where the selected regional or third-party support requires them. Reuse the PCB and software platform where practical; qualify front-end, filter, antenna and firmware differences per destination. Treat exact MCU/driver choices, enclosure dimensions and supply budgets as candidates until their constraints agree. Verify the selected concurrent protocol combinations, power modes and delayed status delivery through a documented qualification plan, not inferred component capability.
After the user approves concrete choices, reconcile the governing product plan, specifications, appendices and open questions. Update navigation and affected integration summaries only where the selected scope requires them. Verify cross-document consistency, local links and git diff --check; run the existing site build for the resulting controlled-document update.

Wired installation and battery maintenance proposal

Product	Recommended role	Maintenance and feedback
Key, four-conductor CAN	Permanent panels where cable installation is feasible	Bus power, no switch battery replacement, continuous state/backlight within the system power budget; direct Core communication without Air Hub
Air, replaceable battery	Retrofit or movable positions where a cable is impractical	Proposed three-year service-interval design target under a defined normal-use profile, with five years a stretch target; brief event feedback and managed low-power receive behavior
Air Hub	Powered receiver and bridge for owned Air	Local pairing, authenticated command/result routing, battery/availability supervision and configuration retention; a wired-only Key installation does not require it

The four functional conductors are V+ (12/24 V nominal, 8-32 V existing Key draft range), GND, CANH and CANL. CANH/CANL form a twisted pair. Specify cable length, bit rate, branch length, connector, supply voltage drop and bus-end termination together; do not install a termination resistor in every switch. Shield/drain implementation remains a separate EMC decision. The TI CAN termination reference places termination at the two bus ends. Retain CAN FD capability if needed by the approved shared protocol, but do not derive a high bus bit rate from button traffic alone.

Use the existing Key family for the CAN option, without introducing an additional Air-CAN family or automatically adding new key-count SKUs. Wired and wireless panels can share selected faceplate/icon/interaction designs; reuse of every enclosure or PCB is not presumed. Key remains dependent on bus supply and Core, and is not a replacement for the separate physical bypass.

Battery sizing illustration, not measured life: the Energizer CR2450 datasheet rates typical capacity at 620 mAh under its stated 7.5 kilohm, 21 C, 2.0 V cutoff test and lists approximately 1% annual self-discharge. Use a provisional 400 mAh service budget solely for comparison, reserving the difference for cutoff, aging, temperature, pulse limitations and self-discharge; that reserve is not yet validated for any installation.

Illustrative interval	Maximum whole-device average from a 400 mAh budget
2 years	22.83 microamps
3 years	15.22 microamps
5 years	9.13 microamps

Calculation: average microamps = 400,000 / (365 x 24 x years). Include idle current, connection maintenance, authentication, transmit/receive windows, heartbeat, LEDs, retries and a bounded service/update allowance. A 20-microamp device lasts approximately 2.28 years under the same simplified budget. These calculations are budget thresholds, not BLE or sub-GHz performance claims. Neither low-frequency operation nor a low SoC sleep figure establishes longer battery life by itself.

Proposed qualification profile: 30 complete user interactions per day at 25 C, including the specified encrypted confirmation and brief LED indication; declare a representative hold-to-dim mix rather than counting only short presses. Include the selected supervision schedule, measured retry/interference distribution and update allowance. Test edge-of-coverage operation, aged-cell pulse behavior, the declared temperature envelope, repeated long holds and gateway outages separately. Cap failed reconnect/scan energy and report unknown state when the gateway is absent. Normal operation needs no continuously lit backlight or continuously enabled receiver, but the selected receive/connection strategy must still meet confirmed-result timing.

The existing public battery target is at least two years, not a verified result. Do not promote three or five years to a public promise until current traces, temperature/aging data and the required service reserve support it. The Bluetooth LE primer describes the connection-interval/peripheral-latency tradeoff; owned Air and Gateway permit coordinated tuning of that tradeoff. Add replaceable-cell access, low-battery reporting, availability supervision and battery-replacement logging to the service experience, without predicting an exact remaining-days value from voltage alone.

Owned Air switch transport recommendation

Criterion	BLE-only recommendation	Regional sub-GHz alternative
Product family	One 2.4 GHz radio platform across the three markets; Air 2 / Air 4 share firmware and electronics where practical	Two RF variants: 433.92 MHz for Europe/China and 902-928 MHz for North America; one application/security protocol with regional PHY profiles
Two-way security	Authenticated LE Secure Connections and encrypted GATT command/result exchange	Standard authenticated encryption over a qualified bidirectional PHY; pairing, key lifecycle, nonce allocation and transport behavior require explicit implementation
Coverage	Qualify gateway placement by cabin/zone; no single-receiver whole-vessel promise	Candidate when fewer receiver locations or a harder installed link is required; qualify antennas, interference and the return link
Power and interaction	Bond once, then use authenticated encrypted connections; benchmark low-duty maintained connections versus reconnect-on-press before freezing timing and battery targets	Event-driven transmit/receive windows; budget retries, authenticated ACK and delayed actuator readback at both ends
Complexity	Lowest RF-variant count; still requires gateway central-role capacity and regional approvals	More RF/antenna and region testing, plus protocol engineering; avoids an additional BLE product line if chosen as the sole Air control transport

Use the existing two-year battery-life and 150 ms typical / 300 ms P99 response figures only as targets to re-qualify. The old 3 microamp sleep budget with 30-minute broadcast heartbeat cannot be reused for a maintained BLE connection without accounting for connection events. Do not re-pair on every press. If the specification requires one receiver to cover distant cabins through difficult bulkheads, re-evaluate the transport before hardware freeze instead of assuming the BLE simplicity recommendation meets that requirement.

The Bluetooth SIG security guide, sections 4.1-4.3 and 4.21, recommends authenticated encrypted LE connections and non-shared keys. Its Security Manager specification distinguishes authenticated OOB/passkey/numeric-comparison pairing from unauthenticated Just Works. For a displayless switch, evaluate LE Secure Connections OOB with NFC and an authenticated installer flow; a physical pairing button or static printed device ID alone is not cryptographic authentication.

Proposed Air wireless security and confirmation contract

Confirmed boundary: Air <-> Gateway requires bidirectional authenticated encryption; Gateway <-> Core and Key <-> Core use the installed CAN protocol without adding encryption. Gateway terminates wireless security and admits only authenticated, authorized Air commands to CAN. The existing CAN command-authentication behavior is unchanged by this decision.

Authenticate both switch and gateway; use unique device identity and per-bond keys. Do not share a fleet-wide control key or use a MAC address as proof of identity. Require authorization for configuration and control characteristics.
Enroll devices only through an explicitly authorized, time-limited pairing flow with authenticated device onboarding. Normal operation must not accept enrollment merely because a transmitter is nearby. Gateway maps an authorized Air button event to its configured action and rejects unpaired, revoked or unauthorized requests before generating CAN commands; do not expose unrestricted raw CAN injection through the Air interface.
Encrypt and authenticate wireless commands and responses with AES-128-CCM through the selected standard stack or an explicitly reviewed sub-GHz protocol. Separate link receipt from actuator-confirmed state; the success LED requires an authenticated Gateway response tied to the originating command and based on actual readback from the trusted CAN network.
Reject recorded packets, tampered payloads, forged replies and copied public identifiers. Across reconnects and power loss, preserve protocol freshness through fresh authenticated sessions and/or durable nonce/counter allocation as appropriate; never reuse a nonce with the same key. Do not add a second custom cryptographic protocol to BLE merely to restate protections already provided by the selected stack.
Give a logical command a stable transaction identifier across retries and deduplicate execution. A lost ACK must not make a toggle execute twice. For sub-GHz retransmissions, the cryptographic nonce may change while the logical transaction remains the same.
Protect provisioned keys, close unauthenticated debug access in production, require signed updates and prevent security rollback. Define physical re-enrollment, revocation and ownership transfer so a replaced or lost switch can be removed without weakening other devices.
Scope the anti-copy claim to verified replay, impersonation and key-protection properties; do not claim invulnerability to invasive extraction or real-time relay from the presence of encryption alone.

Acceptance checks: capture/replay before and after reboot; tamper with commands and ACKs; spoof a device ID; attempt unapproved pairing and a security downgrade; reject out-of-scope actions and verify rejected wireless requests produce no CAN control frame; drop ACKs and verify one execution; power-cycle during persistent freshness updates where used; revoke a switch and reject subsequent control; verify delayed or absent actuator readback never appears as confirmed success. Measure latency and energy under the selected owned-Air workload, adding third-party or Matter traffic only if that expansion is selected.

If the sub-GHz alternative is selected, use a documented low-latency bidirectional FSK/GFSK design rather than adding multiple PHYs by default; finalize the actual PHY/access method against the selected country rules. Similarity of 868 and 915 MHz may allow some hardware reuse, but does not make existing devices interchangeable. Omitting 868 is a product-scope simplification, with a separate cost to third-party 868 MHz compatibility on the gateway.

Staged gateway intake and integration options

The primary release candidate is owned Air pairing and CAN bridging. The following matrix records earlier expansion options; it is not a requirement to populate all radios or implement every Matter role in the first gateway. Select additional protocols only with a named use case and capacity/power budget.

Capability	Proposed product behavior	Qualification boundary
BLE device intake	Decode selected broadcast profiles and/or connect through documented GATT profiles for switches, remotes and sensors	List exact device profiles, commissioning/key requirements, events and available telemetry; BLE support does not automatically include Bluetooth Mesh
Matter device intake	Controller/commissioner role to enroll supported devices and consume supported switch events or sensor attributes	Freeze device types, clusters, fabric ownership and commissioning flow; Wi-Fi and Thread transport coverage are separate choices
Matter bridge	Optionally expose selected YBO or decoded legacy device functions to an external Matter controller	Separate scope decision; map only supported device types and preserve actual state quality
Matter over Thread	Provide an integrated Thread border router for a self-contained installation, or document the dependency on an existing one	Border routing does not replace a Matter controller; qualify coexistence and credential lifecycle
433.92 MHz	Selectively decode and, where required, transmit supported OOK/ASK/FSK profiles	Exact modulations, packet formats and concurrency combinations remain TBD; a generic learn button cannot establish arbitrary rolling-code or encrypted compatibility
Regional higher sub-GHz band	North American 902-928 MHz profiles; 868 MHz only if a selected third-party gateway compatibility requirement warrants it	No owned Air 868 MHz variant proposed; destination-specific channels, power and access rules; no automatic LoRa/EnOcean/proprietary interoperability
Common local model	Normalize identity, button events, measurements, online status and confirmed actuator state where available	One-way devices cannot inherit Air acknowledgements, return LEDs, periodic heartbeat or firmware-update capabilities

For third-party profiles without authentication, define the supported use cases and provenance explicitly before altering the existing authenticated-Air policy. Do not claim those devices gain authentication merely by passing through the gateway. Capacity must be qualified per protocol and traffic pattern; the old 32-switch / 128-key target is a historical starting point, not a limit or an unlimited-capacity promise for the expanded product.

Compatibility verification should exercise two supported protocols concurrently, duplicate/repeated press handling, sensor updates during network traffic, restart without internet, unavailable/stale state and recovery. Distinguish protocol availability in one firmware from simultaneous RF reception.

Proposed regional RF matrix

The primary gateway radio follows the chosen owned Air transport. Matter and additional third-party radios remain expansion options rather than common mandatory hardware. The owned Air recommendation is BLE-only; the sub-GHz matrix applies to the alternative owned-switch route and/or later qualified third-party intake. It is a product proposal based on official references, not a completed conformity assessment.

Regional profile	Proposed sub-GHz coverage	Conditions and evidence
Europe	433.92 MHz; defer 868 MHz unless a third-party gateway requirement is selected	EU Decision 2025/105 includes 433 MHz SRD allocations with profile-specific power and access conditions. Qualify the switch and gateway return transmissions and aggregate traffic, not just occasional button presses.
China	433.92 MHz; no owned 868 MHz variant	MIIT Announcement 2019 No. 52, attachment I(2), lists 433.05-434.79 MHz at 10 mW ERP and bandwidth at most 400 kHz for general wireless remote control. Qualify both ends and the actual application; arbitrary sensor telemetry must be classified separately. European settings are not automatically a complete Chinese profile.
North America	902-928 MHz primary, commonly labeled 915 MHz; optional 433 MHz compatibility after country/device qualification	U.S. Part 15.247, Canadian RSS-247 and Mexico's IFT-008-2015 identify 902-928 MHz for the respective defined equipment classes. Share hardware only where tests support it; approvals and access rules remain country-specific. U.S. 433 MHz operation exists under restricted Part 15.231 paths and is not the default unrestricted telemetry channel.

China's 470-510 MHz civil-metering entry is application- and location-limited; do not adopt a generic "CN470" boat-control profile simply because it is a familiar LoRa regional label. Its separately listed 868-868.6 MHz remote-control option was evaluated previously but is not required by the simplified owned Air proposal.

Platform proposal: common host, enclosure and protocol adapters; a dedicated 433 MHz path where selected; a 915 MHz RF path for selected North American support; 868 MHz only if separately justified by gateway compatibility; and controlled destination profiles for frequency, power, duty cycle/access method and supported protocols. A shared PCB does not establish a universal antenna/filter match. Any ACK or readback transmission is subject to the selected transmit profile. Existing third-party 868 MHz devices do not become 915 MHz devices by changing the gateway's regional setting.

Official references checked during the discussion:

EU Decision 2025/105, annex SRD table; indexed official text was available, while direct retrieval returned an anti-bot page.
MIIT Announcement 2019 No. 52 and technical attachment, pages 3-5.
U.S. 47 CFR 15.247, 2025 annual edition; current eCFR direct retrieval was unavailable. FCC 2026 notice concerns a requested waiver for 433 MHz tire sensors under 15.231(e), not a general grant of new permission.
Canada RSS-247, issue 4.
Mexico IFT-008-2015 official technical record; follow the current national authority's procedures at release.

Risks

Broad standalone support can expand adapters and qualification work substantially; protocol names alone do not establish compatibility with every vendor.
Changing feedback behavior changes receiver duty cycle and battery life; the present two-year target is not a physical test result.
Outdoor protection, multiple regional radios and multiple panel sizes multiply hardware variants and validation work.
Concurrent Core definition may alter interface dependencies; reconcile confirmed capabilities before changing examples.
Matter fabric management, bridging and Thread routing can materially increase storage, memory and radio scheduling needs; the old gateway BOM, power and capacity targets do not automatically transfer.

Scope

Approved supplier-document delivery

The user requested implementation of optimized Air/Key documentation, specifications, chip selection and a requirements guide for a contract manufacturer and design house. This authorizes documentation implementation following the reviewed proposal; it does not freeze untested hardware or release production. Follow the established Chinese-first convention for bizplan/; tracking stays English. Full-tier scope:

Rewrite the six Air Switch, Air Hub and Key specification/design files as a coherent supplier design-input baseline; retain explicit engineering gates for transport, parts and unmeasured targets.
Add one shared supplier guide with requirement IDs, interface deliverables, component rationale and substitution rules, battery and timing budgets, wireless security, DFM/DFT, provisioning, acceptance tests, responsibilities, quotation structure and release blockers.
Reconcile P5/P6 governing summaries and open questions, product navigation and directly affected Tag/Gateway dependency notices. Preserve separately owned Core work and historical extension scope.
Verify component facts against official sources; check cross-document consistency, internal links and requirement coverage; run git diff --check and the VitePress build. No firmware, hardware fabrication, dependency changes, commit, push or deployment.

Original discussion scope

Potential controlled changes after decisions: bizplan/PRODUCT-PLAN.md P5/P6, bizplan/OPEN-QUESTIONS.md P5/P6, the Air Switch / Air Hub / Key Level-1 and Level-2 pairs, and their indexes. Shared protocol/configuration, Studio, Tag, business, commercial and compliance summaries change only if a selected product decision affects them, including Matter roles and third-party device capability definitions. No component procurement, firmware, physical testing, commit, push or deployment is included in the current discussion.

Alternatives

Option	Benefit	Tradeoff
Wired Key plus BLE Air and a focused Air-to-CAN Gateway (recommended)	One worldwide Air radio platform; no switch-battery replacement at wired positions; gateway follows the primary owned-device role	Requires installed BLE coverage and energy validation; wired positions need power and a qualified CAN topology
Wired Key plus regional 433.92/915 MHz Air and matching Gateway	Retains the wired maintenance benefit while evaluating a lower-frequency wireless link for difficult positions	Two regional RF profiles and more RF qualification; longer service life is not automatic
Expand Gateway with selected third-party protocols and Matter roles later	Preserves the earlier expansion direction without making every radio a launch dependency	Each added device profile, controller/bridge role and standalone output adapter needs explicit scope and validation

Annotations

The user clarified that Gateway primarily pairs with owned Air and asked to consider battery service interval and four-conductor CAN switches. Recommend existing Key for wired installations, Air where wiring is difficult, and a focused Air-to-CAN Gateway. Matter and broader device intake remain staged options from the earlier discussion, not mandatory launch features.
Europe, China and North America coverage is explicitly requested. The latest user priorities are two-way encryption, resistance to copying and low product-line complexity, with BLE versus Europe/China 433.92 MHz plus North America 915 MHz under discussion. Recommend BLE-only owned Air first; keep regional sub-GHz as the coverage-driven alternative. Neither transport is approved yet.
The user proposed omitting 868 MHz. Remove it from the required owned-switch proposal; optional third-party 868 MHz support on Gateway is a separate compatibility decision. Do not justify its removal by claiming frequency proximity makes 868 and 915 devices interchangeable.
Matter intake, optional outward bridging, integrated versus external Thread routing, supported third-party profiles and standalone output compatibility still require concrete product decisions.
Proposed battery goals are a three-year service interval under a declared normal-use profile and a five-year stretch target; existing at-least-two-year public draft target remains unvalidated. The 400 mAh comparison budget is an explicit assumption, not measured usable capacity.
The user explicitly confirmed that CAN does not need encryption and that the primary security objective is preventing malicious wireless control through Air. This supersedes the earlier suggestion to extend the encrypted command/result contract to CAN. Keep existing CAN behavior; enforce authenticated pairing, authorized actions, bidirectional wireless encryption and replay rejection at Air and Gateway. No X01 encryption revision is required by this decision.
The user subsequently authorized specification and supplier-guide implementation. The documentation deliverable is complete; final radio/part/connector choices and physical acceptance remain explicitly open in the product supplier guides O-01 through O-08.

Delivery verification

Delivered one Chinese supplier guide with 29 unique common requirement IDs, ten verification groups, component sources and substitution rules, battery/timing budgets, wireless security, manufacturing/provisioning requirements, responsibilities, quotation structure and D0-D4 handoff gates.
Rewrote Air Switch, Key and Gateway Level-1/Level-2 pairs; aligned PRODUCT-PLAN P5/P6, OPEN-QUESTIONS, product indexes and scoped X01/X02/Tag integration notices. Preserved Core, Sense, Hub and AC product-plan sections and separately owned task files.
Manual review resolved the Key LED-channel undercount, unsupported LED-fault telemetry, false OFF after a readback timeout, gesture/latency ambiguity, wireless-origin preservation, scene-result aggregation and outdated multi-radio gateway assumptions.
Official manufacturer references were checked for the recommended Nordic/ST/NXP/TI parts; no stock, price, certification, lifetime or measured product claim was inferred from chip capability.
git diff --check passed. Changed/new document link and table checks passed; all 29 common requirements map to existing verification groups. VitePress build passed; 179 rendered pages and 5,730 internal links/anchors passed validation, including supplier-guide content checks.
Existing build warnings remain: large JavaScript chunks and two oversized research PDF assets excluded by the established publication limit. No new build failure, executable-code/dependency change, physical hardware test, commit, push or deployment.

Product-directory correction

The user requested product-specific placement rather than shared/. Split the former combined guide into Air/Gateway and Key guides under their respective product directories, retained all 29 original common requirement IDs and corresponding acceptance coverage, and updated product/specification/governance links. The Air guide has 22 applicable requirements; Key has 13, with six common IDs shared between them. The shared directory continues to hold X01/X02 protocol foundations only. This is an organizational correction, not a hardware-scope or approval change.