Reference · built on requestOperator by FibricEnergy & demand

Battery Dispatch

Reads battery state of charge, the site load forecast, and day-ahead prices, and proposes tomorrow's charge and discharge schedule.

Request accessPricing ↗

About

A battery earns its keep by charging when energy is cheap and discharging into the hours that cost most or set the demand charge. The controller reports what it can do through the SunSpec Battery Base Model: state of charge, the reserve setpoints SocRsvMin and SocRsvMax, maximum charge and discharge rates, and a charge status of CHARGING, DISCHARGING, HOLDING, or FULL.

Battery Dispatch reads those registers over Modbus TCP, the site's interval load from the service meter, and the day-ahead price and demand forecast EIA publishes for your balancing authority, or the ISO's own market data where you connect it. Each afternoon it drafts the next day's schedule hour by hour: charge, hold, or discharge, and the power level for each, inside the reserve you set. You approve the schedule. Every write to the controller and every reading behind it is kept.

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

  • SoC, SoH, ChaSt, State, and W from SunSpec model 802 over Modbus TCP, with the alarms in Evt1
  • Nameplate limits from the same model: WHRtg, WChaRteMax, WDisChaRteMax, and the reserve setpoints SocRsvMin and SocRsvMax
  • Interval kW and kWh at the service entrance from the site meter over Modbus TCP, as the load history for the forecast
  • Day-ahead and real-time price series and the demand forecast for your balancing authority from EIA
  • Battery telemetry from a monitoring platform where the controller is off the network: Enphase /telemetry/battery or SolarEdge storage telemetry
  • Market prices from CAISO OASIS, ERCOT, PJM, or NYISO feeds when you connect one

Proposed actions

  • Target capability: propose the next day's hourly schedule of charge, hold, and discharge, with a power level for each hour
  • Target capability: propose the register writes that carry the schedule to the controller, one interval at a time, through the Modbus connector
  • Target capability: propose a battery settings change through the Enphase API where the battery is managed there
  • Target capability: propose holding at the reserve when the controller reports an alarm, a FAULT state, or LOCAL control mode
  • Target capability: propose a revised afternoon plan when the real-time price diverges from the day-ahead price it planned on

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

What you can build

  • Shift charging into the cheap hours

    Read state of charge over Modbus TCP and the day-ahead prices from EIA, and get an hourly schedule that charges in the lowest-priced hours and discharges into the highest, inside your reserve.

    With Modbus TCP, Grid Demand & Prices

  • Shave the demand-charge window

    With the site meter's interval history, the schedule holds charge for the tariff's demand window and discharges to keep the peak down, and the receipt shows the kW the meter recorded.

    With Modbus TCP, Grid Demand & Prices

  • Plan on the ISO's own prices

    Where the site settles on nodal prices, connect CAISO OASIS or PJM Data Miner and the schedule plans on those, with EIA kept as the cross-check.

    With CAISO OASIS, PJM Data Miner 2, Modbus TCP

Requirements

  • A battery controller exposing SunSpec model 802 or the vendor's documented registers over Modbus TCP, with remote control permitted
  • A Modbus TCP connector polling the service-entrance meter at the interval your tariff bills on
  • The EIA grid signal with your balancing authority named, or an ISO market feed for the node that prices your site
  • The reserve you want held for outages and the tariff's demand-charge window, both in writing
Authentication
Writes controller registers only through the Modbus connector's per-device allow-list as approved proposals, reads EIA with its free API key, and uses the OAuth 2.0 credentials your Enphase or SolarEdge connector holds for telemetry.

Limits

  • EIA's series arrive with a lag and at hourly resolution. A site that settles on the ISO's real-time interval needs that feed as well.
  • The load forecast comes from your own meter history. A new site or an unusual week gets a wider margin and a smaller dispatch.
  • The schedule stays inside SocRsvMin and SocRsvMax, and inside the rates the controller reports. It never asks for more than the nameplate.
  • SMA's ChargeStorage, DisChargeStorage, and StorageMode commands have no backend function yet, so an SMA plant is read-only here.

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 Battery Dispatch ↗

Questions and answers

What does a person approve each day?
The next day's schedule as a table: each hour's action and power level, the price and forecast load it planned on, the state of charge it expects, and the reserve it keeps. You can edit hours or approve the day. Writes go to the controller only after that.
What record is left for each day?
A receipt per day: the prices and readings used, the schedule approved, every register write with the controller's acknowledgement, the state of charge reported each hour, and who approved it. A day with no approval is logged as held at reserve.
What happens if the battery reports a fault?
The operator proposes holding at reserve and stops sending the day's remaining writes until someone clears the alarm. It never resets an alarm through AlmRst, connects or disconnects the bank, or changes SocRsvMin on its own.
Ask about Battery Dispatch

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