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>
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.