Star

Installation

Documentation for installation and configuration of ThingsBoard IoT Platform.

Installing ThingsBoard on Windows


IoT PaaS Demo


We recommend to use ThingsBoard Professional Edition Live Demo for the seamless experience and the newest features from the latest source code!

Save time on the installation and configuration with several pre-provisioned devices, dashboards available in the cloud and pre-integrated email server to create new customer accounts and users.

Prerequisites

This guide describes how to install ThingsBoard on a Windows machine. Instructions below are provided for Windows 10/8.1/8/7 32-bit/64-bit. Hardware requirements depend on chosen database and amount of devices connected to the system. To run ThingsBoard and PostgreSQL on a single machine you will need at least 2Gb of RAM. To run ThingsBoard and Cassandra on a single machine you will need at least 8Gb of RAM.

Step 1. Install Java 8 (OpenJDK)

ThingsBoard service is running on Java 8. Follow this instructions to install OpenJDK 8.

You can check the installation using the following command (using Command Prompt):

java -version

Expected command output is:

C:\Users\User>java -version
openjdk version "1.8.0_212"
OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_212-b04)
OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.212-b04, mixed mode)

Step 2. ThingsBoard service installation

Download and extract the package.

https://github.com/thingsboard/thingsboard/releases/download/v3.1.1/thingsboard-windows-3.1.1.zip

Note: We assume you have extracted ThingsBoard package to default location: C:\Program Files (x86)\thingsboard

Step 3. Configure ThingsBoard database

ThingsBoard is able to use SQL or hybrid database approach. See corresponding architecture page for more details.

ThingsBoard team recommends to use PostgreSQL for development and production environments with reasonable load (< 5000 msg/sec). Many cloud vendors support managed PostgreSQL servers which is a cost-effective solution for most of ThingsBoard instances.

PostgreSQL Installation

Download the installation file (PostgreSQL 11.7 or newer releases) here and follow the installation instructions.

During PostgreSQL installation, you will be prompted for superuser (postgres) password. Don’t forget this password. It will be used later. For simplicity, we will substitute it with “postgres”.

Create ThingsBoard Database

Once installed, launch the “pgAdmin” software and login as superuser (postgres). Open your server and create database “thingsboard” with owner “postgres”.

ThingsBoard Configuration

In case you have specified the PostgreSQL superuser password as “postgres”, you can skip this step.

Open the Notepad or other editor as administrator user (right click on the app icon and select “Run as administrator”).
Open the following file for editing (select “All Files” instead of “Text Documents” in file choosing dialog, the encoding is UTF-8):

C:\Program Files (x86)\thingsboard\conf\thingsboard.yml

and locate “# SQL DAO Configuration” block. Don’t forget to replace “postgres” with your real postgres user password:

# SQL DAO Configuration
spring:
  data:
    jpa:
      repositories:
        enabled: "true"
  jpa:
    open-in-view: "false"
    hibernate:
      ddl-auto: "none"
    database-platform: "${SPRING_JPA_DATABASE_PLATFORM:org.hibernate.dialect.PostgreSQLDialect}"
  datasource:
    driverClassName: "${SPRING_DRIVER_CLASS_NAME:org.postgresql.Driver}"
    url: "${SPRING_DATASOURCE_URL:jdbc:postgresql://localhost:5432/thingsboard}"
    username: "${SPRING_DATASOURCE_USERNAME:postgres}"
    password: "${SPRING_DATASOURCE_PASSWORD:YOUR_POSTGRES_PASSWORD_HERE}"
    hikari:
      maximumPoolSize: "${SPRING_DATASOURCE_MAXIMUM_POOL_SIZE:5}"

locate “SQL_POSTGRES_TS_KV_PARTITIONING” parameter in order to override the default value for timestamp key-value storage partitioning size:

    sql:
      postgres:
        # Specify partitioning size for timestamp key-value storage. Example: DAYS, MONTHS, YEARS, INDEFINITE.
        ts_key_value_partitioning: "${SQL_POSTGRES_TS_KV_PARTITIONING:MONTHS}"

