If you're sending PLC tag values as JSON from edge gateways to the cloud, you're wasting 80–90% of your bandwidth. On a cellular-connected factory floor with dozens of machines, that's the difference between a $50/month data plan and a $500/month one — and the difference between sub-second telemetry and multi-second lag.

This guide breaks down binary telemetry encoding: how to pack industrial data efficiently at the edge, preserve type fidelity across the wire, and design batch grouping strategies that survive unreliable networks.

If you've ever watched a gateway hammer a PLC with fixed 100ms polls across 200+ tags — while 90% of those values haven't changed since the shift started — you've seen the most common mistake in industrial data acquisition.

Naive polling wastes bus bandwidth, increases response times for the tags that actually matter, and can destabilize older PLCs that weren't designed for the throughput demands of modern IIoT platforms. But the alternative isn't obvious. How do you poll "smart"?

This guide covers the polling strategies that separate production-grade IIoT systems from prototypes: change-of-value detection, register grouping, dependent tag chains, and interval-aware scheduling. We'll look at concrete timing numbers, Modbus and EtherNet/IP specifics, and the failure modes you'll hit in real plants.

If you're polling a PLC with Modbus and reading one register at a time, you're wasting 80% of your bus time on protocol overhead. Every Modbus transaction carries a fixed cost — framing bytes, CRC calculations, response timeouts, and turnaround delays — regardless of whether you're reading 1 register or 120. The math is brutal: reading 60 holding registers individually means 60 request/response cycles. Coalescing them into a single read means one cycle that returns all 60 values.

This article breaks down the mechanics of contiguous register optimization, shows you exactly how to implement it, and explains why it's the single highest-impact change you can make to your IIoT data collection architecture.

The Hidden Cost of Naive Polling​

Let's do the math on a typical Modbus RTU link at 9600 baud.

A single Modbus RTU read request (function code 03) for one holding register looks like this:

The response for a single register:

That's 15 bytes on the wire for 2 bytes of actual data — 13.3% payload efficiency.

Now add the silent interval between frames. Modbus RTU requires a minimum 3.5-character gap (roughly 4ms at 9600 baud) between transactions. Plus a typical slave response time of 5–50ms. For a conservative 20ms response delay:

• Wire time per transaction: ~15.6ms (15 bytes × 1.04ms/byte at 9600 baud)
• Turnaround + gap: ~24ms
• Total per register: ~39.6ms
• 60 registers individually: ~2,376ms (2.4 seconds!)

Now, reading those same 60 registers in one contiguous block:

• Request: 8 bytes (unchanged)
• Response: 1 + 1 + 1 + 120 + 2 = 125 bytes
• Wire time: ~138.5ms
• One turnaround: ~24ms
• Total: ~162.5ms

That's 14.6x faster for the same data. On a serial bus where you might have multiple slave devices and hundreds of tags, this is the difference between a 1-second polling cycle and a 15-second one.

Understanding Modbus Address Spaces​

Before you can coalesce reads, you need to understand that Modbus defines four distinct address spaces, each requiring a different function code:

Critical rule: you cannot coalesce reads across function codes. A request using FC 03 (holding registers) cannot include addresses that belong to FC 04 (input registers). They're physically different memory areas in the PLC. Any optimization algorithm must first partition tags by their function code, then optimize within each partition.

The address encoding convention (where 400001 maps to holding register 0) is a common source of bugs. When you see address 404002 in a tag configuration, the leading 4 indicates holding registers (FC 03), and the actual Modbus address sent on the wire is 4002. Your coalescing logic needs to strip the prefix for wire protocol but keep it for function code selection.

The Coalescing Algorithm​

The core idea is simple: sort tags by address within each function code group, then merge adjacent tags into single read operations. Here's the logic:

Step 1: Sort Tags by Address​

Your tag list must be ordered by Modbus address. If tags arrive in arbitrary order (as they typically do from configuration files), sort them first. This is a one-time cost at startup.

Tag: "Delivery Temp"    addr: 404002  type: float  ecount: 2
Tag: "Mold Temp"        addr: 404004  type: float  ecount: 2
Tag: "Return Temp"      addr: 404006  type: float  ecount: 2
Tag: "Flow Value"        addr: 404008  type: float  ecount: 2
Tag: "System Standby"   addr: 404010  type: float  ecount: 2

