Reference · built on requestOperator by FibricFacilities & comfort

Setpoint Drift

Compares each zone's setpoint with the commissioned standard and proposes restoring the overrides that have drifted.

Request accessPricing ↗

About

A building is commissioned with a setpoint for every zone. Then a tenant asks for two degrees cooler, a technician holds a value during a repair, and a controller keeps a manual override for months. Setpoint Drift reads the active setpoint on each zone controller over BACnet/IP, or through Metasys, Niagara, or Desigo CC, and compares it with the standard you keep for that zone.

Where a zone sits outside its standard, it proposes restoring the value through your building platform, or a ticket when the same zone keeps being moved by hand. It posts the list to the channel your facilities team reads. You approve each restore. It writes nothing on its own, and it never touches a zone with an open ticket.

This is a reference listing. It documents what Fibric would read from Setpoint Drift and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • The active heating and cooling setpoints on each zone controller, read over BACnet/IP or through the Metasys, Niagara, or Desigo CC connector
  • The priority array on writable setpoint points from a Niagara station, so it can tell an operator override from a scheduled value
  • Setpoint history through Metasys attribute samples, to see when a zone moved and whether it ever came back
  • Status_Flags and Reliability on each setpoint point, so a value from a faulted controller is not compared against the standard
  • The standard setpoint and allowed band for each zone, from the commissioning record or setpoint table you supply
  • Occupancy mode and schedule state, so an unoccupied setback is not read as drift
  • Open tickets in Jira Service Management, ServiceNow, or Freshservice, so a zone already under repair is left alone

Proposed actions

  • Target capability: propose restoring a zone setpoint to its standard through your building platform connector, on an allow-listed point, for your approval
  • Target capability: propose releasing a standing override so the point returns to schedule control, where the platform exposes the priority array
  • Target capability: propose a ticket for a zone moved by hand again within days of a restore, with the point and its history attached
  • Target capability: propose a morning notice to Microsoft Teams or Slack listing the zones outside standard and the proposed restores
  • Target capability: propose recording a new standard when you confirm a changed setpoint is intended, so it is not proposed again

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Undo the overrides left after a repair

    A technician holds a setpoint at operator priority during a coil repair and forgets it. Setpoint Drift sees the override in the Niagara priority array, proposes releasing it, links the closed Jira Service Management ticket, and posts the list to Teams.

    With Tridium Niagara, Jira Service Management, Microsoft Teams

  • Find the zones that keep drifting

    Metasys samples show one conference room reset to the same low value every week. The operator proposes one ServiceNow incident with the history, so someone can find the thermostat or the person, rather than restoring it again.

    With Johnson Metasys, ServiceNow

  • Keep a standard current

    A floor is re-let and its zones are meant to run warmer. When you confirm the new values, the operator records them as the standard, closes the Freshservice ticket it proposed, and stops flagging those zones in Slack.

    With BACnet / IP, Freshservice, Slack

Requirements

  • One building platform connector: BACnet/IP, Johnson Metasys, Tridium Niagara, or Siemens Desigo CC, with the zone setpoint points on its read allow-list
  • A setpoint standard per zone: the commissioned value and the band you accept, kept as a table the operator can read
  • A work and ticket management connector for the repeat-offender tickets: Jira Service Management, ServiceNow, or Freshservice
  • One messaging connector, Microsoft Teams or Slack, for the daily list
  • Write access on the zone setpoint points, on the connector's allow-list, if you want restores applied after approval
Authentication
Setpoint Drift holds no credentials. It reads and proposes through the building platform, ticketing, and messaging connectors you have already connected, under their scopes.

Limits

  • Drift is measured against the standard you supply. A zone with no standard on file is reported, never restored.
  • BACnet/IP does not record who changed a value. Without a priority array or audit trail, it sees that a setpoint differs, not who moved it.
  • A restore is a proposal. Nothing is written until a person approves it, and only through a connector that allows writes on that point.
  • Zones that the standard marks as tenant-controlled or under an open ticket are listed but not proposed for restore.

Access and pricing

Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Setpoint Drift ↗

Questions and answers

What do you approve before a restore?
Each restore, each release, and each ticket, one at a time. You see the zone, the value it holds, the standard, how long it has differed, and which point would be written. You can approve, change the target value, or dismiss. A dismissed zone is not proposed again until its value changes.
What is kept after each restore?
A receipt for every proposal: the reading, the standard, who approved it, what was written and at which priority, and how to put the old value back. Dismissals are kept with the reason you give, so the next person can see why a zone was left alone.
Will it change a setpoint without asking?
No. It reads setpoints, schedules, and tickets. A write reaches a controller only after a person approves a proposal, only on points your connector allow-lists, and once per approval. It does not edit schedules, alarm limits, or points on fire and life-safety equipment.
Ask about Setpoint Drift

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This operator is developed, published, and supported by Fibric. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy