Use this file to discover all available pages before exploring further.
This page walks through concrete examples of the charging schedules Axle sends for different intents and tariffs. Use it to reason about what your users will experience, and how to handle the edge cases.
Axle charges throughout the off-peak window, comfortably meeting the 30 kWh intent. The charger idles during peak rates before and after.
OCPP ChargingProfile payload
Axle sets limit to 99999.0 as an “unlimited” signal. The charger draws at its rated power during each charging period. See the integration guide for how to receive these payloads.
Under the default charging_mode: maximise_charging_time, Axle treats the energy intent as a minimum, not a cap, and charges through all remaining off-peak slots.
With charging_mode: minimise_charging_time, Axle charges for just long enough to meet the 10 kWh intent, starting at the beginning of the off-peak window. Axle adds a small safety factor on top to account for variable charging efficiency, so the scheduled energy will be slightly above the stated intent.
At 00:30 a market change makes it more valuable for Axle to insert a one-hour pause, so Axle sends a revised schedule covering the remainder of the session. The Actual row shows what the charger actually delivers — the initial schedule applies until the update lands, and the revised schedule applies from then on.
With may_charge_peak: false, Axle cannot use peak slots. With no off-peak slots available, Axle cannot deliver any energy toward the 10 kWh intent. We still send a schedule (a single 0 W period) to tell the charger explicitly not to charge.If the user needs to override this and charge immediately, initiate the charge on your side and notify Axle with a charge-now event.
A few things to know when handling the schedules Axle sends you.
Stack a default profile behind Axle's schedule
Axle sends schedules at OCPP stackLevel: 1100 with chargingProfilePurpose: TxProfile. You should install a long-running TxDefaultProfile at a lower stack level (e.g. 0) representing your fallback charging policy. When Axle’s TxProfile expires or is superseded, the charger falls back to your default rather than continuing an old Axle schedule.It also acts as a failsafe: if the charger ever loses connectivity or hasn’t yet received a schedule, it falls back to your default rather than charging at full rate immediately.
Each new Axle schedule replaces the previous one
Axle’s schedules at a given stackLevel fully replace the previous schedule at that level. Don’t try to merge them. Treat the most recent schedule as authoritative.
A schedule with only 0 W periods is valid
An Axle schedule containing a single chargingSchedulePeriod with limit: 0.0 is an explicit instruction: hold the charger at 0 W for the schedule’s duration. It’s not an empty or invalid payload. Apply it like any other schedule. The user can always supersede it by triggering an immediate overriding charge.This happens when Axle cannot schedule any charging between the plug-in time and ready-by, typically when may_charge_peak is false and no off-peak slots are available, or when the intent is already satisfied.
