lua_runtime now loads the running script from a new LittleFS-backed
drivers::storage (joltwallet/littlefs, the project's fifth external
managed component -- mounts the "storage" partition already reserved
in partitions.csv), falling back to the compiled-in default script
only on first boot. transport exposes GET/POST /api/script -- raw Lua
text, not JSON, since json_helpers.h can't round-trip scripts safely
-- relayed to lua_runtime via the same callback-registration pattern
already used for LedColorHandler, keeping transport free of a
dependency on lua_runtime. lua_runtime_reload() persists and hot-swaps
to a fresh Lua state immediately, no reboot.
Verified on real ESP32-C6 hardware: script loads via kvida-sdk, an
edited script hot-reloads within one tick, and the edit survives a
power cycle (proving LittleFS persistence, not just an in-RAM change).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Sandboxed Lua state (espressif/lua v5.5.0, base/table/string/math only,
no io/os/package/debug) exposes a kvida API table (chip_temperature,
set_led, publish) to a compiled-in default script that reads chip
temperature, maps it to an LED color, and publishes the reading to
Home Assistant. Generalizes transport's publish_chip_temperature()
into publish_value(name, value), the first real use of AGENTS.md's
semantic publish API. Requires -DLUA_32BITS globally since this
toolchain's long long support isn't visible to Lua's default build.
Verified on real ESP32-C6 hardware: no crashes/errors across multiple
serial monitor windows, LED changes color, chip_temperature sensor
appears in Home Assistant via MQTT Discovery.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Both httpd servers now expose JSON endpoints (POST /api/wifi on the
commissioning AP; GET /api/status, GET/POST /api/mqtt on the settings
server) instead of form-urlencoded bodies, with CORS enabled
(http_cors.h) so a separately-hosted web app can call them from a
browser across origins -- not just the on-device pages, which now use
the same endpoints via fetch() too.
No JSON library ships with ESP-IDF v6.0.2 core (verified: no cJSON, no
bundled json component). Given these payloads are tiny, flat,
fixed-shape objects, json_helpers.h hand-rolls minimal strstr-based
extraction rather than adding a 4th external registry dependency
(already have mdns, mqtt, led_strip).
The settings page (mqtt.cpp) changes from server-side snprintf-built
dynamic HTML to a static embedded settings.html that fetches
/api/mqtt on load -- simpler code, and the actual point of the
refactor: the same API a future kvida-sdk client can use.
url_decode.h is removed (no longer needed once request bodies are
JSON instead of form-urlencoded).
Verified end-to-end against real hardware: /api/status, /api/mqtt,
and the CORS preflight for POST /api/mqtt all return correct
responses/headers when queried with a cross-origin Origin header.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Adds espressif/mqtt and mdns as the project's first external managed
component dependencies (neither ships with ESP-IDF core in v6.0.2
anymore). Once Wi-Fi connects, the device advertises itself on the LAN
as kvida-xxxxxx.local and serves a persistent settings page there for
MQTT broker host/port and credentials -- the ongoing config channel
beyond the one-time Wi-Fi captive portal.
mDNS auto-discovery of _mqtt._tcp was the original plan, but verified
against a real Home Assistant OS + Mosquitto add-on that it doesn't
reliably answer PTR queries on the LAN (confirmed with a raw mDNS
query from the host, parsed properly with dnspython after an earlier
naive byte-check gave a false positive). Manual host/port entry is
now the primary path; mDNS discovery still runs as a secondary
fallback attempt, retried every 30s, in case it works on other
networks.
On MQTT_EVENT_CONNECTED, publishes retained HA MQTT Discovery for a
diagnostic "connectivity" binary_sensor (grouped under a Kvida/Xylon
device block) plus an online/offline availability topic driven by
MQTT's own LWT. Verified end-to-end on real hardware: the device
appears in Home Assistant with a "Connected" Connectivity sensor.
Also extracts url_decode() (previously local to commissioning.cpp)
and a new device_id() helper into shared headers, since both
commissioning's Wi-Fi form and the new MQTT settings form need them.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Implements first-boot Wi-Fi setup with no companion app required: a
SoftAP + captive portal (DNS wildcard redirect, DHCP option 114, HTTP
form) lets the user submit Wi-Fi credentials from any browser. On
submit, credentials are saved to NVS and the device switches to STA
mode; on subsequent boots it reconnects automatically via stored
credentials. dns_server.c/.h are vendored from ESP-IDF's official
captive_portal example (Unlicense/CC0).
Requests both link-local and global IPv6 addresses once the STA
connection has an IPv4 address (not on WIFI_EVENT_STA_CONNECTED --
esp_netif_create_ip6_linklocal() reliably fails there because
esp-netif's own handler, which marks the lwIP netif "up", hasn't run
yet due to event-handler registration order). Verified end-to-end on
real ESP32-C6 hardware: SoftAP comes up, credential submission works,
STA reconnects on reboot, and both a link-local and a router-assigned
global IPv6 address are obtained via SLAAC.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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>
