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


Meeting Notes:


17 April 2024

Discussed:

  • 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

Discussed:

  • 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

Discussed:

  • 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

Discussed:

  • 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

Discussed:

  • 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

Discussed

  • 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

Discussed:

  • 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

Other:


14 February 2024

General updates

Smart Charging implementation: https://github.com/EVerest/libocpp/issues/468

  • 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: https://github.com/EVerest/libocpp/issues/467

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

Auth Cache Cleanup PR: https://github.com/EVerest/libocpp/pull/243

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: https://github.com/EVerest/libocpp/issues/450

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: https://github.com/EVerest/libocpp/issues/432
  • 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