Reference · built on requestOperator by FibricFacilities & comfort

Sensor Health

Finds flat, stuck, or drifting building sensors by comparing neighbors and weather and proposes calibration orders.

Request accessPricing ↗

About

Control loops trust their sensors. A space temperature that reads the same value for days, a CO2 sensor that never leaves its floor, or an outdoor-air probe that reads a few degrees warm will steer a controller wrong without raising an alarm. Sensor Health reads sensor points and their BACnet status properties over BACnet/IP, a Niagara station, or Metasys, along with trend samples where the platform keeps them.

It compares each sensor with its neighbors on the same floor or air handler, and outdoor sensors with the nearest National Weather Service observation. A reading that stops moving, sits outside its range, or drifts away from its peers becomes a proposed calibration or replacement work order in your CMMS, with the evidence attached. You approve the order. The operator never marks a point out of service or edits a value.

This is a reference listing. It documents what Fibric would read from Sensor Health 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

  • Present value on analog input points over BACnet/IP, with each object's Status_Flags and Reliability, including NO_SENSOR, OVER_RANGE, UNDER_RANGE, OPEN_LOOP, and SHORTED_LOOP
  • Whether a point is Out_Of_Service, so a value someone is holding by hand is not judged to be a stuck sensor
  • Historical samples from Metasys through /objects/{objectId}/attributes/{attributeId}/samples, or from a Niagara station's histories, to see how a reading moved
  • Neighboring sensors on the same floor, zone, or air handler, taken from the site tree or your point map
  • The latest NWS observation for the site, with temperature, dewpoint, relative humidity, and a timestamp, for outdoor-air sensors
  • Open calibration work orders on the same asset in Limble, UpKeep, MaintainX, or Fiix, so one sensor is not ordered twice

Proposed actions

  • Target capability: propose a calibration work order for a sensor whose reading has stopped moving while its neighbors change
  • Target capability: propose a replacement work order for a point whose Reliability reports a fault, with the flag and the time it appeared
  • Target capability: propose a check on an outdoor-air sensor that drifts from the NWS observation over successive days, with both series attached
  • Target capability: propose one work order per floor or air handler that groups several suspect sensors, so a technician makes one visit
  • Target capability: propose closing a calibration order once the reading tracks its neighbors again, for the technician to confirm

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

What you can build

  • Find the zone sensors that flatlined

    Space temperature points that hold one value through a full day, while neighbors on the same floor rise and fall, become a proposed Limble task per floor. The task lists each point and its last change.

    With BACnet / IP, Limble CMMS

  • Check rooftop outdoor-air probes against the weather

    Every outdoor-air sensor in Metasys is compared with the nearest NWS station. Ones that drift over days get one proposed UpKeep work order, batched per roof.

    With Johnson Metasys, Weather & Severe Alerts, UpKeep

  • Act on BACnet fault flags nobody watches

    Points whose Reliability shows OPEN_LOOP or SHORTED_LOOP often sit unnoticed in a Niagara station. The operator proposes a MaintainX work order for each, with the flag and when it first appeared.

    With Tridium Niagara, MaintainX

Requirements

  • A BACnet/IP, Tridium Niagara, or Johnson Metasys connector with read access to the sensor points and their status properties
  • A point map that places each sensor on a floor, zone, or air handler, so it has neighbors to compare with
  • The NWS weather signal with each site's coordinates, for outdoor-air sensors
  • A field service or CMMS connector such as Limble, UpKeep, MaintainX, or Fiix, with sensors or their parent equipment listed as assets
Authentication
Reads points and histories through the read allow-list of your building connector, reads NWS observations with no key, and files work orders with the account your CMMS connector uses.

Limits

  • A sensor with no neighbors and no history can be checked only against its own Reliability and Status_Flags.
  • Drift is judged against peers and weather, not a reference instrument. A technician confirms the offset on site before recalibrating.
  • It proposes work orders only. It does not set Out_Of_Service, write a present value, or change alarm limits on any point.
  • Trend samples are read only where your platform stores them. A point that is not trended is compared on live reads alone.

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 Sensor Health ↗

Questions and answers

Who approves a calibration order?
You do, one order at a time. The proposal shows the sensor, what it was compared against, the readings that set it apart, and the draft work order. You edit, approve, or dismiss it. A grouped order lists each sensor so you can strike one out before filing.
What is kept after a proposal?
A receipt per proposal: the point, the neighbors or NWS station used, the samples compared, the work order id in your CMMS, who approved it, and how to cancel it. Dismissed proposals stay on file, so a sensor flagged twice shows its history.
Can it change a sensor's value or take it out of service?
No. It reads present value, Status_Flags, Reliability, and Out_Of_Service through the building connector's read allow-list. It never writes to a point. Fixing, calibrating, or replacing a sensor is a work order a technician carries out.
Ask about Sensor Health

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