ThingsBoard team recommends to use Hybrid database approach if you do plan to have 1M+ devices in production or high data ingestion rate (> 5000 msg/sec). In this case, ThingsBoard will be storing timeseries data in Cassandra while continue to use PostgreSQL for main entities (devices/assets/dashboards/customers).

PostgreSQL Installation

Download the installation file (PostgreSQL 11.7 or newer releases) here and follow the installation instructions.

During PostgreSQL installation, you will be prompted for superuser (postgres) password. Don’t forget this password. It will be used later. For simplicity, we will substitute it with “postgres”.

Create ThingsBoard Database

Once installed, launch the “pgAdmin” software and login as superuser (postgres). Open your server and create database “thingsboard” with owner “postgres”.

Cassandra Installation

Instructions listed below will help you to install Cassandra.

image

  • Clicking next takes you to the end user license agreement:

image

  • The next panel allows you to specify where the software is to be installed:

image

  • Once the installation directory has been set, the installer will ask how you want to handle the service that will be installed:

image

  • The next panel initiates the installation process:

image

image

  • The final panel asks if you would like to register to be updated when new versions of the software become available:

image

  • You can find installed interfaces in “DataStax Community Edition” program group that the installer creates for you:

image

  • The primary interface into Cassandra is the CQL (Cassandra Query Language) shell utility, which can be used to execute CQL commands for the new Cassandra server.
ThingsBoard Configuration

Open the Notepad or other editor as administrator user (right click on the app icon and select “Run as administrator”).
Open the following file for editing (select “All Files” instead of “Text Documents” in file choosing dialog, the encoding is UTF-8):

C:\Program Files (x86)\thingsboard\conf\thingsboard.yml

and locate “# SQL DAO Configuration” block. Don’t forget to replace “postgres” with your real postgres user password:

# SQL DAO Configuration
spring:
  data:
    jpa:
      repositories:
        enabled: "true"
  jpa:
    open-in-view: "false"
    hibernate:
      ddl-auto: "none"
    database-platform: "${SPRING_JPA_DATABASE_PLATFORM:org.hibernate.dialect.PostgreSQLDialect}"
  datasource:
    driverClassName: "${SPRING_DRIVER_CLASS_NAME:org.postgresql.Driver}"
    url: "${SPRING_DATASOURCE_URL:jdbc:postgresql://localhost:5432/thingsboard}"
    username: "${SPRING_DATASOURCE_USERNAME:postgres}"
    password: "${SPRING_DATASOURCE_PASSWORD:YOUR_POSTGRES_PASSWORD_HERE}"
    hikari:
      maximumPoolSize: "${SPRING_DATASOURCE_MAXIMUM_POOL_SIZE:5}"

locate “DATABASE_TS_TYPE” parameter. Replace “sql” with “cassandra”.

    type: "${DATABASE_TS_TYPE:cassandra}" # cassandra OR sql (for hybrid mode, only this value should be cassandra)

You can optionally tune parameters inside “cassandra” configuration block.

# Cassandra driver configuration parameters
cassandra:
  # Thingsboard cluster name
  cluster_name: "${CASSANDRA_CLUSTER_NAME:Thingsboard Cluster}"
  # Thingsboard keyspace name
  keyspace_name: "${CASSANDRA_KEYSPACE_NAME:thingsboard}"
  # Specify node list
  url: "${CASSANDRA_URL:127.0.0.1:9042}"
  # Enable/disable secure connection
  ssl: "${CASSANDRA_USE_SSL:false}"
  # Enable/disable JMX
  jmx: "${CASSANDRA_USE_JMX:true}"
  # Enable/disable metrics collection.
  metrics: "${CASSANDRA_DISABLE_METRICS:true}"
  # NONE SNAPPY LZ4
  compression: "${CASSANDRA_COMPRESSION:none}"
  # Specify cassandra cluster initialization timeout in milliseconds (if no hosts available during startup)
  init_timeout_ms: "${CASSANDRA_CLUSTER_INIT_TIMEOUT_MS:300000}"
  # Specify cassandra claster initialization retry interval (if no hosts available during startup)
  init_retry_interval_ms: "${CASSANDRA_CLUSTER_INIT_RETRY_INTERVAL_MS:3000}"
  max_requests_per_connection_local: "${CASSANDRA_MAX_REQUESTS_PER_CONNECTION_LOCAL:32768}"
  max_requests_per_connection_remote: "${CASSANDRA_MAX_REQUESTS_PER_CONNECTION_REMOTE:32768}"
  # Credential parameters #
  credentials: "${CASSANDRA_USE_CREDENTIALS:false}"
  # Specify your username
  username: "${CASSANDRA_USERNAME:}"
  # Specify your password
  password: "${CASSANDRA_PASSWORD:}"

