Reference · built on requestOperator by FibricEnergy & demand

Tariff Window

Recurring loads such as pumps and heating moved out of the hours your utility rate charges most, one schedule change at a time.

Request accessPricing ↗

About

A booster pump set to run at four in the afternoon costs more than the same pump at four in the morning, and nobody set it that way on purpose. This operator reads your rate from the OpenEI Utility Rate Database, where each energy and demand schedule is twelve month arrays holding one period index per hour, and lays your equipment schedules from the building management platform over them.

Where a recurring load sits inside an expensive period and has room to move, it proposes a new start and stop time. A person approves the change, the schedule is written through the platform or the PLC Command Bridge, and a receipt keeps the old times for undo.

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

  • Your rate in the OpenEI Utility Rate Database: energyweekdayschedule and energyweekendschedule, twelve month arrays with one period index per hour
  • demandweekdayschedule and demandweekendschedule with the demandratestructure they index, and flatdemandstructure by month
  • Schedule information for each pump, boiler, or air handler from the building management platform over BACnet/IP
  • Run state of the scheduled equipment: pump and fan status points and the trend logs behind them
  • Interval load on the main and branch meters over Modbus TCP, so each schedule is seen as the kW it actually draws
  • The rate's startdate and enddate, so a schedule is compared with the version that applies this month

Proposed actions

  • Target capability: propose a new start and stop time for a recurring load, moved out of the hours its rate period charges most
  • Target capability: propose staggering the starts of several loads that fall in the same demand period, so they no longer peak together
  • Target capability: propose a write to a declared schedule point through the PLC Command Bridge, inside the bounds you set for that equipment
  • Target capability: propose a seasonal revision when the rate's month array changes which hours are on peak
  • Target capability: propose a note to the facilities lead listing the loads it could not move and the constraint that held each

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

What you can build

  • Booster pumps off the afternoon period

    Domestic water pumps on a fixed afternoon schedule in the building platform fall inside the demand weekday period from URDB. The operator proposes an early-morning schedule and the kW it takes out of the peak window.

    With BACnet / IP, OpenEI Utility Rate Database

  • Electric preheat before the morning period

    Heating scheduled to start with occupancy is proposed to start earlier, in the last off-peak hours the rate's month array shows, so the space is warm before the price changes.

    With Tridium Niagara, OpenEI Utility Rate Database

  • Schedules held on a controller

    A chiller pump schedule that lives on a PLC rather than the platform is compared using the meter's interval load, and the new times are written through the bridge to the declared schedule point after approval.

    With PLC Command Bridge, Modbus TCP

Requirements

  • The URDB record for your rate, or its label, so the operator reads the schedule the utility applies to your account
  • A building management platform reachable over BACnet/IP, with schedule and status objects for the loads in scope
  • Where a schedule lives on a controller, the PLC Command Bridge with a declared write map for that schedule point
  • A list of loads that may move, with the earliest and latest hours each may run
Authentication
It carries no building or utility login. Rate records come from OpenEI with your API key; schedules and meters are read through the platform and protocol connectors you attach.

Limits

  • It reads the rate as URDB holds it. A rider, a revision, or a contract rate absent from URDB is unseen unless you supply it.
  • A load moves only inside the window you set for it. The operator does not decide what comfort or process can tolerate.
  • It changes when equipment runs, not how much it draws. A load that must run on peak is reported, not shifted.
  • The saving shown on a proposal is computed from the rate arrays and your interval data, not read from a utility bill.

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 Tariff Window ↗

Questions and answers

What does the facilities lead approve?
One schedule change per load: the current times, the proposed times, the rate periods each falls in, and the estimated change in energy and demand charge. The approver can edit the times, approve, or decline with a reason.
What record is left after a change?
A receipt per load: the schedule before and after, the URDB record and effective dates it read, the interval data window, who approved, when, and the write result. Undo is the previous schedule, kept on the receipt.
Does it ever change a schedule on its own?
No. A write happens only after approval, once. When URDB shows a revised rate, the operator raises new proposals; it never applies them unasked.
Ask about Tariff Window

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