Device Management

RIoT devices are ESP32-based data loggers deployed across industrial environments. The platform provides a centralized fleet registry for monitoring device health, issuing commands, and pushing configuration updates -- all from the web dashboard or API.

Device Registry

The Devices page (/devices) lists every device registered to your tenant. Each row displays the device UID, assigned location and area, firmware version, WiFi signal strength (RSSI), and the time it was last seen.

Use the registry to:

  • Monitor fleet health at a glance. Devices that have not reported in recently are flagged automatically.
  • Filter by location or area to narrow the view to a specific site or zone.
  • Search by device UID to locate a specific unit.

Click any row to open the device detail page.

Registering a Device

Before a device can report data, it must be registered in the platform and provisioned with credentials.

What you need:

FieldDescription
device_uidA unique identifier for the device (e.g., rdl-wh-zone4-temp-01). Must be unique across the tenant.
API keyGenerated during registration. Used by the device to authenticate with the backend.
API secretGenerated alongside the API key. Stored securely on the device.
TenantThe tenant this device belongs to. Required.
Location / AreaOptional. Assign the device to a location and area for organizational grouping.

Process:

  1. Navigate to Devices and select Register Device.
  2. Enter the device_uid and assign the device to a tenant.
  3. Optionally assign a location and area.
  4. The platform generates an API key and API secret. Copy both values -- the secret is shown only once.
  5. Flash the device firmware and write the credentials to the device's SD card config.json.
  6. Power on the device. It will authenticate and begin reporting data.

Device Detail

The detail page (/devices/[id]) provides a complete view of a single device.

  • Status summary -- current firmware version, IP address, RSSI, uptime, and last seen timestamp.
  • Health indicator -- whether the device is reporting normally or has gone silent.
  • Sensor readings -- latest values from all sensors attached to the device.
  • Time-range charts -- historical sensor data with selectable time windows. Zoom into specific periods to investigate anomalies or trends.
  • Command history -- log of commands sent to the device and their outcomes.

Device Status

Devices periodically report status to the backend. The following fields are included in each status update:

FieldTypeDescription
device_idstringThe unique device identifier.
firmware_versionstringCurrently running firmware version (e.g., v1.2.3).
rssiintegerWiFi signal strength in dBm. Values closer to 0 indicate a stronger signal. Typical range: -30 (excellent) to -90 (poor).
battery_voltagefloatSupply voltage in volts. Monitor for power issues.
config_versionintegerThe version of the configuration the device is currently running. Used to determine whether a config update is needed.
statusstringCurrent device state (e.g., running).
ip_addressstringThe device's current local IP address.
uptimeintegerSeconds since last reboot.
last_seentimestampWhen the platform last received data from this device.

Commands

Commands let you control devices remotely. Devices poll the backend for pending commands, so delivery is not instantaneous -- it depends on the device's polling interval.

Available Commands

CommandDescriptionParameters
rebootRestart the device.delay_sec (optional) -- seconds to wait before rebooting.
wipeClear all data from the device's local SD card storage.None.
get_statusRequest an immediate status update from the device.None.
update_configPush a new configuration to the device.Configuration payload (upload intervals, sensor settings, etc.).

Command Lifecycle

  1. Pending -- The command is created and queued in the backend. It waits until the device polls for new commands.
  2. Executed -- The device retrieved and successfully executed the command.
  3. Failed -- The device retrieved the command but execution failed. Check the command history on the device detail page for error details.

Devices poll GET /v1/device/commands on each reporting cycle. Commands remain in pending state until the device picks them up.

Remote Configuration

Device configuration is JSON-based and stored locally on the device's SD card as config.json. The platform supports pushing configuration updates over the air.

How it works:

  1. Update the device's configuration in the dashboard or via the API.
  2. The backend stores the new configuration and increments the config_version.
  3. On its next poll cycle, the device calls GET /v1/device/config and compares the remote config_version to its local version.
  4. If the remote version is newer, the device downloads and applies the new configuration, then writes it to the SD card.
  5. The device reports the updated config_version in its next status update, confirming the change.

Configuration updates propagate on the device's next poll cycle. For immediate application, send a get_status command first to trigger a check, or adjust the device's polling interval.