ThingsBoard Calculated Fields: An easy way to handle complex IoT telemetry calculations

With the release of ThingsBoard 4.0, we’re excited to introduce Calculated Fields—a new feature that simplifies telemetry processing. Calculated Fields let you define calculations in a clean, user-friendly way — making your logic easier to manage, scale, and maintain.

To showcase its value, we’ll walk through a real-world example from our Swimming pool SCADA system solution template.

But firstly lets define the problem: complex rule chains and unnecessary database load

One of the common challenges in IoT solutions is the need to derive new telemetry from existing ones — especially when those telemetry come from multiple related devices.

Take our Swimming pool SCADA system as an example. In this solution template, we needed to calculate the status of pipe segments based on the telemetry from several devices. We represent this as asset level attributes like A1, A2, A3, based on telemetry from devices D1, D2, D3.

Usual approach

A common and powerful approach in ThingsBoard-powered IoT solutions for deriving telemetry from multiple related devices is to use Rule Chains composed of multiple rule nodes. This method is widely adopted and provides a detailed customization for implementing complex processing logic across a range of use cases.

We used this exact approach in the SCADA template to calculate whether water was flowing through specific pipe segments.

While this pattern provides flexibility and control, it also requires a solid understanding of the Rule Engine and how to design effective rule chains.

The Solution: Calculated Fields in Action

To solve these challenges, we introduced Calculated Fields — a new way to calculate telemetry values derived from multiple entities.

Instead of fetching the required telemetry keys from the database every time new data arrives, Calculated Fields maintain the latest values in their internal state and use them directly for calculations. This eliminates the need for database interactions on each telemetry update.

Applying Calculated Fields in the Swimming pool SCADA system

In our SCADA solution, we previously used a single large script in the rule chain to calculate pipe segment statuses. Let me remind how the main script in the rule chain looked like.

It’s clear that this approach can quickly become cumbersome — so let’s see how Calculated Fields make it better.

With Calculated Fields, we restructured the logic entirely.

Rather than using one large script, we created a dedicated calculated field for each pipe segment, with its own logic and dependencies — making the system far more modular, readable, and maintainable.

A closer look at the new approach

Let’s walk through the creation of one such field — Heat Segment Flowing:

1. We specified arguments — the telemetry keys needed from related entities (like drainSegmentFlowing, filterSegmentFlowing, and heatPumpIntakeValveOpened).
2. We selected source entities — either the current asset or related devices, depending on the argument.
3. We wrote a custom script — a short expression defining the logic: For example, the heat segment is considered “flowing” if all previous segments are active and the valve is open.
4. We set the output — defining where and how the result should be stored (as an attribute on the asset).

This method makes your logic more user-friendly, easier to trace, and far more efficient than managing everything in one script.

Quick overview of argument types

Calculated Fields support 3 types of arguments, each serving different use cases:

Latest telemetry — the most recent value of a telemetry key. (Used in our SCADA example to define real-time telemetry from devices).
Attribute — attribute values stored on entity. (Also used in the SCADA case to fetch other pipe segment statuses).
Time series rolling — historical time series data over a specified time window for trend analysis.

Although time series rolling is not used in our SCADA system, it’s ideal for scenarios that require time-window-based computations — such as calculating averages or totals over the last few minutes or hours.

Calculated field debugging

Each field includes its own event debug panel, where you can trace calculation history, inspect incoming arguments, and see the output result for each telemetry update.

How Calculated Fields improved the Swimming pool SCADA system

By replacing our old calculation logic with Calculated Fields, we achieved the following improvements:

Clearer, modular logic: Each pipe segment now has its own dedicated expression.
Faster performance under frequent telemetry: Because Calculated Fields operate on up-to-date values without querying the database on each update, the system avoids unnecessary database queries, making it faster.
Debugging made simple: Every field has a debug panel that shows inputs, logic execution, and output in real time. No need to dig through rule chain logs to trace what happened.

Conclusion

Calculated Fields helped us transform complex logic in the Swimming pool SCADA system by replacing manual rule chain calculations with automatic, real-time evaluations. This not only reduced database load, but also improved overall system clarity.

Although we used a SCADA system to demonstrate the feature, Calculated Fields are useful in any solution that involves calculations across multiple entities.

Looking ahead

Starting with version 4.1, Calculated Fields will gain the ability to reprocess historical telemetry. This means you can recalculate past values, apply improved logic to earlier data, and ensure accuracy across your entire timeline.
This feature will be available for the ThingsBoard Professional Edition (PE) only.

Explore Calculated Fields

Check out our example video and official documentation to learn more about how Calculated Fields work and how to start using them.