feat(knx)!: connection task dispatches and pulls; drop Channels (design 054 §4.9)

[lxsaah]

Stage 15 of the design 054 implementation plan (§4.9). User-facing break.

What changes

The KNX connection task now dispatches inbound telegrams through an InboundDispatch and pulls outbound values from OutboundRoutes itself. build() returns that single future, and core runs no pump for KNX any more.

// before
static KNX_CHANNELS: Channels = Channels::new();
KnxConnector::new(binder, delay, "knx://192.168.1.19:3671", &KNX_CHANNELS)
// after
KnxConnector::new(binder, delay, "knx://192.168.1.19:3671")

• connector.rs: Channels, TelegramChannel, CommandChannel, DEFAULT_QUEUE, KnxSink, KnxSource and the N parameter are removed.
• client.rs:
  • TelegramSink::deliver(&str, &[u8]) is implemented for InboundDispatch. The group address is formatted into a stack TopicBuf.
  • CommandSource and the embassy-sync channel glue are removed.
  • The command arm is a poll_fn over poll_stage. It is active only while connected, latches Ready(None), and keeps the arm-order swap.
  • take_staged → GroupWrite::try_new → handle_command. An invalid address or oversize payload is logged and counted as rejected in RouteStats.
• Behaviour while not connected: values produced during connect or backoff wait in their record buffers and are sent after the handshake.
• Callers updated:
  • both KNX demos and the Tokio demo README
  • aimdb-codegen's two KNX templates (flat main.rs and hub)
  • docs/aimdb-usage-guide.md
  • the KNX README

Tests

• Connector: one future, with or without outbound routes. The second-connector rejection is kept.
• Client:
  • Tests now build OutboundRoutes from a test database.
  • New telegrams_round_trip_through_records runs a real KnxConnector against a fake gateway: an inbound telegram reaches its record (with the ACK), and a produced value goes out as a TUNNELING_REQUEST to 1/0/8.
  • New a_value_produced_during_connect_is_sent_after_the_handshake. Mutation check: removing the connected gate makes this test fail.
• topic_provider_tests.rs → topic_writer_tests.rs:
  • Uses TopicWriter with capacity 8. 31/7/255 fits; one byte less overflows.
  • New test: a with_topic_provider link on knx fails the build.
• Removed:
  • shared_channel_on_std.rs, plus the critical-section dev-dependency it needed. Nothing in the crate uses an embassy-sync channel any more.

Verified locally

• cargo test -p aimdb-knx-connector --no-default-features --features std (lib, integration and doc tests)
• KNX clippy legs: std --all-targets, thumbv7em connector and connector,defmt
• KNX doc legs (std, connector) with -D warnings
• make clippy
• cargo fmt --check
• cargo test -p aimdb-codegen
• make codegen-drift. The fixture has no KNX connector, so I also did a one-off run with a KNX variant of the fixture; the generated hub with KnxConnector compiled.
• Builds: knx-connector-demo-common, tokio-knx-connector-demo, and embassy-knx-connector-demo (thumbv8m.main-none-eabihf), plus clippy on the demos.

Left for stage 16

• embassy-sync is now unused but stays in the KNX connector feature until it is dropped together with the old SPI.
• critical-section-std-impl still exists. Its remaining users are the README install snippet, the Tokio demo's Cargo.toml and codegen's generated Cargo.toml. They are harmless and go with that decision.

🤖 Generated with Claude Code