Star

Reference Documentation

Design docs, concept definitions, and references for APIs and CLIs.

Thingsboard Architecture

Thingsboard is designed to distribute workload between multiple nodes without single point of failure. Each Thingsboard node is identical and can handle request from both device and server-side applications.

High level overview

image

Device Connectivity

Thingsboard supports MQTT, CoAP and HTTP protocols for device connectivity. It is possible to plugin support of different protocols or customize existing implementations.

Rule Engine

Thingsboard Rule Engine allows to process messages from devices and trigger configurable processing modules called Plugins.

Core Services

Thingsboard contains set of core services that allow to manage following entities:

Rules and Plugins are able to invoke certain subset of this APIs. For example, rule can create an alarm for certain device.

Server-side API Gateway

Every Thingsboard server provides REST API for registered users. Plugins are able to extend existing REST APIs and also handle websocket connections. For example: - System Telemetry plugin allows to manage attributes and fetch timeseries data using websockets and REST API. - System RPC plugin provides REST API to push custom commands to devices.

Actor model

Actor model enables high performant concurrent processing of messages from devices as long as server-side API calls. Thingsboard uses Akka as an actor system implementation with following actor hierarchies.

image

Brief description of each actors functionality is listed below:

Clustering mode

Service Discovery

Thingsboard uses Zookeeper for service discovery. All Thingsboard nodes are identical and registered as ephemeral in Zookeeper. Apache Curator path cache receipt is used to keep track of all available sibling nodes.

Consistent Hashing

Thingsboard adopts consistent hashing to ensure scalability and availability. Message from Device A that is received on particular node may be forwarded to the other node based on the hash of the device ID. Although this introduce certain networking overhead, it allows to process all messages from particular device using corresponding device actor on a determined server, which introduce following advantages:

The illustration below demonstrates how Thingsboard handles RPC request to Device D1. In this case request arrives to Server A, but D1 is connected using MQTT to Server C. In the worst-case scenario, D1 Device Actor will be located on another server B that obviously does not match either A or C.

image

Security

Transport encryption

As a system administrator you are able to configure Thingsboard to use secure sockets layer for HTTP(s) and MQTT transports. DTLS for CoAP is not supported yet.

Device authentication

Thingsboard is designed to support many types of device credentials. However, current release provides support of token based credentials. Certificate based credentials are coming soon.

Third-party tools

Thingsboard uses following main third-party projects: