A crash log on a release build couldn't be decoded: the release had only
the .bin files, and the ELF was a 5-day CI artifact of other runs. The
panic in #31 names "ELF file SHA256: f85f409205c11d1b" and no copy of that
file exists.
Each release now gets SomfyController.ino.<chip>.elf.zip, built in the
same job as the .bin it decodes. Beside the ELF is its .sha256: the .bin
embeds that hash, and the panic prints its first digits, so a log shows
which build it came from. The bug report form asks for the whole panic
and says how to decode it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- ADR 0003: the C5 gets its own consequence instead of sitting in the
ADR 0006 amendment. It names the single-slot table, the chip revision
minimum (v1.0, CONFIG_ESP32C5_REV_MIN_FULL=100) and the longer WiFi
scans with 5 GHz.
- platformio.ini: the [esp32] comment names the C5 and C6 as released
debug builds; the C5 comment no longer repeats the C6's.
- Transceiver: the C5 comment says why TX and RX are 4 and 5.
- CI: the addr_fs comment names both partition tables.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The C5 builds like the C6: a debug build with one 3 MB app slot, so it
updates over USB. At CORE_DEBUG_LEVEL=2 its image left 3.4 KB of the
1.5 MB OTA slot, under CI's 8 KB.
- platformio.ini: env esp32c5 (esp32-c5-devkitc-1).
- Chip model "c5", so the updater and releases name its files
SomfyController.*.esp32c5.bin.
- Radio defaults: the framework's SPI pins (CSN 6, MOSI 8, MISO 9,
SCK 10), TX 4, RX 5.
- Web UI: GPIO 0-28, without 13-14 (USB) and 15-22 (flash, PSRAM).
- CI builds and releases it; its bootloader sits at 0x2000.
- ADR 0003: amended.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
With the old API gone, the C3 image is 1,498,512 bytes at
CORE_DEBUG_LEVEL=2 and leaves 72.6 KB of its 1.5 MB OTA slot. It was
76.5 KB over when ESP-IDF 5.5 dropped it.
- platformio.ini: env esp32c3, single core, esp32_3MB.csv, level 2.
- CI builds and releases it with the other chips.
- ADR 0003: amended.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
6.2.0.post1 reports itself as 6.2.0-post.1, which the pinned platform's
">=6.2.0" requirement reads as a pre-release, so every ESP32 build
fails at its first pio run.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- data-src/js: ProtoSchema (schema from the sync, short keys and names,
defaults, cached by hash), ProtoModel (rooms, shades, groups, repeaters,
header and status from the sync and the events) and ProtoClient (/ws,
hello, sync with next, op() as a Promise of its reply, events, feeds,
reconnect). Nothing uses them yet: 2b moves the UI onto them.
- minify.py joins js/*.js and index.js into index.js, and the three CSS
files into app.css, so a page load opens fewer connections.
- test/js: node --test on the three modules, replaying the recorded
fixtures; a CI job runs it and the firmware build waits for it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
IDF 4.4 gets no more security fixes, and the planned RMT radio needs
IDF 5's RMT driver. See docs/adr/0003-pioarduino-idf55.md.
- Every env on one pinned pioarduino release. C6 drops its own
library list and flags but stays a debug build on huge_app.
- Release envs build at CORE_DEBUG_LEVEL=2 so the ESP32 image fits its
1.5 MB OTA slot (17 KB free); debug envs stay at 3.
- Drop the C3: its image is 76.5 KB over the OTA slot on IDF 5.5.
- CI installs pioarduino's Core and checks firmware.bin against the app
partition, failing under 8 KB free. PlatformIO's "Flash:" figure
reads ~45 KB low and passed a C3 image that doesn't fit.
- esp_task_wdt_reconfigure(): on 3.x the core already starts the watchdog
and esp_task_wdt_init() fails, so the C6 build kept the 5 s default.
- An updated firmware is kept only once it has run 60 s with the
network up; a reset before then rolls back to the previous one.
- ETH.begin() takes the 3.x argument order; Arduino 2.x branches gone.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Adds a "Unit tests" job running pio test -e native on ubuntu-latest.
The firmware build matrix waits for it, so a failing test also stops
release uploads.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
