Device Flash 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 page, 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

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.

​
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 (Animals & Devices) — including the firmware version the device reports, so the register always shows what each device shipped with.
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.