ocpp¶
This interface allows to control an OCPP service and set and get data from the OCPP service. It is designed to be used for both OCPP1.6 and OCPP2.0.1 module implementations. Therefore, the vars, commands and types are based more on the definitions of OCPP2.0.1, as this offers more flexibility and it is easier to transfer to the capabilities of OCPP1.6 than vice versa.
Variables¶
ocpp_transaction_event: object (ocpp-OcppTransactionEvent)
Emits events related to OCPP transactions
ocpp_transaction_event_response: object (ocpp-OcppTransactionEventResponse)
Emits OCPP transaction responses
charging_schedules: object (ocpp-ChargingSchedules)
Object that contains OCPP charging schedules of all connectors. The object contains one composite charging schedule for each connector id starting from connector 0. Connector 0 contains a schedule for the whole charging station.
is_connected: boolean
Indicates if chargepoint is connected to CSMS
security_event: object (ocpp-SecurityEvent)
Published when an internal security event occurred
event_data: object (ocpp-EventData)
Published when a variable registered via monitor_variables has been changed. The event echoes the addressing form used at registration: canonical registrations receive the canonical component_variable, deprecated legacy key registrations (empty component.name) receive legacy-shaped events. With OCPP1.6 the object may only contain the required properties of the EventData type; with OCPP2.x it may contain all available properties.
boot_notification_response: object (ocpp-BootNotificationResponse)
Published any time a BootNotificationResponse message is received from the CSMS
ocpp_message: object (ocpp-Message)
A serialized OCPP message, published when callback logging is activated
Commands¶
stop: boolean
Disconnects the websocket connection and stops the OCPP communication. No OCPP messages will be stored and sent after a restart.
Result: boolean
Returns true if the service could be stopped successfully, else false
restart: boolean
Connects the websocket and enables OCPP communication after a previous stop call.
Result: boolean
Returns true if the service could be restarted successfully, else false
security_event: void
Triggers a SecurityEventNotification.req at the CSMS if it is deemed critical, either by setting the flag in this event or if absent automatically by libocpp
event: object <required> (ocpp-SecurityEvent)
A security event
get_variables: array
Command to read variables from OCPP. Variables are addressed canonically by component and variable name (e.g. component OCPPCommCtrlr, variable HeartbeatInterval), regardless of whether OCPP1.6 or OCPP2.x is active. An empty component.name marks the deprecated OCPP1.6 legacy key form (variable.name = configuration key); it is only accepted while OCPP1.6 is active and will be removed per the deprecation policy. A request with a non-empty component.name is never reinterpreted as a configuration key. Canonical addressing across protocol versions is provided by the OCPPmulti module; other modules implementing this interface may differ.
requests: array <required>
List of GetVariableRequest
array_item: object (ocpp-GetVariableRequest)
Result: array
List of GetVariableResult containing the result for every requested value. Preserves the order of the input requests. Each result echoes the requested component_variable and carries a status (Accepted, Rejected, UnknownComponent, UnknownVariable or NotSupportedAttributeType).
array_item: object (ocpp-GetVariableResult)
set_variables: array
Command to write variables at OCPP. Uses the same canonical component/variable addressing as get_variables in both protocol versions; the empty-component OCPP1.6 legacy key form is deprecated and scheduled for removal. Connection-configuration writes (component NetworkConfiguration with the profile slot number as component instance, and the OCPPCommCtrlr/NetworkConfigurationPriority selector) return RebootRequired: the value is validated and persisted immediately and takes effect on the next (re)connect or reboot. Slot-based connection configuration is provided by the OCPPmulti module; other modules implementing this interface may differ.
requests: array <required>
List of SetVariableRequests
array_item: object (ocpp-SetVariableRequest)
source: string <required>
Source of variable values
Result: array
List of SetVariableResult containing the result for every requested set operation. Each result echoes the requested component_variable and carries a status (Accepted, RebootRequired, Rejected, UnknownComponent, UnknownVariable or NotSupportedAttributeType).
array_item: object (ocpp-SetVariableResult)
change_availability: object
Allows to send a ChangeAvailabilityRequest internally (as can be done by the CSMS).
request: object <required> (ocpp-ChangeAvailabilityRequest)
The ChangeAvailabilityRequest as specified in OCPP2.0.1. For OCPP 1.6:
Result: object (ocpp-ChangeAvailabilityResponse)
Response to ChangeAvailabilityRequest as specified in OCPP 2.0.1
monitor_variables: void
Command to start monitoring the given ComponentVariable(s), using the same canonical component/variable addressing as get_variables in both protocol versions; the empty-component OCPP1.6 legacy key form is deprecated. Changes to monitored variables are published on the event_data var. Consecutive calls of this operation will not override but extend the existing monitors.
component_variables: array <required>
List of ComponentVariable(s) to monitor
array_item: object (ocpp-ComponentVariable)