ThingsBoard team recommends using Timescale database only for companies that already use TimescaleDB in production. In this case, ThingsBoard will be storing timeseries data in TimescaleDB Hypertable while continue to use PostgreSQL for main entities (devices/assets/dashboards/customers).

PostgreSQL Installation

Download the installation file (PostgreSQL 11.7 or newer releases) here and follow the installation instructions.

During PostgreSQL installation, you will be prompted for superuser (postgres) password. Don’t forget this password. It will be used later. For simplicity, we will substitute it with “postgres”.

Create ThingsBoard Database

Once installed, launch the “pgAdmin” software and login as superuser (postgres). Open your server and create database “thingsboard” with owner “postgres”.

TimescaleDB Installation

Please refer to the official TimescaleDB installation page on Windows and follow the instructions in accordance with your installed PostgreSQL version.

ThingsBoard Configuration

Open the Notepad or other editor as administrator user (right click on the app icon and select “Run as administrator”).
Open the following file for editing (select “All Files” instead of “Text Documents” in file choosing dialog, the encoding is UTF-8):

C:\Program Files (x86)\thingsboard\conf\thingsboard.yml

and locate “# SQL DAO Configuration” block. Don’t forget to replace “postgres” with your real postgres user password:

# SQL DAO Configuration
spring:
  data:
    jpa:
      repositories:
        enabled: "true"
  jpa:
    open-in-view: "false"
    hibernate:
      ddl-auto: "none"
    database-platform: "${SPRING_JPA_DATABASE_PLATFORM:org.hibernate.dialect.PostgreSQLDialect}"
  datasource:
    driverClassName: "${SPRING_DRIVER_CLASS_NAME:org.postgresql.Driver}"
    url: "${SPRING_DATASOURCE_URL:jdbc:postgresql://localhost:5432/thingsboard}"
    username: "${SPRING_DATASOURCE_USERNAME:postgres}"
    password: "${SPRING_DATASOURCE_PASSWORD:YOUR_POSTGRES_PASSWORD_HERE}"
    hikari:
      maximumPoolSize: "${SPRING_DATASOURCE_MAXIMUM_POOL_SIZE:5}"

locate “DATABASE_TS_TYPE” parameter. Replace “sql” with “timescale”.

      ts:
        type: "${DATABASE_TS_TYPE:sql}" # cassandra, sql, or timescale (for hybrid mode, DATABASE_TS_TYPE value should be cassandra, or timescale)
    
    # note: timescale works only with postgreSQL database for DATABASE_ENTITIES_TYPE.

You can optionally tune parameters that refer to the Timescale DB configuration: “timescale” configuration block inside “sql” configuration block.

# SQL configuration parameters
sql:
    timescale:
      # Specify Interval size for new data chunks storage.
      chunk_time_interval: "${SQL_TIMESCALE_CHUNK_TIME_INTERVAL:604800000}"

Step 4. Choose ThingsBoard queue service

ThingsBoard is able to use various messaging systems/brokers for storing the messages and communication between ThingsBoard services. How to choose the right queue implementation?

See corresponding architecture page and rule engine page for more details.

In Memory queue is built-in and enabled by default. No additional configuration steps required.

Kafka Installation

Apache Kafka is an open-source stream-processing software platform.

Install Kafka

Use this instruction for installing Kafka in Docker container.

ThingsBoard Configuration

Open the Notepad or other editor as administrator user (right click on the app icon and select “Run as administrator”).
Open the following file for editing (select “All Files” instead of “Text Documents” in file choosing dialog, the encoding is UTF-8):

