OCPP 1.6J Reference

Overview

This document provides integration specifications for the BrightBlu Charging Communication Controller. Our implementation follows the OCPP 1.6J protocol, with BrightBlu-specific enhancements — including custom configuration keys, Smart Charging, and support for custom packets and custom data packets (vendor-specific DataTransfer messages) for bespoke integrations.

Custom packets (DataTransfer)

BrightBlu chargers support the OCPP DataTransfer message for vendor-specific packets — a way to exchange custom commands or data that are not part of standard OCPP. Custom packets are provisioned per integration: the charger recognises a specific vendorId and one or more agreed messageIds.

A DataTransfer request has this shape:

[2, "<uniqueId>", "DataTransfer", {
  "vendorId": "<your-vendor-id>",
  "messageId": "<message-name>",
  "data": "<payload>"
}]

The charger replies with one of: Accepted, UnknownMessageId (vendor recognised, message not), or UnknownVendorId.

Example — stop at a target energy

A custom stop-energy packet tells the charger to end an ongoing session once it has delivered a target amount of energy. The data field carries the transaction id and the target energy in kWh, separated by an underscore:

[2, "<uniqueId>", "DataTransfer", {
  "vendorId": "<your-vendor-id>",
  "messageId": "Stop_Energy",
  "data": "<transactionId>_<energyKWh>"
}]

For example, "1024_34.5" stops transaction 1024 once 34.5 kWh have been delivered. The charger stores the target and ends the session when the delivered energy reaches it.

To add a custom packet for your platform, contact BrightBlu with the messages and payloads you need.

Transaction Flow Architecture

Our controller implements a state machine for transactions with the following key states:

1. Available: Ready to accept a new transaction
2. Preparing: Authorization in progress
3. Charging: Active charging session
4. Suspended EV: Vehicle has paused charging
5. Finishing: Transaction ending sequence
6. Reserved: Connector is reserved for a specific user
7. DiodeError: Vehicle has detected water/contaminants in the connector. Will not charge
8. VentError: Vehicle has detected ventilation issues with its cooling system and will need to cool down before charging
9. Faulted: Faults detected by the charger or vehicle. Detailed list provided below

Authorization Flow

The authorization sequence follows specific pathways based on configuration parameters:

┌─────────────────┐    ┌───────────────────┐    ┌───────────────────┐
│ RFID Presented  │───►│ LocalPreAuthorize │───►│ Local DB Check    │
└─────────────────┘    └───────────────────┘    └─────────┬─────────┘
                                                           │
                                                           ▼
┌────────────────────┐    ┌───────────────┐    ┌───────────────────┐
│ Remote Authorization◄───┤ Not Found     │◄───┤ RFID Found?      │
└──────────┬─────────┘    └───────────────┘    └───────────────────┘
           │                                            │
           ▼                                            ▼
┌─────────────────────┐                       ┌──────────────────┐
│ Central System Auth  │                      │ Begin Transaction │
└──────────┬──────────┘                       └──────────────────┘
           │
           ▼
┌─────────────────────┐
│ Transaction Decision │
└─────────────────────┘

Parameter Interactions & Dependencies

Authorization Parameter Relationships

The following parameters work together to control authorization behavior:

Primary Parameter	Related Parameters	Interaction Behavior
LocalPreAuthorize	AuthorizationCacheEnabled	When LocalPreAuthorize=true and AuthorizationCacheEnabled=true, the system checks the local cache before making a server request
LocalAuthorizeOffline	AllowOfflineTxForUnknownId	When offline, LocalAuthorizeOffline controls whether local authorization is attempted. If true but RFID is unknown, AllowOfflineTxForUnknownId determines if charging proceeds
AuthorizeRemoteTxRequests	-	Controls whether RemoteStartTransaction commands require separate authorization via Authorize request

Example: If server connectivity is lost during charging (connectionServer=false):

• If LocalAuthorizeOffline=true: New RFID requests will be validated against local whitelist
• If AllowOfflineTxForUnknownId=true: Unknown RFIDs will be accepted
• If both are false: No new charging sessions will be authorized during offline periods

Transaction Control Parameters

These parameters determine behavior during active charging sessions:

Parameter	Related Parameters	Effect
StopTransactionOnEVSideDisconnect	UnlockConnectorOnEVSideDisconnect	When vehicle disconnects while StopTransactionOnEVSideDisconnect=true, transaction ends and connector unlocks if UnlockConnectorOnEVSideDisconnect=true
StopTransactionOnInvalidId	-	When a different RFID is presented during charging, transaction ends if this is true
suspendedEVTimeout	-	Maximum time (seconds) to wait in “SuspendedEV” state before ending transaction

Implementation Detail: Our controller sends StatusNotification with status=“SuspendedEV” when charging pauses, then monitors for timeout specified in suspendedEVTimeout. Once exceeded, a StopTransaction with reason=“EVDisconnected” is automatically triggered.

Meter Value Configuration

The meter value parameters form a complex interaction that controls data sampling and reporting:

Parameter	Related Parameters	Effect
MeterValueSampleInterval	MeterValuesSampledData	Controls how frequently (seconds) the meter values in MeterValuesSampledData are sampled and sent

Implementation Note: Our system attempts to optimize network traffic by:

1. Not sending unchanged meter values when variations are below thresholds
2. Bundling multiple measurements when possible
3. Prioritizing critical measurements (Energy.Active.Import.Register) during network constraints

Phase Configuration & Power Management

The “Phase” parameter is critical for charger operation:

• Single.Phase: Operates on L1-N, limits to 7kW
• Three.Phase: Operates on L1-L2-L3-N, supports up to 22kW

The system automatically applies appropriate limits to DPM (Dynamic Power Management) based on phase configuration.

Meter Value Measurement Specifics

Our implementation supports these specific measurements:

Measurement	Units	Description
Energy.Active.Import.Register	Wh	Cumulative energy consumed (required in all transaction messages)
Voltage	V	RMS voltage per phase
Current.Import	A	Current being drawn per phase
Power.Active.Import	W	Active power being drawn
Temperature	C	Internal temperature of charging unit
Frequency	Hz	AC frequency
Power.Factor	-	Power factor ratio (0.00-1.00)
Current.Offered	A	Maximum current available from EVSE

Implementation Detail: All the data is directly retrieved from the Energy Meter. No calculations/edits are done to these values.

Smart Charging

The charger implements the OCPP 1.6 Smart Charging profile. A CSMS can cap the delivered current with SetChargingProfile, remove caps with ClearChargingProfile, and read the active limit with GetCompositeSchedule. A TxProfile can also be attached to a RemoteStartTransaction.

Profiles and limits

• Purposes — all three are supported: ChargePointMaxProfile (station-wide, must use connectorId 0), TxDefaultProfile (default limit), and TxProfile (per-session; requires an active or pending transaction).
• Kinds — Absolute, Recurring (Daily / Weekly) and Relative are supported. Recurring windows and later schedule periods take effect automatically over time — the charger re-evaluates the active period continuously, so you don’t need to resend a profile for a scheduled step-change.
• Rate unit — send schedules in Current (Amps). Power (Watts) is not supported (ChargingScheduleAllowedChargingRateUnit = Current).
• Clamping — the resulting limit is clamped to 6 A (IEC 61851 minimum) at the low end and the charger’s configured rated maximum (e.g. 32 A) at the high end.
• numberPhases is accepted and echoed back but does not change the Amps limit (the hardware does not switch 1↔3-phase mid-session; ConnectorSwitch3to1PhaseSupported = false).

How profiles combine

Within a purpose, the profile with the highest stackLevel wins (standard OCPP). Across purposes, the charger applies the strictest (lowest) limit of all active profiles — so a TxProfile can tighten but not raise the limit set by a TxDefaultProfile or ChargePointMaxProfile. Re-sending a profile with the same chargingProfileId (or the same purpose + stackLevel + connector) replaces the stored one.

The profile cap is combined with the charger’s thermal/voltage derating — the current the vehicle sees is always the stricter of the two. A newly applied cap becomes effective within a few seconds.

Note

Charging profiles take effect during an active transaction. Outside a session the charger uses its configured rated current.

Storage limits

Max profiles stored	5 total (shared across all purposes and connectors; persist across reboot)
Max stack level	5
Max periods per schedule	8

If all 5 slots are full and a new, non-matching profile arrives, SetChargingProfile is rejected.

Clearing and querying

