Periodic Tag Reset and Forced Reads: Ensuring Data Freshness in Long-Running IIoT Gateways [2026]

Here's a scenario every IIoT engineer has encountered: your edge gateway has been running flawlessly for 72 hours. Dashboards look great. Then maintenance swaps a temperature sensor on a machine, and the new sensor reads 5°C higher than the old one. Your gateway, using change-of-value detection, duly reports the new temperature. But what about the 47 other tags on that machine that haven't changed? Are they still accurate, or has the PLC rebooted during the sensor swap and your cached "last known values" are now stale?

This is the data freshness problem, and it's one of the most overlooked failure modes in industrial IoT deployments. The solution involves periodic tag resets and forced reads — a pattern that sounds simple but requires careful engineering to implement correctly.

The Problem with Pure Change Detection

Change-of-value (COV) detection is an excellent bandwidth optimization strategy. Instead of sending every data point from every polling cycle, the edge gateway compares each new reading against the stored previous value. If nothing changed, nothing is transmitted. For a machine with 200 tags polled every 5 seconds, this can reduce data volume by 85-95% during steady-state operation.

But COV detection introduces a subtle failure mode: what happens when you miss a change?

Missed Change Scenarios

1. PLC Power Cycle During Gateway Downtime

The gateway restarts after a firmware update. The PLC power-cycled while the gateway was down. The gateway comes back with its last known values in memory, compares against the PLC's current state (which may have reset to defaults), and if any values coincidentally match, those tags are never reported.

2. Simultaneous Value Return

A temperature drops from 72°C to 65°C while the gateway is disconnected, then climbs back to 72°C before the gateway reconnects. The gateway compares its cached 72°C against the current 72°C, sees no change, and never reports that the machine went through a thermal excursion.

3. Clock Drift Accumulation

Over days of continuous operation, minor clock drift between the gateway and PLC can cause polling cycles to shift. Tags with long intervals (60+ seconds) might occasionally be skipped due to timing edge cases. Without periodic forced reads, these skipped polls accumulate into gaps.

4. Communication Error Recovery

After a network partition heals, the gateway re-establishes its PLC connection. All tags show their current values, but the gateway's cached values may be from before the partition. If values haven't changed across the partition boundary, they're never re-reported.

The Hourly Reset Pattern

The most effective solution is a periodic full reset of the tag cache, followed by a forced read of every tag. Here's how it works:

How It Works

1. Track the current hour. On each polling cycle, check the system clock. When the hour changes (e.g., from 14:xx to 15:xx), trigger a reset.

2. Clear all tag caches. For every tag in the configuration, clear:

   • The "read at least once" flag
   • The last read timestamp
   • The last read result (success/error)
   • All cached values
   • Delivery timestamps

3. Force a full read on the next cycle. With all caches cleared, the next polling cycle treats every tag as if it's being read for the first time. All values are transmitted regardless of whether they've changed.

Why Hourly?

Hourly strikes the right balance between data freshness and bandwidth efficiency:

Reset Interval	Data Volume Impact	Freshness Guarantee	Practical Assessment
Every cycle (no COV)	Very high (+500-1000%)	Perfect	Wastes bandwidth, often impractical on cellular
Every 5 minutes	High (+100-200%)	Excellent	Overkill for most applications
Every hour	Low (+3-5%)	Very good	Optimal for most deployments
Every 8 hours	Negligible	Acceptable	Risk of prolonged stale data
Never	Zero	None	Dangerous for long-running gateways

An hourly reset on a 200-tag system adds roughly 200 extra data transmissions per hour — negligible compared to the thousands of change-triggered transmissions during active production.

Dependent Tag Cascade

The hourly reset has an important interaction with dependent tag chains. In many PLC configurations, certain "parent" tags trigger reads of "child" tags when they change. For example:

• Parent tag: machine_state (running/stopped/fault)
• Dependent tags: fault_code, fault_timestamp, fault_description

The dependent tags are only read when machine_state changes. During an hourly reset, the parent's cache is cleared, which forces a read. If the parent's new value differs from its pre-reset cached value (which it might not, since the cache was just cleared), the dependents are also triggered.

Key design decision: During a forced read, dependent tags should be read unconditionally — not waiting for the parent to change. This ensures the complete tag tree is refreshed, not just the top-level tags.

Calculated Tag Refresh

Some edge gateways support calculated tags — derived values computed from raw PLC data. A common example is extracting individual alarm bits from a 16-bit alarm word:

• Raw tag: alarm_word (uint16, value 0x0042)
• Calculated tag: high_temp_alarm = bit 1 of alarm_word (true)
• Calculated tag: low_pressure_alarm = bit 6 of alarm_word (true)

During an hourly reset, both the raw tag and all its calculated derivatives must be recomputed and retransmitted. Simply re-reading the raw tag isn't enough — the bit extraction and delivery logic must also fire.

Implementation Considerations

Thread Safety

The hourly reset interacts with multiple threads in a typical edge gateway:

• Polling thread: Reads tags from PLCs at configured intervals
• MQTT delivery thread: Transmits data to the cloud broker
• Configuration thread: Handles remote configuration updates

The reset must be atomic with respect to the polling cycle. You cannot clear a tag's cache while the polling thread is mid-read — this creates a race condition where the polling thread might see a partially cleared cache and misinterpret the data.

