BACnet Polling Schedules for Mixed-Frequency Sensors

Polling looks like the simplest thing in an integration and is where more integrations quietly fail than anywhere else. The failure is not dramatic: the system works, then as points are added it works less reliably, reads start timing out on one trunk, a few values go stale intermittently, and somebody begins replacing controllers that turn out to be fine. The cause is a collection regime nobody sized.

The message up front: set the interval per point from what the data is used for, not uniformly. Group points into a small number of rate classes so the configuration stays manageable, budget the resulting load against each trunk's capacity rather than against the network as a whole, and leave headroom for the points that will be added later. Where a value changes rarely, subscription beats polling decisively. And measure the actual read success rate, because that is the number that tells you whether the regime fits.

1. What should set the rate

Four questions, in order. The answer to the first that gives a demanding rate wins.

• Does anything act on it automatically, and how fast? A value feeding a rule that must respond within a defined time has to be sampled faster than that time, with margin.
• How fast does the underlying physical quantity actually move? Sampling faster than the quantity changes produces identical consecutive readings, which is network traffic and storage spent on nothing.
• What analysis will be done on it later? Energy totals tolerate coarse sampling. Diagnosing a short excursion does not. This is the question most often skipped, and the one that cannot be fixed retrospectively because the data simply is not there.
• Does a person watch it live? A displayed value needs to be fresh enough not to look broken, which is usually a far less demanding requirement than people assume.

The common error is answering only the fourth question, because the live display is the visible part of the system, and then discovering a year later that the historical resolution is too coarse for the analysis somebody now wants.

2. Rate classes rather than per-point intervals

A thousand individually chosen intervals is unmaintainable. A small number of named classes, with every point assigned to one, stays manageable and makes the regime auditable.

Record the class against each point in the points map, alongside the collection mechanism, so the regime is documented rather than living inside a gateway's configuration screen. The field list is in BACnet objects, device instances and addressing.

3. Budget per trunk, not per site

This is where the arithmetic goes wrong. Total network capacity is almost never the constraint; the constraint is the slowest shared segment, and on most building systems that is a serial MS/TP trunk shared by many devices.

A trunk has a finite number of transactions per second available, divided among every device on it, and every poll is a request and a reply. Adding a controller to a trunk does not just add its own traffic; it takes a share of a fixed budget. So a polling regime that was comfortable at commissioning becomes marginal after a fit-out adds a dozen terminal controllers, and nothing announces the change.

Practical approach:

• Count points and required reads per minute per trunk, not per site. One overloaded trunk among twenty healthy ones produces exactly the intermittent symptoms described above.
• Use multi-property or grouped reads where devices support them. Reading several values from one device in one transaction is dramatically more efficient than one transaction each, and it is frequently available and unused.
• Stagger the schedule. Every point on a one-minute cycle firing at the same instant produces a burst that fails, followed by idle time. Spreading the same volume across the interval uses the same capacity without the collisions.
• Leave headroom deliberately. Estates grow. A regime sized to consume the available capacity is a regime that will fail at the next fit-out.
• Treat the IP side separately. A BACnet/IP segment has far more capacity and a different failure mode, so the same budget does not apply. The architecture distinction matters here.

4. Where subscription beats polling outright

For any value that changes rarely, polling is pure waste: you are repeatedly asking a question whose answer you already have. Change-of-value subscription inverts it, and the device reports only when something happens.

The cases where it clearly wins are binary states and alarms, slow analogue values on a loaded trunk, and any point where you care about the transition rather than the level. The cases where it does not are points where you need a guaranteed regular sample regardless of movement, which includes anything feeding a time-weighted calculation.

The cost of subscription is that it has to be maintained. Subscriptions expire, devices restart, and a lapsed subscription produces a connection that looks healthy and delivers nothing. That failure mode and its handling are the subject of BACnet COV subscription recovery after gateway restarts, and it is the reason subscription is sometimes avoided by integrators who have been bitten by it.

5. How the rate interacts with everything downstream

• Trend log buffers. Where the controller is logging as well, the sampling interval determines how fast its buffer fills and therefore how often you must read it. The relationship is set out in BACnet data logging, and changing a sampling rate without rechecking the read frequency is a common way to start losing data silently.
• Storage volume. Sampling rate is the single largest driver of how much you store, and therefore of the retention decisions in BMS data retention policy.
• Alert latency. A condition cannot be detected faster than it is sampled, so the rate sets a floor under the response times assumed in alarm severity and escalation design.
• Staleness detection. The expected interval per point is what makes a staleness check possible. Without a documented rate there is no basis for deciding a value is overdue, which undermines the detection in the connectivity loss playbook.
• Analysis resolution. The irreversible one. Data not sampled is data that never existed, and no amount of later processing recovers it.

6. Measuring whether the regime fits

• Read success rate per trunk. The primary measure. Anything consistently short of complete is a load or configuration problem worth chasing.
• Actual versus configured interval. If a point configured for one rate is arriving at a slower one, the collector is not keeping up.
• Reads per minute per trunk against capacity, trended, so growth is visible before it becomes failure.
• Proportion of consecutive identical readings. A high figure means that point is over-sampled and is a candidate for a slower class or for subscription.
• Time from a value changing in the field to it being visible, sampled occasionally. The measure that matters to users, and usually worse than the configured interval implies.

7. Changing the regime on a live system

• Measure first, for a week. Actual read volumes and success rates per trunk. Intuition about which trunk is loaded is usually wrong.
• Slow the over-sampled classes before speeding anything up. Most estates have capacity available once the points that never change stop being polled every few seconds.
• Change one trunk at a time and confirm the success rate improves before moving on.
• Record the change against the point register, because a rate change silently alters storage volume, staleness thresholds and trend log read timing.
• Recheck after any fit-out. New terminal controllers are the usual cause of a regime that used to work.

The idea to walk away with

Polling rate is not a network setting, it is a statement about what the data will be able to answer. Set it from the use, group points into a few classes so the regime stays maintainable, budget against the slowest shared segment rather than the whole network, and leave room for growth.

The asymmetry worth remembering: over-sampling costs capacity and storage, both of which you can recover later. Under-sampling costs information, which you cannot. Where a point is genuinely important and you are unsure, sample it faster than you think you need and downsample in storage.

Final thoughts

If you suspect a load problem, the cheapest test is a sorted list: points per trunk, and configured reads per minute per trunk. The distribution is almost never even, and one or two trunks usually carry a disproportionate share.

Then look at how many of those points have not changed value in a month. In most estates that is a large fraction, and moving them to a slower class or to subscription releases enough capacity to fix the symptoms without touching any hardware.

Related reading: BACnet data logging, COV subscription recovery, BACnet objects and addressing, BMS data retention policy, Connectivity loss playbook, BACnet acceptance test checklist.