4 Commits

Include renames

Author	SHA1	Message	Date
tfaour	ca06f8a8c7	Bump firmware to 1.1.1	2026-07-21 19:39:27 -04:00
tfaour	4f4b2844e6	Firmware: WiFi fast-connect cache (skip scan + DHCP on the next wake) ... After a successful home-WiFi connection, caches BSSID/channel and IP/netmask/gateway/DNS in NVS. The next wake's first connect attempt uses the cached BSSID/channel (skips the all-channel scan) and applies the cached IP directly once the link comes up (skips DHCP) -- a couple fewer seconds of radio-on time per wake, free every wake since nothing about the network actually needs renegotiating most of the time. Falls back to a normal scan+DHCP attempt, and clears the cache, if: the fast attempt itself fails, or it "succeeds" at the WiFi layer but the full fetch cycle then fails anyway (a stale cached IP/DNS/gateway that associates but can't actually reach the server). Also cleared on (re)provisioning and factory reset, since a new network shouldn't try to reuse the old one's cache. The static-IP path needed care to get right without touching untested territory: esp_netif_set_ip_info() only posts IP_EVENT_STA_GOT_IP (what the existing connect-wait logic blocks on) once the netif is already up, which the internal netif-glue's own WIFI_EVENT_STA_CONNECTED handler guarantees by running first (registered earlier, in esp_netif_create_default_wifi_sta()) -- confirmed against ESP-IDF's own static_ip example and esp_netif_handlers.c source rather than assumed. Falling back after a failed fast attempt also needed an explicit esp_netif_dhcpc_start() first: esp_netif_dhcpc_stop() leaves the netif's DHCP status STOPPED rather than resetting to INIT, and left alone the glue would silently re-post the stale cached IP on the next connect instead of actually running DHCP (esp_netif_action_connected). Version bumped to 1.1.0 (real feature, not just a fix); build-verified clean on both board configs (devkit 8MB, XIAO 4MB), no new warnings.	2026-07-20 23:46:57 -04:00
tfaour	ce98c564e8	Bump firmware to 1.0.1	2026-07-20 22:31:07 -04:00
tfaour	a3ab6c5f13	Firmware: OTA client, dual-board build (devkit/XIAO), version reporting, XIAO fixes ... - version.txt + esp_app_desc_t version reporting (X-Frame-Version header); new ota_update.c checks the server's advertised version against the running one and streams+applies an update via esp_https_ota, gated by bootloader rollback (marks the image valid only after a full successful cycle, so a bad update can't brick a wall-mounted frame). - Dual-OTA partition tables: partitions.csv (8MB dev board, 2MB slots) and new partitions_xiao.csv (4MB XIAO, 1.875MB slots -- the dev board's table doesn't fit the XIAO's flash). New build_for_board.sh gives each board its own build dir + generated sdkconfig via SDKCONFIG_DEFAULTS layering, so switching boards never clobbers the other's config. - fetch_photo_info()/fetch_face_labels() were using the short reachability-check timeout even though the manage-menu path can be the first (cold, TLS-handshake-paying) request of a wake cycle -- switched to the longer fetch timeout to stop spurious ESP_ERR_HTTP_CONNECT failures. - XIAO: the RF switch that selects onboard vs. external antenna (GPIO3/14) isn't initialized by plain ESP-IDF the way Seeed's Arduino package does it, leaving WiFi unable to reliably reach the antenna at all -- new board_antenna.c powers the switch and selects the onboard antenna, gated behind FRAME_XIAO_ANTENNA_INIT (on by default in sdkconfig.xiao). Also remaps the EPD DC/RST/BUSY pins, since the dev board's defaults (GPIO9/10/11) aren't physically exposed on the XIAO.	2026-07-20 22:24:15 -04:00