Retention policies for Zigbee telemetry: decide before your storage fills up

A Zigbee2MQTT setup can begin with a few sensors and a small database on a Raspberry Pi, NAS, or home server. At first, telemetry storage barely registers: a temperature reading every few minutes, a contact event when a door opens, and an occasional battery update.

Then the setup grows. More rooms get sensors. Smart plugs report power frequently. An energy meter sends cumulative consumption and instantaneous load. You add debug fields, link-quality values, or raw MQTT payloads because they may be useful later. Months pass, and the database becomes one of the larger components on the host.

That growth is not a database bug. Time-series data is designed to accumulate observations over time. If you want historical Zigbee data to remain useful without keeping every high-resolution point indefinitely, you need a retention strategy.

This article explains what retention policies and downsampling are, how they work together, and how to make a sensible decision for a self-hosted or managed telemetry setup.

Time-series data has no natural endpoint

A time series is a set of timestamped measurements: temperature at 08:00, 08:05, and 08:10; power usage every few seconds; or battery level whenever a device reports it. Unlike a configuration database, its normal behaviour is to grow as long as devices continue sending messages.

The storage cost depends on more than the number of devices. Reporting interval, number of fields, tags or labels, retained raw payloads, and database indexing all influence it. A battery-powered contact sensor that reports only on state changes has a very different footprint from a mains-powered plug reporting power every few seconds.

For a small setup, keeping everything can be a reasonable deliberate choice. But it should be a choice, not the default you inherit because no expiry was configured.

The operational consequence is simple: without a plan, the question is not whether storage will grow, but how quickly it will grow and what will happen when the host approaches capacity. On a dedicated server with monitoring, backups, and available storage, that may be manageable. On a small SD-card-based host, it can become an avoidable failure mode.

Disk pressure affects more than the telemetry database. It can prevent services from writing logs or temporary files, make backups fail, and leave little room for normal database maintenance. The appropriate response is capacity planning, monitoring, and retention—not assuming a particular database will fail in a particular way.

Retention decides how long raw data remains

A retention policy defines the period for which data is kept before it becomes eligible for deletion. In InfluxDB terminology, a retention policy or bucket retention period governs how long the database retains data; data older than that period can be removed.

For Zigbee telemetry, a retention policy answers a practical question: how much detail do you need at each age of the data?

A useful policy might look like this:

Data age	Resolution retained	Typical use
Last 14 days	Raw device messages or short intervals	Troubleshooting, automation tuning, recent incidents
14 days to 6 months	Hourly aggregates	Daily temperature patterns, battery trends, energy behaviour
6 months to 2 years	Daily aggregates	Seasonal comparisons and long-term baselines

These periods are examples, not a universal configuration. A mains power monitor may justify detailed recent data. A door contact sensor usually needs an event log rather than hourly averages. A temperature sensor may be adequately represented by hourly values after the period in which you normally troubleshoot heating or ventilation issues.

Retention is also a data-governance decision. Once raw data expires, it is no longer available for a later investigation. That is often acceptable, but it should be intentional. Before setting a short raw-data window, consider the longest period in which you usually discover an issue after it occurred.

Downsampling preserves the trend

Retention alone answers, “When do we delete data?” Downsampling answers, “What summary should we keep first?”

Downsampling takes many detailed observations and produces a lower-resolution series. For example, a system can calculate an hourly average, minimum, maximum, first value, last value, sum, or count from the original readings. The right aggregate depends on the measurement.

For a room-temperature sensor, an hourly average may be useful for broad trends, while hourly minimum and maximum preserve information about heating cycles that an average could hide. For energy data, a sum or change in a cumulative meter may be more appropriate than an average. For a door sensor, aggregation is often the wrong model entirely: the individual open and close events are the history you care about.

InfluxDB’s own documentation describes this common pattern: write high-precision data into a short-retention destination, create a downsampling task or continuous query that writes aggregated values into longer-retention storage, then allow the detailed source data to expire.

The ordering matters. If data expires before the downsampling job has processed it, the long-term series contains gaps. InfluxDB specifically advises scheduling downsampling tasks before data in a finite-retention bucket is dropped.