C:\Program Files (x86)\thingsboard\conf\thingsboard.yml

and locate “queue:” block. Make sure the queue type is “kafka”, and don’t forget to replace “localhost:9092” with your real Kafka bootstrap servers:

queue:
  type: "${TB_QUEUE_TYPE:kafka}"
...
  kafka:
    bootstrap.servers: "${TB_KAFKA_SERVERS:localhost:9092}"
    acks: "${TB_KAFKA_ACKS:all}"
    retries: "${TB_KAFKA_RETRIES:1}"
    batch.size: "${TB_KAFKA_BATCH_SIZE:16384}"
    linger.ms: "${TB_KAFKA_LINGER_MS:1}"
    buffer.memory: "${TB_BUFFER_MEMORY:33554432}"
    replication_factor: "${TB_QUEUE_KAFKA_REPLICATION_FACTOR:1}"

AWS SQS Configuration

To access AWS SQS service, you first need to create an AWS account.

To work with AWS SQS service you will need to create your next credentials using this instruction:

  • Access key ID
  • Secret access key
ThingsBoard Configuration

Open the Notepad or other editor as administrator user (right click on the app icon and select “Run as administrator”).
Open the following file for editing (select “All Files” instead of “Text Documents” in file choosing dialog, the encoding is UTF-8):

C:\Program Files (x86)\thingsboard\conf\thingsboard.yml

and locate “queue:” block. Make sure the queue type is “aws-sqs”, and don’t forget to replace “YOUR_KEY”, “YOUR_SECRET” with your real AWS SQS IAM user credentials and “YOUR_REGION” with your real AWS SQS account region:

queue:
  type: "${TB_QUEUE_TYPE:aws-sqs}"
...
  aws_sqs:
    access_key_id: "${TB_QUEUE_AWS_SQS_ACCESS_KEY_ID:YOUR_KEY}"
    secret_access_key: "${TB_QUEUE_AWS_SQS_SECRET_ACCESS_KEY:YOUR_SECRET}"
    region: "${TB_QUEUE_AWS_SQS_REGION:YOUR_REGION}"

These params affect the number of requests per second from each partitions per each queue.

Number of requests to particular Message Queue calculated based on the formula:

((Number of Rule Engine and Core Queues) * (Number of partitions per Queue) + (Number of transport queues) + (Number of microservices) + (Number of JS executors)) * 1000 / POLL_INTERVAL_MS

For example, number of requests based on default parameters is:

Rule Engine queues:

Main 10 partitions + HighPriority 10 partitions + SequentialByOriginator 10 partitions = 30

Core queue 10 partitions

Transport request Queue + response Queue = 2

Rule Engine Transport notifications Queue + Core Transport notifications Queue = 2

Total = 44

Number of requests per second = 44 * 1000 / 25 = 1760 requests

Based on the use case, you can compromise latency and decrease number of partitions/requests to the queue, if the message load is low.

Sample parameters to fit into 10 requests per second on a “monolith” deployment:

queue:
...
  transport_api:
    request_poll_interval: "${TB_QUEUE_TRANSPORT_REQUEST_POLL_INTERVAL_MS:1000}"
    response_poll_interval: "${TB_QUEUE_TRANSPORT_RESPONSE_POLL_INTERVAL_MS:1000}"
...
  core:
    poll-interval: "${TB_QUEUE_CORE_POLL_INTERVAL_MS:1000}"
    partitions: "${TB_QUEUE_CORE_PARTITIONS:2}"
...
  js:
    response_poll_interval: "${REMOTE_JS_RESPONSE_POLL_INTERVAL_MS:1000}"
...
  rule-engine:
    poll-interval: "${TB_QUEUE_RULE_ENGINE_POLL_INTERVAL_MS:1000}"
...
    queues:
        poll-interval: "${TB_QUEUE_RE_MAIN_POLL_INTERVAL_MS:1000}"
        partitions: "${TB_QUEUE_RE_MAIN_PARTITIONS:2}"
...
        poll-interval: "${TB_QUEUE_RE_HP_POLL_INTERVAL_MS:1000}"
        partitions: "${TB_QUEUE_RE_HP_PARTITIONS:1}"
