Updating the Firmware

Development and production defaults now enable CONFIG_BOOTLOADER_APP_ROLLBACK_ENABLE=y. Older units need a bootloader update over USB before automatic rollback is available; updating only Safi.bin through OTA cannot enable rollback in an existing bootloader.

The database preserves complete 4-, 7-, and 10-byte UIDs. With the new rfid_nvs partition at 0xB40000 in the development layout or 0xB60000 in the production layout (size 0x40000, 256 KB), firmware supports up to 256 registered cards. Devices with the legacy partition table retain the 50-card limit. An application-only OTA update cannot add this partition; the new partition table must be flashed over USB. Back up card bindings before changing flash layout.

Firmware updates install from the dashboard's Update page while the device keeps running. Safi uses an A/B scheme: the new firmware is written to a spare slot, and the device only switches to it after it proves it can boot. A failed update rolls back automatically. You cannot brick the device with a bad update file.

Getting update files

Each release on the GitHub releases page ships a pre-built OTA update image:

• Download latest Safi.bin (direct OTA file)
• Accompanying SHA-256 checksums and first-time USB flashing binaries are listed in the release notes. Only Safi.bin is needed for over-the-air updates.

Method 1: upload from the browser

1. Open Update in the dashboard.
2. Choose the downloaded Safi.bin and click upload.
3. The progress bar runs to 100 percent (the file is written to the spare slot as it uploads), then the device reboots into the new firmware.
4. The dashboard reconnects by itself once the new firmware is running.

Method 2: pull from a URL

Instead of uploading, paste a URL and the device downloads the file itself. This is the method for updating devices you are not sitting next to.

By default, URL pulls require HTTPS with a valid certificate: the Update page's Verify TLS checkbox controls this and stays on unless a development build has explicitly enabled insecure pulls. Production builds can additionally pin the exact server they accept updates from. The full model is in the developer OTA chapter.

What happens during an update

The critical step is the last one: the new firmware must explicitly confirm itself after booting successfully. If it crashes before confirming, or fails to boot at all, the bootloader falls back to the previous firmware on the next restart. Your settings, favorites, cards, and schedules live in a separate storage area and are untouched by updates in either direction.

During the update

• The display shows an update screen with progress and a "do not power off" warning.
• Playback stops for the reboot (a few seconds).
• Losing power mid-download is safe: the device is still running the old firmware, and the half-written spare slot is simply overwritten by the next attempt.

If an update seems to fail

Symptom	Meaning	Action
Progress stops, error shown	Download or verification failed	Check the file or URL; the device is unaffected, retry
Device reboots back to the old version	The new firmware failed its first boot and rolled back	Report it; the device healed itself
Dashboard unreachable after update	The device got a new IP or the browser cached a dead connection	Check the IP on the idle screen, refresh