Skip to main content

Advanced Technical Guide

Introduction​

This guide provides technical details about advanced AITHA platform features, including RPC commands, telemetry data structures, and device-specific hardware functions for AITHA Things.

IMPORTANT: This guide is intended for tenant administrators and advanced users. Incorrect RPC usage or configuration changes can impact device operation.

Telemetry, Attributes, and RPC​

Telemetry​

Telemetry is time-series data sent from devices to the platform. Each telemetry message typically includes:

  • Timestamp - when the data was collected
  • Key/value pairs - sensor readings and state information
  • Data type - number, string, boolean, or JSON object

Example telemetry message:

{
  "ts": 1704891234567,
  "values": {
    "gps.main.latitude": -34.603722,
    "gps.main.longitude": -58.381592,
    "gps.main.signal": true,
    "connmgr.main.connected": true,
    "accel.accel.accel_x": 0.05,
    "accel.accel.accel_y": -0.02,
    "accel.accel.accel_z": 9.81
  }
}

Attributes​

Attributes are key/value pairs used to store configuration and metadata. There are three main types:

Server attributes​

  • Managed by the platform
  • Not sent to the device
  • Used for platform-side configuration

Example:

{
  "deviceType": "AITHA Core2",
  "firmwareVersion": "1.2.3",
  "lastMaintenance": "2026-01-01"
}

Shared attributes​

  • Set by the platform
  • Sent to the device
  • Used for device configuration

Example:

{
  "telemetryInterval": 60,
  "alarmThreshold": 100,
  "enableGPS": true
}

Client attributes​

  • Set by the device
  • Sent to the platform
  • Used to report device capabilities/state

RPC (Remote Procedure Calls)​

RPC lets you send commands from the platform to a device.

General characteristics:

  • RPC can be one-way (fire-and-forget) or request/response depending on device support.
  • RPC payloads are usually JSON and may contain a method and params.

Example RPC request:

{
  "method": "setValue",
  "params": {
    "key": "relay.relay1.start",
    "value": true
  }
}

Best practices:

  • Test in a staging tenant first.
  • Use the smallest change that solves the problem.
  • Keep a rollback path (known-good shared attributes and alarm thresholds).

Battery Anti-Theft (Advanced)​

This section complements the customer-facing anti-theft guide by clarifying how the platform uses telemetry/attributes.

Common concepts:

  • Motion / impact events are typically derived from accelerometer telemetry.
  • GPS movement detection is often based on a reference location + a distance threshold.

Recommended approach:

  1. Calibrate the device at the installation site (rest position + initial GPS position).
  2. Start with conservative sensitivity thresholds.
  3. Reduce false positives first (tune response), then increase sensitivity.

See: Battery Anti-Theft Dashboard

Firmware Updates (Operational)​

Firmware update workflows vary by tenant and device generation. In general:

  • Confirm the current firmware version via device attributes/telemetry.
  • Update in small batches.
  • Verify connectivity, power, and rollback behavior.

Troubleshooting (Advanced)​

If a device does not respond to RPC:

  1. Verify the device is online.
  2. Verify the RPC method name and parameter keys.
  3. Check device logs/telemetry for rejected commands.
  4. Validate that shared attributes are being applied.

If GPS location looks wrong:

  1. Confirm GPS signal/quality telemetry.
  2. Use WiFi-based location only as a fallback.
  3. Re-set the initial reference location.