4af0f1b248
Quick end-to-end data-flow proof using only what's on the ESP32-C6- DevKitC-1 itself (no sensors on the bare devkit -- confirmed via research: BOOT button, WS2812 LED, no external sensors): - drivers::chip_temperature_* wraps ESP-IDF's built-in temperature_sensor driver (SoC die temperature). - drivers::rgb_led_* wraps the onboard WS2812 (GPIO8) via the espressif/led_strip managed component (another external registry dependency, like mdns/mqtt). - profiles::ChipTemperatureSensor is the first real implementation of the Sensor interface designed earlier, converting the driver's float reading to the fixed-point convention once at the boundary. - transport/mqtt.cpp publishes chip temperature as an HA "temperature" sensor every 30s, and exposes the LED as an HA "light" entity (rgb_command_topic) -- the first use of MQTT subscribe in this project, not just publish. Added a ChipTemperature SensorChannel (distinct from AmbientTemperature -- different meaning/range) to sensor.h. Verified live: both the chip temperature reading and LED color control work from Home Assistant against the real device. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
kvida-os
Fastvare for Kvida — en konfigurerbar automasjonsplattform (ESP32-C6) fra Xylon.
Visjon og arkitektur er beskrevet i meta-repoet kvida. Dette repoet inneholder kun fastvaren, bygget på ESP-IDF (C++17).
Forutsetninger
- Docker
- WSL2
usbipd-win(for å videresende ESP32-C6 sin USB-seriellport fra Windows til WSL2 ved flashing)
Arkitektur
Lagdelt: drivers -> sensors -> profiles -> lua_runtime -> transport, se komponent-READMEene under components/ og AGENTS.md for detaljer. Bruker konfigurerer enheten visuelt (Blockly -> Lua), ikke ved å skrive/kompilere fastvare.
Quickstart
# Bygg toolchain-imaget (Espressif sitt offisielle ESP-IDF v6.0.2-image)
docker compose build
# Velg target (kjøres én gang; genererer sdkconfig)
docker compose run --rm build idf.py set-target esp32c6
# Bygg fastvaren
docker compose run --rm build idf.py build
# Flash + monitor (krever seriellport videresendt via usbipd-win til WSL2)
docker compose run --rm build idf.py -p <PORT> flash monitor
Prosjektet er pinnet til ESP-IDF v6.0.2 (se docker/Dockerfile).
Testing
Host-baserte enhetstester ligger per komponent, under <component>/test_apps/host/, bygget mot ESP-IDFs linux-target (ikke behov for kort) — se components/sensors/test_apps/host/ for et fungerende eksempel (verifisert i en ren kjøring: bygger, 4 tester passerer).
docker run --rm -v "$(pwd)":/project -w /project/components/sensors/test_apps/host espressif/idf:v6.0.2 \
bash -lc 'idf.py --preview set-target linux && idf.py build && ./build/test_sensor_host.elf'
(Imagets entrypoint aktiverer ESP-IDF-miljøet automatisk — ikke source export.sh selv.)
Merk: under gjentatte, raske kjøringer mot denne
test_apps/*/build-mappen observerte jeg periodiskFileExistsErrorfraidf.py(og enkelte gangerls/rmsom var uenige om mappen fantes) — både viadocker compose runog rendocker run. Mistenkelig likt kjent metadata-cache-lag i WSL2s DrvFs (/mnt/*) under raske create/delete-sykluser på tvers av containergrenser, ikke en feil i selve kodebasen (en ren, isolert kjøring bygger og består alltid). Hvis du støter på dette: slettbuild/sdkconfigi mappen fra Windows/PowerShell-siden og vent et par sekunder før du prøver igjen.
Status
main/ bygger og logger oppstart. components/sensors har et reelt Sensor-grensesnitt (include/sensor.h, Zephyr-inspirert: fetch/get-splitt, fixed-point verdier, finkornet kanal-enum, trigger-API) med et verifisert host-testoppsett. Resten av components/* inneholder foreløpig bare README-er som beskriver ansvar per lag. partitions.csv har et A/B OTA + LittleFS-oppsett med plassholder-størrelser (4MB flash) som bør justeres når ekte flash-størrelse/image-størrelse er kjent.