Reference · built on requestConnectorSensors, meters & gateways

ThingsBoard

Devices, time-series telemetry, attributes, alarms, and RPC from the ThingsBoard REST API and WebSocket API.

Request accessPricing ↗

About

ThingsBoard is an open-source IoT platform, available as Community Edition, Professional Edition, and ThingsBoard Cloud. Devices connect over MQTT, HTTP, CoAP, or LwM2M and post telemetry and attributes. The REST API, browsable in Swagger UI, exposes tenant devices and assets, time-series values with aggregation over a range, attributes in server, shared, and client scopes, alarms with severity and acknowledgement state, and one-way or two-way RPC to a device. A rule engine passes every message through chains of filter, enrichment, transformation, action, and external nodes. The WebSocket API subscribes to telemetry and alarms as they change.

An operator on Fibric reads telemetry and alarms and proposes the RPC, the shared attribute, or the acknowledgement for your approval.

This is a reference listing. It documents what Fibric would read from ThingsBoard and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Tenant devices and assets through GET /api/tenant/devices and GET /api/tenant/assets, paged with pageSize and page
  • Latest time-series values through GET /api/plugins/telemetry/DEVICE/{deviceId}/values/timeseries with a keys list
  • History between startTs and endTs in epoch milliseconds, with agg of AVG, MIN, MAX, SUM, COUNT, or NONE, an interval, limit, and orderBy
  • Server, shared, and client attributes through /api/plugins/telemetry/DEVICE/{deviceId}/values/attributes and the SERVER_SCOPE, SHARED_SCOPE, and CLIENT_SCOPE paths
  • Alarms with originator, type, severity (CRITICAL, MAJOR, MINOR, WARNING, INDETERMINATE), and active, cleared, and acknowledged state through alarm-controller and POST /api/alarmsQuery/find
  • Live telemetry and alarm updates through WebSocket API subscriptions
  • Persistent RPC status (QUEUED, SENT, DELIVERED, SUCCESSFUL) through GET /api/rpc/persistent/device/{deviceId}

Proposed actions

  • Target capability: propose a one-way command through POST /api/rpc/oneway/{deviceId} with method and params
  • Target capability: propose a two-way command through POST /api/rpc/twoway/{deviceId} and record the device's reply or the HTTP 504
  • Target capability: propose a shared attribute write through POST /api/plugins/telemetry/DEVICE/{deviceId}/attributes/SHARED_SCOPE
  • Target capability: propose acknowledging, clearing, or assigning an alarm through alarm-controller

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Work the alarm flood down to what matters

    Query active alarms by severity and originator through the Alarm Query API. Group repeats from one device, propose which to acknowledge and which need a person, and leave the acknowledgement on the alarm.

    With Alarm Triage, Alarm Flood

  • Send the command that fixes it

    When telemetry crosses a threshold, propose a two-way RPC with the method and params the device handles. You approve; Fibric records the reply or the timeout beside the reading that triggered it.

    With Cold Chain Excursion, Setpoint Drift

  • Catch the device that stopped posting

    Read the latest timestamp per key and listen for the rule engine's INACTIVITY_EVENT message type. Propose the check with the last known values attached.

    With Sensor Health, Data Freshness

Requirements

  • A ThingsBoard tenant on Community Edition, Professional Edition, or ThingsBoard Cloud, reachable over HTTPS
  • A tenant administrator or customer user whose permissions cover the devices, assets, and alarms in scope
  • An API key created under the API Keys settings, or a login for the JWT endpoint
  • Devices whose firmware handles the RPC method names you intend to send
Authentication
An X-Authorization header carrying either an API key (ApiKey, available since ThingsBoard 4.3 and revocable in the UI) or a JWT from POST /api/auth/login that lasts 2.5 hours with a refresh token good for 1 week.

Limits

  • Two-way RPC waits timeout milliseconds, default 10000 and minimum 5000, then returns HTTP 504; a lightweight RPC is lost if the device is offline
  • Persistent RPC survives a disconnect but lives in the database under a configurable TTL and retry count
  • Time-series retention is a deployment setting; PostgreSQL is the default store and Cassandra the option for long retention
  • Rate limits and quotas come from the tenant profile set by the platform administrator, not from a fixed API contract

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request ThingsBoard ↗

Questions and answers

Which authentication should Fibric use?
An API key passed as X-Authorization: ApiKey, available from ThingsBoard 4.3 and revocable in the UI, with no login step. JWT login through POST /api/auth/login also works; access tokens last 2.5 hours and refresh tokens 1 week. If both are sent, the JWT takes priority.
How is historical telemetry read?
Through GET /api/plugins/telemetry/DEVICE/{deviceId}/values/timeseries with keys, startTs and endTs in epoch milliseconds, an agg of AVG, MIN, MAX, SUM, COUNT, or NONE, and an interval or a limit with orderBy. A range is removed through the timeseries/delete path.
What if the device is offline when a command is approved?
A lightweight RPC stays in memory and is lost. With persistent set to true the command is stored with a TTL and retries and delivered when the device reconnects, moving through QUEUED, SENT, DELIVERED, and SUCCESSFUL, states Fibric reads back from the persistent RPC endpoint.
Ask about ThingsBoard

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with ThingsBoard through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy