BACnet Sensor Timestamp and Clock Synchronisation

Time is the one field in building data that everybody assumes is correct and almost nobody checks. It is also the field that every analysis depends on, because the entire value of historical data is in the ordering. A reading with a wrong timestamp is not slightly degraded data; depending on what you are doing with it, it is worse than no reading at all, because it will be used.

The message up front: decide which clock is authoritative, synchronise every device to it by a defined mechanism, monitor the drift rather than assuming the mechanism works, and store event time and ingestion time as two separate fields so that a bad device clock is visible instead of invisible. Store everything in UTC and render local. None of this is difficult and all of it is routinely skipped, which is why most estates have a dataset that quietly cannot support correlation between plant items.

1. Which clock produced this timestamp

A reading can be stamped by any of three clocks, and which one it was changes what the value means.

• The device clock. Used when a controller records into its own trend log. This is the only timestamp that describes when the condition actually occurred, and it is the least trustworthy of the three.
• The collector clock. Applied when something polls a point and stamps the reply. Accurate as a record of when you asked, which is not the same as when the value became true.
• The store clock. Applied on insert. Useful for operational monitoring of the pipeline, meaningless as a description of the building.

Polled data is stamped by the collector and the error is bounded by the polling interval. Trend log data carries the device's own time, which can be wrong by an arbitrary amount. The mechanism-by-mechanism detail is in BACnet data logging, and the practical consequence is that mixing the two in one series without recording which is which produces a dataset with inconsistent time semantics.

2. How device clocks go wrong

The last row is the important one. Clock synchronisation is nearly always configured and nearly never monitored, so a sync source that becomes unreachable, commonly after a network change, produces an estate that slowly comes apart with no alarm anywhere.

3. What a wrong clock actually breaks

• Correlation between plant items. If a pump and the zone it serves are stamped by clocks minutes apart, the causal relationship between them cannot be seen. Most fault analysis depends on exactly this.
• Sequence reconstruction. An investigation that shows the response occurring before the alarm is not usable, and the error discredits everything else in the record. This is why the audit trail in the alert-to-work-order audit trail insists on recording which clock each timestamp came from.
• Energy totals by period. Readings landing in the wrong hour or the wrong day move consumption between periods, which matters for tenant recharge and for any reporting obligation.
• Duplicate and gap artefacts. A clock that jumps backwards produces apparent duplicates; one that jumps forwards produces an apparent gap. Both look like collection faults and get investigated as such.
• Anything schedule-related. Optimised start, setback and occupancy-driven control all run on the controller's own clock, so a wrong clock is an operational problem as well as a data one.

4. Synchronising, and the questions to settle

Mechanisms vary by platform and device, and the right one is whatever your controls party supports properly. What matters is that the decisions are explicit:

• One authoritative source for the whole estate, not one per site and not one per manufacturer. Two sources that disagree are worse than one that is slightly wrong, because at least a consistent offset can be corrected.
• A defined synchronisation frequency, chosen against how fast your devices actually drift rather than against a default.
• A single time zone policy. The cleanest arrangement is devices running UTC with local time applied at presentation, where the platform allows it. Where devices must run local time, the daylight-saving behaviour must be identical across every device, which needs checking rather than assuming.
• Known behaviour on power loss. Which devices retain their clock, for how long, and what they default to. Devices that lose time on every power cut need either a battery or a sync on startup.
• Reachability of the source from every network segment. This is where it usually breaks, and it breaks after a firewall change rather than at commissioning, which is why it belongs in the change conversation described in BMS cybersecurity for connected buildings.

5. Monitoring the drift

Synchronisation that is configured and unmonitored is synchronisation you are assuming. The checks are cheap:

• Offset per device, tracked over time. The difference between event time and ingestion time, as above, per device, trended. Alarm on a step change or on growth beyond a threshold you set.
• Readings stamped in the future. Anything claiming a time ahead of your ingestion clock is wrong by definition. Flag rather than discard.
• Readings stamped implausibly far in the past. Distinguish these from legitimate buffered recovery, which is a known and expected case described in store-and-forward buffering.
• Backwards jumps within one device's series. A reading older than the previous reading from the same point indicates a clock reset.
• A twice-yearly check at the daylight-saving transitions, which is when inconsistent time zone configuration becomes visible and the only time it does.

Route the resulting work to whoever maintains the controllers rather than to a plant technician, for the same reason instrumentation faults are routed that way in what to do when a fault clears before a technician arrives.

6. Handling data that arrives with a bad timestamp

• Never silently substitute. Replacing a suspect device time with the ingestion time produces a plausible dataset that is wrong, and nothing downstream can tell. Keep both and flag the row.
• Do not discard. The reading still carries information about the value even if the time is suspect, and discarding creates a gap that looks like a collection failure.
• Correct only with a known, recorded offset. Where a device is found to be consistently out by a fixed amount, a correction can be applied, but the raw value, the offset applied and the period it covers all have to be stored so the correction is reversible.
• Mark the affected period on the point. Analysis spanning a period of known clock error should be able to see that, which is the quality-flag approach used in BACnet data quality flags.
• Decide what reporting does with flagged rows, explicitly, rather than letting each report make its own choice.

7. What to require at commissioning

• Every device synchronised to the named source, demonstrated rather than asserted, with the offset of each recorded at handover as a baseline.
• The time zone and daylight-saving configuration of every device, documented and identical.
• Clock retention behaviour per device type, from the manufacturer documentation.
• A demonstrated power-loss test on a sample device: remove power, restore, confirm the clock is correct afterwards. Takes minutes and finds the devices with no battery.
• Confirmation that the sync source is reachable from every network segment, which is the item most likely to be broken by a later network change and therefore worth recording so it can be re-tested.

These belong in the wider set in the BACnet integration acceptance test checklist.

The idea to walk away with

Time is a field with a provenance, and treating it as a fact rather than as something a particular clock asserted is the root of the problem. Record which clock produced each timestamp, keep the ingestion time alongside the event time so the two can be compared, and monitor the difference.

That one structural change converts an invisible failure into a measurable one, and it costs a column. Everything else here follows from being able to see the drift.

Final thoughts

The diagnostic takes ten minutes if you already store both timestamps and an afternoon if you do not. For each controller, compare the time it reports against a known-good reference and list the offsets.

In most estates the distribution is not uniform. A handful of devices are badly out, usually ones that have lost power at some point, and the rest are close. Fixing the handful is quick, and knowing which they were matters for any historical analysis over the period they were wrong.

Related reading: BACnet data logging, Late and out-of-order readings, BACnet data quality flags, The alert-to-work-order audit trail, BACnet acceptance test checklist, BACnet objects and addressing.