• ClearChargingProfile — filter by any of id, connectorId, stackLevel, chargingProfilePurpose (all criteria present must match). An empty request clears every profile. Returns Accepted if any were cleared, otherwise Unknown.
• GetCompositeSchedule — returns the current effective limit as a flat schedule for the requested connector. It reports the limit in force now; it does not project future step-changes (an upcoming recurring window or a later period will not appear as a separate period). Use it to read the present cap, not to forecast.

Reservation Implementation

Our reservation system has specific behavior:

1. Reservations timeout after the expiry time in ReserveNow
2. Only the specified idTag can initiate a transaction during reservation
3. Presenting a different RFID during the reservation period results in rejection

Error Code Details

When sending StatusNotification, our controller uses these specific error codes:

Error Code	Description	System Response
ConnectorLockFailure	Unable to lock/unlock connector	Retry 3 times, then report failure
EVCommunicationError	Cannot establish/maintain EV communication	Wait 30s, attempt reset
GroundFailure	Ground fault detected	Immediate shutdown, requires manual reset
HighTemperature	System temperature exceeds safe threshold	Reduces max current, may shutdown
PowerMeterFailure	Unable to read energy meter	Falls back to calculated energy values
PowerSwitchFailure	Cannot control power contactor	Immediate shutdown, reports fatal error
ReaderFailure	RFID reader malfunction	System remains operational but requires service
ResetFailure	Failed to reset system	Attempts alternative reset method
WeakSignal	Cellular/WiFi signal below threshold	Only sent in Available State and is NOT a FAULTED state. Attempts connectivity recovery measures.

The following error codes carry additional detail on the specific condition/threshold that triggers them:

Error Code	Description
UnderVoltage	BRIGHTBLU Chargers support an input supply value of +/- 20% of 230V
OverVoltage	BRIGHTBLU Chargers support an input supply value of +/- 20% of 230V
OverCurrentFailure	Charger has detected that the current drawn is greater than max allowed (32A)
HighTemperature	Charger temperature sensor detects an internal temperature greater than 80°C and has shut down to prevent further damage
GroundFailure	Neutral - Earth voltage has exceeded permissible values (maximum allowed 8V)
DiodeError	Diode failure detected at vehicle end
VentError	Ventilation error failure detected at vehicle end

OtherError covers the following sub-errors, reported via vendorErrorCode:

• EmergencyButton — Emergency button is pressed
• InputFrequencyError — Frequency of input supply is not between 50/60 Hz
• EarthLeakageError — A current leakage of either 30mA AC or 6mA DC has been detected
• PowerFailure — Loss of input supply power (will only work with BRIGHTBLU POWER BACKUP systems)
• ModBusComsFailure — Loss of communication with Energy Meter
• VPRError — Input supply error (phase reversal or asymmetrical input supply), mostly with 3-Phase
• SDCardFailure — Internal SD card error (logging and OTA updates disabled but charger will function normally otherwise)

Configuration parameters

Every OCPP configuration key the charger supports — with its access (RW / RO / WO), type, default, accepted values and meaning — is documented on the Configuration Keys page.

Charger Configuration

To set up your charger, please download the BRIGHTBLU Install Partner application:

• Play Store
• App Store

Authentication requires a one-time password (OTP) provided by BRIGHTBLU Support. After successful login, you can connect to your BRIGHTBLU JOLT Charger.

Important Configuration Notes

1. Device Identification

   • The Charger ID displayed in the BLE application is fixed and cannot be changed
   • The OCPP Device ID setting affects only OCPP server communications

2. Server URL Format

   • Use the following format: ws://"host":"port"/"path" or wss://"host":"port"/"path"
   • Port specification is mandatory (even for default ports 80/443)
   • Do not include trailing slashes (/) or the charger ID in the URL
   • The device automatically appends the charger ID to complete the connection URL

3. Energy Metering

   • Jolt Business: Stores cumulative energy values between sessions
   • HomePlus: Resets energy counter at the start of each session (meterStart = 0)

4. Network

   • BRIGHTBLU Jolt HomePlus only supports WiFi / BLE / SIM
   • BRIGHTBLU Jolt Business supports WiFi / BLE / SIM / LAN
   • BRIGHTBLU JOLT always uses WiFi. The SIM Module on the JOLT acts as a hotspot for the controller to connect to. If you do not wish to connect it to SIM, you can always configure the charger to access other WiFi connections and also configure fallback WiFi connections.

Contact Information

For technical support or further information, please contact:

• [email protected]