Analytics translators
An analytics translator watches a device over time and reports something about its behaviour rather than its latest reading: how fast a value is moving, how much of the day something was in use, how badly the radio link is performing, or how far a sensor has drifted from its true zero.
Like the other logic translators they are chained, running on top of the device's hardware translator.
Why use an analytics translator
The difference from a calculation translator is history. A calculation derives its answer from the reading in front of it: Celsius to Fahrenheit needs nothing else. An analytics translator cannot answer from one reading at all. "Is this climbing too fast?" and "how much of today was this light on?" only mean something across a series of uplinks.
So these translators keep state on the device between reports, and each new uplink updates the picture. That is work you would otherwise do by exporting history and analysing it somewhere else, after the fact. Here the answer is a live field on the device, which means it can be shown on a dashboard, filtered in a view, and supervised by an alarm translator like any other value.
The translators
| Translator | What it reports | Fields produced |
|---|---|---|
analytics-change-rate | How fast a reading is changing, per hour. Positive when rising, negative when falling, near zero when steady. Catches a temperature climbing faster than it should, which often means a fault rather than a warm day | changeRate |
analytics-utilization-rates | How much something is actually being used over time. Built for a customer who suspected indoor lights were being left on, and wanted to see how long they ran dimly lit versus brightly lit | utilization, utilizationDaily, utilizationHigh, utilizationLow |
analytics-frame-loss-rate | How many uplinks a device is losing, by watching its frame counter jump. Frames numbered 10 then 13 means two went missing. A direct measure of radio coverage quality, and the input to set-alarm-frame-loss-rate | frameLossRate |
analytics-building-energy-efficiency | Benchmarks a building's energy efficiency and points at the next saving. Reports both a temperature-normalised efficiency figure and energyIntensity, the standard energy use per square metre, with weekly, monthly, quarterly and yearly means | energyEfficiency, energyIntensity, energyEfficiencyRolling, energyEfficiencyWeekly, energyEfficiencyMonthly, energyEfficiencyQuarterly, energyEfficiencyYearly, deltaTemperature |
analytics-abc-calibration | Corrects a sensor whose zero point drifts. Automatic Baseline Calibration assumes the recurring low readings represent the true baseline, learns it from daily minima over a window, and subtracts the drift. The classic case is a CO2 sensor that should return to outdoor levels overnight | calibratedValue, calibrationOffset |
analytics-abc-calibration-adaptive | The same idea, tracking the baseline adaptively over a drift period instead of a fixed calendar window. For sensors that do not return to baseline on a tidy daily rhythm | calibratedValue, calibrationOffset |
analytics-suspected-activity-during-time-window | Flags people present somewhere that should be empty, such as premises in the evening and at night. A sound sensor listens for noise that stays raised for long enough to be a person rather than a passing bang, but only during the watch hours | suspectedActivity, activitySince |
Parameters
The same convention as elsewhere: most parameters are optional and carry a default, though some are required, and inputField points the translator at a specific source field when the automatic choice is wrong.
| Parameter | Used by | Purpose |
|---|---|---|
inputField | most | The field to analyse |
timeZone | the period-aware ones | Local time zone deciding when a day rolls over |
sampleSize, changeRateSampleSize, efficiencySampleSize | change rate, frame loss, energy efficiency | How many readings to smooth over, so one odd uplink does not swing the result |
calibrationWindowDays, baselinePercentile, calibrationFloor, adaptiveDriftDays | the ABC pair | How the baseline is learned and how far it is allowed to move |
buildingArea, energyThreshold | energy efficiency | Floor area for the intensity figure, and a floor below which a quiet period is disregarded rather than flattering the result |
averageThreshold, peakThreshold, activityDurationMins, maxGapMins, watchStartHour, watchEndHour | suspected activity | What counts as noise, how long it must persist, and when to be watching |
Chaining
Two chains worth knowing, both ending in an alarm so the result reaches someone:
- Coverage monitoring. Device →
analytics-frame-loss-rate→set-alarm-frame-loss-rate. The analytics translator measures the loss rate, the alarm fires when a device's coverage degrades past what you accept, which is how you find a gateway problem before users report it. - Runaway detection. Sensor →
analytics-change-rate→set-alarm-change-rate. Rate of change first, then a threshold on the rate rather than on the value, so a freezer failing fast is caught long before it is warm.
For the alarms, see Alarm translators. For the full A–Z index of every translator, see the translators overview.