How Tuning Policies Work in Niagara 4 Drivers
A Niagara tuning policy sets how a driver's proxy points write, rewrite, go stale and how often they are polled. Getting it right keeps networks fast and data trustworthy.
Every proxy point in a Niagara 4 station, whether from BACnet, Modbus, LonWorks or a third-party driver, follows a tuning policy. Most engineers leave everything on the default policy and only discover tuning when a network is overloaded, a valve chatters, or a point shows {stale} for no obvious reason. This guide explains each tuning policy property, how it interacts with the poll scheduler, and practical settings for common situations.
Where tuning policies live
Each driver network has a Tuning Policy Map (usually a Tuning Policies slot under the network, for example BacnetNetwork > Tuning Policies). It contains:
- a Default Policy, which cannot be deleted and applies to any point not assigned another policy
- any additional policies you create, for example
Fast,Slow,Meters,Critical Writes
Each proxy point's proxy extension has a Tuning Policy Name property that selects which policy it uses. Changing a policy's settings changes the behaviour of every point that references it, which makes policies a powerful way to manage hundreds of points at once.
Tuning policy properties
The exact list varies slightly between drivers, but these are the standard properties.
Min Write Time
The minimum time between writes to the device for a point. If the point's value changes faster than this, intermediate values are held back and only the latest is written when the time has elapsed.
- Use it to stop "chatter": a PID loop output that changes every second does not need to be written to a valve actuator every second. A min write time of a few seconds cuts network traffic and actuator wear without affecting control.
- 0 means no limit: every change is written immediately.
Max Write Time
The maximum time between writes. If the value has not changed for this long, the driver rewrites it anyway.
- Use it to recover from devices that lose their commanded value, for example after a device restarts and comes back with a default, or where another system overwrites the value.
- 0 disables periodic rewrites.
- Be careful with devices that store values in non-volatile memory (EEPROM). Frequent rewrites of setpoints into EEPROM can wear the memory out. Prefer Write On Up for these.
Write On Start
If true, the driver writes the point's current value to the device when the station starts. Useful so that devices receive the station's commands after a station restart. Set false for points where the device should keep its own value until the station deliberately changes it.
Write On Up
If true, the driver writes the value when the device changes from down to up, for example after it restarts or after a communication fault clears. This is usually the best way to ensure devices that lose settings on power-up are corrected, without periodic rewrites.
Write On Enabled
If true, the driver writes the value when the point or its parent device or network changes from disabled to enabled.
Stale Time
If the point has not been successfully read within the stale time, its status becomes stale ({stale}), signalling that the value may no longer be current.
- 0 disables stale detection.
- Set it comfortably longer than the point's poll interval, for example three to five times the poll rate of the frequency it uses, so a single slow poll does not flag stale.
- Stale status is valuable: it tells operators and logic that a value is not live. Logic can use it to fall back to a safe action.
Poll Frequency
For polled drivers (Modbus, many serial drivers, BACnet points not using COV), the poll frequency places the point in the Fast, Normal or Slow bucket of the network's poll scheduler. The actual times are set on the poll scheduler, not on the tuning policy.
How tuning policies and the poll scheduler fit together
| Component | Decides |
|---|---|
| Poll scheduler (on the network) | How long the Fast, Normal and Slow cycles are, and which points are polled at all (subscribed points) |
| Tuning policy (per point via name) | Which bucket a point is in, when writes happen, when values become stale |
A common mistake is to set every point to Fast "to be safe". On a serial network this simply means nothing achieves the fast rate. See how the poll scheduler works.
Recommended policies for a typical BMS station
| Policy | Poll frequency | Min write | Max write | Write on start | Write on up | Stale time | Use for |
|---|---|---|---|---|---|---|---|
| Default | Normal | 0–1 s | 0 | True | True | 3–5 × normal rate | Most points |
| Fast | Fast | 0 | 0 | True | True | 3–5 × fast rate | Values shown on live graphics, critical statuses |
| Slow | Slow | 0 | 0 | False | True | 3–5 × slow rate | Energy totals, configuration values, slowly changing temperatures |
| Modulating outputs | Normal | 5–10 s | 0 | True | True | 3–5 × normal rate | Valve and damper commands from PID loops |
| Volatile setpoints | Normal | 1 s | 10–30 min | True | True | 3–5 × normal rate | Devices that lose commanded values and do not report restarts |
These are starting points. Tune them to your devices and network speed.
Examples
Stopping a chattering valve command
A PID loop in the JACE drives a heating valve on a Modbus RTU I/O module. The loop output changes every second, generating a write every second and filling the serial bus. Assign the valve point a policy with Min Write Time 5 s. The valve still receives the latest value within five seconds, bus traffic drops, and polling of other points speeds up.
Fan coil controllers losing their setpoint after a power cut
After a power cut, BACnet MS/TP fan coil controllers restart with default setpoints. The station does not resend them because the values have not changed. Enable Write On Up on the policy for those setpoints, so the driver rewrites them as soon as each device comes back online.
Energy meter totals marked stale
Meter totals are in a Slow policy (poll every 5 minutes) but stale time is 60 seconds, so they show {stale} most of the time. Set Stale Time to around 15–25 minutes for that policy.
Tuning policies in BACnet
BACnet points can be updated by COV (change of value) subscriptions instead of polling where the device supports it. COV reduces traffic dramatically. Tuning policies still control write behaviour and stale time, and the poll frequency applies to points that are polled. Use COV for points on live graphics and polling for the rest.
Setting up tuning policies on a new station
A simple, repeatable approach for every project:
- Before adding points, create a standard set of policies on each network: for example Default, Fast, Slow, Outputs and Setpoints.
- Configure each with the values from your company standard (see the table above as a starting point).
- Add the policies to your device templates so every point from a template already references the right policy.
- Assign policies as points are added, using the batch editor for large groups.
- Measure with the poll scheduler statistics after commissioning and adjust policy settings, not individual points.
- Document the policies in the O&M manual so future engineers understand the intent.
Consistency is the real benefit: when every station in an estate uses the same policy names and meanings, diagnosing performance and data-quality problems becomes much faster.
Worked example: a policy plan for a plant room
A plant room JACE integrates boilers, pumps and meters over Modbus RTU at 19,200 baud, and AHU controllers over BACnet/IP.
| Point group | Policy | Settings |
|---|---|---|
| Boiler and pump statuses, flow temperatures on the plant graphic | Fast | Fast poll, stale time 10 s |
| Boiler and pump enables, mixing valve outputs | Outputs | Normal poll, min write 5 s, write on start and up |
| Boiler setpoints | Setpoints | Normal poll, write on up, no max write (stored in device memory) |
| Energy and gas meter totals | Slow | Slow poll (60 s), stale time 5 min, no writes |
| AHU points (BACnet COV where supported) | Default | Normal poll for non-COV points, stale time 30 s |
After commissioning, poll scheduler statistics show the Modbus network around 50% busy with all buckets meeting their rates, and nothing stale in normal operation.
Tuning policies and data quality
Tuning policies directly affect how trustworthy the data in histories and analytics is:
- Stale detection shows when values are not live. Histories record the stale status with the value, so analytics can exclude unreliable periods.
- Write behaviour determines whether devices actually hold what the BMS believes it has commanded. A setpoint that silently reverted after a power cut produces misleading energy data.
- Poll frequency sets the resolution of fast-changing values. A pressure polled every 30 seconds cannot show a 5-second spike.
When analytics or energy reports look odd, check tuning policies and poll statistics before suspecting the sensors.
Troubleshooting with tuning policies
Points intermittently stale. Stale time too short for the actual poll cycle. Check the poll scheduler's cycle times and set stale time above them.
Writes seem delayed. Min write time is holding them back, or the network is so busy that writes queue behind polls.
Device settings keep reverting. Another system writes to the same object, or the device restores defaults on restart. Use Write On Up, or Max Write Time where appropriate.
Network overloaded after a station restart. Write On Start is enabled on thousands of points, which all write at once. Disable it on points that do not need it.
EEPROM wear warnings from a manufacturer. Periodic rewrites (Max Write Time) to stored settings. Disable max write and rely on Write On Up.
Frequently asked questions
What is a tuning policy in Niagara 4?
A set of rules, shared by many proxy points, that controls when values are written to devices, when values become stale, and which poll frequency (Fast, Normal or Slow) a point uses.
What does stale mean in Niagara?
A point is stale when it has not been successfully read within its tuning policy's stale time, so its value may not be current.
What is the difference between min write time and max write time?
Min write time limits how often a changing value is written. Max write time forces a rewrite of an unchanged value after a set time.
Should I set all points to Fast poll?
No. On slower networks this means no point achieves the fast rate. Use Fast only for points that need it, such as values on live graphics.
Where do I assign a tuning policy to a point?
In the point's proxy extension, set the Tuning Policy Name to one of the policies in the network's tuning policy map.
Can I change the default tuning policy?
You can change its settings but not delete it. Changing the default affects every point that does not reference another policy, so do it deliberately.
How many tuning policies should a network have?
A handful is enough: typically Default, Fast, Slow and one or two for writes. Too many policies make the station harder to understand.
Do tuning policies apply to BACnet COV points?
Write behaviour and stale time still apply. The poll frequency matters only for points that are polled rather than updated by COV.
Why do my points show {stale} after a station restart?
Until each point has been read successfully after the restart, it may report stale. On a busy network this can take a while; it should clear once polling catches up. If it does not, check device status and stale time settings.
Can tuning policies stop actuator wear?
Yes. A suitable min write time stops rapidly changing loop outputs being written to actuators every second, reducing wear and network traffic.
Need help from a Niagara engineer?
If this guide has not solved the problem, contact the Tyrrell Products technical team on 01942 732819 or [email protected]. Tell us the controller or host type, its Niagara version and what you have already tried, and we will help you get the system running.