Building Temperature KPIs

Who it’s for

Facility, building, and infrastructure operators asking “what’s the hottest reading right now?”, “what’s the coldest reading in the cold store?”, “is the building running warmer than yesterday on average?” — when spatial spread across an asset’s child sensors matters more than any single reading.

What it does

Lives on the parent asset. Reads each child’s temperature telemetry via the Contains relation, then emits three statistics atomically — average, maximum, and minimum — so dashboards see the hot-spot, the cold-spot, and the trend from one consistent snapshot.

How to set up

This CF lives on the parent asset (building, zone, floor). Before it can aggregate, each child sensor must be linked to the parent via a Contains relation.

Via UI:

1. Open the parent asset’s details page (Entities → Assets → [asset name]).
2. Navigate to the Relations tab and select the From scope.
3. Click + to open the Add relation dialog.
4. Set type Contains, target type Device, and pick the temperature sensor to include.
5. Click Add.
6. Repeat for each sensor that should contribute to the building KPIs.

When sensors are added or removed, create or delete the corresponding Contains relation. The CF automatically adjusts the aggregation.

For bulk setup across many assets and sensors, use the Relations REST API.

How to customize

• To aggregate a different telemetry key — change the Time series key on the source argument (e.g. temperature → humidity, co2, pressure).
• To use a different fallback when no data has arrived — change Default value on the source argument (defaults to 0).
• To rename the outputs for a different domain — change each Metric name (e.g. avgBuildingTemp → avgBuildingHumidity, maxBuildingTemp → maxBuildingHumidity, minBuildingTemp → minBuildingHumidity) so downstream dashboards bind to meaningful keys.
• To add or remove statistics — click Add metric and pick a function (SUM, COUNT, COUNT UNIQUE, …). Each metric defines one output key and its function.
• To scope a metric to a subset of children — apply a TBEL filter on the metric (e.g. count only readings from active devices — add an active server-scope argument first, then filter return active == true;).
• To follow a different relation type — change the Relation type from Contains to whatever your hierarchy uses (Manages, MonitoredBy).
• To match how often child sensors report — tweak the Deduplication interval (minimum time between aggregations).
• To timestamp the aggregated output with the latest source reading’s time instead of aggregation time — toggle Use latest timestamp. Default is on for this template. Turn it off if you’d rather the output ts mark when the aggregation ran on the server.
• To turn off the database write, WebSocket push, or downstream CF re-evaluation — under Process right away, toggle Save to time series, Save to latest values, Send to WebSockets, or Send to Calculated fields.
• To filter, transform, or forward the result to external systems — switch Strategy to Process via Rule Chains. Rule nodes then receive the output and can drop it, change it, save it conditionally, push it to an external system, or anything else the chain defines.