Install the scan panel¶

Why a single public binary is safe here

The firmware carries no Wi-Fi credentials, no bridge URL and no bearer token. Everything deployment-specific is set at runtime and stored in the panel's flash. That is what makes a browser installer possible at all — see the firmware README's "Secret-free firmware".

Updates come from your bridge, not from this site

Once the panel knows its Bridge URL, it checks that bridge for newer firmware and reports one as Firmware Update on its own dashboard. There is also a Check for Update button: it asks the bridge to look at GitHub at once, and the panel then reads the answer three times, so it does not have to wait for the next scheduled check.

Usually the result is there within about a minute and a half. It can take up to eleven minutes: the bridge keeps five minutes between two GitHub calls, so a press shortly after another check has to wait that out before the bridge even looks, and the look itself may take another five. Pressing the button again restarts that sequence rather than speeding it up — if nothing has appeared, waiting is faster than pressing.

How often it checks depends on how the last check went. While none has succeeded — a wrong Bridge URL, a bridge that is not up — it asks every minute, so correcting the setting shows a result almost at once. Once one succeeds it settles to every 30 minutes, and it goes back to every minute as soon as a check fails. Note what that does and does not promise: a bridge that goes away is noticed when the next scheduled check runs and times out, so a little over half an hour later. But from that moment the panel retries every minute, so it finds the bridge again within about three minutes of its return. With no Bridge URL set at all it does not check. Each check is one small request to your own bridge; it never reaches GitHub.

The detour through the bridge is not a preference. The panel cannot reach this site, or GitHub, or anything else over HTTPS:

E esp-tls-mbedtls: mbedtls_ssl_setup returned -0x7F00
E http_request.update: Failed to fetch manifest

-0x7F00 is MBEDTLS_ERR_SSL_ALLOC_FAILED. The TLS session cannot be allocated — the panel already carries Wi-Fi, the Bluetooth stack, LVGL and its own dashboard, and mbedTLS wants roughly 32 KB more on top. This is a memory ceiling, not a certificate problem: embedding a root CA would make it worse, because the failure happens before any certificate is examined.

So scan-bridge does that part. It asks GitHub for the latest release every five hours, downloads the firmware, checks it against the release's own SHA256SUMS, and only then offers it at http://<your-bridge>:18080/firmware/manifest.json. A file that fails its checksum is discarded and the bridge keeps serving the release it already had. The manifest never names a build the bridge cannot hand over.

Nothing is required of you afterwards: the mirror is on by default. If your bridge must not talk to the public internet, set firmware.enabled = false under [firmware] in config.toml and use the upload form instead.

What protects an update

The integrity guarantee is the manifest's MD5, and the panel verifies it while writing. A truncated or altered download is discarded and the running firmware survives — an interrupted update cannot brick the panel. Between GitHub and your bridge, the SHA-256 checksums add a second, stronger check the panel is not able to do itself.

Between your bridge and the panel the traffic is plain HTTP on your own network. Someone who can rewrite traffic on that network can serve both a forged manifest and a matching binary, and the MD5 check would pass. That is why the panel reports updates but never installs one by itself: the window that matters is the moment you press install, not on every poll. The full reasoning is in ADR 0024 and ADR 0025 in the repository.