...
        poll-interval: "${TB_QUEUE_RE_SQ_POLL_INTERVAL_MS:1000}"
        partitions: "${TB_QUEUE_RE_SQ_PARTITIONS:1}"
...
  transport:
    poll_interval: "${TB_QUEUE_TRANSPORT_NOTIFICATIONS_POLL_INTERVAL_MS:1000}"

Google Pub/Sub Configuration

To access Pub/Sub service, you first need to create an Google cloud account.

To work with Pub/Sub service you will need to create a project using this instruction.

Create service account credentials with the role “Editor” or “Admin” using this instruction, and save json file with your service account credentials step 9 here.

ThingsBoard Configuration

Open the Notepad or other editor as administrator user (right click on the app icon and select “Run as administrator”).
Open the following file for editing (select “All Files” instead of “Text Documents” in file choosing dialog, the encoding is UTF-8):

C:\Program Files (x86)\thingsboard\conf\thingsboard.yml

and locate “queue:” block. Make sure the queue type is “pubsub”, and don’t forget to replace “YOUR_PROJECT_ID”, “YOUR_SERVICE_ACCOUNT” with your real Pub/Sub project id, and service account (it is whole data from json file):

queue:
  type: "${TB_QUEUE_TYPE:pubsub}"
...
  pubsub:
    project_id: "${TB_QUEUE_PUBSUB_PROJECT_ID:YOUR_PROJECT_ID}"
    service_account: "${TB_QUEUE_PUBSUB_SERVICE_ACCOUNT:YOUR_SERVICE_ACCOUNT}"
    max_msg_size: "${TB_QUEUE_PUBSUB_MAX_MSG_SIZE:1048576}" #in bytes
    max_messages: "${TB_QUEUE_PUBSUB_MAX_MESSAGES:1000}"

These params affect the number of requests per second from each partitions per each queue.

Number of requests to particular Message Queue calculated based on the formula:

((Number of Rule Engine and Core Queues) * (Number of partitions per Queue) + (Number of transport queues) + (Number of microservices) + (Number of JS executors)) * 1000 / POLL_INTERVAL_MS

For example, number of requests based on default parameters is:

Rule Engine queues:

Main 10 partitions + HighPriority 10 partitions + SequentialByOriginator 10 partitions = 30

Core queue 10 partitions

Transport request Queue + response Queue = 2

Rule Engine Transport notifications Queue + Core Transport notifications Queue = 2

Total = 44

Number of requests per second = 44 * 1000 / 25 = 1760 requests

Based on the use case, you can compromise latency and decrease number of partitions/requests to the queue, if the message load is low.

Sample parameters to fit into 10 requests per second on a “monolith” deployment:

queue:
...
  transport_api:
    request_poll_interval: "${TB_QUEUE_TRANSPORT_REQUEST_POLL_INTERVAL_MS:1000}"
    response_poll_interval: "${TB_QUEUE_TRANSPORT_RESPONSE_POLL_INTERVAL_MS:1000}"
...
  core:
    poll-interval: "${TB_QUEUE_CORE_POLL_INTERVAL_MS:1000}"
    partitions: "${TB_QUEUE_CORE_PARTITIONS:2}"
...
  js:
    response_poll_interval: "${REMOTE_JS_RESPONSE_POLL_INTERVAL_MS:1000}"
...
  rule-engine:
    poll-interval: "${TB_QUEUE_RULE_ENGINE_POLL_INTERVAL_MS:1000}"
...
    queues:
        poll-interval: "${TB_QUEUE_RE_MAIN_POLL_INTERVAL_MS:1000}"
        partitions: "${TB_QUEUE_RE_MAIN_PARTITIONS:2}"
...
        poll-interval: "${TB_QUEUE_RE_HP_POLL_INTERVAL_MS:1000}"
        partitions: "${TB_QUEUE_RE_HP_PARTITIONS:1}"
...
        poll-interval: "${TB_QUEUE_RE_SQ_POLL_INTERVAL_MS:1000}"
        partitions: "${TB_QUEUE_RE_SQ_PARTITIONS:1}"
