Total devices
—Registered in your workspace
FIRMWARE MANAGEMENT
Your fleet, at a glance.
Keep your devices in sync and your next release moving.
Seen recently
—Checked in within 24 hours
Firmware releases
—Available in your library
Latest upload
—No release information yet
Recent releases
A home for every firmware version.
Loading releases…
BEFORE THE NEXT UPDATE
Check the path
to your next release.
Find the available update for any device and its current firmware.
Open OTA checkerDevices 0
Firmware versions and the latest device check-ins.
| Device / type | Firmware version | Last seen | Activity | Actions |
|---|---|---|---|---|
| Loading devices… | ||||
Firmware library 0
Versioned binaries, ready for your devices.
| Version / type / file | Size | SHA-256 | Uploaded | Actions |
|---|
Check for an update
Compare a device’s version with your firmware library.
Check result
Ready when you are
Enter a device’s details to see whether a newer firmware version is available.
Connect your ESP32
Register over HTTP, listen over MQTT, and download the matching firmware.
01 · Register / check02 · Subscribe to MQTT03 · Fetch & verify
Use your server’s LAN IP or HTTPS domain. localhost points to the ESP32 itself. This field changes the examples only; configure PUBLIC_BASE_URL on the server for absolute MQTT URLs.
The device must be able to reach both the API and MQTT broker. Publish the API port to your LAN or use a reverse proxy; the development Compose setup binds HTTP to localhost.
01 · Register and check for firmware
GET /api/ota/check
Request URL
Example response · update available
- All three parameters are required. Type must be EMS or BMS; versions use semantic versioning.
- The endpoint registers the serial number and updates its version and last-seen time. Save
device_idand subscribe tomqtt_topic. - Only newer firmware of the same type is returned. With no update,
update_availableis false,firmwareis null, anddownload_urlis omitted. - Existing unknown devices acquire their type on the first typed check. A known serial number cannot switch between EMS and BMS (HTTP 409).
02 · Listen for an update request
MQTT broker: mqtt.elbisolo.id:1883 · configurable on the backend
Subscribe to the exact mqtt_topic returned by your first check. The topic uses the numeric database ID, not the serial number.
Example topic for device ID 42
device/firmware/42Command payload
On check_update, request check_url with your own serial_number, device_type, and currently running firmware_version as URL-encoded query parameters. Resolve a relative URL against your configured API origin.
- Publish uses QoS 1, retained=false. Duplicate delivery is possible; guard against concurrent update attempts.
- Subscribe with QoS 1 on each MQTT reconnect. An offline device may miss a command, so also check on startup or on a schedule.
- The dashboard’s Trigger OTA button calls
POST /api/devices/{id}/trigger. A successful response confirms the broker acknowledgement, not a device update. - Schedule HTTP checks outside your MQTT callback so downloads do not block the MQTT loop.
03 · Download and verify
GET /api/firmwares/{id}/download
When update_available is true, verify firmware.device_type matches your device, resolve download_url against the API origin, and stream the binary. Verify its byte count against file_size and its SHA-256 against sha256 before finalizing the OTA image. The download also sends X-Checksum-SHA256.
After a successful update and reboot, check again with the new running version. This refreshes the version shown in the dashboard.
ESP32 integration flow (pseudocode)
on_boot_or_scheduled_check:
result = GET check_url + encode(serial_number, device_type, running_version)
subscribe(result.mqtt_topic, qos=1)
if result.update_available:
require result.firmware.device_type == my_device_type
stream result.download_url to the inactive OTA partition
require size and SHA256 match result.firmware
finalize update, reboot, and report the new version
on_mqtt_message(topic, payload):
if topic == my_topic and payload.command == "check_update":
schedule one check using my current running versionConfigure an OTA-capable ESP32 partition layout. For deployment, use verified TLS connections and firmware signature verification; a checksum verifies integrity, not publisher identity.
API reference
| Method | Endpoint | Purpose |
|---|---|---|
| GET | /api/devices?device_type=EMS | List devices; type filter is optional |
| GET | /api/firmwares?device_type=BMS | List firmware; type filter is optional |
| POST | /api/firmwares | Multipart: device_type, version, file |
| GET | /api/firmwares/{id}/download | Binary download with range support |
| GET | /api/ota/check | serial_number, device_type, firmware_version |
| POST | /api/devices/{id}/trigger | Publish MQTT check_update; empty body |
| PATCH | /api/devices/{id} | JSON: serial_number, device_type, firmware_version |
| DELETE | /api/devices/{id} | Remove a device record |
| PATCH | /api/firmwares/{id} | JSON: version, device_type; the binary is unchanged |
| DELETE | /api/firmwares/{id} | Remove firmware metadata and its binary |
| GET | /api/config | Public UI configuration; no broker credentials |
Errors return {"error":"message"}: 400 invalid input, 404 missing record, 409 duplicate type/version, duplicate serial number, or device type mismatch, 413 oversized upload, 502 broker failure, 503 MQTT not configured. Unknown firmware remains downloadable for inspection but is never offered by OTA. Edit it to an explicit EMS/BMS type to make it available.