Skip to content
Stand with Ukraine flag

Calculate Delta from Tank Level Sensor

  • Calculated Field
  • 217 installs
  • v1.0.0
  • Jun 15, 2026
  • MIT license
  • v4.2+

Compute the per-reading delta from a tank level sensor — fuel level, water level, chemical storage level, UPS battery state-of-charge, or any gauge that drops as the resource is used.

Type
  • Script
Category
  • Custom Formula
Use Cases
  • Tank Level Monitoring
  • Industrial Automation
  • Smart Metering

Who it’s for

Fleet managers, facility operators, and telematics teams asking “how much fuel did the tank lose since the last report?”, “is the battery draining faster than expected today?”, “did the chemical level drop overnight?” — when your source telemetry is a tank level sensor or similar dropping gauge, and what you need on the dashboard is the drop between two consecutive readings.

What it does

Reads the fuelLevel telemetry as a rolling window holding the two most recent readings, and emits the drop between them as readingsDelta — the amount the level fell since the previous reading:

Reading delta from tank level sensor diagram

Refuelling and recharging events (which cause the value to go up) are ignored — the script returns 0 instead of a negative delta. The first evaluation also returns 0, because there is no previous value to compare to yet.

To turn readingsDelta into a consumption or drain view, you have three paths:

  • For totals that other dashboards, alarms, or APIs need — install one of the aggregation calculated fields in See also below. The CF stores each interval’s total as time-series, so it’s available to other dashboards, alarm rules, the REST API, and downstream calculated fields.
  • For a roll-up that lives only on one chart — enable aggregation in the chart widget’s time-window settings. Computed at view time and not stored, so it’s quick to set up but invisible outside that chart.
  • For a per-reading trend — plot readingsDelta directly on a chart.

How to set up

The CF reads fuelLevel through a rolling-window argument. Rolling arguments don’t fall back to a default, so the device must already have at least one fuelLevel reading in its telemetry history before the CF can initialize. Until then the platform reports Required arguments are missing: level and the CF stays inactive.

How to customize

  • To read a different gauge — change the Time series key on the level argument (e.g. fuelLevelbatterySoc, chemicalLevel, tankLevel).
  • To rename the output for a different domain — open the script and replace readingsDelta in the return object with the key your downstream dashboards and alarms expect (e.g. fuelUsed, batteryDrop, chemicalUsed).
  • To tune the window to your reporting frequency — the Time window is how far back the CF looks to find a previous reading. The Limit is fixed at 2, so only the two most recent readings inside the window are ever compared. Defaults to 2.5 days, sized for daily reporters with margin for late uploads. Decrease it for high-frequency reporters, increase it for slower-than-daily ones.
  • To change the output precision — adjust Decimals by default on the output to whatever precision your dashboards and alarms need.
  • To timestamp the result with server time instead of the latest input reading — the script currently wraps its return with ctx.latestTs under a values envelope, so each record is stamped at the timestamp of the latest level reading. Drop that envelope and return the output key at the top level instead. The record then uses server time at the moment of evaluation.

See also

For per-day, per-week, or per-month totals (calendar-aligned, with configurable interval):

Daily Energy Consumption Total Dmytro Shvaika

For per-shift totals (8 / 12 / 6 hour windows, with configurable shift start time):

Manufacturing Plant Output Per 8-Hour Shift Dmytro Shvaika

Share Your Calculated Field with the Community

Built a useful data transformation? Export it as a JSON from ThingsBoard and publish it to the IoT Hub. Share it with thousands of ThingsBoard developers worldwide.