Installing ThingsBoard on Raspberry Pi 3 Model B



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.

This guide describes how to install ThingsBoard on a Raspberry Pi 3 running Raspbian Buster.

Third-party components installation

Step 1. Install Java 8 (OpenJDK)

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

sudo apt update sudo apt install openjdk-8-jdk

Please don’t forget to configure your operating system to use OpenJDK 8 by default. You can configure which version is the default using the following command:

sudo update-alternatives --config java

You can check the installation using the following command:

java -version

Expected command output is:

openjdk version "1.8.0_xxx" OpenJDK Runtime Environment (...) OpenJDK 64-Bit Server VM (build ...)

Step 2. ThingsBoard service installation

Download installation package.

wget https://github.com/thingsboard/thingsboard/releases/download/v3.1.1/thingsboard-3.1.1.deb

Install ThingsBoard as a service

sudo dpkg -i thingsboard-3.1.1.deb

Step 3. Configure ThingsBoard database

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

Instructions listed below will help you to install PostgreSQL.

# install **wget** if not already installed: sudo apt install -y wget # import the repository signing key: wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add - # add repository contents to your system: RELEASE = $( lsb_release -cs ) echo "deb http://apt.postgresql.org/pub/repos/apt/ ${ RELEASE } " -pgdg main | sudo tee /etc/apt/sources.list.d/pgdg.list # install and launch the postgresql service: sudo apt update sudo apt -y install postgresql-12 sudo service postgresql start

Once PostgreSQL is installed you may want to create a new user or set the password for the the main user. The instructions below will help to set the password for main postgresql user

sudo su - postgres psql \password \q

Then, press “Ctrl+D” to return to main user console and connect to the database to create thingsboard DB:

psql -U postgres -d postgres -h 127.0.0.1 -W CREATE DATABASE thingsboard; \q

ThingsBoard Configuration

Edit ThingsBoard configuration file

sudo nano /etc/thingsboard/conf/thingsboard.conf

Add the following lines to the configuration file. Don’t forget to replace “PUT_YOUR_POSTGRESQL_PASSWORD_HERE” with your real postgres user password:

# DB Configuration export DATABASE_ENTITIES_TYPE = sql export DATABASE_TS_TYPE = sql export SPRING_JPA_DATABASE_PLATFORM = org.hibernate.dialect.PostgreSQLDialect export SPRING_DRIVER_CLASS_NAME = org.postgresql.Driver export SPRING_DATASOURCE_URL = jdbc:postgresql://localhost:5432/thingsboard export SPRING_DATASOURCE_USERNAME = postgres export SPRING_DATASOURCE_PASSWORD = PUT_YOUR_POSTGRESQL_PASSWORD_HERE export SPRING_DATASOURCE_MAXIMUM_POOL_SIZE = 5 # Specify partitioning size for timestamp key-value storage. Allowed values: DAYS, MONTHS, YEARS, INDEFINITE. export SQL_POSTGRES_TS_KV_PARTITIONING = MONTHS

Step 4. Choose ThingsBoard queue service

ThingsBoard uses queue services for API calls between micro-services and able to use next queue services: In Memory (default), AWS SQS, Google Pub/Sub or Azure Service Bus.