...
  transport:
    poll_interval: "${TB_QUEUE_TRANSPORT_NOTIFICATIONS_POLL_INTERVAL_MS:1000}"

Azure Service Bus Configuration

To access Azure Service Bus, you first need to create an Azure account.

To work with Service Bus service you will need to create a Service Bus Namespace using this instruction.

Create Shared Access Signature using this instruction.

ThingsBoard Configuration

Open the Notepad or other editor as administrator user (right click on the app icon and select “Run as administrator”).
Open the following file for editing (select “All Files” instead of “Text Documents” in file choosing dialog, the encoding is UTF-8):

C:\Program Files (x86)\thingsboard\conf\thingsboard.yml

and locate “queue:” block. Make sure the queue type is “service-bus”, and don’t forget to replace “YOUR_NAMESPACE_NAME” with your real Service Bus namespace name, and “YOUR_SAS_KEY_NAME”, “YOUR_SAS_KEY” with your real Service Bus credentials. Note: “YOUR_SAS_KEY_NAME” it is “SAS Policy”, “YOUR_SAS_KEY” it is “SAS Policy Primary Key”:

queue:
  type: "${TB_QUEUE_TYPE:service-bus}"
...
  service_bus:
    namespace_name: "${TB_QUEUE_SERVICE_BUS_NAMESPACE_NAME:YOUR_NAMESPACE_NAME}"
    sas_key_name: "${TB_QUEUE_SERVICE_BUS_SAS_KEY_NAME:YOUR_SAS_KEY_NAME}"
    sas_key: "${TB_QUEUE_SERVICE_BUS_SAS_KEY:YOUR_SAS_KEY}"
    max_messages: "${TB_QUEUE_SERVICE_BUS_MAX_MESSAGES:1000}"

These params affect the number of requests per second from each partitions per each queue.

Number of requests to particular Message Queue calculated based on the formula:

((Number of Rule Engine and Core Queues) * (Number of partitions per Queue) + (Number of transport queues) + (Number of microservices) + (Number of JS executors)) * 1000 / POLL_INTERVAL_MS

For example, number of requests based on default parameters is:

Rule Engine queues:

Main 10 partitions + HighPriority 10 partitions + SequentialByOriginator 10 partitions = 30

Core queue 10 partitions

Transport request Queue + response Queue = 2

Rule Engine Transport notifications Queue + Core Transport notifications Queue = 2

Total = 44

Number of requests per second = 44 * 1000 / 25 = 1760 requests

Based on the use case, you can compromise latency and decrease number of partitions/requests to the queue, if the message load is low.

Sample parameters to fit into 10 requests per second on a “monolith” deployment:

queue:
...
  transport_api:
    request_poll_interval: "${TB_QUEUE_TRANSPORT_REQUEST_POLL_INTERVAL_MS:1000}"
    response_poll_interval: "${TB_QUEUE_TRANSPORT_RESPONSE_POLL_INTERVAL_MS:1000}"
...
  core:
    poll-interval: "${TB_QUEUE_CORE_POLL_INTERVAL_MS:1000}"
    partitions: "${TB_QUEUE_CORE_PARTITIONS:2}"
...
  js:
    response_poll_interval: "${REMOTE_JS_RESPONSE_POLL_INTERVAL_MS:1000}"
...
  rule-engine:
    poll-interval: "${TB_QUEUE_RULE_ENGINE_POLL_INTERVAL_MS:1000}"
...
    queues:
        poll-interval: "${TB_QUEUE_RE_MAIN_POLL_INTERVAL_MS:1000}"
        partitions: "${TB_QUEUE_RE_MAIN_PARTITIONS:2}"
...
        poll-interval: "${TB_QUEUE_RE_HP_POLL_INTERVAL_MS:1000}"
        partitions: "${TB_QUEUE_RE_HP_PARTITIONS:1}"
...
        poll-interval: "${TB_QUEUE_RE_SQ_POLL_INTERVAL_MS:1000}"
        partitions: "${TB_QUEUE_RE_SQ_PARTITIONS:1}"
...
  transport:
    poll_interval: "${TB_QUEUE_TRANSPORT_NOTIFICATIONS_POLL_INTERVAL_MS:1000}"

