The C6 autodetect picked the CUSTOM profile, but load_board_profile() has
no entry for it, so Rx, Tx and the button stayed at the placeholder 99.
The startup settings load then failed the GPIO check and fell back to an
empty settings object (blank Board Profile, Tx Mode and Bus ID), and every
Application settings save returned 400 until valid pins were sent together
with CUSTOM through the API.
Start a C6 without a profile as CUSTOM with pins for the Seeed XIAO
ESP32-C6 (the c6_xiao_4M build): Rx GPIO20 (D9), Tx GPIO19 (D8), button
GPIO9 (BOOT), no LED, no Dallas sensor.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The TIME_ZONES table predates several tz releases, so 32 zones give the
wrong UTC offset today or within the next year when the device applies
the string with setenv("TZ"): Mexico (no DST since 2022), Egypt (DST
again since 2023), Kazakhstan, Morocco, Paraguay, Iran, Jordan, Syria,
Greenland, and from 1 November 2026 British Columbia, Alberta, the
Northwest Territories and Manitoba (permanent UTC-7, -6, -6 and -5).
Each value is now the POSIX TZ footer of the zone's TZif file in IANA
tz 2026e (PyPI tzdata 2026.5). The keys and their order are unchanged.
"UNK" abbreviations become the numeric <+01> form, which newlib accepts.
America/Godthab and America/Scoresbysund still show summer time from
1 January to the last Sunday in March on newlib: their rule time is
negative (M3.5.0/-1) and newlib's tzset reads it as unsigned. That is
a newlib bug, not a table error.
On boards with PSRAM the MQTT client runs in its own task with a 5120
byte stack. Verifying an EC certificate chain against a CA, such as
Let's Encrypt ISRG Root X2, needs about 6 KB, so the task overflowed
and the board boot looped on every connect.
The espMqttClient constructors now take the stack size, and
startClient() passes EMSESP_MQTT_STACKSIZE_CA (8192) when TLS is on
with a CA, keeping the 5120 default for insecure TLS and plain MQTT.
The client is recreated when that changes. The stack usage log
reports against the size the task was created with.
uploadComplete() leaves _is_firmware / _is_filesystem set after a
successful upload. When the client then closes the connection,
handleDisconnect() sees the flags, treats it as an aborted upload and
sets the status back to NORMAL, cancelling the pending restart. The WebUI
gets away with it because its status poll turns the pending restart into
a requested one first; an upload from curl or a script is accepted
(md5_ok) but the device keeps running the old firmware until something
else restarts it.
Clear the flags once the upload has completed.
proddy