Files
kvida-os/components/transport/README.md
Ronny Eia 524714148b Rebuild firmware scaffold for ESP32-C6/ESP-IDF, replacing NCS/Zephyr
The product pivoted away from a Matter-first nRF54L15 device to an
ESP32-C6/ESP-IDF/C++17 platform where behaviour is defined by a
Blockly-generated Lua program instead of custom firmware (see the
updated kvida meta-repo vision). Removes the west/NCS/Zephyr scaffold
and replaces it with:

- A pinned ESP-IDF v6.0.2 Docker build environment (Espressif's
  official image already bundles the toolchain, unlike NCS/west).
- A layered component structure (drivers -> sensors -> profiles ->
  lua_runtime -> transport) matching the new architecture principles,
  with per-component READMEs describing responsibilities.
- An A/B OTA + LittleFS partition table and a minimal main.cpp.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-08 19:54:25 +02:00

1005 B

transport

Wi-Fi connectivity, MQTT client, and Home Assistant MQTT Discovery payloads. Exposes a semantic publish(topic, value)-style API — application code (including Lua) never depends on MQTT directly, per the transport abstraction principle in AGENTS.md. No dependency on other Kvida components.

Also owns Wi-Fi/MQTT configuration storage for now (not broken out into its own component since AGENTS.md doesn't call out a separate config layer — revisit if this grows).

Future transports (Zigbee, Thread, Matter) should implement the same publish API as alternate backends behind this component's interface, without changing callers.

TODO: built on ESP-IDF's own esp_wifi and mqtt_client (esp-mqtt) components once real code lands — both ship with ESP-IDF, no extra registry dependency needed.

TODO: A/B OTA update-checking belongs here, driven by ESP-IDF's native esp_ota_ops against the ota_0/ota_1 partitions in partitions.csv — no extra dependency needed either.