RabbitMQ Installation

For installing RabbitMQ use this instruction.

ThingsBoard Configuration

Open the Notepad or other editor as administrator user (right click on the app icon and select “Run as administrator”).
Open the following file for editing (select “All Files” instead of “Text Documents” in file choosing dialog, the encoding is UTF-8):

C:\Program Files (x86)\thingsboard\conf\thingsboard.yml

and locate “queue:” block. Make sure the queue type is “rabbitmq” and don’t forget to replace “YOUR_USERNAME” and “YOUR_PASSWORD” with your real user credentials, “localhost” and “5672” with your real RabbitMQ host and port:

queue:
  type: "${TB_QUEUE_TYPE:rabbitmq}"
...
  rabbitmq:
    exchange_name: "${TB_QUEUE_RABBIT_MQ_EXCHANGE_NAME:}"
    host: "${TB_QUEUE_RABBIT_MQ_HOST:localhost}"
    port: "${TB_QUEUE_RABBIT_MQ_PORT:5672}"
    virtual_host: "${TB_QUEUE_RABBIT_MQ_VIRTUAL_HOST:/}"
    username: "${TB_QUEUE_RABBIT_MQ_USERNAME:YOUR_USERNAME}"
    password: "${TB_QUEUE_RABBIT_MQ_PASSWORD:YOUR_PASSWORD}"
    automatic_recovery_enabled: "${TB_QUEUE_RABBIT_MQ_AUTOMATIC_RECOVERY_ENABLED:false}"
    connection_timeout: "${TB_QUEUE_RABBIT_MQ_CONNECTION_TIMEOUT:60000}"
    handshake_timeout: "${TB_QUEUE_RABBIT_MQ_HANDSHAKE_TIMEOUT:10000}"
    queue-properties:

Confluent Cloud Configuration

To access Confluent Cloud you should first create an account, then create a Kafka cluster and get your API Key.

ThingsBoard Configuration

Open the Notepad or other editor as administrator user (right click on the app icon and select “Run as administrator”).
Open the following file for editing (select “All Files” instead of “Text Documents” in file choosing dialog, the encoding is UTF-8):

C:\Program Files (x86)\thingsboard\conf\thingsboard.yml

and locate “queue:” block. Make sure the queue type is “kafka”, replication factor is “3” and use confluent cloud is “true”.

Don’t forget to replace “CLUSTER_API_KEY”, “CLUSTER_API_SECRET” and “localhost:9092” with your real Confluent Cloud bootstrap servers:

queue:
  type: "${TB_QUEUE_TYPE:kafka}"
...
  kafka:
    bootstrap.servers: "${TB_KAFKA_SERVERS:localhost:9092}"
...
    replication_factor: "${TB_QUEUE_KAFKA_REPLICATION_FACTOR:3}"
...
    use_confluent_cloud: "${TB_QUEUE_KAFKA_USE_CONFLUENT_CLOUD:true}"
...
      sasl.config: "${TB_QUEUE_KAFKA_CONFLUENT_SASL_JAAS_CONFIG:org.apache.kafka.common.security.plain.PlainLoginModule required username=\"CLUSTER_API_KEY\" password=\"CLUSTER_API_SECRET\";}"

These params affect the number of requests per second from each partitions per each queue.

Number of requests to particular Message Queue calculated based on the formula:

((Number of Rule Engine and Core Queues) * (Number of partitions per Queue) + (Number of transport queues) + (Number of microservices) + (Number of JS executors)) * 1000 / POLL_INTERVAL_MS

For example, number of requests based on default parameters is:

Rule Engine queues:

Main 10 partitions + HighPriority 10 partitions + SequentialByOriginator 10 partitions = 30

Core queue 10 partitions

Transport request Queue + response Queue = 2

Rule Engine Transport notifications Queue + Core Transport notifications Queue = 2

Total = 44

Number of requests per second = 44 * 1000 / 25 = 1760 requests

Based on the use case, you can compromise latency and decrease number of partitions/requests to the queue, if the message load is low.

Sample parameters to fit into 10 requests per second on a “monolith” deployment:

