Reference · built on requestOperator by FibricEnergy & demand

Schedule Leak

Equipment found running outside the occupancy schedule, from platform status, badge events, and meter load, with the schedule fix proposed.

Request accessPricing ↗

About

Air handlers run all weekend because someone extended a schedule for one event and never put it back. This operator reads the schedule objects and run-state points on your building management platform over BACnet/IP, badge events and door schedules from your access control system, and interval load from the meters. When status says off but the meter says on, the meter wins.

Equipment running in unoccupied hours on repeated days is raised as a schedule correction, an override clear, or an occupancy-based schedule, with the evidence attached. A person approves, the platform writes the schedule, and a weekly summary shows what leaked and what it cost.

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

  • Occupancy schedules and the schedule object each air handler, lighting group, or pump follows, over BACnet/IP
  • Equipment run state: fan and pump status, damper and valve positions, and change-of-value events stamped at the change
  • Credential use from your access control system: who badged where and when, and the door schedules in effect
  • Interval load from the main and branch meters over Modbus TCP, so a load with no status point still shows as kW
  • Override and hand-off-auto states where the platform exposes them, since a manual override is the usual leak
  • Holiday and exception entries on the schedule, to tell a planned run from a leak

Proposed actions

  • Target capability: propose a schedule correction for equipment found running in unoccupied hours on several days, with the hours observed
  • Target capability: propose clearing an override that has outlived the reason logged for it, after the person who set it is asked
  • Target capability: propose an occupancy-based schedule where badge events show a floor empties long before the schedule ends
  • Target capability: propose a write to a schedule object through the building management platform, applied only after approval
  • Target capability: propose a weekly leak summary: the equipment, the hours, and the estimated kWh outside occupancy

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

What you can build

  • Air handlers after hours

    Fan status stays on after the last badge-out on the floor. After the pattern repeats across a week, the operator proposes the schedule end time that matches when people actually leave.

    With BACnet / IP, Access Control

  • Lighting left on across a weekend

    The lighting panel's schedule shows off, but the branch meter shows a steady weekend load. The override on the Niagara station is proposed for clearing, with the meter trace attached.

    With Tridium Niagara, Modbus TCP

  • Overrides that outlived their event

    A Metasys schedule extended for a one-off event is still extended a month later. The operator asks the person who set it, then proposes restoring the previous schedule.

    With Johnson Metasys, Access Control

Requirements

  • A building management platform over BACnet/IP with schedule, status, and override points for the equipment in scope
  • An access control platform whose events the connector can read, limited to the doors you choose
  • Interval meters over Modbus TCP for loads the platform does not expose as status
  • A written occupancy policy: the hours, the floors, the exempt equipment, and who may approve a schedule change
Authentication
It signs in to nothing. The platform, the access control system, and the meters are read through the connectors you attach, each with an account limited to the equipment and doors in scope.

Limits

  • It infers occupancy from badge events and load, so a floor used without badging looks empty. You set the confidence it needs.
  • Equipment that must run unoccupied, such as a server room unit, must be listed as exempt or it is raised every week.
  • Where the platform gives no override state, an override is inferred from a run that ignores the schedule, and the proposal says so.
  • It writes schedules through the platform's own objects. It does not bypass a controller's local program.

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 Schedule Leak ↗

Questions and answers

What gets approved, and by whom?
A change per piece of equipment: the current schedule, the hours it ran outside it, the badge and load evidence, and the proposed schedule or override clear. The approver can edit, approve, mark the equipment exempt, or decline.
What record is left?
A receipt: the equipment, the schedule before and after, the evidence window, who approved, when, and the write result on the platform. The old schedule stays on the receipt so the change can be reversed.
Does it ever change a schedule or clear an override by itself?
No. Every write follows an approval, once. A leak that continues after a change is proposed again, not fixed quietly.
Ask about Schedule Leak

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