Provisioning Flows - CSMS Developer Guide

On CS reconnection after offline period:
  1. Accept and process StatusNotificationRequests
  2. Update connector status records in database
  3. Resume accepting HeartbeatRequests
  4. Be prepared to receive queued TransactionEventRequests
     for transactions that occurred while offline

{
  "setVariableData": [            // REQUIRED, array, minItems: 1
    {
      "attributeType": "<AttributeEnumType>",  // optional (default: "Actual")
      "attributeValue": "<string, max 1000>",  // REQUIRED
      "component": {                            // REQUIRED
        "name": "<string, max 50>",             // REQUIRED
        "instance": "<string, max 50>",         // optional
        "evse": {                               // optional
          "id": "<integer>",                    // REQUIRED within EVSE
          "connectorId": "<integer>"            // optional
        }
      },
      "variable": {                             // REQUIRED
        "name": "<string, max 50>",             // REQUIRED
        "instance": "<string, max 50>"          // optional
      }
    }
  ]
}

{
  "setVariableResult": [          // REQUIRED, array, minItems: 1
    {
      "attributeType": "<AttributeEnumType>",     // optional (default: "Actual")
      "attributeStatus": "<SetVariableStatusEnumType>", // REQUIRED
      "attributeStatusInfo": {                     // optional
        "reasonCode": "<string, max 20>",
        "additionalInfo": "<string, max 512>"
      },
      "component": { ... },  // mirrors request
      "variable": { ... }    // mirrors request
    }
  ]
}

When setting variables:
  1. Respect ItemsPerMessageSetVariables limit
  2. Do not duplicate Component+Variable+AttributeType in one request
  3. Process each SetVariableResult in the response:
     - Accepted: Variable was set. Update internal records if maintained
     - RebootRequired: Variable will take effect after reboot.
       CSMS may need to send ResetRequest (B11/B12) for it to take effect
     - Rejected: Check statusInfo for reason
     - UnknownComponent/UnknownVariable: The CS doesn't recognize this
     - NotSupportedAttributeType: This attribute type not supported
  4. If attributeType was omitted in request, response will contain Actual

When getting variables:
  1. Respect ItemsPerMessageGetVariables limit
  2. If attributeType omitted, CS will return Actual value
  3. Process each GetVariableResult:
     - Accepted: attributeValue contains the value
     - Rejected: Variable is WriteOnly
     - UnknownComponent/UnknownVariable: CS doesn't know this
     - NotSupportedAttributeType: Attribute type not supported
  4. Note: attributeValue may be empty string even when Accepted
     (e.g., Target not yet set)

{
  "requestId": "<integer>",          // REQUIRED - matches GetBaseReportRequest.requestId
  "generatedAt": "<dateTime>",       // REQUIRED - when report was generated at CS
  "seqNo": "<integer>",              // REQUIRED - sequence number, starts at 0
  "tbc": "<boolean>",                // optional (default: false) - true if more parts follow
  "reportData": [                    // optional - array of ReportDataType
    {
      "component": { ... },
      "variable": { ... },
      "variableAttribute": [         // REQUIRED, 1-4 items
        {
          "type": "<AttributeEnumType>",        // optional (default: Actual)
          "value": "<string, max 2500>",        // optional (omitted if WriteOnly)
          "mutability": "<MutabilityEnumType>", // optional (default: ReadWrite)
          "persistent": "<boolean>",            // optional (default: false)
          "constant": "<boolean>"               // optional (default: false)
        }
      ],
      "variableCharacteristics": {   // optional
        "dataType": "<DataEnumType>",        // REQUIRED
        "supportsMonitoring": "<boolean>",   // REQUIRED
        "unit": "<string, max 16>",          // optional
        "minLimit": "<number>",              // optional
        "maxLimit": "<number>",              // optional
        "valuesList": "<string, max 1000>"   // optional - CSV of allowed values
      }
    }
  ]
}
// MutabilityEnumType: ReadOnly, WriteOnly, ReadWrite
// DataEnumType: string, decimal, integer, dateTime, boolean, OptionList, SequenceList, MemberList

When requesting base reports:
  1. Generate a unique requestId (integer) to correlate responses
  2. Send GetBaseReportRequest with desired reportBase
  3. On receiving GetBaseReportResponse:
     - Accepted: Prepare to receive NotifyReportRequest messages
     - Rejected: CS temporarily unable, retry later
     - NotSupported: This reportBase not supported by CS
     - EmptyResultSet: Nothing to report
  4. Collect all NotifyReportRequest messages with matching requestId
  5. Reassemble using seqNo (starts at 0, incremental)
  6. Check tbc (to be continued):
     - true: more messages coming
     - false/absent: this is the last message
  7. Store the full device model (components, variables, attributes,
     characteristics) for the Charging Station
  8. Respond to each NotifyReportRequest with empty NotifyReportResponse

{
  "requestId": "<integer>",                  // REQUIRED
  "componentCriteria": [                     // optional, 1-4 items
    "<ComponentCriterionEnumType>"
  ],
  "componentVariable": [                     // optional, array
    {
      "component": {                         // REQUIRED
        "name": "<string, max 50>",
        "instance": "<string, max 50>",
        "evse": { "id": "<integer>", "connectorId": "<integer>" }
      },
      "variable": {                          // optional
        "name": "<string, max 50>",
        "instance": "<string, max 50>"
      }
    }
  ]
}

