Multi-Node Polling vs Event-Driven Reporting

Key Takeaways

• Multi-node polling reads every node on a fixed schedule, so scan time grows in proportion to node count.
• A timeout is the worst-case cost of one transaction, and an absent node pays it on every cycle.
• Event-driven reporting sends only a change of state or an alarm, so quiet periods cost no bandwidth.
• Event reporting needs a heartbeat, sequence numbering and duplicate suppression to stay trustworthy.
• Most large networks combine a slow full poll with fast exception reporting for the changes that matter.

1. What Is Multi-Node Polling?

Multi-node polling is a master-initiated scan in which one master reads every slave node in turn on a fixed schedule.

The master owns the schedule. It sends a request to address one, waits for the answer, then repeats the sequence for the next address until every node has been read, after which the cycle starts again.

Core characteristics

• One master, many slaves: a single controller holds the schedule, and every other device answers only when it is addressed.
• Scan time scales with node count: total time is roughly the sum of every transaction, so doubling the addresses roughly doubles the cycle.
• Timeouts dominate the worst case: a node that is slow or missing costs the master the full timeout before the scan can move on.
• Simple to reason about: lost data is easy to detect, because a missing answer within the timeout is the main failure mode to handle.

2. How Does a Polling Cycle Work?

A polling cycle is a fixed loop of request, wait, and advance, repeated for every address on the bus.

1. The master sends a request to the first node. It transmits a read command for one address and then releases the bus, because a half-duplex link allows one talker at a time.
2. The master waits for the answer. The wait ends in one of two ways: the response frame arrives and is accepted, or the timeout counter expires with no valid frame.
3. The master stores the value and advances. On a good answer it hands the data to the application, increments to the next address, and repeats the same sequence.
4. Total scan time is the sum of every transaction. With N nodes, one cycle is roughly N times the average request-and-response time, plus any retries the master performs.

3. What Is Event-Driven Reporting?

Event-driven reporting is a data-collection method in which a node transmits only when its own measured value changes or an alarm condition appears.

The control inverts: instead of the master deciding when to read, each node decides when to speak, and traffic follows the process rather than the clock.

Core characteristics

• The node initiates traffic: each device watches its own input and reports when something changes, rather than waiting to be asked.
• A change of state triggers a message: a value beyond a deadband, a threshold crossing, or a flipped digital input becomes a reportable event.
• Quiet periods cost nothing: when nothing changes the bus stays silent, and several nodes can report at the same time when a shared event occurs.
• The master must accept unsolicited traffic: it cannot assume every received frame answers a request, and it still needs a slow heartbeat or periodic full read to know the network is alive.

4. Multi-Node Polling vs Event-Driven Reporting: What Is the Difference?

The two methods differ mainly in who initiates traffic and what that costs when the network is quiet or when a node fails.

The decision rule: poll when you need a bounded, predictable update for every point on a known schedule, and switch to exception reporting with a heartbeat when most points rarely change and the fast ones matter.

5. Configuration and Key Parameters

The parameters below decide whether a polling or event network behaves, and each one fails in a recognisable way in the field.

• Scan time against node count and retry budget: total time is roughly the sum of every transaction, so it grows with each address and each retry.
• Timeout value against link latency: the timeout must cover the worst round trip through radio, relay or bus.
• Deadband and threshold: the deadband is the smallest reportable change, and the threshold raises an alarm.
• Report rate against duty cycle and channel occupancy: event reporting trades a constant poll for bursts, so the busiest case sets the channel occupancy.
• Heartbeat interval: a periodic heartbeat proves that a quiet node is still alive.
• Sequence numbering: a counter in each report lets the master detect a lost or out-of-order message.
• Retry and duplicate suppression: a retried report can arrive twice, so the master needs an identifier or timestamp to drop the repeat.
• Buffering when several nodes report together: a small buffer holds bursts that arrive while the master is busy.
• Timestamp and stale values: every value should carry the time it was measured, not the time it was received.
• Polled register versus latched alarm: a polled register can miss a brief event, while a latched alarm stays set until cleared.

6. When to Use Polling and When to Use Event Reporting

The choice follows the update requirement, the node count, and how much channel the network can afford.

Good fit for multi-node polling

• A small to medium node count where cycle time stays inside the control requirement.
• Points that must be read on a fixed schedule, such as trend logging or energy totals.
• Installations that need a simple, deterministic protocol with a single timeout to tune.

Good fit for event-driven reporting

