The Device Flash tab on the Devices page puts new hardware on the farm without a toolchain: flash the firmware over USB, provision the device’s identity and network settings from the same tab, and — for the fixed relay stations — push over-the-air updates so a relay bolted to a shed never needs the cable again.
Device Flash & Provisioning: role cards for web flashing, the serial provisioning console, and the OTA push section
Flashing and provisioning use Web Serial, so the page needs Chrome or Edge on desktop. Work with one device at a time: flash first, then provision.

​
1 · Flash over USB

The page groups the role cards by board family. Both families run the same firmware and the same radio protocols, so a paddock can mix them freely.

​
ESP32 boards

Plug the board in, pick its role card — Ear tag, Ear tag (BLE-only), Collar or Fixed relay — and choose the USB serial port in the browser dialog. Use Install for a first-time or role-change flash (full erase), or Update to keep the device’s stored provisioning.

​
nRF52840 boards

1

Press Install on the role's card

Ear tag, Ear tag (BLE-only) or Collar. The badge shows the firmware version you’ll get. Pick the XIAO in the browser’s port dialog.
2

Pick the board again if asked

The board restarts into its updater on its own, which shows up as a different USB device. The first time, the card asks you to Select board once more. After that the browser remembers it.
3

Wait for Installed

A progress bar shows the upload (about 15 seconds). The board restarts on the new firmware.
If the page can’t reach the board, double-tap its reset button and press Install again. Then provision it below exactly like an ESP32 board — the serial console is the same.
Each card also offers Download UF2: double-tap reset and copy the file onto the XIAO-BOOT (or XIAO-SENSE) drive that appears. Recent macOS versions often refuse to write to that drive, so use Install on a Mac.
The fixed relay has no nRF52840 build. A relay’s job is to bridge LoRa to WiFi, and the nRF52840 has no WiFi radio. Relays stay on the ESP32-S3 board.

​
2 · Provision

Connect device opens the firmware’s serial console and reads its current settings into the form: device ID, farm, radio parameters, and (for relays) the WiFi, MQTT and OTA endpoints. The page suggests the next free device ID and the active farm automatically; passwords read back masked, so leave them untouched to keep the stored value. Saving writes the settings to the device’s flash and registers it in the farm’s device list (Devices) — including the firmware version the device reports, so the register always shows what each device shipped with.

​
nRF52840 collars: GNSS and NFC

An nRF52840 collar with the L76K GNSS module fitted reports its real position automatically; without one it reports a simulated position near the origin you set. There is nothing to configure. These collars also offer an NFC write PIN field. With an NFC antenna fitted to the board, anyone can tap a phone on the collar to read its settings. Setting a PIN (4–16 characters) additionally lets someone holding the PIN change the device ID, farm, reporting epoch and origin from the phone, by writing a text record such as:
Leave the PIN empty to keep the collar read-only over NFC. Radio and network settings can never be changed over NFC.
For a relay, set the OTA base URL to your ingest host’s OTA endpoint (the ingest API URL plus /ota, e.g. http://ingest-host:8090/ota). That single setting is what lets the relay update itself later.

​
3 · Push an OTA update to the relays

Relay stations sit on WiFi, so they can fetch their own firmware — no ladder, no USB cable. Each relay checks the OTA service shortly after boot and then hourly: when the published version differs from what it is running, it downloads the image, verifies the checksum, installs and reboots. A failed download or checksum leaves the running firmware untouched.
The Push OTA update section: ingest API credentials, publish and trigger buttons, and each relay's running firmware version
The Push OTA update section drives the whole cycle from the browser:
  1. Enter the ingest API URL and key. The browser talks to the ingest service directly, so you need to be on a network that can reach it. The key is the INGEST_API_KEY from the ingest service’s configuration — both values are remembered on this device.
  2. Publish. The button is labelled with the firmware version bundled with the app (e.g. Publish 8d15e01). One click uploads that image to the OTA service; the badge alongside confirms what is now published.
  3. Trigger. Rather than waiting for the hourly check, Trigger update tells every relay on the farm to check right now. Relays re-check within seconds and install if they’re behind.
Below the buttons, each relay is listed with the firmware version it last reported in its status heartbeat, when that heartbeat arrived, and an up to date / behind badge against the published version. After a trigger, a relay typically reboots onto the new version within a minute — watch its badge flip and its heartbeat resume.
Only relay stations update over the air. Ear tags and collars have no WiFi — they’re reflashed over USB with the role cards above.

​
How versions are tracked

The firmware version is stamped into every build from source control, and it surfaces in three places:
  • This page — the bundled version on the Publish button, the published version badge, and each relay’s running version.
  • The device register — recorded when a device is provisioned.
  • Relay heartbeats — every status message a relay publishes carries its version, which also feeds the link-health series in Analytics.