ThingsBoardLearning

ThingsBoard is an open-source IoT platform that enables rapid development, management, and scaling of IoT projects. Our goal is to provide the out-of-the-box IoT cloud or on-premises solution that will enable server-side infrastructure for your IoT applications.

• scalable: the horizontally scalable platform, built using leading open-source technologies.
• fault-tolerant: no single-point-of-failure, every node in the cluster is identical.
• robust and efficient: a single server node can handle tens or even hundreds of thousands of devices, depending on the use-case. ThingsBoard cluster can handle millions of devices.
• customizable: adding new functionality is easy with customizable widgets and rule engine nodes.
• durable: never lose your data.

0. Architecture

• ThingsBoard transports: provides MQTT, HTTP, CoAP and LwM2M based APIs
• ThingsBoard Core: handling REST API calls and WebSocket subscriptions. storing up to date information about active device sessions and monitoring device connectivity state.
• ThingsBoard Rule Engine
• ThingsBoard Web UI

.1. Monolithic architecture

.2. Microservice architecture

1. Device Connection

2. Key Concepts

.1. Entities and relations

• Tenants - you can treat the tenant as a separate business-entity: it’s an individual or an organization who owns or produce devices and assets; Tenant may have multiple tenant administrator users and millions of customers, devices and assets;
• Customers - the customer is also a separate business-entity: individual or organization who purchase or uses tenant devices and/or assets; Customer may have multiple users and millions of devices and/or assets;
• Users - users are able to browse dashboards and manage entities;
• Devices - basic IoT entities that may produce telemetry data and handle RPC commands. For example, sensors, actuators, switches;
• Assets - abstract IoT entities that may be related to other devices and assets. For example factory, field, vehicle;
• Entity Views - useful if you like to share only part of device or asset data to the customers;
• Alarms - events that identify issues with your assets, devices, or other entities;
• Dashboards - visualization of your IoT data and ability to control particular devices through the user interface;
• Rule Node - processing units for incoming messages, entity lifecycle events, etc;
• Rule Chain - defines the flow of the processing in the Rule Engine. May contain many rule nodes and links to other rule chains;

Each entity supports:

• Attributes - static and semi-static key-value pairs associated with entities. For example serial number, model, firmware version;
• Time-series data - time-series data points available for storage, querying and visualization. For example temperature, humidity, battery level;
• Relations - directed connections to other entities. For example contains, manages, owns, produces.

.2. Tenant Profiles

a System Administrator is able to configure common settings for multiple tenants using Tenant Profiles. Each Tenant has the one and only profile at a single point in time.

• entity limits: to configure a maximum number of entities that each Tenant is able to create.
• API limits: to configure a maximum number of messages, API calls, etc., per month that each Tenant would like to perform.
  • Transport Messages means any message that your device sends to the server. This may be telemetry, attribute update, RPC call, etc.
  • Transport Data Points means a number of the Key-Value pairs that your telemetry or attribute messages contain.

.3. Device Profiles

the Tenant administrator is able to configure common settings for multiple devices using Device Profiles. Each Device has one and only profile at a single point in time.

• the Root Rule Chain processes all incoming messages and events for any device.
• Queue Name:
  • the Main queue will be used to store all incoming messages and events from any device. The transport layer will submit messages to this queue and Rule Engine will poll the queue for new messages.
  • Separation of the queues also allows you to customize different submit and processing strategies. configure it in the thingsboard.yml
• Transport configuration:
  • default transport type: the platform’s default MQTT, HTTP, CoAP and LwM2M APIs
  • MQTT transport type: specify custom MQTT topics filters for time-series data and attribute updates that correspond to the telemetry upload API and attribute update API, respectively
  • CoAP default: supports basic CoAP API same as for Default transport type. However, it is also possible to send data via Protocol Buffers by changing the parameter CoAP device payload to Protobuf.
  • CoAP device type: Efento NB-IoT:
• Alarm rules:
  • Alarm Type - a type of Alarm. Alarm type must be unique within the device profile alarm rules;
  • Clear condition - defines criteria when the Alarm will be cleared;
  • Advanced settings - defines alarm propagation to related assets, customers, tenant, or other entities.
  • Create Conditions - defines the criteria when the Alarm will be created/updated. Severiy, Key Filters, Condition Type, Schedule, Details

.4. Attributes

• server-side attributes:

• shared attributes

The device firmware/application may request the value of the shared attribute(s) or subscribe to the updates of the attribute(s).

• client-side attributes

.5. Time-series Data

• Collect data from devices using various protocols and integrations;
• Store time series data in SQL (PostgreSQL) or NoSQL (Cassandra or Timescale) databases;
• Query the latest time series data values or all data within the specified time range with flexible aggregation;
• Subscribe to data updates using WebSockets for visualization or real-time analytics;
• Visualize time series data using configurable and highly customizable widgets and dashboards;
• Filter and analyze data using flexible Rule Engine;
• Generate alarms based on collected data;
• Forward data to external systems using External Rule Nodes (e.g. Kafka or RabbitMQ Rule Nodes).

ThingsBoard internally treats time-series data as timestamped key-value pairs. We call single timestamped key-value pair a data point.

.6. Remote Command to devices

• Client-side RPC

send the request from the device to the platform and get the response back to the device.

• Irrigation system gets the weather forecast from the online service through the platform.
• Constrained device without system clock requests the current timestamp from the platform.
• Access Control card reader sends the request to third-party security system to make a decision to open the door and log access.

• Server-side RPC

send the request from the platform to the device and optionally get the response back to the platform.

• remote control: reboot, turn the engine on/off, change state of the gpio/actuators, change configuration parameters, etc.

3. Rule Engine

4. Gateway

• MQTT connector to control, configure and collect data from IoT devices that are connected to external MQTT brokers using existing protocols.
• OPC-UA connector to collect data from IoT devices that are connected to OPC-UA servers.
• Modbus connector to collect data from IoT devices that are connected through Modbus protocol.
• BLE connector to collect data from IoT devices that are connected using Bluetooth Low Energy.
• Request connector to collect data from IoT devices that are have HTTP(S) API endpoints.
• CAN connector to collect data from IoT devices that are connected through CAN protocol.
• BACnet connector to collect data from IoT devices that are connected throughBACnet protocol.
• ODBC connector to collect data from ODBC databases.
• REST connector to create endpoints and collect data from incoming HTTP requests.
• SNMP connector to collect data from SNMP managers.
• FTP connector to collect data from FTP server
• Custom connector to collect data from IoT devices that are connected by different protocols. (You can create your own connector for the requires protocol).
• Persistence of collected data to guarantee data delivery in case of network or hardware failures.
• Automatic reconnect to ThingsBoard cluster.
• Simple yet powerful mapping of incoming data and messages to unified format.