20260911-1933-control-platform-protocol-evaluation Evaluate smart-home protocols for an independent local-first control application platform

status: completed
createdAt: 2026-09-11 19:33
approvedAt: 2026-09-11 19:42
relatedTask: 20260911-1930-control-platform-protocol-evaluation

Context

What the repository says today about external control:

PRODUCT-PLAN.md §1: Wi-Fi is a P03 Hub capability; Air Hub Wi-Fi is a separate expansion. The control-plane doctrine (render only confirmed read-back, ~5 s revert, audit every remote/automation action) applies to Hub UI, Mate and Studio. §3: mutual-TLS MQTT, per-device identity, no inbound ports, cloud-relayed remote access.
product/switch/P05-air-hub.md R0.1: BLE + CAN only, "无强制云或 Wi-Fi"; Matter controller/bridge/Thread border router and Wi-Fi/PoE are separately reviewed expansions (§5). Control loop is Air → Gateway → CAN → Core; Hub/cloud outside the loop.
docs/plan/20260911-1919-air-key-hub-sleep-and-key-scaling.md (draft, not approved): renames the receiver to Air Hub and compares a Linux + dual ESP32-C6 option carrying Wi-Fi/802.15.4/Matter. This is the "Air supports MQTT and Wi-Fi" direction the user refers to; it is still pending.
product/mate/P03-mate-hub.md: local Web UI fully usable with zero internet (FR-08), Wi-Fi AP + STA (FR-07), mTLS MQTT uplink with no inbound WAN/LTE ports (FR-10), Murata Type 2EL / NXP IW612 with 802.15.4 on the custom board.
product/mate/P03-mate-software.md: Mate is the App + cloud + vessel-management product. FR-12 local mode over boat Wi-Fi/BLE; FR-18 helm lock blocks remote switching and can only be lifted on board; FR-20 remote commands carry expiry and idempotency keys; FR-13 automation limited to a whitelisted action enumeration; §6 CRA/RED cybersecurity evidence.
product/index.md: P09 is reserved and unassigned; a new product line needs a directory with index.md, a row in the product table, and a PRODUCT-PLAN section first.
No document evaluates Tuya, Matter, Thread, Zigbee, Z-Wave, HomeKit or Home Assistant as a platform choice; Matter appears only as an unreviewed expansion role, and the research catalogue covers switch/gateway vendors (Shelly, Homey, EnOcean, Flic, YoLink) individually.

Premise correction to record in the document: the base Air receiver specification today has no Wi-Fi or MQTT. Wi-Fi/MQTT come from the P03 Hub, or from the Air Hub direction if plan 1919 is approved. The evaluation therefore treats "the local bridge" abstractly and states which hardware carries which radio.

Proposal

Create product line P09 YBO Control (working name) as a local-first control application platform, and deliver its protocol evaluation:

bizplan/product/control/index.md — directory entry: tier, lifecycle concept, document inventory (breadcrumb label per .vitepress/config.mts).
bizplan/product/control/P09-control-protocol-evaluation.md — the requested Chinese evaluation document:
- §1 Positioning: independent product line; boundary against Mate (cloud, telemetry, vessel management), Hub (Linux bridge, local Web UI), Studio (configuration) and the Air receiver (wireless admission + CAN). Control owns the local control plane and ecosystem exposure; it does not own configuration, cloud storage or CAN admission.
- §2 Requirements: offline-first, security isolation, local veto over remote (the three user requirements) plus derived ones: no CAN access from any third-party layer, per-device identity, confirmed read-back only, audit, no inbound ports, regional radio compliance, RED/CRA evidence.
- §3 Candidate-by-candidate evaluation, each with official source URLs: Tuya (cloud-centric, vendor app/SDK, TuyaOS, local-control status), Matter (fabric/ACL, PASE/CASE, DAC/PAA, DCL, local by design, bridge and controller roles, current version), Thread (802.15.4 transport, border router, not an application layer), Zigbee, Z-Wave / Z-Wave LR, HomeKit (HAP vs Matter path), Home Assistant (open controller, local API conventions), plain MQTT conventions (Homie, HA discovery), KNX, Google Home / Alexa / SmartThings / Mi Home / HiLink as ecosystem endpoints, NMEA 2000 / Modbus as the marine baseline already in the plan.
- §4 Comparison matrix scored against the requirements: offline operation, cloud dependency, identity/crypto model, local-veto feasibility, isolation from the CAN bus, certification cost and gate, regional availability (EU/CN/NA), DIY/integrator ecosystem, hardware fit (nRF54L15, ESP32-C6, IW612), lock-in.
- §5 Recommendation: an owned local control core (YBO local API over mTLS MQTT/WebSocket on the boat LAN, mirroring the existing Mate topic model) with a Matter bridge as the ecosystem exposure layer, Thread only as a transport when the bridge hardware carries 802.15.4, Home Assistant as the first open integration; Tuya not adopted as the core because of cloud dependency and identity ownership. Recorded as a recommendation pending gate approval, not a frozen decision.
- §6 Platform architecture: layers (device → CAN → local bridge → local control API → app / ecosystem bridge → optional cloud relay), the local-veto mechanism (helm lock, remote-disable switch, allow-list of remotely permitted circuits, only lifted on board), and where each security boundary sits.
- §7 Compliance and certification hooks (CSA membership/certification, Thread Group, RED/CRA rows in COMPLIANCE-MATRIX, GDPR when a cloud relay exists).
- §8 Open items and dependencies (bridge hardware from plan 1919, Matter device types for marine circuits, cost, launch geography) with IDs CTL-O-nn.
- Change record.
bizplan/product/index.md — replace the P09 reserved row with the Control directory link.
bizplan/PRODUCT-PLAN.md — add a short P9 section (positioning, tier T2, dependencies, unresolved-decision pointer) between P8 and P11 and a §6 item for the protocol decision.
bizplan/OPEN-QUESTIONS.md — add a P9 section carrying the CTL-O-nn items.
docs/changelog.md — record the new product line and the recommendation.

Not touched: Air/Key/Gateway, Hub, Mate, Studio and X01/X02 documents (owned by task 1916 or out of scope).

Risks

Overlap with Mate: P08 already claims "App + cloud + remote switching". If Control is an independent line, the Mate remote-control path must later be re-scoped to route through Control; this plan only records the boundary and does not edit P08.
Hardware assumption: which device carries Wi-Fi/802.15.4 is undecided (P03 Hub vs Air Hub per plan 1919). The document states both paths and does not assert that a bridge exists.
Protocol facts move quickly (Matter/Thread releases, Tuya local features); every figure is dated and sourced, and unverified items are marked.
Certification cost and membership fees are commercial claims; they are given as published list values with URLs or marked (t).

Scope

Six files: two new (control/index.md, control/P09-control-protocol-evaluation.md), four edited (product/index.md, PRODUCT-PLAN.md, OPEN-QUESTIONS.md, docs/changelog.md). Documentation only; verification by bun run docs:build, git diff --check and a link/anchor check.

Alternatives

Put the evaluation under bizplan/research/ instead of a product directory: lighter, but the user asked for an independent product line, and research documents cannot carry a product's requirements.
Fold the platform into Mate (P08) as a "local mode" chapter: avoids a new product line but contradicts the request and keeps control coupled to the cloud product.
Use P13 instead of the reserved P09: P09 is explicitly reserved for allocation in the product plan; taking it avoids a gap.

Annotations

(none yet)