Possible Solution: Optimizing BACnet Polling Performance
Slow BACnet polling response (4+ seconds) can be due to several factors related to network setup, register mapping, polling strategy, and firmware configuration. Here's how to tighten that up:1. Reduce the Number of Polled Registers Per Request
Issue:Polling too many registers at once can create large responses that must be fragmented across multiple packets.
Action:
In your BMS or polling engine (like Niagara, JACE, or Tridium):
- Break polling into smaller groups (10–15 points per poll)
- Prioritize analog input registers only that are needed (e.g., AI.1 – AI.12)
- Avoid polling unused binary or multi-state objects.
2. Adjust Polling Interval and Timeout
Issue:If the interval is too aggressive or the timeout too short, retries and congestion may occur.
Action:
- Set poll interval to 5–10 seconds per group of registers.
- Use a timeout of at least 1.5–2.0 sec.
- Ensure you don’t overlap with previous polls — stagger them if multiple devices are on the bus.
3. Confirm Device is in BACnet IP Mode (Not MSTP)
Issue:If you're using BACnet MSTP over RS-485, 4-second delays are common due to token passing limitations.
Action:
- Prefer BACnet IP over MSTP for better polling speed.
- If you must use MSTP:
- Reduce the Max Master setting in your BMS to the number of actual devices.
- Use baud rates of 38.4 kbps or higher (if supported).
- Avoid daisy-chaining too many devices.
4. Use COV (Change of Value) Subscriptions if Supported
Issue:Polling every value all the time can be wasteful.
Action:
- If your BMS supports BACnet COV, subscribe to only the registers that change frequently (like kW, A, or status).
- This reduces traffic and increases responsiveness for critical points.
5. Use the Correct Firmware & Object Configuration
Issue:Older firmware or improper object mapping (e.g., overusing Calculated Registers) may impact performance.
Action:
- Confirm your meter firmware is current
- Use physical input objects rather than calculated objects where possible.
- Disable unused alarms or logging features in ViewPoint HD that could consume internal processing.
