Overview
Every data point in Mango by Radix IoT can be configured to log its values to the built-in historian — a time series store of timestamped values. This historical data powers trend charts, dashboards, KPI calculations, rollup statistics, and scheduled reports. Without logging, a data point only shows its current live value and has no history.
How you configure logging has a direct impact on three things: the level of detail available for analysis, the performance of your Mango server, and the amount of disk space consumed.
Prerequisites
- Mango 4.x or 5.x with admin access
- At least one data source with active data points
- Basic understanding of data point types (numeric, binary, multistate, alphanumeric)
How the Mango Historian Works
A logged point value is a value plus a timestamp in milliseconds. That is the whole record. Mango can attach an annotation to a value — for example, noting that it was written by a user rather than polled from a device — but an annotation is optional extra information, not a quality flag carried on every sample.
These records accumulate to form the point's historical time series. Where they are stored depends on the point value backend installed on your system; the logging settings described below behave the same way regardless of backend.
Step 1: Choose a Logging Type
Mango has six logging types, set per data point on the Logging properties tab of the point editor. What a new point starts on depends on its data type: setting the type to Numeric seeds Interval logging, while Binary, Multistate and Alphanumeric seed When point value changes. Either way, the logging type is yours to change.
| UI label | Export code | What gets written |
|---|---|---|
| When point value changes | ON_CHANGE | A value that qualifies as a change against the previous one |
| All data | ALL | Every value the point receives |
| Do not log | NONE | Nothing — the live value is still tracked |
| Interval | INTERVAL | One value per interval, computed by the interval logging type |
| When point timestamp changes | ON_TS_CHANGE | A value whose timestamp differs from the previous one |
| Interval and point value changes | ON_CHANGE_INTERVAL | Qualifying changes, plus a value when the interval elapses without one |
When point value changes (ON_CHANGE)
The value is logged only when it qualifies as a change against the last one. For numeric points the comparison uses the configured tolerance: the value is logged when it differs from the last logged value by more than the tolerance, so a tolerance of 0 logs any difference. For non-numeric points the values are simply compared for equality. A point that has never stored a value logs its first one unconditionally, because there is nothing to compare against. A restart is not the same thing: Mango reloads the point's most recent stored value into the runtime and compares against that, so restarting alone does not force a record.
Best for: Binary points (on/off, open/closed), multistate points (mode selectors, fault codes), and any point where the value changes infrequently.
- Advantages: Minimal storage consumption, no redundant records
- Disadvantages: Long stretches with no samples while the value is stable, which some queries and reports handle awkwardly
All data (ALL)
Every value the point receives is logged, whether or not it changed. If the data source polls every 10 seconds, a record is written every 10 seconds even when the reading is identical each time.
Best for: Points where you need a complete record of what the device reported, or where the polling interval is already low-frequency (once per minute or slower).
- Advantages: Complete record of every update received
- Disadvantages: Highest storage consumption — at 1-second polling this produces 86,400 records per day per point, and a constant reading costs exactly as much as a volatile one
Do not log (NONE)
No history is written. The point still polls and still shows a current value, so it remains usable for live displays, scripting, and event detection.
Best for: Diagnostic or intermediate points you need to watch but never need to trend.
Warning
While Use data source and data point purge setting overrides (slower) is ticked on Purge settings (the default on a new install), the nightly purge treats a point set to Do not log as having no history to keep, and deletes any values it still holds. With that setting off, the point only loses values older than the system purge period, like any other point. Do not switch a point to Do not log as a temporary measure if you intend to keep its existing history.
Interval (INTERVAL)
Mango writes one value each time the configured interval elapses, independent of polling frequency. A point polling every 5 seconds can log once every 60 seconds. A point created in the point editor starts at 1 minute; 15 minutes is Mango's built-in fallback, used when the period is absent — on a configuration import that omits it, for example.
What that logged value contains depends on the Interval logging type, which has four options for numeric, binary, and multistate points. Alphanumeric points are offered Instant only.
| Interval logging type | Value written at the end of each interval |
|---|---|
| Instant | The point's current value at the moment the interval fires — a snapshot, ignoring everything in between. This is the default. |
| Maximum | The highest value seen during the interval |
| Minimum | The lowest value seen during the interval |
| Average | For numeric points, the time-weighted average across the interval; for multistate points, the state occupied for the largest proportion of the interval |
Note
Interval logging is not always a raw snapshot. Choosing Average means the stored sample is a computed statistic, and Mango timestamps it at the centre of the averaging window rather than at the end, so an averaged series is deliberately offset from the interval boundaries.
Best for: Numeric points polled faster than the historical analysis needs. This is the most common choice for analog sensor data.
- Advantages: Decouples polling from logging; predictable, evenly spaced data; reduced storage
- Disadvantages: With Instant, short-duration spikes between intervals are missed entirely. Maximum or Minimum avoids that for excursions in one direction.
When point timestamp changes (ON_TS_CHANGE)
The value is logged whenever its timestamp differs from the previous value's timestamp, regardless of whether the value itself changed. This suits sources that report a device-supplied timestamp, where a fresh timestamp on an unchanged reading is itself meaningful — it proves the device is still reporting.
Interval and point value changes (ON_CHANGE_INTERVAL)
This is a single logging type in its own right, not a combination of two settings you tick separately. Qualifying changes are logged as they happen, using the same tolerance comparison as When point value changes. Each time a value is saved, the interval timer restarts; if the interval elapses with no qualifying change, Mango logs the current value anyway.
Example: A temperature sensor polling every 5 seconds, with the interval set to 60 seconds and a tolerance of 2.0°F. A steady reading produces roughly one record per minute. A 5°F jump is captured as soon as it is polled, rather than waiting for the next minute boundary.
Tip
For numeric points that need both even spacing and prompt capture of excursions, Interval and point value changes is usually the right choice — select it as the logging type rather than looking for two options to enable together.
Step 2: Choose a Logging Interval
The table below is a set of starting points drawn from common practice, not a product limit or a Mango recommendation. Treat it as a first guess and adjust once you can see how the data actually behaves.
| Data Type | Typical Poll Rate | Starting Log Interval | Rationale |
|---|---|---|---|
| Fast-changing analog (vibration, current) | 1–10 seconds | 10–30 seconds | High detail needed for diagnostics |
| Moderate analog (temperature, pressure) | 5–30 seconds | 30–60 seconds | Good balance of detail and storage |
| Slow-changing analog (tank level, ambient) | 30–60 seconds | 60–300 seconds | Values change slowly |
| Binary (pump status, door contact) | 5–30 seconds | When point value changes | Only transitions matter |
| Multistate (equipment mode, fault code) | 5–30 seconds | When point value changes | Only transitions matter |
| Alphanumeric (status messages) | Varies | When point value changes | Only new messages matter |
Rule of thumb: If you cannot articulate a reason to log more frequently than once per minute, log once per minute.
Display Precision
There is no decimal-places field on a Mango data point. Numeric display precision comes from the Format pattern on the Analog text renderer, set on the point editor's Text renderer properties tab; new numeric points start on Analog with a format of 0.00. The format governs display only — the stored value keeps its full precision either way — but showing more digits than the instrument can resolve misleads whoever reads the chart.
- Voltage (120.0V):
0.0 - Temperature HVAC (72.5°F):
0.0 - Laboratory temperature:
0.00 - Flow rate (125.3 GPM):
0.0 - Electrical current (15.25A):
0.00
Match the format to the measurement resolution. A sensor accurate to 0.1% gains nothing from ten digits after the point.
How Logging Feeds Downstream Features
- Trend charts and dashboards query the historian for time-range data. Higher logging frequency = smoother lines but heavier queries.
- Rollup statistics (min, max, average, sum, count) aggregate logged records. Change-based logging may leave some intervals with no samples of their own.
- KPI calculations depend on point history — consistent logging ensures accuracy.
- Scheduled reports pull historical data. High-frequency points produce longer reports.
Step 3: Estimate the Record Volume
The reliable way to plan storage is to count records first, then measure bytes on your own system. Record counts follow directly from the logging configuration:
| Logging configuration | Records per point per day |
|---|---|
| All data at 1-second polling | 86,400 |
| All data at 5-second polling | 17,280 |
| Interval at 10 seconds | 8,640 |
| Interval at 60 seconds | 1,440 |
| Interval at 15 minutes | 96 |
Multiply by point count for a daily total. Moving a 4,000-point system from 10-second to 60-second interval logging cuts the record count by roughly 83%, and storage falls in proportion.
Note
Bytes per record are not fixed. They depend on the point value backend you are running, the data type, and how well the values compress. Rather than working from a published per-record figure, measure your own growth: note the size of the point value store, wait a week under representative load, and measure again.
Step 4: Apply Settings Point by Point
Logging type, interval, interval logging type, and tolerance are properties of each data point, configured in the point editor. There is no system-wide logging default in Mango Core that new points inherit; the editor seeds them from the point's data type instead. Numeric gives Interval logging with interval logging type Average every 1 minute; Binary, Multistate and Alphanumeric give When point value changes. All four start with a tolerance of 0. A point created without going through the editor — a configuration import or a REST call that leaves these fields out — falls back to Mango's built-in object defaults of When point value changes, a 15-minute interval and Instant.
For bulk changes, use the bulk data point edit tools rather than opening points one at a time. Worked examples:
- Binary pump status: When point value changes. Only transitions are recorded.
- HVAC temperature sensor: Interval at 60 seconds, Instant. One record per minute is plenty for comfort monitoring.
- Generator voltage: Interval and point value changes at 15–30 seconds with a 2V tolerance. Enough detail for power-quality diagnostics without logging every poll.
- Flow rate feeding a daily total: Interval at 60 seconds with interval logging type Average, so each stored sample represents the whole minute rather than one instant in it.
- PLC status message: When point value changes. Status strings are often static for hours.
- Device heartbeat with a device-supplied timestamp: When point timestamp changes, so a repeated value with a fresh timestamp still proves the device is reporting.
Verification
- ☐ Open the point's history after a few intervals and confirm the sample spacing matches the logging type you selected
- ☐ For a point set to All data, hold the source value constant and confirm records keep appearing — that is the expected behaviour, and the reason this setting is expensive
- ☐ For a point set to When point value changes with a numeric tolerance, make a change smaller than the tolerance and confirm nothing is logged, then a larger one and confirm a record appears
- ☐ For Interval with Average, confirm the sample timestamps sit at interval centres rather than boundaries before building reports that assume boundary alignment
- ☐ For Interval and point value changes, confirm a quiet point still produces one record per interval
- ☐ Re-measure the point value store size after a week and compare against your record-count estimate
Troubleshooting
| Symptom | Likely Cause | Fix |
|---|---|---|
| Trend charts show long flat runs between samples | When point value changes on a stable point — working as designed | Switch to Interval and point value changes if the chart needs regular samples |
| Server slow or running out of disk | High-frequency All data logging on many points | Move to Interval logging, or lengthen the interval |
| An interval has no samples of its own | Nothing qualified for logging during that interval | Switch that point to an interval-based logging type. Note that rollups summarise the samples that exist; they do not manufacture samples for empty intervals |
| Logged values look smoothed and slightly time-shifted | Interval logging type is Average, which stores a computed statistic timestamped at the window centre | Use Instant if you need raw snapshots at interval boundaries |
| A point stopped logging but still shows a live value | Logging type is Do not log | Set a logging type. While Use data source and data point purge setting overrides (slower) is ticked (the default), the nightly purge will already have removed that point's stored history; with it off, only values older than the purge period are gone |
| Numeric point logs far less than expected | Tolerance is set too wide for the signal | Reduce the tolerance, or move to an interval-based logging type |
Summary
Point logging configuration is one of the most impactful settings in Mango. Pick from all six logging types rather than defaulting to the familiar two: Interval and point value changes for numeric points that need both regular spacing and prompt excursion capture, When point value changes for binary, multistate, and alphanumeric points, and Interval with an explicit interval logging type when you want a statistic rather than a snapshot. Match the interval to actual analysis requirements rather than to the polling frequency, and measure real storage growth on your own system instead of relying on published per-record sizes.