This working group focusses on the communication between the charging station (EVerest) and the management system(s) (CPMS)

Meeting Notes:

17 April 2024


  • Database Migrations now merged. Documentation added to explain how it works. When migrating to this version the first version needs manuel work. After this it will be automatic.
  • Size of PRs. Larger or small, pros and cons
  • Discussed meeting format: stick to weekly. Try to discuss ongoing on next planned use cases.

10 April 2024


  • OCPP 2.0.1 status document merged. When adding new OCPP 2.0.1 features, please update the document.
  • Pull request for database migrations is open. Developer documentation will be added.
  • Discussed how to handle custom data fields.

3 April 2024


  • Function requirement status doc:
    • OCPP 2.0.1 status: Piet checked all not yet completed
    • OCTT 2.0.1 test cases status: Robert will convert sheet do markdown and put in EVerest documentation or core.
  • Configurable TxStart/TxStop points:
    • Proposal to put functionality for this in EVerest core, not libOCPP for now. Quicker to implement, this functionality can later be moved to libOCPP.
    • Nobody requires this functionality in libOCPP already.

27 March 2024


  • Drop websocketpp and move to libwebsockets
    • moving websocketpp to new websocket interface appears to require a lot of effort
    • discussion about dropping support for websocketpp → decision postponed
  • Review pull request process
    • Draft PRs can be used for internal reviews
    • Once PR is converted for review the maintainers will start the review process
  • How to get list of functional requirements up to date
  • List of past OCTT test cases
    • We will not add this to libocpp since it cannot be guaranteed that tests pass only with using libocpp → Correct integration of libocpp is required
    • Such a list could be added to everest-core 

20 March 2024


  • Optional requirements:
    • Long term EVerest should support as much functionality as possible.
    • For now it is ok to skip optional requirements.
    • If an optional requirement just allows (slightly) incorrect behaviou
    • K01.FR.44 specific: we will not implement, this allows bad behavior from a CSMS, not ideal.

  • Document implemented use case/functional requirements status:
    • Add the list of use cases in one file in Github, make it a table
    • Requirement number, status, remark
    • Table per functional block
    • Add status of Google Sheet in this file
    • Add checkmark to the pull request template

Action Items: 

  • Robert: Make table of OCPP 2.0.1 function requirements in Github
  • Robert: Move status from Google sheet into the github list
  • Robert: Update pull request template: Add "list of functional requirements updated."

13 March 2024


  • WebSocket compression. Is required for an CSMS, optional for a Charging Station. But a really nice to have.
  • How to setup security profile 2 and 3. Proposal to make an MRE to demonstrate this.
  • PKI and governance and policies for validation of certificates
  • Device Model
    • Currently supports all standardized variables (specified in the OCPP2.0.1 spec)
    • Defined mechanism to access EVSE and Connector components upcoming (Piet will create issue)
    • Functional requirements are sometimes ambigous because its not clear to wich component a referenced variable belongs to

6 March 2024


  • Pull requests: 440 & 452
  • Possible multi-threading problem during reconnects and (re)sending message during reconnects: triggering another reconnect 3 seconds later.
  • IdToken case insensitive, required by OCPP, where to handle this in EVerest? libOCPP? Some use cases might need case sensitive tokens. 

Action Items:

  • Put Signed MeterValues on Agenda General Call next week.
  • Write documentation on how to change OCPP 2.0.1 CSMS URL. 

21 February 2024

CSR flexibility

Update on websocket refactor

OCPP1.6 handling while in Pending


14 February 2024

General updates

Smart Charging implementation:

  • Slight incompatabilities between 1.6 and 2.0.1 for Smart Charging make it hard to find a common implementation for both 
  • Decision made to have separate implementations of OCPP1.6 and OCPP2.0.1 Smart Charging

OCPP Test naming convention:

Status: Websocket refactor update @Soumya Subramanya @Maaike Zijderveld @Marc Emmers

Auth Cache Cleanup PR:

7 February 2024

When to send signed meter values

  • End of the transaction is most logical.
  • Looks like code currently does not store values in the DB.
  • An libOCPP API change is needed to merge the signed meter values pull request.
  • The is an existing old pull request that also provides such a change.

DB Migration tools: See issue:

Status OCPP 2.0.1 development:

  • Shared sheet is not updated. Current coverage is getting to 100%, but that is not reflected in the sheet as agreed.
  • OCTT takes about 2 days to run all tests manually, API for CI/CD integration not yet available
  • Action Item: Robert will ask OCA about potential license issues with OCTT running in LFE build pipelines.

31 January 2024:

Faking MeterValue

  • Make faking MeterValue and TransactionEvent timestamps a configurable feature
  • Keep talking to OCA and OCTT team to find out more detailed requirements

Websocket refactoring:

  • Alfen to work on charge_point and websocket interface
  • Pionix to support on websocketpp and libwebsocket implementations of the interfaces
  • Discussion how we split up PRs (between interfaces and implementations) still ongoing @Soumya to provide feedback

Smart Charging:

  • Bug found within clear charging profiles:
  • Agreed on common base classes for OCPP1.6 and OCPP2.0.1 Smart Charging handling
  • Goal is to reuse as much of OCPP1.6 implementation for common smart charging implementation
  • No labels