• Networks with many nodes where only a few values change often.
• Alarms and fault signals that must reach the master without waiting for a scan.
• Battery or duty-cycle limited nodes that cannot answer every cycle.

Poor fit for multi-node polling

• Very large node counts, where the sum of transactions exceeds the control requirement.
• A few fast alarms mixed into a slow poll, because each alarm waits its turn in the cycle.

Poor fit for event-driven reporting alone

• Points that must be sampled on a schedule even when they do not change.
• Networks with no heartbeat or timestamp, where a silent node is indistinguishable from a failed one.
• Safety functions that need a bounded worst-case update, which polling gives and event reporting does not.

7. Real-World Applications

In water, energy and factory telemetry the common pattern is a master that polls on a slow cycle while the fast points report on change.

Ebyte DTUs cover both sides of that design. The E90-DTU(400SL30L) is an industrial-grade 30 dBm LoRa radio for 410.125-493.125 MHz with up to 10 km over RS485 and 3.3 V TTL ports; the E90-DTU(400SL22) is an SX1268-based transceiver with dual RS232 and RS485 ports, 22 dBm and up to 5 km; the E22-400T33S is a Semtech SX1268 UART module on 410.125-493.125 MHz with a default of 433.125 MHz, 33 dBm and a 16 km figure; the E220-900T22D uses ChirpIoT LoRa at 22 dBm on the 915 MHz band over UART; and the E48-433T20S is a 20 dBm 433 MHz UART transceiver with automatic frequency hopping and automatic retransmission.

For the reporting side of the same network, Ebyte I/O and gateway modules bring real points onto the bus. The ME31-AXXX8000 is an 8-way dry contact input Modbus gateway supporting Modbus TCP or RTU on RJ45 and RS485, the MA01-AACX2220 is an RS485 Modbus RTU I/O module with 2DI, 2AI and 2DO, and the E831-RTU(8080T-485) is an industrial digital IO controller with RS485 and Modbus RTU for dry and wet contact acquisition and relay output.

The scan strategy and the radio settings have to be sized together.

8. FAQ: Polling and Event Reporting in Practice

Q1: What is multi node polling?

Multi node polling is a method where one master reads every node in turn on a fixed schedule, so each device answers only when addressed. Total cycle time is roughly the sum of every transaction, which means scan time grows with node count and with the timeout budget of the slowest link.

Q2: How does scan time scale with the number of nodes?

Scan time grows roughly in proportion to node count, because each address adds one request and one response to the cycle. A node that is slow or absent adds the full timeout instead of a short answer, so one failed device lengthens every pass until it is fixed.

Q3: Why is my polling network slow or dropping values?

• Values arrive late in the cycle -> reduce node count per master, raise the poll rate, or check the retry budget.
• One node always times out -> verify its address, wiring and power, then confirm the timeout covers the link latency.
• Values look stale after a change -> the poll rate is slower than the process, so add exception reporting for that point.
• Scan time rises after adding nodes -> the cycle is near its limit; split the network or move quiet points to change-of-state reporting.

Q4: Is event-driven reporting always faster than polling?

Not always. Event reporting is faster for a change, because the node sends as soon as its value moves instead of waiting its turn in a scan. It is not automatically cheaper at the worst moment, though, because several nodes can report at once and the burst still has to fit the channel.

Q5: How do I stop losing reports in an event-driven network?

Add a sequence number and a heartbeat. Sequence numbering lets the master notice a gap, and the heartbeat proves that a quiet node is still alive. Retry the missing report, then suppress duplicates by identifier so one change is not counted twice, and timestamp every value so stale data is visible.

Q6: Can I use both polling and event reporting on one network?

Yes, and most large networks do. A slow full poll keeps a scheduled record and confirms every address, while exception reporting pushes a change of state or an alarm as soon as it happens. The master then handles request-and-answer and unsolicited traffic, and the two cycles are sized so they do not saturate the channel together.

9. Sizing Checklist Before You Set the Poll Rate

1. Estimate the worst-case scan time as the sum of every transaction at the chosen baud rate, including the timeout for a missing node.
2. Check that the worst-case scan time is still shorter than the control requirement for the fastest point.
3. Set the timeout to cover the real round trip through radio, relay and bus, and test it with a node powered down.
4. Decide which points must be sampled on a schedule and which may report on change, then give every event point a deadband and a threshold.
5. Give every event report a sequence number, a timestamp and a heartbeat, so a lost or stale value is visible.