Pattern: Perform the reset at the beginning of a polling cycle, before any reads start. Check the hour at the top of each cycle, clear caches if needed, then proceed with normal reads. Since caches are cleared, all tags will be read and delivered as if for the first time.

Monotonic vs. Wall Clock

Use the wall clock (real-time clock) for the hourly check, not a monotonic timer. Here's why:

• Monotonic timers don't account for NTP corrections. If the gateway's clock jumps forward by a few seconds after an NTP sync, a monotonic timer wouldn't notice and might drift.
• Wall clock naturally aligns resets to consistent time boundaries. "Top of every hour" is easy to reason about when debugging data gaps.

However, use monotonic timestamps for measuring intervals between reads. The wall clock can jump backward (NTP adjustment), which would make interval calculations return negative values and cause immediate re-reads of everything.

Handling Long Read Cycles

On gateways with many tags (500+) or slow PLC connections (Modbus RTU at 9600 baud), a full read cycle can take several minutes. The hourly reset should not restart mid-cycle if the hour changes while reads are in progress.

Solution: Check the hour once at the start of each top-level read cycle. If the hour changed, perform the reset. Then proceed with the full read. Even if the read takes 10 minutes and spans into the next hour, don't reset again until the following top-of-cycle check detects another hour change.

Memory Impact

Clearing tag caches is essentially zeroing out the last_values array for each tag. On a 200-tag system with 32-bit values, this is about 800 bytes of memory — trivial on any modern edge gateway.

The real memory concern is the delivery buffer. An hourly forced read generates a burst of outbound data. If the MQTT connection is down during the reset, all forced-read values must be buffered locally. Ensure your store-and-forward buffer has sufficient capacity for at least one full forced-read cycle (all tags × all values).

For a 200-tag system with an average of 20 bytes per tag message (including overhead), that's approximately 4KB per forced-read burst. Even a modest 64KB store-and-forward buffer can hold 16 full bursts without overflow.

When to Go Beyond Hourly

Some scenarios demand more aggressive freshness guarantees:

Safety-Critical Monitoring

Tags related to safety systems (emergency stops, safety interlocks, gas detection) should never rely on change detection alone. Poll these at maximum frequency and always transmit, regardless of whether the value changed. The bandwidth cost of a few extra safety-critical data points per second is insignificant compared to the cost of missing a safety event.

Multi-PLC Synchronization

When an edge gateway monitors multiple PLCs that interact (e.g., an upstream extruder feeding a downstream die), force reads on all PLCs simultaneously at the top of each hour. This ensures cross-machine data is temporally consistent. Staggered resets across PLCs can make it appear that upstream and downstream values are misaligned, complicating root cause analysis.

Post-Maintenance Reads

After any maintenance event (detected via a maintenance-mode tag or manually triggered), force an immediate full read of all tags. Don't wait for the next hourly cycle. Maintenance often involves sensor replacement, wiring changes, and PLC program updates — all of which can change tag values without triggering normal change detection.

Measuring Data Freshness

How do you know your freshness strategy is working? Track two metrics:

Last Read Time (LRT)

For each tag, record the monotonic timestamp of the last successful read from the PLC. Expose this in your gateway's status report. If any tag's LRT is more than 2× its configured interval, something is wrong — the tag is being skipped.

Last Delivery Time (LDT)

For each tag, record the monotonic timestamp of the last time the tag's value was actually delivered (either to a batch or directly to MQTT). The gap between LRT and LDT tells you how long data sits in the gateway before being transmitted.

Healthy system: LDT should be within seconds of LRT for critical tags, and within the batch timeout period (typically 60 seconds) for batched tags.

Unhealthy system: LDT lagging LRT by hours means your change detection is too aggressive and values aren't being delivered because they haven't changed. The hourly reset fixes this.

How machineCDN Handles Data Freshness

machineCDN's edge gateway implements the hourly reset pattern natively, with intelligent handling of the subtleties described above. The platform tracks both LRT and LDT for every tag across every connected device, making data freshness visible in the fleet management dashboard.

When a forced read triggers, machineCDN's binary batching system efficiently packs all tag values into minimal-overhead telemetry frames. The paged store-and-forward buffer ensures that even if the cloud connection is momentarily interrupted during the burst, no data is lost.

For safety-critical tags, machineCDN supports do_not_batch mode — these values bypass the batching layer entirely and are transmitted immediately via MQTT QoS 1, with delivery confirmation.

---

Key Takeaways

1. Change-of-value detection saves bandwidth but creates data freshness risk. Without periodic resets, your gateway can go hours or days without confirming that cached values are still accurate.

2. Hourly tag cache resets strike the optimal balance — adding only 3-5% data overhead while guaranteeing no value goes more than an hour without being confirmed.

3. Clear everything during a reset: the read-once flag, last values, last timestamps, and last status. A partial reset defeats the purpose.

4. During forced reads, trigger dependent and calculated tag chains unconditionally. Don't rely on parent changes to cascade reads during a refresh cycle.

5. Use wall clock for hourly checks, monotonic clock for interval timing. They serve different purposes and mixing them causes bugs.

6. Safety-critical tags should always transmit — never gate them behind change detection, regardless of bandwidth concerns.

7. Track LRT and LDT for every tag. These two timestamps tell you everything about your gateway's data freshness health.

Data freshness isn't glamorous, but it's the difference between a monitoring system you can trust and one that silently goes stale. The cost of implementing hourly resets is negligible. The cost of not implementing them is a maintenance team making decisions based on data that's hours — or days — old.