20260911-1957-control-non-marine-air-positioning Reposition Control as the off-boat Air platform with a control-protocol integration

status: completed
createdAt: 2026-09-11 19:57
approvedAt: 2026-09-11 20:05
relatedTask: 20260911-1954-control-non-marine-air-positioning

Context

The delivered bizplan/product/control/P09-control-protocol-evaluation.md positions Control as a marine local-control platform layered on the P03 Hub or Air Hub, with the helm lock as the veto mechanism and Mate as the cloud sibling.
The user's corrections: Mate is the marine wired solution with internal control; Air can be sold outside boats, so Control complements Mate for those markets; off the boat, Air controls external circuit breakers or relays through the gateway (Air Hub). The executor is therefore a third-party actuator, not a YBO Core, and the "control-protocol integration" is the Air Hub's link to those actuators.
Off the boat there is no P03 Hub, no YBO CAN bus and no Mate. The product is Air + Air Hub + Control app. PRODUCT-PLAN §6 item 11 already keeps the "gateway + switch controls existing third-party actuators" standalone-kit direction; this plan gives it a protocol.
The Air Hub base (STM32G0B1CE + nRF54L15) has no Wi-Fi and no actuator interface other than YBO CAN; the Linux + ESP32-C6 option in plan 20260911-1919 has Wi-Fi/802.15.4. Off the boat, an IP or field-bus interface toward actuators is mandatory.
Actuator-side protocol candidates and the evidence found today:
- Matter (controller role): DIN-rail and flush-mount relays with Matter certification exist — Shelly 1 Gen4 / 1PM Gen4 dry-contact relays (Wi-Fi, Zigbee, Matter — Shelly), Shelly Pro 1PM 40A Gen4 as the first DIN-rail Matter module (matter-smarthome, vendor announcement). The Air Hub would own a fabric and commission actuators; Matter's On/Off attribute subscription gives confirmed read-back. Controller/commissioner software is not vetted the way devices are (NIST analysis); CSA certifies software components including controllers when they run on a supported environment, so whether the Air Hub controller must be certified is an open item.
- Modbus RTU/TCP (master role): industrial DIN relays and motorised MCBs; RS-485 already in the platform (Hub, Key variants). Coil read-back is native.
- Native relay outputs / dry-contact expansion module on the Air Hub: no protocol, lowest integration risk; read-back needs an auxiliary contact or current sense.
- Zigbee coordinator: Tuya-class smart breakers; adds a full stack and a hub-vendor lock; not adopted.
- Vendor local APIs (Shelly RPC/MQTT etc.): per-vendor; only as a stopgap.
Matter's Generic Switch device type (Switch cluster 0x003B — Matter Handbook, esp-matter example) remains the way to expose Air keys to Apple/Google/Alexa/HA so those ecosystems can also bind Air to their own devices; this becomes the secondary path.
Two further user requirements (2026-09-11 20:05): (1) Air must be able to join Matter, HomeKit and Home Assistant OS ecosystems as a wireless switch — so the Generic Switch exposure is a first-class direction, not a secondary path; Apple Home is reached through Matter (HAP not needed, per §4.6), HAOS through Matter or the local MQTT discovery. (2) Control may have its own cloud, and must be able to interoperate with third parties in both directions — Air drives third-party actuators, and third-party ecosystems/clouds drive YBO-controlled circuits — under the same local lock.
The three hard requirements and the per-protocol evaluation do not change; what changes is positioning, host, actuator integration, ecosystem exposure as a first-class direction, the cloud stance, veto naming, recommendation and open items.

Proposal

Revise, not rewrite, the six delivered files:

P09-control-protocol-evaluation.md
- §1: Control = the application and protocol-integration platform for Air sold outside boats; Mate stays the marine wired internal-control solution. Off boat: Air → Air Hub → external breakers/relays; the Air Hub is the actuator controller and the policy point. Boundary table gains an on-boat / off-boat split.
- §3: Air Hub with Wi-Fi/Ethernet and an actuator interface (Matter controller and/or RS-485 and/or relay outputs) is the required host off the boat; P03 Hub path is marine-only.
- New §4.12 Actuator-side integration evaluating the five candidates above against the same requirements (read-back, local, identity, veto, isolation, cost), with the Shelly/DIN-rail evidence and the controller-certification question.
- §5 matrix gains an "actuator control" column; §6 recommendation becomes three equal directions: (A) actuator integration — Matter controller role first (standard, multi-vendor, local, read-back), Modbus RTU master for industrial relays, native relay outputs as the no-protocol floor; (B) ecosystem membership as a wireless switch — Matter bridge exposing each Air key as a Generic Switch endpoint (multi-admin: Apple Home, Google Home, Alexa, HAOS, 米家 at once) and re-exposing the actuators it controls, plus HAOS MQTT discovery; (C) cloud and third-party interoperation — an optional YBO cloud relay (same rules as Mate: mTLS, no inbound ports, command expiry) for the Control app's remote access, and bidirectional third-party interoperation: ecosystems control YBO-driven circuits through (B), Air controls ecosystem devices through the ecosystem's own bindings or through (A); cloud-to-cloud links (Works with Alexa / Google Home / 米家 cloud) recorded as the phase-2 option because they add a cloud hop the local lock must still gate. Air stays BLE; the alternative of making Air a native Matter device is recorded and not adopted.
- §7: "舵位锁" becomes a generic 本地锁; helm lock is its marine instance. Remote off the boat = ecosystem clouds plus the optional YBO cloud; no Mate dependency; every remote path (YBO cloud, ecosystem cloud, cloud-to-cloud) is gated by the same lock and audited with its source.
- §11: new items — actuator list and read-back method per class (breaker vs relay), Air Hub Wi-Fi/RS-485/relay variant as the product, Matter controller certification, consumer-market compliance (RED/CRA; electrical-installation rules for breakers are the actuator vendor's), YBO cloud scope for Control (own tenant vs shared with Mate; EU/CN hosting), cloud-to-cloud integrations and their certification programmes.
- Change record row.
control/index.md: positioning sentence.
product/index.md: P09 row wording.
PRODUCT-PLAN.md: P9 section rows and §6 item 12; T2 entry unchanged.
OPEN-QUESTIONS.md: P9 list extended.
docs/changelog.md: decision entry.

Not touched: Air Switch, Air Hub, Hub, Mate, Studio, X01/X02 (task 1916 owns the Air Hub files; the Air Hub interface requirement is recorded as a dependency in P9 and CTL-O, not written into P05).

Risks

The Air Hub actuator-interface requirement collides with the Air Hub base scope ("无强制云或 Wi-Fi", CAN only); recorded as a dependency on task 1916 / plan 1919, not decided here.
Matter controller on the Air Hub means YBO owns commissioning UX and fabric management — a larger software scope than the bridge; stated with its cost, not hidden.
Whether the controller software needs CSA certification is unresolved; recorded as an open item with the sources found.
Consumer-market examples are illustrative; no market sizing is asserted.

Scope

Six existing files revised; no new files. Documentation only; verification by bun run docs:build, git diff --check, table-shape and rendered-link checks.

Alternatives

Make Air a native Matter device so any ecosystem hub drives the breakers directly, no Air Hub off the boat: breaks the Air BLE/battery baseline and adds per-SKU certification; recorded in §6, not adopted.
Native relay outputs only (no protocol): cheapest, but every actuator becomes YBO-wired and read-back needs auxiliary contacts; kept as the floor, not the direction.

Annotations

(none yet)