RFC: Deferring USB / Serial Gateway (Legrand 3578 / OpenZigBee) out of v2.0.0 stable

[GreenGrassBlueOcean]

@anotherjulien @fedem95 @Interstellar0verdrive @gdluck @xtimmy86x @mvalla

Context: Why USB / Serial was added in early v2

Back in September, when we started shaping the v2 architecture in #229, @mvalla (creator of openwebnet4j and the OpenHAB OpenWebNet binding) asked whether the new layered design could accommodate USB-based serial interfaces—specifically the Legrand 3578 OpenZigBee USB gateway (<8-digit id>#9 unit addressing).

Because the early v2 prototype still owned its own core/transport/ stream abstraction inside MyHOME, we opened #233 and laid down initial scaffolding: AsyncSerialTransport, a 3578 gateway profile, a serial port picker in config_flow.py, and serial entries in the gateway compatibility tables.

Where things stand nearing v2.0.0 GA

Over the past nine beta releases (v2.0.0b9 → v2.0.0b17), our release bar has become strict and evidence-driven: every supported gateway model and subsystem is backed by real plant bus traces replayed in CI (#466) and/or emulated firmware verdicts (own-firmware-oracle).

Auditing the Legrand 3578 / OpenZigBee path ahead of the v2.0.0 stable cutover turned up two hard realities:

1. Zero hardware testing & zero traces: Nobody has tested a physical Legrand 3578 (or 088328) gateway during the entire v2 beta cycle, we have not a single serial/OpenZigBee trace in #466, and we have no firmware image for the 3578 in own-firmware-oracle.
2. The current serial path in v2-phase1-architecture is broken at runtime: As the protocol engine was extracted into standalone OWNd (OWNGateway) and our entity/address routing hardened around real SCS captures, the untested serial scaffolding drifted out of sync in four concrete places:
   • Unwired runtime session (gateway.py → OWNGateway): config_flow.py (async_step_serial) saves CONF_HOST = "/dev/ttyUSB0", CONF_PORT = 19200, and "transport_type": "serial" without probing the port. MyHOMEGateway.__init__ then passes build_info straight into OWNGateway(build_info), which only opens TCP sockets (*99*0## / *99*1##). AsyncSerialTransport is never instantiated at runtime—selecting USB / Serial Gateway (Legrand 3578) in the UI today actually attempts a TCP connection to hostname "/dev/ttyUSB0" on TCP port 19200.
   • Missing dependency extra (manifest.json): manifest.json pins "OWNd==2.0.0b13" rather than "OWNd[serial]", whereas pyserial-asyncio>=0.6 is an optional extra in OWNd/pyproject.toml.
   • #9 OpenZigBee suffix stripped during discovery (discovery.py): Address.from_message() only preserves F422 bus-routing suffixes (#4#<bus> via message.interface) and drops where_param = ["9"] on <8-digit id>#9 frames. Discovered entities would lose the mandatory #9 ZigBee selector on outbound commands.
   • SCS APL address guards (gateway_sessions.py, validate.py): is_apl_address() strictly enforces 2- or 4-digit SCS A/PL addresses and rejects 8/9-digit OpenZigBee unit IDs, while single-pipe serial frame demultiplexing (no *99* session split) and ZigBee WHO 25 / discovery behaviour remain completely unverified.

Shipping a Config Flow option and documentation table claiming Legrand 3578 USB / OpenZigBee support in v2.0.0 when it fails immediately on setup goes against everything we built in b14–b17 and against our Home Assistant Quality Scale standards.

Proposal for v2.0.0

Rather than trying to blind-patch serial session wiring and <id>#9 addressing right before v2.0.0 GA without a physical device or a single trace to verify against, I propose we cleanly defer USB / OpenZigBee out of v2.0.0:

1. Remove the serial option from the v2.0.0 Config Flow UI (config_flow.py, strings.json, and translations/*.json) so users are not presented with a non-functional setup path.
2. Remove Legrand 3578 from v2.0.0 "Supported Hardware" claims across README.md, docs/, and custom_components/myhome/quality_scale.yaml (moving it to the v2.1+ roadmap / known limitations as unsupported pending hardware verification).
3. Clean up dead transport code in MyHOME: remove the unreferenced custom_components/myhome/core/transport/ copy in MyHOME so transport abstractions live in one place (OWNd), ready to be wired into OWNGateway when real hardware is available.
4. Set clear re-entry criteria for v2.1+: re-introduce USB / OpenZigBee support once we have:
   • at least one active tester (or a bench 3578 / 088328 stick + ZigBee actuator/control) to validate setup end-to-end;
   • real raw serial captures (startup, <8-digit id>#9 lighting/cover commands & echoes, discovery) committed to the CI trace corpus (#466);
   • OWNGateway single-pipe serial session handling and #9 address preservation tested against those captures.

Questions for Maintainers & Community

1. Scope cut for v2.0.0: Do we agree on removing Legrand 3578 / OpenZigBee from the Config Flow UI and supported-hardware docs before cutting stable v2.0.0?
2. Dead core/transport/ cleanup: Any objection to removing the unused custom_components/myhome/core/transport/ package from MyHOME and keeping serial transport work strictly inside OWNd until it is wired end-to-end?
3. Hardware call-out: Does anyone here (@mvalla or others in the community) currently have a physical Legrand 3578 / 088328 OpenZigBee setup they would like to test with for a v2.1+ branch once v2.0.0 lands?

[gdluck]

Agree with removing.

[mvalla]

Agree to move this to 2.1+.
I can confirm I have available a physical Legrand 3578 / 088328 OpenZigBee setup with actuators to test on a 2.1+ branch.
I suggest to take out the already merged PR and move it to the next release.
Also feature request #233 should be re-opened.