All five tags use FC 03 (holding registers). Their addresses are contiguous: 4002, 4004, 4006, 4008, 4010. Each occupies 2 registers (32-bit float = 2 × 16-bit registers).

Step 2: Walk the Sorted List and Build Read Groups​

Starting from the first tag, accumulate subsequent tags into the same group as long as:

1. Same function code — The address prefix maps to the same Modbus command
2. Contiguous addresses — The next tag's address equals the current head address plus accumulated register count
3. Same polling interval — Tags with different intervals should be in separate groups (a 1-second tag shouldn't force a 60-second tag to be read every second)
4. Register count limit — Modbus protocol limits a single read to 125 registers (for FC 03/04) or 2000 coils (for FC 01/02). In practice, keeping it under 50–120 registers per read improves reliability on noisy links

When any condition fails, finalize the current group, issue the read, and start a new group with the current tag as head.

Step 3: Dispatch the Coalesced Read​

For our five temperature tags:

Single coalesced read:
  Function Code: 03
  Starting Address: 4002
  Quantity: 10 registers (5 tags × 2 registers each)

One transaction returns all 10 registers. The response buffer contains the raw bytes in order — you then walk through the buffer, extracting values according to each tag's type and element count.

Step 4: Unpack Values from the Response Buffer​

This is where data types matter. The response is a flat array of 16-bit words. For each tag in the group, you consume the correct number of words:

• uint16/int16: 1 word, direct assignment
• uint32/int32: 2 words, combine as (word[1] << 16) | word[0] (check your PLC's byte order!)
• float32: 2 words, requires IEEE 754 reconstruction — modbus_get_float() in libmodbus or manual byte swapping
• bool/int8/uint8: 1 word, mask with & 0xFF

Response buffer: [w0, w1, w2, w3, w4, w5, w6, w7, w8, w9]
                  |-------|  |-------|  |-------|  |-------|  |-------|
                  Tag 0      Tag 1      Tag 2      Tag 3      Tag 4
                  float      float      float      float      float

Handling Gaps in the Address Space​

Real-world tag configurations rarely have perfectly contiguous addresses. You'll encounter gaps:

Tag A: addr 404000, ecount 2
Tag B: addr 404004, ecount 2   ← gap of 2 registers at 404002
Tag C: addr 404006, ecount 2

You have two choices:

1. Read through the gap — Issue one read from 4000 to 4007 (8 registers), and simply ignore the 2 garbage registers at offset 2–3. This is usually optimal if the gap is small (< 10 registers). The cost of reading extra registers is almost zero.

2. Split into separate reads — If the gap is large (say, 50+ registers), two smaller reads are more efficient than one bloated read full of data you'll discard.

A good heuristic: if the gap is less than the per-transaction overhead expressed in registers, read through it. At 9600 baud, a transaction costs ~24ms of overhead, equivalent to reading about 12 extra registers. So gaps under 12 registers should be read through.

Handling Mixed Polling Intervals​

Not all tags need the same update rate. Temperature setpoints might only need reading every 60 seconds, while pump status flags need 1-second updates. Your coalescing algorithm must handle this.

The approach: partition by interval before coalescing by address. Tags with interval: 1 form one pool, tags with interval: 60 form another. Within each pool, apply address-based coalescing normally.

During each polling cycle, check whether enough time has elapsed since a tag's last read. If a tag isn't due for reading, skip it — but this means breaking the contiguous chain:

Cycle at T=30s:
  Tag A (interval: 1s)  → READ    addr: 404000
  Tag B (interval: 60s) → SKIP    addr: 404002  ← breaks contiguity
  Tag C (interval: 1s)  → READ    addr: 404004

Tags A and C can't be coalesced because Tag B sits between them and isn't being read. The algorithm must detect the break and issue two separate reads.

Optimization: If Tag B is cheap to read (1–2 registers), consider reading it anyway and discarding the result. The overhead of an extra 2 registers in a contiguous block is far less than the overhead of a separate transaction.

Modbus RTU vs TCP: Different Optimization Priorities​

Modbus RTU (Serial)​

• Bottleneck: Baud rate and turnaround time
• Priority: Minimize transaction count at all costs
• Flush between reads: Always flush the serial buffer before starting a new poll cycle to clear any stale or corrupted data
• Retry logic: Implement 2–3 retries per read with short delays — serial links are noisy, but a retry is still cheaper than dropping data
• Response timeout: Configure carefully. Too short (< 50ms) causes false timeouts; too long (> 500ms) kills throughput. 100–200ms is typical for most PLCs
• Byte/character timeout: Set to ~5ms at 9600 baud. This detects mid-frame breaks

Modbus TCP​

• Bottleneck: Connection management, not bandwidth
• Priority: Keep connection alive and reuse it
• Connection recovery: Detect ETIMEDOUT, ECONNRESET, ECONNREFUSED, EPIPE, and EBADF — these all mean the connection is dead and needs reconnecting
• No inter-frame gaps: TCP handles framing, so back-to-back transactions are fine
• Default port: 502, but some PLCs use non-standard ports — make this configurable

Real-World Configuration Example​

Here's a practical tag configuration for a temperature control unit using Modbus RTU, with 32 holding registers read as IEEE 754 floats:

{
  "protocol": "modbus-rtu",
  "batch_timeout": 60,
  "link": {
    "port": "/dev/rs232",
    "base_addr": 1,
    "baud": 9600,
    "parity": "N",
    "data_bits": 8,
    "stop_bits": 2,
    "byte_timeout_ms": 5,
    "response_timeout_ms": 200
  },
  "tags": [
    {"name": "Delivery Temp",    "addr": 404002, "type": "float", "ecount": 2, "interval": 60},
    {"name": "Mold Temp",        "addr": 404004, "type": "float", "ecount": 2, "interval": 60},
    {"name": "Return Temp",      "addr": 404006, "type": "float", "ecount": 2, "interval": 60},
    {"name": "Flow Value",       "addr": 404008, "type": "float", "ecount": 2, "interval": 60},
    {"name": "Heater Output %",  "addr": 404054, "type": "float", "ecount": 2, "interval": 60},
    {"name": "Cooling Output %", "addr": 404056, "type": "float", "ecount": 2, "interval": 60},
    {"name": "Pump Status",      "addr": 404058, "type": "float", "ecount": 2, "interval": 1, "immediate": true},
    {"name": "Heater Status",    "addr": 404060, "type": "float", "ecount": 2, "interval": 1, "immediate": true},
    {"name": "Vent Status",      "addr": 404062, "type": "float", "ecount": 2, "interval": 1, "immediate": true}
  ]
}

The coalescing algorithm would produce:

• Group 1 (interval: 60s): Read 404002–404009 → 4 tags, 8 registers, one read
• Group 2 (interval: 60s): Read 404054–404057 → 2 tags, 4 registers, one read (non-contiguous with Group 1, separate read)
• Group 3 (interval: 1s): Read 404058–404063 → 3 tags, 6 registers, one read

Three transactions instead of nine. At 9600 baud, that saves ~240ms per polling cycle — which adds up to minutes of saved bus time per hour.

Common Pitfalls​

1. Ignoring Element Count​

A float tag occupies 2 registers, not 1. If your coalescing logic treats every tag as 1 register, your contiguity check will be wrong and you'll read corrupt data. Always use addr + elem_count when calculating the next expected address.

2. Byte Order Confusion​

Different PLCs use different byte orders for 32-bit values. Some use big-endian word order (ABCD), others use little-endian (DCBA), and some use mid-endian (BADC or CDAB). If your float values come back as NaN or astronomically wrong numbers, byte order is almost certainly the issue. Test with a known value (like a temperature setpoint you can verify on the HMI) and adjust.

3. Not Handling Read Failures Gracefully​

When a coalesced read fails, the entire group fails. Don't panic — just flush the serial buffer, log the error, and retry up to 3 times. If the error is a connection-level failure (timeout, connection reset), close and reopen the Modbus context rather than hammering a dead link.

4. Exceeding the Register Limit​

The Modbus specification allows up to 125 registers per read (FC 03/04) and 2000 coils (FC 01/02). In practice, many PLCs choke at lower limits — some only handle 50–60 registers per request reliably. Cap your coalesced read size at a conservative number (50 is safe for virtually all PLCs) and test with your specific hardware.

5. Mixing Immediate and Batched Tags​

Some tags (like alarm states, emergency stops, or pump status changes) need to be sent to the cloud immediately — not held in a batch for 60 seconds. These "do not batch" tags should be delivered to the MQTT layer as soon as they're read, bypassing the batching pipeline. But they can still participate in coalesced reads; the immediate/batched distinction is about delivery, not reading.

How machineCDN Handles This​

The machineCDN edge daemon implements all of these optimizations natively. Tags are automatically sorted by address at configuration load time, coalesced into contiguous read groups respecting function code boundaries and interval constraints, and read with retry logic tuned for industrial serial links. Both Modbus RTU and Modbus TCP are supported with automatic protocol detection — the daemon probes the PLC at startup to determine the device type, serial number, and communication protocol before configuring the polling loop.

The result: a single edge gateway on a Teltonika RUT9 industrial router can poll hundreds of tags from multiple devices with sub-second cycle times, even on 9600 baud serial links.

Conclusion​

Contiguous register optimization is not optional for production IIoT deployments. The performance difference between naive per-register polling and properly coalesced reads is an order of magnitude. The algorithm is straightforward — sort by address, group by function code and interval, cap at the register limit, and handle gaps intelligently. Get this right, and your serial bus goes from bottleneck to barely loaded.

The tags are just data points. How you read them determines whether your IIoT system is a science project or production infrastructure.

Factory networks go down. Cellular modems lose signal. Cloud endpoints hit capacity limits. VPN tunnels drop for seconds or hours. And through all of it, your PLCs keep generating data that cannot be lost.

Store-and-forward buffering is the difference between an IIoT platform that works in lab demos and one that survives a real factory. This guide covers the engineering patterns — memory buffer design, connection watchdogs, batch queuing, and delivery confirmation — that keep telemetry flowing even when the network doesn't.

Commissioning a new IIoT gateway on a factory floor usually starts the same way: someone hands you an IP address, a spreadsheet of tag names, and the vague instruction "connect to the PLC." No documentation about which protocol the PLC speaks. No model number. Sometimes the IP address is wrong.

Manually probing devices is tedious and error-prone. Does this PLC speak EtherNet/IP or Modbus TCP? Is it a Micro800 or a CompactLogix? What registers hold the serial number? You can spend an entire day answering these questions for a single production cell.

Automated device discovery solves this by systematically probing known protocol endpoints, identifying the device type, extracting identification data (serial numbers, firmware versions), and determining the correct communication parameters — all without human intervention.

This guide covers the engineering details: protocol probe sequences, identification register maps, fallback logic, and the real-world edge cases that trip up naive implementations.

Your edge gateway reads 200 tags from a PLC every second. The MQTT connection to your cloud broker drops for 3 minutes because someone bumped the cellular antenna. What happens to the 36,000 data points collected during the outage?

If your answer is "they're gone," you have a toy system, not an industrial one.

Reliable telemetry delivery is the hardest unsolved problem in most IIoT architectures. Everyone focuses on the protocol layer — Modbus reads, EtherNet/IP connections, OPC-UA subscriptions — but the real engineering is in what happens between reading a value and confirming it reached the cloud. This article breaks down the buffer architecture that makes zero-data-loss telemetry possible on resource-constrained edge hardware.

The Problem: Three Asynchronous Timelines​

In any edge-to-cloud telemetry system, you're managing three independent timelines:

1. PLC read cycle — Tags are read at fixed intervals (1s, 60s, etc.). This never stops. The PLC doesn't care if your cloud connection is down.

2. Batch collection — Raw tag values are grouped into batches by timestamp and device. Batches accumulate until they hit a size limit or a timeout.

3. MQTT delivery — Batches are published to the broker. The broker acknowledges receipt. At QoS 1, the MQTT library handles retransmission, but only if you give it data in the right form.

These three timelines run independently. The PLC read loop runs on a tight 1-second cycle. Batch finalization might happen every 30–60 seconds. MQTT delivery depends on network availability. If any one of these stalls, the others must keep running without data loss.

This is fundamentally a producer-consumer problem with a twist: the consumer (MQTT) can disappear for minutes at a time, and the producer (PLC reads) cannot slow down.

The Batch Layer: Grouping Values for Efficient Transport​

Raw tag values are tiny — a temperature reading is 4 bytes, a boolean is 1 byte. Sending each value as an individual MQTT message would be absurdly wasteful. Instead, values are collected into batches — structured payloads that contain multiple timestamped readings from one or more devices.

Batch Structure​

A batch is organized as a series of groups, where each group represents one polling cycle (one timestamp, one device):

Batch
├── Group 0: { timestamp: 1709284800, device_type: 5000, serial: 12345 }
│   ├── Value: { id: 2, values: [72.4] }          // Delivery Temp
│   ├── Value: { id: 3, values: [68.1] }          // Mold Temp
│   └── Value: { id: 5, values: [12.6] }          // Flow Value
├── Group 1: { timestamp: 1709284860, device_type: 5000, serial: 12345 }
│   ├── Value: { id: 2, values: [72.8] }
│   ├── Value: { id: 3, values: [68.3] }
│   └── Value: { id: 5, values: [12.4] }
└── ...

Dual-Format Encoding: JSON vs Binary​

Production edge daemons typically support two encoding formats for batches, and the choice has massive implications for bandwidth:

JSON format:

{
  "groups": [
    {
      "ts": 1709284800,
      "device_type": 5000,
      "serial_number": 12345,
      "values": [
        {"id": 2, "values": [72.4]},
        {"id": 3, "values": [68.1]}
      ]
    }
  ]
}

Binary format (same data):

Header:  F7                           (1 byte - magic)
Groups:  00 00 00 01                  (4 bytes - group count)
Group 0: 65 E5 A0 00                  (4 bytes - timestamp)
         13 88                        (2 bytes - device type: 5000)
         00 00 30 39                  (4 bytes - serial number)
         00 00 00 02                  (4 bytes - value count)
Value 0: 00 02                        (2 bytes - tag id)
         00                           (1 byte  - status: OK)
         01                           (1 byte  - values count)
         04                           (1 byte  - element size: 4 bytes)
         42 90 CC CD                  (4 bytes - float 72.4)
Value 1: 00 03
         00
         01
         04
         42 88 33 33                  (4 bytes - float 68.1)

The JSON version of this payload: ~120 bytes. The binary version: ~38 bytes. That's a 3.2x reduction — and on a metered cellular connection at $0.01/MB, that savings compounds quickly when you're transmitting every 30 seconds 24/7.

The binary format uses a simple TLV-like structure: magic byte, group count (big-endian uint32), then for each group: timestamp (uint32), device type (uint16), serial number (uint32), value count (uint32), then for each value: tag ID (uint16), status byte, value count, element size, and raw value bytes. No field names, no delimiters, no escaping — just packed binary data.

Batch Finalization Triggers​

A batch should be finalized (sealed and queued for delivery) when either condition is met:

1. Size limit exceeded — When the accumulated batch size exceeds a configured maximum (e.g., 500KB for JSON, or when the binary buffer is 90%+ full). The 90% threshold for binary avoids the edge case where the next value would overflow the buffer.

2. Collection timeout expired — When elapsed time since the batch started exceeds a configured maximum (e.g., 60 seconds). This ensures data flows even during quiet periods with few value changes.

if (elapsed_seconds > max_collection_time) → finalize
if (batch_size > max_batch_size)          → finalize

Both checks happen after every group is closed (after every polling cycle). This means finalization granularity is tied to your polling interval — if you poll every 1 second and your batch timeout is 60 seconds, each batch will contain roughly 60 groups.

The "Do Not Batch" Exception​

Some values are too important to wait for batch finalization. Equipment alarms, pump state changes, emergency stops — these need to reach the cloud immediately. These tags are flagged as "do not batch" in the configuration.

When a do-not-batch tag changes value, it bypasses the normal batch pipeline entirely. A mini-batch is created on the spot — containing just that single value — and pushed directly to the outgoing buffer. This ensures sub-second cloud visibility for critical state changes, while bulk telemetry still benefits from batch efficiency.

Tag: "Pump Status"     interval: 1s    do_not_batch: true
Tag: "Heater Status"   interval: 1s    do_not_batch: true
Tag: "Delivery Temp"   interval: 60s   do_not_batch: false  ← normal batching

The Buffer Layer: Surviving Disconnections​

This is where most IIoT implementations fail. The batch layer produces data. The MQTT layer consumes it. But what sits between them? If it's just an in-memory queue, you'll lose everything on disconnect.

Page-Based Ring Buffer Architecture​

The production-grade answer is a page-based ring buffer — a fixed-size memory region divided into equal-sized pages that cycle through three states:

States:
  FREE  → Available for writing
  WORK  → Currently being filled with batch data
  USED  → Filled, waiting for MQTT delivery

Lifecycle:
  FREE → WORK (when first data is added)
  WORK → USED (when page is full or batch is finalized)
  USED → transmit → delivery ACK → FREE (recycled)

Here's how it works:

Memory layout: At startup, a contiguous block of memory is allocated (e.g., 2MB). This block is divided into pages of a configured size (matching the MQTT max packet size, typically matching the batch size). Each page has a small header tracking its state and a data area.

┌──────────────────────────────────────────────┐
│ [Page 0: USED] [Page 1: USED] [Page 2: WORK]│
│ [Page 3: FREE] [Page 4: FREE] [Page 5: FREE]│
│ [Page 6: FREE] ... [Page N: FREE]            │
└──────────────────────────────────────────────┘

Writing data: When a batch is finalized, its serialized bytes are written to the current WORK page. Each message gets a small header: a 4-byte message ID slot (filled later by the MQTT library) and a 4-byte size field. If the current page can't fit the next message, it transitions to USED and a fresh FREE page becomes the new WORK page.

Overflow handling: When all FREE pages are exhausted, the buffer reclaims the oldest USED page — the one that's been waiting for delivery the longest. This means you lose old data rather than new data, which is the right trade-off: the most recent readings are the most valuable. An overflow warning is logged so operators know the buffer is under pressure.

Delivery: When the MQTT connection is active, the buffer walks through USED pages and publishes their contents. Each publish gets a packet ID from the MQTT library. When the broker ACKs the packet (via the PUBACK callback for QoS 1), the corresponding page is recycled to FREE.

Disconnection recovery: When the MQTT connection drops:

1. The disconnect callback fires
2. The buffer marks itself as disconnected
3. Data continues accumulating in pages (WORK → USED)
4. When reconnected, the buffer immediately starts draining USED pages

No data is lost unless the buffer physically overflows. With 2MB of buffer and 500KB page size, you get 4 pages of headroom — enough to survive several minutes of disconnection at typical telemetry rates.

Thread Safety​

The PLC read loop and the MQTT event loop run on different threads. The buffer must be thread-safe. Every buffer operation acquires a mutex:

• buffer_add_data() — called from the PLC read thread after batch finalization
• buffer_process_data_delivered() — called from the MQTT callback thread on PUBACK
• buffer_process_connect() / buffer_process_disconnect() — called from MQTT lifecycle callbacks

Without proper locking, you'll see corrupted pages, double-free crashes, and mysterious data loss under load. This is non-negotiable.

Sizing the Buffer​

Buffer sizing depends on three variables:

1. Data rate: How many bytes per second does your polling loop produce?
2. Expected outage duration: How long do you need to survive without MQTT?
3. Available memory: Edge devices (especially industrial routers) have limited RAM

Example calculation:

• 200 tags, average 6 bytes each (including binary overhead) = 1,200 bytes/group
• Polling every 1 second = 1,200 bytes/second = 72KB/minute
• Target: survive 30-minute outage = 2.16MB buffer
• With 500KB pages = 5 pages minimum (round up for safety)

In practice, 2–4MB covers most scenarios. On a 32MB industrial router, that's well within budget.

The MQTT Layer: QoS, Reconnection, and Watchdogs​

QoS 1: At-Least-Once Delivery​

For industrial telemetry, QoS 1 is the right choice:

• QoS 0 (fire and forget): No delivery guarantee. Unacceptable for production data.
• QoS 1 (at least once): Broker ACKs every message. Duplicates possible but data loss prevented. Good trade-off.
• QoS 2 (exactly once): Eliminates duplicates but doubles the handshake overhead. Rarely worth it for telemetry.

The page buffer's recycling logic depends on QoS 1: pages are only freed when the PUBACK arrives. If the ACK never comes (connection drops mid-transmission), the page stays in USED state and will be retransmitted after reconnection.

Connection Watchdog​

MQTT connections can enter a zombie state — the TCP socket is open, the MQTT loop is running, but no data is actually flowing. This happens when network routing changes, firewalls silently drop the connection, or the broker becomes unresponsive.

The fix: a watchdog timer that monitors delivery acknowledgments. If no PUBACK has been received within a timeout window (e.g., 120 seconds) and data has been queued for transmission, force a reconnect:

if (now - last_delivered_packet_time > 120s) {
  if (has_pending_data) {
    // Force MQTT reconnection
    reset_mqtt_client();
  }
}

This catches the edge case where the MQTT library thinks it's connected but the network is actually dead. Without this watchdog, your edge daemon could silently accumulate hours of undelivered data in the buffer, eventually overflowing and losing it all.

Asynchronous Connection​

MQTT connection establishment (DNS resolution, TLS handshake, CONNACK) can take several seconds, especially over cellular links. This must not block the PLC read loop. The connection should happen on a separate thread:

1. Main thread detects connection is needed
2. Connection thread starts connect_async()
3. Main thread continues reading PLCs
4. On successful connect, the callback fires and buffer delivery begins

If the connection thread is still working when a new connection attempt is needed, skip it — don't queue multiple connection attempts or you'll thrash the network stack.

TLS for Production​

Any MQTT connection leaving your plant network must use TLS. Period. Industrial telemetry data — temperatures, pressures, equipment states, alarm conditions — is operationally sensitive. On the wire without encryption, anyone on the network path can see (and potentially modify) your readings.

For cloud brokers like Azure IoT Hub, TLS is mandatory. The edge daemon should:

• Load the CA certificate from a PEM file
• Use MQTT v3.1.1 protocol (widely supported, well-tested)
• Monitor the SAS token expiration timestamp and alert before it expires
• Automatically reinitialize the MQTT client when the certificate or connection string changes (file modification detected via stat())

Daemon Status Reporting​

A well-designed edge daemon reports its own health back through the same MQTT channel it uses for telemetry. A periodic status message should include:

• System uptime and daemon uptime — detect restarts
• PLC link state — is the PLC connection healthy?
• Buffer state — how full is the outgoing buffer?
• MQTT state — connected/disconnected, last ACK time
• SAS token expiration — days until credentials expire
• Software version — for remote fleet management

An extended status format can include per-tag state: last read time, last delivery time, current value, and error count. This is invaluable for remote troubleshooting — you can see from the cloud exactly which tags are stale and why.

Value Comparison and Change Detection​

Not all values need to be sent every polling cycle. A temperature that's been 72.4°F for the last hour doesn't need to be transmitted 3,600 times. Change detection — comparing the current value to the last sent value — can dramatically reduce bandwidth.

The implementation: each tag stores its last transmitted value. After reading, compare:

if (tag.compare_enabled && tag.has_been_read_once) {
  if (current_value == tag.last_value) {
    skip_this_value();  // Don't add to batch
  }
}

Important caveats:

• Not all tags should use comparison. Continuous process variables (temperatures, flows) should always send, even if unchanged — the recipient needs the full time series to calculate trends and detect flatlines (a stuck sensor reads the same value forever, which is itself a fault condition).
• Discrete state tags (booleans, enums) are ideal for comparison — they change rarely and each change is significant.
• Floating-point comparison should use an epsilon threshold, not exact equality, to avoid sending noise from ADC jitter.

Putting It All Together: The Main Loop​

The complete edge daemon main loop ties all these layers together:

1. Parse configuration (device addresses, tag lists, MQTT credentials)
2. Allocate memory (PLC config pool + output buffer)
3. Format output buffer into pages
4. Start MQTT connection thread
5. Detect PLC device (probe address, determine type/protocol)
6. Load device-specific tag configuration

MAIN LOOP (runs every 1 second):
  a. Check for config file changes → restart if changed
  b. Read PLC tags (coalesced Modbus/EtherNet/IP)
  c. Add values to batch (with comparison filtering)
  d. Check batch finalization triggers (size/timeout)
  e. Process incoming commands (config updates, force reads)
  f. Check MQTT connection watchdog
  g. Sleep 1 second

Every component — polling, batching, buffering, delivery — operates within this single loop iteration, keeping the system deterministic and debuggable.

How machineCDN Implements This​

The machineCDN edge runtime implements this full stack natively on resource-constrained industrial routers. The page-based ring buffer runs in pre-allocated memory (no dynamic allocation after startup), the MQTT layer handles Azure IoT Hub and local broker configurations interchangeably, and the batch layer supports both JSON and binary encoding selectable per-device.

On a Teltonika RUT9xx router with 256MB RAM, the daemon typically uses under 4MB total — including 2MB of buffer space that can store 20+ minutes of telemetry during a connectivity outage. Tags are automatically sorted, coalesced, and dispatched with zero configuration beyond listing the tag names and addresses.

The result: edge gateways that have been running continuously for years in production environments, surviving cellular dropouts, network reconfigurations, and even firmware updates without losing a single data point.

Conclusion​

Reliable telemetry delivery isn't about the protocol — it's about the pipeline. Modbus reads are the easy part. The hard engineering is in the layers between: batching values efficiently, buffering them through disconnections, and confirming delivery before recycling memory.

The key design principles:

1. Never block the read loop — PLC polling is sacred
2. Buffer with finite, pre-allocated memory — dynamic allocation on embedded systems is asking for trouble
3. Reclaim oldest data first — in overflow, recent values matter more
4. Acknowledge before recycling — a page stays USED until the broker confirms receipt
5. Watch for zombie connections — a connected socket doesn't mean data is flowing

Get these right, and your edge infrastructure becomes invisible — which is exactly what production IIoT should be.

Most IIoT engineers live in the world of Modbus registers, EtherNet/IP CIP objects, and MQTT topics. BACnet — the dominant protocol in building automation — rarely appears on their radar. But as manufacturing facilities increasingly integrate HVAC, energy management, and environmental monitoring into their operational technology (OT) stacks, understanding BACnet becomes a practical necessity.

This article explains BACnet from the perspective of someone who already understands industrial protocols. If you can read a Modbus register map, you can understand BACnet's object model. The concepts map more cleanly than you might expect.

SCADA systems have been the backbone of industrial monitoring for four decades. They've earned their place — when a plant needed visibility into process variables, alarms, and equipment status, SCADA was the only game in town.

But here's what's happening in 2026: manufacturers aren't replacing their SCADA systems because SCADA stopped working. They're looking for alternatives because SCADA was built for a world that no longer exists — a world where data lived on-premise, where remote access meant a VPN headache, where adding a new data point required an integrator and a purchase order.

The modern manufacturing floor demands real-time cloud analytics, mobile access, AI-powered predictive maintenance, and deployments measured in minutes, not months. Legacy SCADA can't deliver that. These alternatives can.

Every IIoT engineer eventually faces the same rude awakening: you've got a perfectly good Modbus connection to a PLC, registers are responding, data is flowing — and every single value is wrong.

Not "connection refused" wrong. Not "timeout" wrong. The insidious kind of wrong where a temperature reading of 23.5°C shows up as 17,219, or a pressure value oscillates between astronomical numbers and zero for no apparent reason.

Welcome to the data normalization problem — the unsexy, unglamorous, absolutely critical layer between raw industrial registers and usable engineering data. Get it wrong, and your entire IIoT platform is built on garbage.

If you've ever stared at a raw Modbus register dump and tried to figure out why your temperature reading shows 16,838 instead of 72.5°F, this article is for you. Data normalization is the unglamorous but absolutely critical layer between industrial equipment and useful analytics — and getting it wrong means your dashboards lie, your alarms misfire, and your predictive maintenance models train on garbage.

After years of building data pipelines from PLCs across plastics, HVAC, and conveying systems, here's what we've learned about the hard parts nobody warns you about.