queue:
...
  transport_api:
    request_poll_interval: "${TB_QUEUE_TRANSPORT_REQUEST_POLL_INTERVAL_MS:1000}"
    response_poll_interval: "${TB_QUEUE_TRANSPORT_RESPONSE_POLL_INTERVAL_MS:1000}"
...
  core:
    poll-interval: "${TB_QUEUE_CORE_POLL_INTERVAL_MS:1000}"
    partitions: "${TB_QUEUE_CORE_PARTITIONS:2}"
...
  js:
    response_poll_interval: "${REMOTE_JS_RESPONSE_POLL_INTERVAL_MS:1000}"
...
  rule-engine:
    poll-interval: "${TB_QUEUE_RULE_ENGINE_POLL_INTERVAL_MS:1000}"
...
    queues:
        poll-interval: "${TB_QUEUE_RE_MAIN_POLL_INTERVAL_MS:1000}"
        partitions: "${TB_QUEUE_RE_MAIN_PARTITIONS:2}"
...
        poll-interval: "${TB_QUEUE_RE_HP_POLL_INTERVAL_MS:1000}"
        partitions: "${TB_QUEUE_RE_HP_PARTITIONS:1}"
...
        poll-interval: "${TB_QUEUE_RE_SQ_POLL_INTERVAL_MS:1000}"
        partitions: "${TB_QUEUE_RE_SQ_PARTITIONS:1}"
...
  transport:
    poll_interval: "${TB_QUEUE_TRANSPORT_NOTIFICATIONS_POLL_INTERVAL_MS:1000}"

Step 5. [Optional] Memory update for slow machines (1GB of RAM)

Open the Notepad or other editor as administrator user (right click on the app icon and select “Run as administrator”).
Open the following file for editing (select “All Files” instead of “Text Documents” in file choosing dialog, the encoding is UTF-8):

C:\Program Files (x86)\thingsboard\thingsboard.xml

Locate the following lines to the configuration file.

    <startargument>-Xms512m</startargument>
    <startargument>-Xmx1024m</startargument>

and change them to

    <startargument>-Xms256m</startargument>
    <startargument>-Xmx256m</startargument>

Step 6. Run installation script

Launch windows shell (Command Prompt) as Administrator. Change directory to your ThingsBoard installation directory.

Execute install.bat script to install ThingsBoard as a Windows service (or run “install.bat –loadDemo” to install and add demo data). This means it will be automatically started on system startup. Similar, uninstall.bat will remove ThingsBoard from Windows services. The output should be similar to this one:

C:\Program Files (x86)\thingsboard>install.bat --loadDemo
Detecting Java version installed.
CurrentVersion 18
Java 1.8 found!
Installing thingsboard ...
...
ThingsBoard installed successfully!

Step 7. Start ThingsBoard service

Now let’s start the ThingsBoard service! Open the command prompt as an Administrator and execute the following command:

net start thingsboard

Expected output:

The ThingsBoard Server Application service is starting.
The ThingsBoard Server Application service was started successfully.

In order to restart the ThingsBoard service you can execute following commands:

net stop thingsboard
net start thingsboard

Once started, you will be able to open Web UI using the following link:

http://localhost:8080/

The following default credentials are available if you have specified –loadDemo during execution of the installation script:

You can always change passwords for each account in account profile page.

Please allow up to 90 seconds for the Web UI to start. This is applicable only for slow machines with 1-2 CPUs or 1-2 GB RAM.

Troubleshooting

The log files are located in logs folder (“C:\Program Files (x86)\thingsboard\logs” in our case).

The thingsboard.log file should contain following line:

YYYY-MM-DD HH:mm:ss,sss [main] INFO  o.t.s.ThingsboardServerApplication - Started ThingsboardServerApplication in x.xxx seconds (JVM running for x.xxx)

In case of any unclear errors, use general troubleshooting guide or contact us.

Windows firewall settings

In order to have external access to ThingsBoard Web UI and device connectivity (HTTP, MQTT, CoAP) you need to create a new inbound rule with Windows Firewall with Advanced Security.

image

image

image

image

image

image

image

image

Next steps