Reference · built on requestOperator by FibricEnergy & demand

Depot Charging

Builds each vehicle's overnight charge schedule from state of charge, departure time, and tariff periods, and proposes it to the depot lead.

Request accessPricing ↗

About

A depot fills its chargers at plug-in and pays peak rates for energy that could have waited. Every vehicle has a state of charge, a departure, and an energy need for tomorrow's route. The tariff has hours that cost less.

Depot Charging reads state of charge and charging status from Samsara or Geotab, the next departure from the route plan, and the utility's weekday and weekend hour schedules from the OpenEI Utility Rate Database. It reads what each charger has delivered so far over OCPP. It then drafts one schedule per vehicle: when to charge, at what current, and to what limit, so every vehicle leaves ready and as much energy as possible lands in the cheaper hours. The depot lead approves the plan, and each vehicle's schedule and the reasons for it are kept.

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

  • evStateOfChargeMilliPercent, evChargingStatus, and evChargingEnergyMicroWh from the Samsara vehicle stats feed
  • ChargeEvent records from Geotab: startStateOfCharge, endStateOfCharge, energyConsumedKwh, peakPowerKw, and AC or DC chargeType
  • Routes, stops, and planned departure times from the telematics platform, so each vehicle's next need is known
  • Transactions and MeterValues per charger over OCPP, or Monta charges with consumedKwh and soc
  • energyweekdayschedule, energyweekendschedule, and energyratestructure for the depot's rate from OpenEI URDB
  • The depot's charger count, port power, and any site limit that Charge Balancing already enforces

Proposed actions

  • Target capability: propose a charge schedule per vehicle: start, current, and charge limit, laid out against the tariff periods
  • Target capability: propose the schedule to the vehicle as set_scheduled_departure or add_charge_schedule through the Tesla Fleet API
  • Target capability: propose a charging profile per station over OCPP that holds a session until the cheaper window begins
  • Target capability: propose starting or stopping a charge on a Monta charge point at the scheduled time
  • Target capability: propose pulling a vehicle forward when its departure moves earlier than its schedule allows

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

What you can build

  • Fill a van fleet after the peak window

    Read state of charge from Samsara, tomorrow's first stop per vehicle, and the weekday schedule from OpenEI URDB, and get a schedule that starts each charger over OCPP when the cheaper hours begin.

    With Samsara, OpenEI Utility Rate Database, Open Charge Point Protocol (OCPP)

  • Schedule Tesla vehicles by departure

    Where the depot runs Tesla vehicles, the proposed plan becomes set_scheduled_departure per vehicle, with the off-peak end taken from the tariff, sent through the Tesla Fleet API on approval.

    With Tesla Fleet API, Geotab, OpenEI Utility Rate Database

  • Pull forward a vehicle whose route changed

    When Geotab shows a departure moved earlier, the operator proposes advancing that vehicle's charge on its Monta charge point and shows which schedule it displaces.

    With Geotab, Monta Public API

Requirements

  • A Samsara or Geotab connector with electric vehicles reporting state of charge, and a route or departure plan
  • An OCPP management system, Monta, or ChargePoint connector for the depot chargers, or the Tesla Fleet API for the vehicles
  • The depot's utility rate, chosen from OpenEI URDB or written down with its weekday and weekend hours
  • The energy each route needs, or enough trip history for the operator to estimate it per vehicle
Authentication
Reads telematics with the API token or user your Samsara or Geotab connector holds, reads OpenEI URDB with its free api_key, and sends vehicle or charger commands only through the OCPP, Monta, or Tesla connector as approved proposals.

Limits

  • State of charge arrives through the telematics platform on its own cadence. A vehicle that stopped reporting is scheduled from its last reading.
  • OpenEI URDB entries are records, not your bill. Riders, demand charges, and a rate your utility has not published there need a hand-written schedule.
  • A vehicle that must leave before the cheaper window can fill it is scheduled to leave ready, at peak price. The plan says so.
  • It proposes schedules. It does not dispatch vehicles, change routes, or move a departure.

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 Depot Charging ↗

Questions and answers

What does the depot lead approve?
The night's plan: one row per vehicle with its state of charge, departure, energy need, the charger and window assigned, and the tariff period each hour falls in. They can move a vehicle, change a limit, or approve the plan whole. Nothing reaches a charger or vehicle first.
What record is left in the morning?
A receipt per vehicle: the readings used, the schedule proposed, what was sent to the charger or vehicle and when, the state of charge reported at departure, and who approved it. The rate used is named with its OpenEI URDB entry.
Will it ever leave a vehicle unready to save money?
Not by design. Departure readiness comes first in every plan. Where the cheaper window cannot deliver the energy in time, the schedule charges through peak hours and the receipt shows the cost of that choice.
Ask about Depot Charging

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