Azan Flash Server — NVS blob delivery

01 How the update travels

Website this server, port —
Wi-Fi HTTP GET, no TLS needed
ESP32-C5 fetches, streams over SDIO
ESP32-P4 checks version, length, CRC32
NVS year slot / logistics / config

Automatic update is started from the board UI: enable Auto update in Settings → About device. It runs at most once per power cycle, waits for the Wi-Fi/C5 connection, then compares the version it already holds against the version published here. A file is fetched only when the website is strictly newer, so a board running the same or a newer version is left untouched and nothing is written to flash. Otherwise prayer_data.bin, logistics.bin, and mosque_config.bin are downloaded in sequence. The C5 has no access to the P4's flash, so it acts purely as a fetcher; the P4 checks the version, length and CRC32 and stores each file in NVS. If one file fails, the automatic sequence stops for that power cycle. The board is kept awake for the whole sequence. Manual FLW console commands remain available for testing.

02 Point the board at this server

The board needs this machine's address on the local network. Configure the base URL once with the FLW SET command below; it is remembered in NVS. After that, the normal user flow is Settings → About device → Auto update. The switch is off by default and, once enabled, starts no more than one automatic update sequence per power cycle: a version check, then up to three file transfers.

Base URL used by the board

Reading this machine's network addresses…

Console command

FLW SET http://:8080

03 Files on offer

Each card describes one NVS blob the board can fetch. The version.bin entry is an advisory sidecar: it carries only the version stamps that the board compares before deciding whether to transfer anything, and nothing from it is stored in NVS. The three data blobs are fetched in order and stored only after their version, length and CRC checks pass; a blob whose installed version is already equal or newer is skipped. Manual console transfers remain independent and can still be run one at a time when needed.

loading manifest…

04 Automatic or manual update

On the board console

115200 8N1, CR or LF terminated.

FLW STATUS

FLW version

FLW year

FLW logistics

FLW config

Pass an explicit URL to override the base URL for one transfer, e.g. FLW year http://192.168.1.50:8080/prayer_data.bin

What comes back

For automatic update, the board logs one result per file and then reports completion or failure for the sequence. When the website is not newer, nothing is downloaded and the console says so instead.

FLW QUEUED year

wf_last: kind=year status=OK detail=4420 B, slot 1

auto update: already up to date (installed 20260914 >= website 20260914)

FLW STATUS also reports the configured base URL, the installed and website versions, whether a transfer is running, and the result of the last one.

Status values reported by `wf_last`
Value	Meaning
`OK`	Downloaded, length and CRC32 matched, stored in NVS.
`HTTP_FAIL`	C5 could not fetch the URL — wrong address, server not running, or no route.
`TOO_LARGE`	The served body is bigger than the blob can ever be.
`SIZE_MISMATCH`	Body length is not the expected size for that block, or a chunk went missing.
`CRC_MISMATCH`	The bytes arrived but their CRC32 does not match what the C5 announced.
`BAD_REQUEST`	Unknown blob kind or an empty URL on the request side.
`NVS_FAIL`	Blob was valid but the flash write was rejected.
`C5_BUSY`	A transfer was already in progress on the C5.
`NO_WIFI`	Transport is up but the station is not associated.
`NO_RESPONSE`	The C5 never finished — check its serial log.
`RPC_FAIL`	The request could not be handed to the C5 at all.

05 Confirm what is stored

These console commands report what the board currently holds, independently of this server. Compare them against the values in section 03.

DIAG

Full report: year-table year and CRC, both year slots, logistics version, mosque config, today's times, clock, heap, and the last transfer result.

FLV

Year-table CRC only, as CRC . This is the same value the UART tool compares after flashing, so it is the quickest cross-check.

This server is open. Anyone on the same network can read it, and any board that knows the address can pull blobs from it. Run it only on a trusted network, and only while you are updating a board.

06 Which mosque each board uses

Every board scrapes its prayer times from a masjidbox page, and that page differs per installation. Changing it does not require reflashing: once per power cycle the C5 asks this server which page belongs to it, and stores the answer in its own NVS.

Lookup request, sent by the C5 once per boot

GET /api/mosque?mac=aa:bb:cc:dd:ee:ff

The board substitutes its own station MAC address.

Answer

{"mac": "a0:b1:c2:d3:e4:f5", "url": "https://masjidbox.com/gebetszeiten/tewhid", "source": "default", "found": true}

source is table when the MAC is listed below, default when default_url was used, and none when neither is available — then url is empty and the board keeps the URL it already stored.

Assigning a board

Edit web/mosques.json. It is read on every request, so a change takes effect without restarting the server.

{
  "default_url": "https://masjidbox.com/gebetszeiten/tewhid",
  "mosques": {
    "a0:b1:c2:d3:e4:f5": "https://masjidbox.com/gebetszeiten/other"
  }
}

Keys may be written with any separator and any case; the server normalises them to aa:bb:cc:dd:ee:ff before matching.

On the board

The C5 logs every step on its own console under the mosque_url tag: the stored URL, the board's MAC, the request, the answer, and whether anything was written.

mosque URL loaded from NVS: https://…

URL unchanged — nothing written to NVS, no prayer re-fetch

URL changed: "https://…" -> "https://…"

The prayer download is never delayed by this lookup: it starts immediately with whatever URL the board already has, and is repeated only when the answer differs. The address of this server is kept in the board's NVS too, so it can be changed without rebuilding the firmware.