Question 1

Why does ThingsBoard route alarm creation as ENTITY_CREATED instead of ALARM_CREATED?

Accepted Answer

In ThingsBoard, an alarm is a type of entity. When an alarm is created, the system emits an ENTITY_CREATED event because it is a new entity creation. The ALARM_CREATED message type is used for events like an existing alarm being triggered or updated, not for the initial creation of the alarm entity. If your rule chain should only process device creations, add a filter node before the Message Type Switch to check the entity type, for example using a TBEL script: return msg.id != null && msg.id.entityType == 'DEVICE';

Question 2

What happens to MQTT messages when the ThingsBoard transport rate limit is exceeded?

Accepted Answer

When a device exceeds the transport rate limit (e.g., 100 messages/s, 1,000/min, 15,000/h), ThingsBoard does not silently acknowledge and drop. It sends an MQTT DISCONNECT and closes the connection. For QoS 0, messages are lost with no retry mechanism. For QoS 1, if the device uses a persistent session (Clean Start = false), unacknowledged messages are retransmitted on reconnect per the MQTT standard. With an ephemeral session (Clean Start = true), in-flight state is cleared, causing message loss regardless of QoS. There is no per-message logging on the platform side; only a rate-limit breach notification is generated. To recover lost telemetry, rely on the device's local buffer.

Question 3

Why is my ThingsBoard Cloud data points quota running out quickly even with low telemetry frequency?

Accepted Answer

In ThingsBoard, each key in a telemetry JSON payload counts as one data point, not the entire message. For example, a message with 32 keys uses 32 data points per send. Rule chains that save each key individually can further multiply consumption. To reduce usage: minimize the number of keys per message, lower the publishing frequency, and review rule chains to eliminate redundant data point saves. Check the number of active devices as total usage scales linearly with device count and keys per message.

Question 4

How to trigger an alarm on a specific bit of an integer telemetry value in ThingsBoard?

Accepted Answer

Direct bit checking in alarm rules is not yet supported (feature request #8055). Workaround: use a Rule Chain with a Script node (JavaScript) to extract the bit into a new telemetry key via bitwise operations, then set an alarm rule on that key. Example to extract bit 0 (emergency stop): `var fault = msg.faultWord; msg.emergencyStop = (fault & 1) !== 0; return {msg: msg, metadata: metadata, msgType: msgType};` Then create an alarm rule for `emergencyStop == true`. Repeat for other bits as needed.

thingsboard

Core Features

What It Can't Do

Use Cases

Tags

Getting Started

Similar Projects