In Memory (built-in and default) AWS SQS (managed service from AWS) Google Pub/Sub (managed service from Google) Azure Service Bus (managed service from Azure) Confluent Cloud (Event Streaming Platform based on Kafka) In Memory queue is built-in and enabled by default. No additional configuration steps required. 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 Edit ThingsBoard configuration file sudo nano /etc/thingsboard/conf/thingsboard.conf Add the following lines to the configuration file. 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: export TB_QUEUE_TYPE = aws-sqs export TB_QUEUE_AWS_SQS_ACCESS_KEY_ID = YOUR_KEY export TB_QUEUE_AWS_SQS_SECRET_ACCESS_KEY = YOUR_SECRET export 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 is 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: export TB_QUEUE_CORE_POLL_INTERVAL_MS = 1000 export TB_QUEUE_CORE_PARTITIONS = 2 export TB_QUEUE_RULE_ENGINE_POLL_INTERVAL_MS = 1000 export TB_QUEUE_RE_MAIN_POLL_INTERVAL_MS = 1000 export TB_QUEUE_RE_MAIN_PARTITIONS = 2 export TB_QUEUE_RE_HP_POLL_INTERVAL_MS = 1000 export TB_QUEUE_RE_HP_PARTITIONS = 1 export TB_QUEUE_RE_SQ_POLL_INTERVAL_MS = 1000 export TB_QUEUE_RE_SQ_PARTITIONS = 1 export TB_QUEUE_TRANSPORT_REQUEST_POLL_INTERVAL_MS = 1000 export TB_QUEUE_TRANSPORT_RESPONSE_POLL_INTERVAL_MS = 1000 export 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 Edit ThingsBoard configuration file sudo nano /etc/thingsboard/conf/thingsboard.conf Add the following lines to the configuration file. 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): export TB_QUEUE_TYPE = pubsub export TB_QUEUE_PUBSUB_PROJECT_ID = YOUR_PROJECT_ID export TB_QUEUE_PUBSUB_SERVICE_ACCOUNT = YOUR_SERVICE_ACCOUNT # These params affect the number of requests per second from each partitions per each queue!!! export TB_QUEUE_TRANSPORT_REQUEST_POLL_INTERVAL_MS = 1000 export TB_QUEUE_TRANSPORT_RESPONSE_POLL_INTERVAL_MS = 1000 export TB_QUEUE_CORE_POLL_INTERVAL_MS = 1000 export REMOTE_JS_RESPONSE_POLL_INTERVAL_MS = 1000 export TB_QUEUE_RULE_ENGINE_POLL_INTERVAL_MS = 1000 export TB_QUEUE_RE_MAIN_POLL_INTERVAL_MS = 1000 export TB_QUEUE_RE_HP_POLL_INTERVAL_MS = 1000 export TB_QUEUE_RE_SQ_POLL_INTERVAL_MS = 1000 export TB_QUEUE_TRANSPORT_NOTIFICATIONS_POLL_INTERVAL_MS = 1000 # These params affect the number of requests per second from each partitions per each queue. # Number of requests to particular Message Queue is 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: export TB_QUEUE_CORE_POLL_INTERVAL_MS = 1000 export TB_QUEUE_CORE_PARTITIONS = 2 export TB_QUEUE_RULE_ENGINE_POLL_INTERVAL_MS = 1000 export TB_QUEUE_RE_MAIN_POLL_INTERVAL_MS = 1000 export TB_QUEUE_RE_MAIN_PARTITIONS = 2 export TB_QUEUE_RE_HP_POLL_INTERVAL_MS = 1000 export TB_QUEUE_RE_HP_PARTITIONS = 1 export TB_QUEUE_RE_SQ_POLL_INTERVAL_MS = 1000 export TB_QUEUE_RE_SQ_PARTITIONS = 1 export TB_QUEUE_TRANSPORT_REQUEST_POLL_INTERVAL_MS = 1000 export TB_QUEUE_TRANSPORT_RESPONSE_POLL_INTERVAL_MS = 1000 export 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 Edit ThingsBoard configuration file sudo nano /etc/thingsboard/conf/thingsboard.conf Add the following lines to the configuration file. 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”: export TB_QUEUE_TYPE = service-bus export TB_QUEUE_SERVICE_BUS_NAMESPACE_NAME = YOUR_NAMESPACE_NAME export TB_QUEUE_SERVICE_BUS_SAS_KEY_NAME = YOUR_SAS_KEY_NAME export TB_QUEUE_SERVICE_BUS_SAS_KEY = YOUR_SAS_KEY # These params affect the number of requests per second from each partitions per each queue!!! export TB_QUEUE_TRANSPORT_REQUEST_POLL_INTERVAL_MS = 1000 export TB_QUEUE_TRANSPORT_RESPONSE_POLL_INTERVAL_MS = 1000 export TB_QUEUE_CORE_POLL_INTERVAL_MS = 1000 export REMOTE_JS_RESPONSE_POLL_INTERVAL_MS = 1000 export TB_QUEUE_RULE_ENGINE_POLL_INTERVAL_MS = 1000 export TB_QUEUE_RE_MAIN_POLL_INTERVAL_MS = 1000 export TB_QUEUE_RE_HP_POLL_INTERVAL_MS = 1000 export TB_QUEUE_RE_SQ_POLL_INTERVAL_MS = 1000 export TB_QUEUE_TRANSPORT_NOTIFICATIONS_POLL_INTERVAL_MS = 1000 # These params affect the number of requests per second from each partitions per each queue. # Number of requests to particular Message Queue is 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: export TB_QUEUE_CORE_POLL_INTERVAL_MS = 1000 export TB_QUEUE_CORE_PARTITIONS = 2 export TB_QUEUE_RULE_ENGINE_POLL_INTERVAL_MS = 1000 export TB_QUEUE_RE_MAIN_POLL_INTERVAL_MS = 1000 export TB_QUEUE_RE_MAIN_PARTITIONS = 2 export TB_QUEUE_RE_HP_POLL_INTERVAL_MS = 1000 export TB_QUEUE_RE_HP_PARTITIONS = 1 export TB_QUEUE_RE_SQ_POLL_INTERVAL_MS = 1000 export TB_QUEUE_RE_SQ_PARTITIONS = 1 export TB_QUEUE_TRANSPORT_REQUEST_POLL_INTERVAL_MS = 1000 export TB_QUEUE_TRANSPORT_RESPONSE_POLL_INTERVAL_MS = 1000 export TB_QUEUE_TRANSPORT_NOTIFICATIONS_POLL_INTERVAL_MS = 1000 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 Edit ThingsBoard configuration file sudo nano /etc/thingsboard/conf/thingsboard.conf Add the following lines to the configuration file. Don’t forget to replace “CLUSTER_API_KEY”, “CLUSTER_API_SECRET” and “localhost:9092” with your real Confluent Cloud bootstrap servers:** export TB_QUEUE_TYPE = kafka export TB_QUEUE_KAFKA_USE_CONFLUENT_CLOUD = true export TB_KAFKA_SERVERS = localhost:9092 export TB_QUEUE_KAFKA_REPLICATION_FACTOR = 3 export 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 is 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: export TB_QUEUE_CORE_POLL_INTERVAL_MS = 1000 export TB_QUEUE_CORE_PARTITIONS = 2 export TB_QUEUE_RULE_ENGINE_POLL_INTERVAL_MS = 1000 export TB_QUEUE_RE_MAIN_POLL_INTERVAL_MS = 1000 export TB_QUEUE_RE_MAIN_PARTITIONS = 2 export TB_QUEUE_RE_HP_POLL_INTERVAL_MS = 1000 export TB_QUEUE_RE_HP_PARTITIONS = 1 export TB_QUEUE_RE_SQ_POLL_INTERVAL_MS = 1000 export TB_QUEUE_RE_SQ_PARTITIONS = 1 export TB_QUEUE_TRANSPORT_REQUEST_POLL_INTERVAL_MS = 1000 export TB_QUEUE_TRANSPORT_RESPONSE_POLL_INTERVAL_MS = 1000 export TB_QUEUE_TRANSPORT_NOTIFICATIONS_POLL_INTERVAL_MS = 1000

Edit ThingsBoard configuration file

sudo nano /etc/thingsboard/conf/thingsboard.conf

Add the following lines to the configuration file.

# Update ThingsBoard memory usage and restrict it to 256MB in /etc/thingsboard/conf/thingsboard.conf export JAVA_OPTS = " $JAVA_OPTS -Xms256M -Xmx256M"

Step 6. Run installation script

Once ThingsBoard service is installed and DB configuration is updated, you can execute the following script:

# --loadDemo option will load demo data: users, devices, assets, rules, widgets. sudo /usr/share/thingsboard/bin/install/install.sh --loadDemo

Step 7. Start ThingsBoard service

Execute the following command to start ThingsBoard:

sudo service thingsboard start

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 240 seconds for the Web UI to start. This is applicable only for slow machines with 1-2 CPUs or 1-2 GB RAM.

Troubleshooting

ThingsBoard logs are stored in the following directory:

/var/log/thingsboard

You can issue the following command in order to check if there are any errors on the backend side:

cat /var/log/thingsboard/thingsboard.log | grep ERROR

Next steps