A practical temperature example is:

• Keep five-minute readings for 30 days.
• Produce hourly average, minimum, and maximum values.
• Keep those hourly values for a year.
• Produce daily average, minimum, and maximum values for longer seasonal comparison.

That design lets you inspect the detail of a recent heating issue while retaining enough information to compare this winter with the previous one.

Why operating a DIY policy takes care

InfluxDB, Grafana, and other self-hosted tools can support a robust telemetry setup. They are valid choices, especially when you need full control over storage, custom dashboards, local-only processing, or integrations beyond a focused device-history product.

The work is not limited to creating one retention setting, however. A dependable setup usually needs several connected decisions:

• Which fields are stored, and at what message frequency?
• Which measurements are raw events versus values suitable for aggregation?
• Which aggregates preserve the information you will actually use?
• When do downsampling jobs run, and how do you confirm they completed?
• Which data stores expire, and when?
• How do you monitor database and host disk capacity?
• How are the database and its configuration backed up and restored?

InfluxDB 1.x and 2.x use different operational models. InfluxDB 1.x documentation uses retention policies and continuous queries; InfluxDB 2.x documentation describes bucket retention periods and scheduled tasks for downsampling. That does not make either version unsuitable, but copied configuration from a guide for a different version can be misleading.

The risk is usually not that retention is inherently difficult. The risk is that it becomes invisible after initial setup. A task can be misconfigured, a new device field can increase write volume, or a dashboard can continue querying a raw measurement after it should query the aggregated one. If nobody checks storage growth and job outcomes, the first alert may be a nearly full disk.

A good self-hosted setup therefore monitors the host as well as the data. InfluxDB provides tools to inspect disk usage by shard, database, retention policy, and measurement, which can help identify where capacity is being used. General disk-utilisation monitoring is equally important: the aim is to see a growth trend early, not to wait for an outage.

Managed history changes the operational boundary

A managed telemetry service does not remove the need to decide what information is useful. You still control your Zigbee network, device placement, Zigbee2MQTT configuration, and local automations. You still need to understand whether a battery device is expected to be quiet or whether a sensor is reporting an implausible measurement.

What changes is who operates the history pipeline. Instead of running a database, defining its storage lifecycle, maintaining dashboard queries, and watching the host’s disk capacity specifically for telemetry, you use the service’s supported ingestion and history workflow.

For ZigStream, verify the current product retention and data-handling policy before making claims about exact retention periods or long-term aggregate resolution. The current history interface does automatically return one hourly point for 7-day and 30-day history ranges. That is a documented query-resolution behaviour; it should not be presented as a promise about storage retention beyond those ranges.

This distinction matters. “Managed” should not mean vague or automatic claims about every storage outcome. Before choosing any managed service, confirm:

• Which device data is ingested and visible in history.
• Available time ranges and query resolution.
• Retention periods and deletion behaviour.
• Export, access, and account-data options that matter to your setup.
• What remains your responsibility locally, including Zigbee2MQTT availability and device configuration.

A managed service is a strong fit when your main goal is to inspect and act on device history without operating dedicated time-series infrastructure. A DIY stack remains a strong fit when local control, a bespoke data model, or deep customisation is worth the operational responsibility.

Choose a policy before storage becomes urgent

Retention policies are not merely a database housekeeping feature. They determine the detail you have when investigating a recent issue, the trend information you preserve for longer periods, and the storage burden your telemetry system creates.

For a self-hosted stack, start small but explicitly: identify the high-volume devices, decide how long raw data is genuinely useful, create the aggregates that match each metric, and set an alert well before the host reaches capacity. Test that downsampled data exists before the raw data window expires.

If you prefer a managed history workflow, evaluate its documented ranges, resolution, and data policy with the same care. ZigStream can provide device-history queries without requiring you to run a separate time-series database, while Zigbee2MQTT remains the local source of your device data.

The useful question is not whether raw telemetry should be kept forever. It is whether your retained data will still answer the questions you expect to ask later—without making storage management another permanent task.