When requesting custom reports:
  1. Set componentCriteria to filter by component state (logical OR if multiple)
  2. Set componentVariable to filter by specific components/variables
  3. Both can be combined - results are the intersection
  4. If variable is omitted in componentVariable, CS reports every variable
     of that component
  5. If variable.instance is omitted, CS reports every instance
  6. The response flow is identical to B07 (NotifyReportRequest messages)
  7. Respect ItemsPerMessageGetReport limit

{
  "configurationSlot": "<integer>",      // REQUIRED - slot number
  "connectionData": {                    // REQUIRED - NetworkConnectionProfileType
    "ocppVersion": "<OCPPVersionEnumType>",    // REQUIRED
    "ocppTransport": "<OCPPTransportEnumType>", // REQUIRED
    "ocppCsmsUrl": "<string, max 512>",        // REQUIRED - URL of target CSMS
    "messageTimeout": "<integer>",             // REQUIRED - seconds
    "securityProfile": "<integer>",            // REQUIRED
    "ocppInterface": "<OCPPInterfaceEnumType>", // REQUIRED
    "apn": {                                   // optional - APNType
      "apn": "<string, max 512>",             // REQUIRED
      "apnAuthentication": "<APNAuthenticationEnumType>", // REQUIRED
      "apnUserName": "<string, max 20>",      // optional
      "apnPassword": "<string, max 20>",      // optional
      "simPin": "<integer>",                   // optional
      "preferredNetwork": "<string, max 6>",   // optional
      "useOnlyPreferredNetwork": "<boolean>"   // optional (default: false)
    },
    "vpn": {                                   // optional - VPNType
      "server": "<string, max 512>",          // REQUIRED
      "user": "<string, max 20>",             // REQUIRED
      "password": "<string, max 20>",         // REQUIRED
      "key": "<string, max 255>",             // REQUIRED
      "type": "<VPNEnumType>",                // REQUIRED
      "group": "<string, max 20>"             // optional
    }
  }
}
// OCPPVersionEnumType: OCPP12, OCPP15, OCPP16, OCPP20
// OCPPTransportEnumType: JSON, SOAP
// OCPPInterfaceEnumType: Wired0-Wired3, Wireless0-Wireless3
// APNAuthenticationEnumType: CHAP, NONE, PAP, AUTO
// VPNEnumType: IKEv2, IPSec, L2TP, PPTP

{
  "status": "<SetNetworkProfileStatusEnumType>", // REQUIRED
  "statusInfo": {                                 // optional
    "reasonCode": "<string, max 20>",
    "additionalInfo": "<string, max 512>"
  }
}

When setting a network profile:
  1. First use GetBaseReport or GetVariables to discover:
     - Available configuration slots (NetworkConfigurationPriority valuesList)
     - Active configuration slot (OCPPCommCtrlr.ActiveNetworkProfile)
     - Current security profile
  2. Choose a configurationSlot from the available slots
  3. Build the connectionData with the new CSMS URL and settings
  4. Send SetNetworkProfileRequest
  5. Process response:
     - Accepted: Profile stored. Changes won't take effect until reboot
       or migration (B10)
     - Rejected: Check statusInfo.reasonCode for details
     - Failed: Storage issue, may retry
  6. To activate: use B10 (Migrate to new CSMS) or B11/B12 (Reset)

Migration procedure:
  1. Prepare new CSMS connection data
  2. Send SetNetworkProfileRequest to store new profile in an available slot
  3. Verify Accepted response
  4. Send SetVariablesRequest for NetworkConfigurationPriority
     to place new profile slot first in priority list
  5. Send ResetRequest (type: OnIdle) to trigger reboot
  6. CS will reboot and connect to new CSMS

Fallback behavior:
  - If CS cannot reach new CSMS, it tries old connection profiles
  - CS alternates between old/new if both fail
  - CS should never permanently stop reconnection attempts

When resetting a CS (no active transactions):
  1. Determine scope:
     - Full CS reset: omit evseId
     - Single EVSE reset: include evseId
  2. Determine urgency:
     - Immediate: reset now (use when urgent)
     - OnIdle: reset when no transactions (safer, preferred)
  3. Send ResetRequest
  4. Process response:
     - Accepted: CS will reset. Expect:
       * For full CS reset: BootNotificationRequest after reboot
       * For EVSE reset: StatusNotificationRequest (Unavailable then Available)
     - Rejected: CS cannot reset (e.g., EVSE reset not supported)
     - Scheduled: CS will reset when idle (see B12)
  5. After reboot, follow B01 flow

When resetting a CS with ongoing transactions:

For Immediate reset:
  1. Send ResetRequest with type=Immediate
  2. CS responds Accepted
  3. Expect TransactionEventRequest(Ended, reason=ImmediateReset)
     for each active transaction - handle transaction cleanup
  4. Then expect BootNotificationRequest after reboot
  5. Handle any meter values in the final TransactionEventRequest

For OnIdle reset:
  1. Send ResetRequest with type=OnIdle
  2. CS responds Scheduled (if transactions active)
  3. CS stops accepting new transactions
  4. Wait for TransactionEventRequest(Ended) as transactions
     complete naturally
  5. CS reboots when all transactions ended
  6. Expect BootNotificationRequest after reboot

For EVSE-specific reset with transaction:
  - Same logic but scoped to a single EVSE
  - No full CS reboot needed
  - Expect StatusNotification (Unavailable -> Available) for that EVSE