everest / everest-core Goto Github PK

License: Apache License 2.0

CMake 3.79% C++ 83.40% JavaScript 3.14% C 2.30% Shell 0.15% Dockerfile 0.01% Python 3.80% Rust 2.87% Starlark 0.54%

everest-core's Introduction

The primary goal of EVerest is to develop and maintain an open source software stack for EV charging infrastructure. EVerest is developed having modularity and customizability in mind, so it consists of a framework to configure several interchangeable modules which are coupled by MQTT with each other. EVerest will help to speed the adoption to e-mobility by utilizing all the open source advantages for the EV charging world. It will also enable new features for local energy management, PV-integration, and many more.
The EVerest project was initiated by PIONIX GmbH, to help with the electrification of the mobility sector.

A complete documentation can be found here.

Build & Install

everest-core

Community

Welcome to the EVerest community 👋. See COMMUNITY.md how to get in contact with us.

Contributing

Anyone can contribute to the EVerest project - learn more at CONTRIBUTING.md. All project management related documents incl. our roadmap can be found here.

Governance

EVerest is a project hosted by the LF Energy Foundation. This project's technical charter is located in CHARTER.md and has established it's own processes for managing day-to-day processes in the project at GOVERNANCE.md.

Reporting Issues

To report a problem, you can open an issue in repository against a specific workflow. If the issue is sensitive in nature or a security related issue, please do not report in the issue tracker but instead email [email protected].

Licensing

EVerest and its subprojects are licensed under the Apache License, Version 2.0. See LICENSE for the full license text.

everest-core's People

Contributors

Stargazers

Watchers

everest-core's Issues

SerialCommHub doesn't support write_single_register command

As far as I can see the re is no way to send command WRITE_SINGLE_REGISTER to the Modbus device.

Theoretically, it it could be done by "write multiple registers" with count 1. But behaviour of the remote device can be different depending on command that is used.

To my knowledge some functionality of Iskra meter can be only used with WRITE_SINGLE_REGISTER command.

EVerest signalize 5% duty cycle during PLC network leave

Hi,
we recently tested AC HLC on our Tarragon platform (everest-core 2023.12.0). After an unsuccessful V2G session, we noticed that EVerest set a duty cycle of 5% during PLC network leave.

Expected behavior:
Starting with sending of CM_SET_KEY.REQ (leave current network) the duty cycle should be set to 100%. Otherwise EVs might start a SLAC session but this would likely fail because of packet lost (reason: PLC node reset / network leave). The duty cycle should be set to 5% only if the PLC node is ready to operate.

Jan 30 08:57:19 tarragon manager[1832]: 2024-01-30 08:57:19.292199 [INFO] iso15118_charge  :: TCP connection closed gracefully
Jan 30 08:57:19 tarragon manager[1828]: 2024-01-30 08:57:19.320970 [INFO] connector_1:Evs  :: EVSE ISO D-LINK_TERMINATE.req
Jan 30 08:57:19 tarragon manager[1828]: 2024-01-30 08:57:19.322053 [INFO] connector_1:Evs  :: EVSE IEC Set PWM Off
Jan 30 08:57:19 tarragon manager[1834]: 2024-01-30 08:57:19.442119 [INFO] tarragon_bsp:Cb  :: handle_pwm_off: Setting new duty cycle of 100.00%
Jan 30 08:57:19 tarragon manager[1834]: 2024-01-30 08:57:19.575191 [INFO] tarragon_bsp:Cb  :: handle_pwm_on: Setting new duty cycle of 5.00%
Jan 30 08:57:19 tarragon manager[1825]: 2024-01-30 08:57:19.594865 [INFO] EvseSlac0:EvseS  :: D-LINK_TERMINATE.request received, leaving network.
Jan 30 08:57:19 tarragon manager[1825]: 2024-01-30 08:57:19.595597 [INFO] EvseSlac0:EvseS  :: EvseSlac: Entered Reset state
Jan 30 08:57:19 tarragon manager[1825]: 2024-01-30 08:57:19.597394 [INFO] EvseSlac0:EvseS  :: EvseSlac: New NMK key: 51:4E:52:53:48:58:4D:48:46:4F:52:41:35:43:52:4F
Jan 30 08:57:19 tarragon manager[1825]: 2024-01-30 08:57:19.600537 [INFO] EvseSlac0:EvseS  :: EvseSlac: Received CM_SET_KEY_CNF
Jan 30 08:57:19 tarragon manager[1825]: 2024-01-30 08:57:19.601028 [INFO] EvseSlac0:EvseS  :: EvseSlac: Entered Idle state
Jan 30 08:57:19 tarragon manager[1828]: 2024-01-30 08:57:19.634055 [INFO] connector_1:Evs  :: EVSE ISO D-LINK_READY (false)
Jan 30 08:57:19 tarragon manager[1828]: 2024-01-30 08:57:19.651865 [INFO] connector_1:Evs  :: EVSE IEC Set PWM On (5.000000074505806%) took 140 ms
Jan 30 08:57:19 tarragon manager[1828]: 2024-01-30 08:57:19.740296 [INFO] connector_1:Evs  :: EVSE ISO SLAC UNMATCHED

Binary folder

Is it recommended that we copy binaries from build/dist/bin to ~/.local/bin since it has already been added to the path?

If so, should it be reflected in the documentation?

Cmake error while building everest core: "device_model_storage.db" not found

Hello,
I get the following error while building everest-core on Ubuntu 22.04 according to https://everest.github.io/nightly/general/03_quick_start_guide.html#quickstartguide-helpers.

CMake Error at _deps/libocpp-build/config/v201/cmake_install.cmake:57 (file):
  file INSTALL cannot find
  "/home/italia.texa.org/mmariotto/repos/checkout/everest-workspace/everest-core/build/_deps/libocpp-build/config/v201/device_model_storage.db":
  No such file or directory.
Call Stack (most recent call first):
  _deps/libocpp-build/config/cmake_install.cmake:52 (include)
  _deps/libocpp-build/cmake_install.cmake:66 (include)
  cmake_install.cmake:92 (include)

Building and linking goes fine until the install phase where this error occurs.
Do you have any idea why the device_model_storage.db is missing?

ALIAS target CURL::libcurl missing when using libcurl from dependencies.yaml

using curl as the target name works, but we should probably define the ALIAS target ourselves if it's missing

First compilation fails

When building everest-core following a procedure similar to the one used in everest-demo (i.e. using the EVerest CI build-kit container), the first compilation fails with the following error:

ninja: job failed: /usr/bin/ccache /usr/bin/c++ -DBOOST_ATOMIC_DYN_LINK -DBOOST_ATOMIC_NO_LIB -DBOOST_CHRONO_DYN_LINK -DBOOST_CHRONO_NO_LIB -DBOOST_FILESYSTEM_DYN_LINK -DBOOST_FILESYSTEM_NO_LIB -DBOOST_LOG_DYN_LINK -DBOOST_LOG_NO_LIB -DBOOST_REGEX_DYN_LINK -DBOOST_REGEX_NO_LIB -DBOOST_SYSTEM_DYN_LINK -DBOOST_SYSTEM_NO_LIB -DBOOST_THREAD_DYN_LINK -DBOOST_THREAD_NO_LIB -DFMT_SHARED -DONLY_C_LOCALE=0 -DUSE_OS_TZDB=1 -I/ext/source/modules/OCPP201 -I/workspace/build/generated/include -I/workspace/build/generated/modules/OCPP201 -I/workspace/build/_deps/everest-framework-build/generated -I/ext/cache/cpm/everest-framework/63a1c5de90bf26a8034c80c08ab99667b5ea4fb8/everest-framework/include -I/ext/cache/cpm/date/91ef8592e97dd3a2a15aed9de5dbf7e3ff2636eb/date/include -I/ext/cache/cpm/nlohmann_json/b3708972f6694fe462e4112e47aa04f10d2390b4/nlohmann_json/include -I/ext/cache/cpm/nlohmann_json_schema_validator/648e7cc933b58ff9d20a5288445b6172aa5fc67f/nlohmann_json_schema_validator/src -I/ext/cache/cpm/libfmt/db7252a8aa3d829180246c17fb97ef0f367a2322/libfmt/include -I/ext/cache/cpm/liblog/5d578ffd5bc0e07e1c9bd75d269f3692d33a96ca/liblog/include -I/ext/cache/cpm/libocpp/736f6150a3a497aa7dd80d7d9a65dfe59d3613e5/libocpp/include -I/ext/cache/cpm/libtimer/5f95893b9dd3ee5a130229e9a42efaedcd74640b/libtimer/include -I/ext/cache/cpm/libevse-security/548ca4a70a1757b2b6474706e0f4f603bd68f4d6/libevse-security/include -I/ext/source/lib/staging/ocpp -isystem /ext/cache/cpm/websocketpp/5d9dc11d6860090858d1bdaae8c72318d01a0a5a/websocketpp -g -std=gnu++17 -MD -MT modules/CMakeFiles/OCPP201.dir/OCPP201/data_transfer/ocpp_data_transferImpl.cpp.o -MF modules/CMakeFiles/OCPP201.dir/OCPP201/data_transfer/ocpp_data_transferImpl.cpp.o.d -o modules/CMakeFiles/OCPP201.dir/OCPP201/data_transfer/ocpp_data_transferImpl.cpp.o -c /ext/source/modules/OCPP201/data_transfer/ocpp_data_transferImpl.cpp
c++: fatal error: Killed signal terminated program cc1plus
compilation terminated.
ninja: job failed: /usr/bin/ccache /usr/bin/c++ -DBOOST_ATOMIC_DYN_LINK -DBOOST_ATOMIC_NO_LIB -DBOOST_CHRONO_DYN_LINK -DBOOST_CHRONO_NO_LIB -DBOOST_FILESYSTEM_DYN_LINK -DBOOST_FILESYSTEM_NO_LIB -DBOOST_LOG_DYN_LINK -DBOOST_LOG_NO_LIB -DBOOST_REGEX_DYN_LINK -DBOOST_REGEX_NO_LIB -DBOOST_SYSTEM_DYN_LINK -DBOOST_SYSTEM_NO_LIB -DBOOST_THREAD_DYN_LINK -DBOOST_THREAD_NO_LIB -DFMT_SHARED -DONLY_C_LOCALE=0 -DUSE_OS_TZDB=1 -I/ext/source/modules/OCPP201 -I/workspace/build/generated/include -I/workspace/build/generated/modules/OCPP201 -I/workspace/build/_deps/everest-framework-build/generated -I/ext/cache/cpm/everest-framework/63a1c5de90bf26a8034c80c08ab99667b5ea4fb8/everest-framework/include -I/ext/cache/cpm/date/91ef8592e97dd3a2a15aed9de5dbf7e3ff2636eb/date/include -I/ext/cache/cpm/nlohmann_json/b3708972f6694fe462e4112e47aa04f10d2390b4/nlohmann_json/include -I/ext/cache/cpm/nlohmann_json_schema_validator/648e7cc933b58ff9d20a5288445b6172aa5fc67f/nlohmann_json_schema_validator/src -I/ext/cache/cpm/libfmt/db7252a8aa3d829180246c17fb97ef0f367a2322/libfmt/include -I/ext/cache/cpm/liblog/5d578ffd5bc0e07e1c9bd75d269f3692d33a96ca/liblog/include -I/ext/cache/cpm/libocpp/736f6150a3a497aa7dd80d7d9a65dfe59d3613e5/libocpp/include -I/ext/cache/cpm/libtimer/5f95893b9dd3ee5a130229e9a42efaedcd74640b/libtimer/include -I/ext/cache/cpm/libevse-security/548ca4a70a1757b2b6474706e0f4f603bd68f4d6/libevse-security/include -I/ext/source/lib/staging/ocpp -isystem /ext/cache/cpm/websocketpp/5d9dc11d6860090858d1bdaae8c72318d01a0a5a/websocketpp -g -std=gnu++17 -MD -MT modules/CMakeFiles/OCPP201.dir/OCPP201/auth_provider/auth_token_providerImpl.cpp.o -MF modules/CMakeFiles/OCPP201.dir/OCPP201/auth_provider/auth_token_providerImpl.cpp.o.d -o modules/CMakeFiles/OCPP201.dir/OCPP201/auth_provider/auth_token_providerImpl.cpp.o -c /ext/source/modules/OCPP201/auth_provider/auth_token_providerImpl.cpp
c++: fatal error: Killed signal terminated program cc1plus
compilation terminated.
ninja: job failed: /usr/bin/ccache /usr/bin/c++ -DBOOST_ATOMIC_DYN_LINK -DBOOST_ATOMIC_NO_LIB -DBOOST_CHRONO_DYN_LINK -DBOOST_CHRONO_NO_LIB -DBOOST_FILESYSTEM_DYN_LINK -DBOOST_FILESYSTEM_NO_LIB -DBOOST_LOG_DYN_LINK -DBOOST_LOG_NO_LIB -DBOOST_REGEX_DYN_LINK -DBOOST_REGEX_NO_LIB -DBOOST_SYSTEM_DYN_LINK -DBOOST_SYSTEM_NO_LIB -DBOOST_THREAD_DYN_LINK -DBOOST_THREAD_NO_LIB -DFMT_SHARED -DONLY_C_LOCALE=0 -DUSE_OS_TZDB=1 -I/ext/source/modules/OCPP201 -I/workspace/build/generated/include -I/workspace/build/generated/modules/OCPP201 -I/workspace/build/_deps/everest-framework-build/generated -I/ext/cache/cpm/everest-framework/63a1c5de90bf26a8034c80c08ab99667b5ea4fb8/everest-framework/include -I/ext/cache/cpm/date/91ef8592e97dd3a2a15aed9de5dbf7e3ff2636eb/date/include -I/ext/cache/cpm/nlohmann_json/b3708972f6694fe462e4112e47aa04f10d2390b4/nlohmann_json/include -I/ext/cache/cpm/nlohmann_json_schema_validator/648e7cc933b58ff9d20a5288445b6172aa5fc67f/nlohmann_json_schema_validator/src -I/ext/cache/cpm/libfmt/db7252a8aa3d829180246c17fb97ef0f367a2322/libfmt/include -I/ext/cache/cpm/liblog/5d578ffd5bc0e07e1c9bd75d269f3692d33a96ca/liblog/include -I/ext/cache/cpm/libocpp/736f6150a3a497aa7dd80d7d9a65dfe59d3613e5/libocpp/include -I/ext/cache/cpm/libtimer/5f95893b9dd3ee5a130229e9a42efaedcd74640b/libtimer/include -I/ext/cache/cpm/libevse-security/548ca4a70a1757b2b6474706e0f4f603bd68f4d6/libevse-security/include -I/ext/source/lib/staging/ocpp -isystem /ext/cache/cpm/websocketpp/5d9dc11d6860090858d1bdaae8c72318d01a0a5a/websocketpp -g -std=gnu++17 -MD -MT modules/CMakeFiles/OCPP201.dir/OCPP201/auth_validator/auth_token_validatorImpl.cpp.o -MF modules/CMakeFiles/OCPP201.dir/OCPP201/auth_validator/auth_token_validatorImpl.cpp.o.d -o modules/CMakeFiles/OCPP201.dir/OCPP201/auth_validator/auth_token_validatorImpl.cpp.o -c /ext/source/modules/OCPP201/auth_validator/auth_token_validatorImpl.cpp
c++: fatal error: Killed signal terminated program cc1plus
compilation terminated.
ninja: job failed: /usr/bin/ccache /usr/bin/c++ -DBOOST_ATOMIC_DYN_LINK -DBOOST_ATOMIC_NO_LIB -DBOOST_CHRONO_DYN_LINK -DBOOST_CHRONO_NO_LIB -DBOOST_FILESYSTEM_DYN_LINK -DBOOST_FILESYSTEM_NO_LIB -DBOOST_LOG_DYN_LINK -DBOOST_LOG_NO_LIB -DBOOST_REGEX_DYN_LINK -DBOOST_REGEX_NO_LIB -DBOOST_SYSTEM_DYN_LINK -DBOOST_SYSTEM_NO_LIB -DBOOST_THREAD_DYN_LINK -DBOOST_THREAD_NO_LIB -DFMT_SHARED -DONLY_C_LOCALE=0 -DUSE_OS_TZDB=1 -I/ext/source/modules/OCPP201 -I/workspace/build/generated/include -I/workspace/build/generated/modules/OCPP201 -I/workspace/build/_deps/everest-framework-build/generated -I/ext/cache/cpm/everest-framework/63a1c5de90bf26a8034c80c08ab99667b5ea4fb8/everest-framework/include -I/ext/cache/cpm/date/91ef8592e97dd3a2a15aed9de5dbf7e3ff2636eb/date/include -I/ext/cache/cpm/nlohmann_json/b3708972f6694fe462e4112e47aa04f10d2390b4/nlohmann_json/include -I/ext/cache/cpm/nlohmann_json_schema_validator/648e7cc933b58ff9d20a5288445b6172aa5fc67f/nlohmann_json_schema_validator/src -I/ext/cache/cpm/libfmt/db7252a8aa3d829180246c17fb97ef0f367a2322/libfmt/include -I/ext/cache/cpm/liblog/5d578ffd5bc0e07e1c9bd75d269f3692d33a96ca/liblog/include -I/ext/cache/cpm/libocpp/736f6150a3a497aa7dd80d7d9a65dfe59d3613e5/libocpp/include -I/ext/cache/cpm/libtimer/5f95893b9dd3ee5a130229e9a42efaedcd74640b/libtimer/include -I/ext/cache/cpm/libevse-security/548ca4a70a1757b2b6474706e0f4f603bd68f4d6/libevse-security/include -I/ext/source/lib/staging/ocpp -isystem /ext/cache/cpm/websocketpp/5d9dc11d6860090858d1bdaae8c72318d01a0a5a/websocketpp -g -std=gnu++17 -MD -MT modules/CMakeFiles/OCPP201.dir/__/generated/modules/OCPP201/ld-ev.cpp.o -MF modules/CMakeFiles/OCPP201.dir/__/generated/modules/OCPP201/ld-ev.cpp.o.d -o modules/CMakeFiles/OCPP201.dir/__/generated/modules/OCPP201/ld-ev.cpp.o -c /workspace/build/generated/modules/OCPP201/ld-ev.cpp
c++: fatal error: Killed signal terminated program cc1plus
compilation terminated.
ninja: subcommands failed

However, subsequent builds with cache enabled succeed.

How to reproduce the issue

Checkout the everest-core repository.

Run the EVerest build kit:

docker run -it --name everest-core-build-kit -v .:/ext/source ghcr.io/everest/build-kit-alpine bash

Copy the compile script to the /ext/scripts directory inside the container:

mkdir -p /ext/scripts && cp /ext/source/.ci/build-kit/compile.sh /ext/scripts

Run the build:
```
/entrypoint.sh run-script compile
```
Approximately at step [306/1074] you should get the compilation error.
Run the build again:
```
/entrypoint.sh run-script compile
```
The build should succeed now.

EVSEManager: Module does not stop HLC in case of an unexpected CP state while charging

Describe the bug

Currently the module does not terminate the HLC communication when the CP state changes from CP state C/D (charging) to B/E/F. The implementation currently relies on the EV to close the HLC communication. This unexpected CP change can be caused by a faulty EV implementation, a defect in the CP cabling or even stray incoming electromagnetic interference.

EVerest Domain

ISO15118

Affected EVerest Module

EvseManager, EvseV2G

To Reproduce

SIL:

start SIL (e.g. run-sil.sh)
reach charging state in a HLC session (CP state C/D)
simulate CP state by sending MQTT topic 'mosquitto_pub -t everest/connector_1_powerpath/evse_board_support/var -m '{"data":{"event":"B"},"name":"event"}'' (Note: check the name of the bsp module)

HIL:

start AC/DC HLC charging session (CP state C/D)
configure CP state B/E/F while charging (Note: EV implementation shall not stop HLC communication on unxpected CP)

Anything else?

No response

python3 -m pip install --upgrade pip setuptools wheel jstyleson jsonschema error.

Describe the bug

EVerest Domain

Other

Affected EVerest Module

No response

To Reproduce

No response

Anything else?

No response

update configure_network_connection_profile_callback

Update configure_network_connection_profile_callback to work with std::future<ConfigNetworkResult> instead of bool.

Auth (multiport): connector remains in plug_in_queue, although it is plugged out

Version:
2024.2.0

Module config:

    config_module:
      connection_timeout: 20
      prioritize_authorization_over_stopping_transaction: true
      selection_algorithm: PlugEvents

    connections:
      evse_manager:
        - module_id: connector_1
          implementation_id: evse
        - module_id: connector_2
          implementation_id: evse

Describe the problem:

In case when a plug is plugged-in and plugged-out without performing an authorization via RFID, the connector remains in the plug_in_queue although it has already been unplugged. As a result, the plug-selection-algorithm, bases on "PlugEvents", detects the unplugged connector and authorize it for charging when a RFID card is presented, without any plugged-in connectors.

How to reproduce:

In a setup for a Multi-port charger, plug in one of the connectors, without authorziation (Plug in before authoziation).
Plug the connector out, also without authoziation.
Swipe a RFID card. The authoziation will be assigned to the connector which was just plugged out.

Expectation:
The authoziation should not be assigned to any connector until one of them is plugged in.

Describe your solution:

Remove connector ID from list in case "SessionFinished" event has been received

Additional context:

EvseV2G: No reaction if the contract is rejected during authorization

Describe the bug

If a contract is rejected, the charger should react accordingly and send a prober ResponseCode to the car. This is not happing right now.

EVerest Domain

ISO15118

Affected EVerest Module

EvseV2G

To Reproduce

Geneate an incorrect contract leaf and start a pnc sil

Anything else?

No response

EvseV2G: Plug&Charge does not work properly when resumed

Describe the bug

After resuming the session, EVerest is caught in an auth loop. Although the session is already authorized. It is also unclear whether, for example, the car should send the payment details message again.

EVerest Domain

ISO15118

Affected EVerest Module

EvseV2G
PyEvJosev

To Reproduce

Start a pnc sil, pause the session and resume after e.g. 15 seconds.

Anything else?

No response

EvseV2G: complete migration to libevse-security

In commits 138b9db and dda60db, the EvseV2G module was converted to use libevse-security to locate the TLS certificates.

Yet there are still certificate paths for PnC which are (hard-) coded within the source code, e.g. here:

everest-core/modules/EvseV2G/iso_server.cpp

Lines 1226 to 1227 in d40971c

 std::string v2g_root_cert_path = conn->ctx->certs_path + "/ca/v2g/V2G_ROOT_CA.pem"; 

 std::string mo_root_cert_path = conn->ctx->certs_path + "/ca/mo/MO_ROOT_CA.pem";

For consistency, EvseV2G should be converted to use libevse-security here.

Additionally, EvseV2G could use libevse-security to verify client certificates (etc.), instead of using its own code. (Stage 2, nice to have.)

Setup module should not perform wifi related tasks if setup_wifi is false

At the moment some wifi related operations are still periodically triggered, even if setup_wifi is set to false in the module config.
This can result in messages like:

Failed to connect to non-global ctrl_ifname: <INTERFACE_NAME>  error: Permission denied

DC SIL remains in the authorization loop despite accepted authorization.

Describe the bug

The DC Sil gets stuck in the current main commit in the authorization loop. However, the AC SIL works.

EVerest Domain

Authorization, Simulation

Affected EVerest Module

JsDCSupplySimulator

To Reproduce

Start config-sil-dc on actual main.

Anything else?

No response

UK smart charging regulations random delay

The UK smart charging regulations require a random delay whenever the charging current changes, either because of a start/stop of charging or if the current is adapted during charging (e.g. from 16 to 8 amps or 8 amps to 16 amps). The delay needs to be adjustable and should default to 600 seconds.

There are excemptions when the delay requirement does not apply, i.e. whenever the reason for the current change event itself was already sufficiently random.

The idea behind this is that all reasons for changing grid load that are synchronized over larger areas could cause problems in the power grid. E.g. When power comes back after a blackout not all EVs should start charging at the same time. But also a schedule coming from OCPP that is based on price signals is synchronized with many chargers and needs to have a random delay.

Finding out the root cause for a requested current change and verify whether it is already random or not is beyond the scope of everest-core. We should however implement helper functionality to enable those random delays and give external processes the possibility to cancel/enable/disable them.

Watchdog in EVerest

Right now the manager exits EVerest whenever a child (module) dies. Then systemd usually restarts EVerest to recover. If a module hangs in a command handler, the framework will also timeout and exit the module process which results in a restart of EVerest. We recently added some dead-lock detecting mutexes to EvseManager as well to ensure restarts in case a module hangs somewhere.

There is however no generic watchdog functionality that can be used inside of a module to watch a long running thread (e.g. a mainloop thread, or an IO thread) to see if it is still running, so there are still some threads in some modules that may hang without leading to an exit of the module process.

We should ensure that such scenarios will restart EVerest.

EvseV2G: Integration of libcbv2g as OpenV2G replacement

Currently the EvseV2G module uses the OpenV2G project to encode and decode EXI messages.
The goal now is to replace OpenV2G with the new libcbv2g library.

The libcbv2g contains the generated c EXI code from the cbexigen generator with a CMake integration.

Tasks:

dependencies.yaml + module-dependencies.cmake: replace openv2g with libcbv2g
EvseV2G module: Customize CMakeLists.txt
EvseV2G module: Customize include headers
EvseV2G module: Customize src code
DIN70121 is working
ISO15118-2 AC EIM is working
ISO15118-2 DC EIM is working
ISO15118-2 PnC is working

Every contribution is appreciated 😃

C++ objects within structure allocated via calloc()

Describe the bug

C++ objects should be created via new and removed via delete. This ensures that their constructors and destructors are properly called.

The v2g_context structure in EvseV2G is mostly pointers and basic types where use of calloc() to create the structure is fine.
However there are some std::string objects included that are not correctly constructed. When free() is called on the v2g_context pointer the strings are not destructed and hence there could be a memory leak.

One option would be to split the v2g_context structure into parts that can be managed via calloc/free and parts that require new/delete.

Starting points:

v2g.hpp for the v2g_context definition
v2g_ctx.cpp and v2g_ctx.hpp for functions creating and releasing v2g_context

EVerest Domain

ISO15118

Affected EVerest Module

EvseV2G

To Reproduce

Present in the 2024.3.0 release

Anything else?

No response

Segmentation fault (sigsegv) -- set_root_schema -- JSON validator

The source code is cross compiled for the raspberry pi with the bullseye toolchain (armv8-rpi4-linux-gnueabihf). The build is success, however, while running the everest manager, a segmentation fault is observed. I traced the segmentation fault to the function call: validator.set_root_schema(schema)
The input argument is a json file. Attached is the file being read by the software
validator.txt

The runtime failure is:
everest-dev.service: Main process exited, code=dumped, status=11/SEGV
systemd[1]: everest-dev.service: Failed with result 'core-dump'.

EVSE Paused when using OCPP

Hello,

I have to similar configs where one of the uses dummytokenvalidator while the other uses OCPP,
When ever I try to use the ocpp one I get EVSE paused almost immediately after clicking car plugin in the simulator, while when using the dummytokenvalidator, it works perfectly.
when I first created the ocpp config file it was working as expected but out of nowhere it stopped.

Here is the log in both cases:

dummytokenvalidator:

2024-03-06 14:19:51.916337 [INFO] DummyTokenValid :: Got validation request for token: 0123456789ABCD
2024-03-06 14:19:52.416672 [INFO] DummyTokenValid :: Returning validation status: Accepted
2024-03-06 14:19:52.439238 [INFO] auth:Auth :: Providing authorization to connector#1
2024-03-06 14:19:52.769891 [INFO] evse_manager:Ev :: EVSE IEC Set PWM On (5.000000074505806%) took 0 ms
2024-03-06 14:19:52.915920 [INFO] auth:Auth :: Result for token: 0123456789ABCD: ACCEPTED
2024-03-06 14:19:52.977889 [INFO] evse_manager:Ev :: EVSE IEC EIM Authorization received
2024-03-06 14:19:52.978091 [INFO] evse_manager:Ev :: EVSE IEC Transaction Started (0 kWh)
2024-03-06 14:19:52.978408 [INFO] evse_manager:Ev :: EVSE IEC DC mode. We are in 5percent mode so we can continue without further action.
2024-03-06 14:19:52.978506 [INFO] evse_manager:Ev :: EVSE IEC Charger state: Wait for Auth->PrepareCharging
2024-03-06 14:19:54.115482 [INFO] evse_manager:Ev :: EVSE ISO SLAC MATCHED
2024-03-06 14:19:54.135855 [INFO] evse_manager:Ev :: EVSE ISO D-LINK_READY (true)

OCPP:

2024-03-06 14:17:44.156164 [INFO] auth:Auth :: Providing authorization to connector#1
2024-03-06 14:17:44.940664 [INFO] evse_manager:Ev :: EVSE IEC Set PWM On (5.000000074505806%) took 0 ms
2024-03-06 14:17:45.130324 [INFO] auth:Auth :: Result for token: 0123456789ABCD: ACCEPTED
2024-03-06 14:17:45.206881 [INFO] evse_manager:Ev :: EVSE IEC EIM Authorization received
2024-03-06 14:17:45.207509 [INFO] evse_manager:Ev :: EVSE IEC Transaction Started (0 kWh)
2024-03-06 14:17:45.208729 [INFO] evse_manager:Ev :: EVSE IEC DC mode. We are in 5percent mode so we can continue without further action.
2024-03-06 14:17:45.209089 [INFO] evse_manager:Ev :: EVSE IEC Charger state: Wait for Auth->PrepareCharging
2024-03-06 14:17:45.287327 [INFO] OCPP0:OCPP :: EVSE#1: Received TransactionStarted
2024-03-06 14:17:45.616218 [INFO] evse_manager:Ev :: EVSE IEC Transaction Finished: DeAuthorized (0 kWh)
2024-03-06 14:17:45.710445 [INFO] evse_manager:Ev :: EVSE IEC Charger state: PrepareCharging->EVSE Paused
2024-03-06 14:17:45.710753 [INFO] evse_manager:Ev :: EVSE IEC Set PWM Off
2024-03-06 14:17:46.126347 [INFO] evse_manager:Ev :: EVSE ISO SLAC MATCHED
2024-03-06 14:17:46.146723 [INFO] evse_manager:Ev :: EVSE ISO D-LINK_READY (true)

Any help would be appreciated, Thank you!

Missing dependencies for cmake target `test`

Describe the bug

When running make test directly after configuring with cmake the tests aren't build yet:

Running tests...
Test project /home/andreas/EVworkspaces/reproduce-issue-unit-tests/build
    Start 1: everest-core_auth_tests
Could not find executable everest-core_auth_tests
Looked in the following places:
everest-core_auth_tests
everest-core_auth_tests
Release/everest-core_auth_tests
Release/everest-core_auth_tests
Debug/everest-core_auth_tests
Debug/everest-core_auth_tests
MinSizeRel/everest-core_auth_tests
MinSizeRel/everest-core_auth_tests
RelWithDebInfo/everest-core_auth_tests
RelWithDebInfo/everest-core_auth_tests
Deployment/everest-core_auth_tests
Deployment/everest-core_auth_tests
Development/everest-core_auth_tests
Development/everest-core_auth_tests
Unable to find executable: everest-core_auth_tests
1/5 Test #1: everest-core_auth_tests .........................***Not Run   0.00 sec
    Start 2: everest-core_EvseManager_tests
Could not find executable everest-core_EvseManager_tests
Looked in the following places:
everest-core_EvseManager_tests
everest-core_EvseManager_tests
Release/everest-core_EvseManager_tests
Release/everest-core_EvseManager_tests
Debug/everest-core_EvseManager_tests
Debug/everest-core_EvseManager_tests
MinSizeRel/everest-core_EvseManager_tests
MinSizeRel/everest-core_EvseManager_tests
RelWithDebInfo/everest-core_EvseManager_tests
RelWithDebInfo/everest-core_EvseManager_tests
Deployment/everest-core_EvseManager_tests
Deployment/everest-core_EvseManager_tests
Development/everest-core_EvseManager_tests
Development/everest-core_EvseManager_tests
Unable to find executable: everest-core_EvseManager_tests
2/5 Test #2: everest-core_EvseManager_tests ..................***Not Run   0.00 sec
    Start 3: everest-core_lem_dcbm_400600_controller_tests
Could not find executable everest-core_lem_dcbm_400600_controller_tests
Looked in the following places:
everest-core_lem_dcbm_400600_controller_tests
everest-core_lem_dcbm_400600_controller_tests
Release/everest-core_lem_dcbm_400600_controller_tests
Release/everest-core_lem_dcbm_400600_controller_tests
Debug/everest-core_lem_dcbm_400600_controller_tests
Debug/everest-core_lem_dcbm_400600_controller_tests
MinSizeRel/everest-core_lem_dcbm_400600_controller_tests
MinSizeRel/everest-core_lem_dcbm_400600_controller_tests
RelWithDebInfo/everest-core_lem_dcbm_400600_controller_tests
RelWithDebInfo/everest-core_lem_dcbm_400600_controller_tests
Deployment/everest-core_lem_dcbm_400600_controller_tests
Deployment/everest-core_lem_dcbm_400600_controller_tests
Development/everest-core_lem_dcbm_400600_controller_tests
Development/everest-core_lem_dcbm_400600_controller_tests
Unable to find executable: everest-core_lem_dcbm_400600_controller_tests
3/5 Test #3: everest-core_lem_dcbm_400600_controller_tests ...***Not Run   0.00 sec
    Start 4: everest-core_lem_time_sync_helper_tests
Could not find executable everest-core_lem_time_sync_helper_tests
Looked in the following places:
everest-core_lem_time_sync_helper_tests
everest-core_lem_time_sync_helper_tests
Release/everest-core_lem_time_sync_helper_tests
Release/everest-core_lem_time_sync_helper_tests
Debug/everest-core_lem_time_sync_helper_tests
Debug/everest-core_lem_time_sync_helper_tests
MinSizeRel/everest-core_lem_time_sync_helper_tests
MinSizeRel/everest-core_lem_time_sync_helper_tests
RelWithDebInfo/everest-core_lem_time_sync_helper_tests
RelWithDebInfo/everest-core_lem_time_sync_helper_tests
Deployment/everest-core_lem_time_sync_helper_tests
Deployment/everest-core_lem_time_sync_helper_tests
Development/everest-core_lem_time_sync_helper_tests
Development/everest-core_lem_time_sync_helper_tests
Unable to find executable: everest-core_lem_time_sync_helper_tests
4/5 Test #4: everest-core_lem_time_sync_helper_tests .........***Not Run   0.00 sec
    Start 5: everest-core_setup_tests
Could not find executable everest-core_setup_tests
Looked in the following places:
everest-core_setup_tests
everest-core_setup_tests
Release/everest-core_setup_tests
Release/everest-core_setup_tests
Debug/everest-core_setup_tests
Debug/everest-core_setup_tests
MinSizeRel/everest-core_setup_tests
MinSizeRel/everest-core_setup_tests
RelWithDebInfo/everest-core_setup_tests
RelWithDebInfo/everest-core_setup_tests
Deployment/everest-core_setup_tests
Deployment/everest-core_setup_tests
Development/everest-core_setup_tests
Development/everest-core_setup_tests
Unable to find executable: everest-core_setup_tests
5/5 Test #5: everest-core_setup_tests ........................***Not Run   0.00 sec

0% tests passed, 5 tests failed out of 5

Total Test time (real) =   0.01 sec

The following tests FAILED:
          1 - everest-core_auth_tests (Not Run)
          2 - everest-core_EvseManager_tests (Not Run)
          3 - everest-core_lem_dcbm_400600_controller_tests (Not Run)
          4 - everest-core_lem_time_sync_helper_tests (Not Run)
          5 - everest-core_setup_tests (Not Run)
Errors while running CTest
Output from these tests are in: /home/andreas/EVworkspaces/reproduce-issue-unit-tests/build/Testing/Temporary/LastTest.log
Use "--rerun-failed --output-on-failure" to re-run the failed cases verbosely.
make: *** [Makefile:91: test] Fehler 8

EVerest Domain

Testing

Affected EVerest Module

All unit tests

The following tests FAILED:
          1 - everest-core_auth_tests (Not Run)
          2 - everest-core_EvseManager_tests (Not Run)
          3 - everest-core_lem_dcbm_400600_controller_tests (Not Run)
          4 - everest-core_lem_time_sync_helper_tests (Not Run)
          5 - everest-core_setup_tests (Not Run)
Errors while running CTest

To Reproduce

Checkout everest-core
Run

mkdir build

cmake ../everest-core -DBUILD_TESTING=ON

make test

Anything else?

No response

Auth Token handling seems to be not case-insensitive

Environment:

EVerest 2024.2.0 running on a single port charger
OCPP backend SteVe
DummyTokenProvider configured which provides the token "DEADBEEF" (upper-case)

Test Sequence:

charger is online, connected via OCPP
in SteVe, the token is configured using lower-case letters
a normal charging session can be started successfully
terminate the charging session normally
install a reservation via SteVe for the socket, using the "DEADBEEF" token
try to start the session

Expected Behavior:

reservation is recognized and the token is allowed to start the session
reason: auth tokens in OCPP should be handled case-insenstive

Observed Behavior:

reservation is recognized but the token is rejected

Trace (stripped down to relevant parts IMHO):

Feb 28 13:30:29 ccc300 manager[2007]: 2024-02-28 13:30:29.356093 [INFO] auth:Auth        :: Received new token: {
Feb 28 13:30:29 ccc300 manager[2007]:     "authorization_type": "RFID",
Feb 28 13:30:29 ccc300 manager[2007]:     "id_token": "DEADBEEF"
Feb 28 13:30:29 ccc300 manager[2007]: }

Feb 28 13:30:29 ccc300 manager[2007]: 2024-02-28 13:30:29.515186 [INFO] auth:Auth        :: Connector is reserved but token is not valid for this reservation
Feb 28 13:30:29 ccc300 manager[2007]: 2024-02-28 13:30:29.605651 [INFO] auth:Auth        :: Result for token: DEADBEEF: REJECTED

Additional note:

We observed a similar behavior when using LocalAuthList feature of OCPP (i.e. a lower-case token is stored in the list, but then the token provider shows a upper-case one) - so it might be worth to double-check those places of the token handling, too.
When changing the token in SteVe between step 5 and 6 to lower-case, then the reservation is recognized and the token is accepted, the charging starts.

Everest-core Compilation Failure with EvseManager.hpp

Describe the bug

Trying to compile Everest-core using below steps
cd {EVerest Workspace Directory}/everest-core
mkdir build
cd build
cmake ..
make install

make install is failing with below error

Error :
76%] Building CXX object modules/CMakeFiles/EvseManager.dir/EvseManager/EvseManager.cpp.o
In file included from /home/gvijay/everest-dev-environment/everest-core/modules/EvseManager/EvseManager.cpp:3:
/home/gvijay/everest-dev-environment/everest-core/modules/EvseManager/EvseManager.hpp: In constructor ‘module::EvseManager::EvseManager(const ModuleInfo&, Everest::MqttProvider&, Everest::TelemetryProvider&, std::unique_ptr<evse_managerImplBase>, std::unique_ptr, std::unique_ptr<auth_token_providerImplBase>, std::unique_ptr<uk_random_delayImplBase>, std::unique_ptr<evse_board_supportIntf>, std::vector<std::unique_ptr<ac_rcdIntf> >, std::vector<std::unique_ptr<connector_lockIntf> >, std::vector<std::unique_ptr >, std::vector<std::unique_ptr >, std::vector<std::unique_ptr >, std::vector<std::unique_ptr<ISO15118_chargerIntf> >, std::vector<std::unique_ptr<isolation_monitorIntf> >, std::vector<std::unique_ptr<power_supply_DCIntf> >, module::Conf&)’:
/home/gvijay/everest-dev-environment/everest-core/modules/EvseManager/EvseManager.hpp:126:22: error: use of deleted function ‘constexpr std::atomic<_Tp>::atomic() [with _Tp = std::chrono::time_point<std::chrono::_V2::steady_clock, std::chrono::duration<long int, std::ratio<1, 1000000000> > >]’
126 | config(config){};
| ^
In file included from /usr/include/c++/9/future:42,
from /home/gvijay/everest-dev-environment/everest-framework/include/framework/everest.hpp:7,
from /home/gvijay/everest-dev-environment/everest-framework/include/framework/ModuleAdapter.hpp:6,
from /home/gvijay/everest-dev-environment/everest-core/build/generated/modules/EvseManager/ld-ev.hpp:11,
from /home/gvijay/everest-dev-environment/everest-core/modules/EvseManager/EvseManager.hpp:11,
from /home/gvijay/everest-dev-environment/everest-core/modules/EvseManager/EvseManager.cpp:3:
/usr/include/c++/9/atomic:198:7: note: ‘constexpr std::atomic<_Tp>::atomic() noexcept [with _Tp = std::chrono::time_point<std::chrono::_V2::steady_clock, std::chrono::duration<long int, std::ratio<1, 1000000000> > >]’ is implicitly deleted because its exception-specification does not match the implicit exception-specification ‘’
198 | atomic() noexcept = default;
| ^~~~~~
make[2]: *** [modules/CMakeFiles/EvseManager.dir/build.make:70: modules/CMakeFiles/EvseManager.dir/EvseManager/EvseManager.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:5116: modules/CMakeFiles/EvseManager.dir/all] Error 2
make: *** [Makefile:152: all] Error 2

EVerest Domain

Other

Affected EVerest Module

everest-core

To Reproduce

No response

Anything else?

No response

0 kW power delivered while in the Charging phase

Describe the bug

US-JOET and the Sandia team are developing one-liner demos in everest-demo. We were able to run an AC ISO15118-2 PnC charging session using MaEVe as the CSMS. Everything works fine except for the fact that while in the Charging phase in the GUI, it shows 0 kW power being delivered. Please check the attached screenshot. In other modes (i.e., AC 3ph 16A), it works as expected. We were told that it is a known problem so I am submitting an issue against it.

AC 15118-2 PnC:

AC 3ph 16A:

EVerest Domain

Energy Management, ISO15118, Simulation

Affected EVerest Module

No response

To Reproduce

Use this version and the Basic and ISO 15118-2 AC Charging with OCPP 2.0.1 CSMS (MaEVe Security Profile 3) one-liner to reproduce.

Anything else?

No response

EvseV2G can not encode ServiceDiscoveryRes if both payment options are disabled

Describe the bug

If in the config both payment options are disabled, then the EvseV2G module can not encode the ServiceDiscoveryRes message. Because no payment is provided.

EVerest Domain

ISO15118

Affected EVerest Module

EvseV2G

To Reproduce

evse_manager:
    module: EvseManager
    config_module:
      payment_enable_contract: false
      payment_enable_eim: false

Anything else?

No response

Using Ninja as the Cmake generator

I had trouble compiling this repo in VSCODE and the Cmake Tools extension due to its preference for Ninja.

However, I found by running export CMAKE_GENERATOR=Ninja before cmake .., I was able to build in VSCODE.

Would the team consider adding this line of code (as optional) to the build documentation for others who wish to use this build environment?

Flood of DiagnosticsStatusNotification status: "Uploading"

OCPP Version: 1.6

Description: If we trigger GetDiagnostics against a HTTP server with our Tarragon BSP (EVerest 24.01), we observed lots of unnecessary DiagnosticsStatusNotification with status: "Uploading". Unfortunately i don't have a PCAP trace, so i don't know the result code of the HTTP server from the upload attempt has an influence on this issue.

How to reproduce: Let the Tarragon with EVerest connect via WS to Steve 3.5.0, go to Operations > OCPP v1.6 > GetDiagnostics. Select the chargepoint lesbos_right, enter the URL of a HTTP server and press "Perform".

Expected behavior: EVerest should only send DiagnosticsStatusNotification with status: "Uploading" once.

CSMS log:

[INFO ] 2024-02-07 16:51:50,744 de.rwth.idsg.steve.ocpp.ws.WebSocketLogger - [chargeBoxId=lesbos_right, sessionId=0cafa312-caba-a2a2-d208-006920ee3159] Sending: [2,"ecc98d9e-50e2-484c-959c-61a934788570","GetDiagnostics",{"location":"http://192.168.1.5/"}]
[INFO ] 2024-02-07 16:51:50,931 de.rwth.idsg.steve.ocpp.ws.WebSocketLogger - [chargeBoxId=lesbos_right, sessionId=0cafa312-caba-a2a2-d208-006920ee3159] Received: [3,"ecc98d9e-50e2-484c-959c-61a934788570",{"fileName":"diagnostics-2024-02-07T16:51:50.808ZblrG7o"}]
[INFO ] 2024-02-07 16:51:50,935 de.rwth.idsg.steve.ocpp.ws.WebSocketLogger - [chargeBoxId=lesbos_right, sessionId=0cafa312-caba-a2a2-d208-006920ee3159] Received: [2,"0015c9f2-52c5-487d-abe7-c653ea43ae69","DiagnosticsStatusNotification",{"status":"Uploading"}]
[INFO ] 2024-02-07 16:51:50,942 de.rwth.idsg.steve.ocpp.ws.WebSocketLogger - [chargeBoxId=lesbos_right, sessionId=0cafa312-caba-a2a2-d208-006920ee3159] Sending: [3,"0015c9f2-52c5-487d-abe7-c653ea43ae69",{}]
[INFO ] 2024-02-07 16:51:53,121 de.rwth.idsg.steve.ocpp.ws.WebSocketLogger - [chargeBoxId=lesbos_right, sessionId=0cafa312-caba-a2a2-d208-006920ee3159] Received: [2,"6545fccf-9864-4de5-8b19-589a18f8941c","DiagnosticsStatusNotification",{"status":"Uploading"}]
[INFO ] 2024-02-07 16:51:53,125 de.rwth.idsg.steve.ocpp.ws.WebSocketLogger - [chargeBoxId=lesbos_right, sessionId=0cafa312-caba-a2a2-d208-006920ee3159] Sending: [3,"6545fccf-9864-4de5-8b19-589a18f8941c",{}]
[INFO ] 2024-02-07 16:51:53,144 de.rwth.idsg.steve.ocpp.ws.WebSocketLogger - [chargeBoxId=lesbos_right, sessionId=0cafa312-caba-a2a2-d208-006920ee3159] Received: [2,"501fcbb4-9486-4c2b-b786-8f7f9f7369bb","DiagnosticsStatusNotification",{"status":"Uploading"}]
[INFO ] 2024-02-07 16:51:53,146 de.rwth.idsg.steve.ocpp.ws.WebSocketLogger - [chargeBoxId=lesbos_right, sessionId=0cafa312-caba-a2a2-d208-006920ee3159] Sending: [3,"501fcbb4-9486-4c2b-b786-8f7f9f7369bb",{}]
[INFO ] 2024-02-07 16:51:53,157 de.rwth.idsg.steve.ocpp.ws.WebSocketLogger - [chargeBoxId=lesbos_right, sessionId=0cafa312-caba-a2a2-d208-006920ee3159] Received: [2,"66c4961d-09a1-4d4a-853e-dc631b405f84","DiagnosticsStatusNotification",{"status":"Uploading"}]
[INFO ] 2024-02-07 16:51:53,159 de.rwth.idsg.steve.ocpp.ws.WebSocketLogger - [chargeBoxId=lesbos_right, sessionId=0cafa312-caba-a2a2-d208-006920ee3159] Sending: [3,"66c4961d-09a1-4d4a-853e-dc631b405f84",{}]
[INFO ] 2024-02-07 16:51:53,171 de.rwth.idsg.steve.ocpp.ws.WebSocketLogger - [chargeBoxId=lesbos_right, sessionId=0cafa312-caba-a2a2-d208-006920ee3159] Received: [2,"99db7a2a-5dcc-4d85-a2e6-b41e7dd114d4","DiagnosticsStatusNotification",{"status":"Uploading"}]
[INFO ] 2024-02-07 16:51:53,173 de.rwth.idsg.steve.ocpp.ws.WebSocketLogger - [chargeBoxId=lesbos_right, sessionId=0cafa312-caba-a2a2-d208-006920ee3159] Sending: [3,"99db7a2a-5dcc-4d85-a2e6-b41e7dd114d4",{}]
[INFO ] 2024-02-07 16:51:53,186 de.rwth.idsg.steve.ocpp.ws.WebSocketLogger - [chargeBoxId=lesbos_right, sessionId=0cafa312-caba-a2a2-d208-006920ee3159] Received: [2,"46a82900-7a04-42ed-a898-0e451c5e5b52","DiagnosticsStatusNotification",{"status":"Uploading"}]
[INFO ] 2024-02-07 16:51:53,188 de.rwth.idsg.steve.ocpp.ws.WebSocketLogger - [chargeBoxId=lesbos_right, sessionId=0cafa312-caba-a2a2-d208-006920ee3159] Sending: [3,"46a82900-7a04-42ed-a898-0e451c5e5b52",{}]
[INFO ] 2024-02-07 16:51:53,198 de.rwth.idsg.steve.ocpp.ws.WebSocketLogger - [chargeBoxId=lesbos_right, sessionId=0cafa312-caba-a2a2-d208-006920ee3159] Received: [2,"0c887a0a-65c5-4407-a4c5-f36c37345a06","DiagnosticsStatusNotification",{"status":"Uploading"}]
[INFO ] 2024-02-07 16:51:53,201 de.rwth.idsg.steve.ocpp.ws.WebSocketLogger - [chargeBoxId=lesbos_right, sessionId=0cafa312-caba-a2a2-d208-006920ee3159] Sending: [3,"0c887a0a-65c5-4407-a4c5-f36c37345a06",{}]
[INFO ] 2024-02-07 16:51:53,210 de.rwth.idsg.steve.ocpp.ws.WebSocketLogger - [chargeBoxId=lesbos_right, sessionId=0cafa312-caba-a2a2-d208-006920ee3159] Received: [2,"6325e32b-2bce-413d-a56e-f79530e30da1","DiagnosticsStatusNotification",{"status":"Uploading"}]
[INFO ] 2024-02-07 16:51:53,212 de.rwth.idsg.steve.ocpp.ws.WebSocketLogger - [chargeBoxId=lesbos_right, sessionId=0cafa312-caba-a2a2-d208-006920ee3159] Sending: [3,"6325e32b-2bce-413d-a56e-f79530e30da1",{}]
[INFO ] 2024-02-07 16:51:53,221 de.rwth.idsg.steve.ocpp.ws.WebSocketLogger - [chargeBoxId=lesbos_right, sessionId=0cafa312-caba-a2a2-d208-006920ee3159] Received: [2,"e6869280-d113-4e48-ab8f-2ca94ab8466f","DiagnosticsStatusNotification",{"status":"Uploading"}]
[INFO ] 2024-02-07 16:51:53,223 de.rwth.idsg.steve.ocpp.ws.WebSocketLogger - [chargeBoxId=lesbos_right, sessionId=0cafa312-caba-a2a2-d208-006920ee3159] Sending: [3,"e6869280-d113-4e48-ab8f-2ca94ab8466f",{}]
[INFO ] 2024-02-07 16:51:53,234 de.rwth.idsg.steve.ocpp.ws.WebSocketLogger - [chargeBoxId=lesbos_right, sessionId=0cafa312-caba-a2a2-d208-006920ee3159] Received: [2,"0450a63a-8a80-4a45-9e97-b4d645f5f786","DiagnosticsStatusNotification",{"status":"Uploading"}]
[INFO ] 2024-02-07 16:51:53,236 de.rwth.idsg.steve.ocpp.ws.WebSocketLogger - [chargeBoxId=lesbos_right, sessionId=0cafa312-caba-a2a2-d208-006920ee3159] Sending: [3,"0450a63a-8a80-4a45-9e97-b4d645f5f786",{}]
[INFO ] 2024-02-07 16:51:53,246 de.rwth.idsg.steve.ocpp.ws.WebSocketLogger - [chargeBoxId=lesbos_right, sessionId=0cafa312-caba-a2a2-d208-006920ee3159] Received: [2,"360e092e-2d11-48b6-8923-3379f64d738e","DiagnosticsStatusNotification",{"status":"Uploaded"}]
[INFO ] 2024-02-07 16:51:53,249 de.rwth.idsg.steve.ocpp.ws.WebSocketLogger - [chargeBoxId=lesbos_right, sessionId=0cafa312-caba-a2a2-d208-006920ee3159] Sending: [3,"360e092e-2d11-48b6-8923-3379f64d738e",{}]

OCPP configuration:

{
    "Internal": {
        "ChargePointId": "lesbos_right",
        "CentralSystemURI": "ws://192.168.1.5:8081/steve/websocket/CentralSystemService/lesbos_right",
        "ChargeBoxSerialNumber": "123",
        "ChargePointModel": "Charge Control C",
        "ChargePointVendor": "chargebyte",
        "FirmwareVersion": "0.1",
        "LogMessagesFormat": []
    },
    "Core": {
        "AuthorizeRemoteTxRequests": false,
        "ClockAlignedDataInterval": 900,
        "ConnectionTimeOut": 10,
        "ConnectorPhaseRotation": "0.RST,1.RST",
        "GetConfigurationMaxKeys": 100,
        "HeartbeatInterval": 86400,
        "LocalAuthorizeOffline": false,
        "LocalPreAuthorize": false,
        "MeterValuesAlignedData": "Energy.Active.Import.Register",
        "MeterValuesSampledData": "Energy.Active.Import.Register",
        "MeterValueSampleInterval": 0,
        "NumberOfConnectors": 1,
        "ResetRetries": 1,
        "StopTransactionOnEVSideDisconnect": true,
        "StopTransactionOnInvalidId": true,
        "StopTxnAlignedData": "Energy.Active.Import.Register",
        "StopTxnSampledData": "Energy.Active.Import.Register",
        "SupportedFeatureProfiles": "Core,FirmwareManagement,RemoteTrigger,Reservation,LocalAuthListManagement,SmartCharging",
        "TransactionMessageAttempts": 1,
        "TransactionMessageRetryInterval": 10,
        "UnlockConnectorOnEVSideDisconnect": true
    },
    "FirmwareManagement": {
        "SupportedFileTransferProtocols": "FTP"
    },
    "LocalAuthListManagement": {
        "LocalAuthListEnabled": true,
        "LocalAuthListMaxLength": 42,
        "SendLocalListMaxLength": 42
    },
    "SmartCharging": {
        "ChargeProfileMaxStackLevel": 42,
        "ChargingScheduleAllowedChargingRateUnit": "Current",
        "ChargingScheduleMaxPeriods": 42,
        "MaxChargingProfilesInstalled": 42
    },
    "Security": {
        "SecurityProfile": 0
    },
    "PnC": {
        "ISO15118PnCEnabled": true,
        "ContractValidationOffline": true
    }
}

Plug unlocked before contactor is open after transition from CP state E to C

Hi,
we have recently implemented the new connector lock interface on our Tarragon platform (everest-core 2023.12.0). During our tests with AC free charging (Dummy token provider), we noticed an unexpected behavior. In case we are in free charging (CP state C, contactor closed) and then switch to CP state E, the plug lock is unlocked before the contactor is open. So it seems the EvseManager has an issue.

Expected behavior:
For safety reason the plug lock should only be opened after the contactor open.

Observed behavior:
After a CP state change from E to C, the plug lock is opened before the contactor is open.

Log:

Jan 23 14:55:20 tarragon manager[7678]: 2024-01-23 14:55:20.465163 [INFO] connector_1:Evs  ::                                     CAR IEC Event CarRequestedPower
Jan 23 14:55:20 tarragon manager[7678]: 2024-01-23 14:55:20.466460 [INFO] connector_1:Evs  :: EVSE IEC Charger state: PrepareCharging->Charging
Jan 23 14:55:20 tarragon manager[7681]: 2024-01-23 14:55:20.553929 [INFO] tarragon_bsp:Cb  :: Closing contactor...
Jan 23 14:55:20 tarragon manager[7681]: 2024-01-23 14:55:20.646881 [INFO] tarragon_bsp:Cb  :: Contactor state: CLOSED
Jan 23 14:55:20 tarragon manager[7678]: 2024-01-23 14:55:20.680267 [INFO] connector_1:Evs  :: EVSE IEC Event PowerOn
Jan 23 14:55:25 tarragon manager[7681]: 2024-01-23 14:55:25.892872 [INFO] tarragon_bsp:Cb  :: CP state change from C to E, U_CP+: 764 mV, U_CP-: -11175 mV
Jan 23 14:55:26 tarragon manager[7677]: 2024-01-23 14:55:26.555977 [INFO] cb_tarragon_plu  :: is unlocked
Jan 23 14:55:26 tarragon manager[7681]: 2024-01-23 14:55:26.659319 [INFO] tarragon_bsp:Cb  :: Opening contactor...
Jan 23 14:55:26 tarragon manager[7681]: 2024-01-23 14:55:26.691790 [INFO] tarragon_bsp:Cb  :: Contactor state: OPEN
Jan 23 14:55:26 tarragon manager[7678]: 2024-01-23 14:55:26.732036 [INFO] connector_1:Evs  :: EVSE IEC Event PowerOff

Config:

active_modules:
  api:
    module: API
    connections:
      evse_manager:
      - module_id: connector_1
        implementation_id: evse
  auth:
    module: Auth
    config_module:
      connection_timeout: 10
      prioritize_authorization_over_stopping_transaction: true
      selection_algorithm: PlugEvents
    connections:
      token_provider:
      - module_id: token_provider_1
        implementation_id: main
      token_validator:
      - module_id: token_validator
        implementation_id: main
      evse_manager:
      - module_id: connector_1
        implementation_id: evse
  cb_tarragon_driver:
    module: CbTarragonDriver
    connections: {}
  cb_tarragon_pluglock:
    module: CbTarragonPlugLock
    connections: {}
  energy_manager:
    module: EnergyManager
    connections:
      energy_trunk:
      - module_id: grid_connection_point
        implementation_id: energy_grid
  connector_1:
    module: EvseManager
    config_module:
      ac_enforce_hlc: false
      ac_hlc_enabled: false
      ac_hlc_use_5percent: true
      ac_nominal_voltage: 230
      ac_with_soc: false
      charge_mode: AC
      connector_id: 1
      country_code: DE
      dbg_hlc_auth_after_tstep: false
      ev_receipt_required: false
      evse_id: DE*CHB*E123456*1
      has_ventilation: true
      max_current_import_A: 16
      payment_enable_contract: false
      payment_enable_eim: true
      session_logging: false
      session_logging_path: /tmp/everest-logs
      session_logging_xml: false
      three_phases: true
    connections:
      bsp:
        - module_id: cb_tarragon_driver
          implementation_id: evse_board_support
      connector_lock:
        - module_id: cb_tarragon_pluglock
          implementation_id: connector_lock
  grid_connection_point:
    module: EnergyNode
    config_module:
      fuse_limit_A: 63
      phase_count: 3
    connections:
      energy_consumer:
      - implementation_id: energy_grid
        module_id: connector_1
  token_provider_1:
    module: DummyTokenProvider
    config_implementation:
      main:
        timeout: 10
        token: DEADBEEF
        type: RFID
    connections:
      evse:
      - module_id: connector_1
        implementation_id: evse
  token_validator:
    module: DummyTokenValidator
    config_implementation:
      main:
        sleep: 0.25
        validation_reason: Token seems valid
        validation_result: Accepted
    connections: {}
x-module-layout: {}

sqlite_cpp deprecation warning

Describe the bug

In current main, the following annoying warning gets emitted:

... sqlite_cpp/cpplint.py:50: DeprecationWarning: module 'sre_compile' is deprecated
  import sre_compile

If possible, the cmake logic for sqlite_cpp can be disabled - there is no reason why this cpplint.py should run.

EVerest Domain

Compilation

Affected EVerest Module

No response

To Reproduce

just build. The warning might depend on the installed python environment.

Anything else?

No response

Log is flooded by serialcommhub_x in case Modbus slave is not available

Hi,
we have tested the lastest everest-core 2024.01 and accidentially configured a meter on our Tarragon platform, which is not available via Modbus. After the start of EVerest the whole log is flooded (multiple times per second) by error messages from serialcommhub_x, which cause eMMC wearout:

Feb 01 13:53:51 tarragon manager[539]: 2024-02-01 13:53:51.074076 [ERRO] serialcommhub_x std::vector<short unsigned int> tiny_modbus::decode_reply(const uint8_t*, int, uint8_t, tiny_modbus::FunctionCode) :: Packet too small: 3 bytes.
Feb 01 13:53:51 tarragon manager[539]: 2024-02-01 13:53:51.293540 [ERRO] serialcommhub_x std::vector<short unsigned int> tiny_modbus::decode_reply(const uint8_t*, int, uint8_t, tiny_modbus::FunctionCode) :: Packet too small: 3 bytes.
Feb 01 13:53:51 tarragon manager[539]: 2024-02-01 13:53:51.423442 [ERRO] serialcommhub_x std::vector<short unsigned int> tiny_modbus::decode_reply(const uint8_t*, int, uint8_t, tiny_modbus::FunctionCode) :: Packet too small: 3 bytes.
Feb 01 13:53:51 tarragon manager[539]: 2024-02-01 13:53:51.553456 [ERRO] serialcommhub_x std::vector<short unsigned int> tiny_modbus::decode_reply(const uint8_t*, int, uint8_t, tiny_modbus::FunctionCode) :: Packet too small: 3 bytes.
Feb 01 13:53:52 tarragon manager[539]: 2024-02-01 13:53:52.733426 [ERRO] serialcommhub_x std::vector<short unsigned int> tiny_modbus::decode_reply(const uint8_t*, int, uint8_t, tiny_modbus::FunctionCode) :: Packet too small: 3 bytes.
Feb 01 13:53:52 tarragon manager[539]: 2024-02-01 13:53:52.863485 [ERRO] serialcommhub_x std::vector<short unsigned int> tiny_modbus::decode_reply(const uint8_t*, int, uint8_t, tiny_modbus::FunctionCode) :: Packet too small: 3 bytes.
Feb 01 13:53:52 tarragon manager[539]: 2024-02-01 13:53:52.993451 [ERRO] serialcommhub_x std::vector<short unsigned int> tiny_modbus::decode_reply(const uint8_t*, int, uint8_t, tiny_modbus::FunctionCode) :: Packet too small: 3 bytes.
Feb 01 13:53:53 tarragon manager[539]: 2024-02-01 13:53:53.203441 [ERRO] serialcommhub_x std::vector<short unsigned int> tiny_modbus::decode_reply(const uint8_t*, int, uint8_t, tiny_modbus::FunctionCode) :: Packet too small: 3 bytes.
Feb 01 13:53:53 tarragon manager[539]: 2024-02-01 13:53:53.333437 [ERRO] serialcommhub_x std::vector<short unsigned int> tiny_modbus::decode_reply(const uint8_t*, int, uint8_t, tiny_modbus::FunctionCode) :: Packet too small: 3 bytes.
Feb 01 13:53:53 tarragon manager[539]: 2024-02-01 13:53:53.463633 [ERRO] serialcommhub_x std::vector<short unsigned int> tiny_modbus::decode_reply(const uint8_t*, int, uint8_t, tiny_modbus::FunctionCode) :: Packet too small: 3 bytes.
Feb 01 13:53:53 tarragon manager[539]: 2024-02-01 13:53:53.673413 [ERRO] serialcommhub_x std::vector<short unsigned int> tiny_modbus::decode_reply(const uint8_t*, int, uint8_t, tiny_modbus::FunctionCode) :: Packet too small: 3 bytes.
Feb 01 13:53:53 tarragon manager[539]: 2024-02-01 13:53:53.803650 [ERRO] serialcommhub_x std::vector<short unsigned int> tiny_modbus::decode_reply(const uint8_t*, int, uint8_t, tiny_modbus::FunctionCode) :: Packet too small: 3 bytes.
Feb 01 13:53:53 tarragon manager[539]: 2024-02-01 13:53:53.933530 [ERRO] serialcommhub_x std::vector<short unsigned int> tiny_modbus::decode_reply(const uint8_t*, int, uint8_t, tiny_modbus::FunctionCode) :: Packet too small: 3 bytes.

Expected behavior:
Such communication issues shouldn't be handled by the modbus library. It would be better to let upper layer handle the issue.

Example:
EVerest Modbus module detects that connection to Modbus slave has been lost. Module logs the event of disconnect and a possible reason. In case the connection to the Modbus slave has been re-established again the EVerest Modbus module the re-connect should be logged.

active_modules:
  api:
    module: API
    connections:
      evse_manager:
      - module_id: connector
        implementation_id: evse
  tarragon_bsp:
    module: CbTarragonDriver
    config_module:
      contactor_1_feedback_type: nc
      relay_2_name: none
  tarragon_pluglock:
    module: CbTarragonPlugLock
  serialcommhub_x7:
    module: SerialCommHub
    config_implementation:
      main:
        serial_port: /dev/ttymxc0
        ignore_echo: true
  powermeter:
    module: GenericPowermeter
    config_implementation:
      main:
        model: Eastron_SDM72DM-V2
        powermeter_device_id: 1
    connections:
      serial_comm_hub:
        - module_id: serialcommhub_x7
          implementation_id: main
  serialcommhub_x8:
    module: SerialCommHub
    config_implementation:
      main:
        serial_port: /dev/ttymxc4
        ignore_echo: true
  connector:
    module: EvseManager
    config_module:
      connector_id: 1
      has_ventilation: false
      disable_authentication: true
    connections:
      bsp:
        - module_id: tarragon_bsp
          implementation_id: evse_board_support
      connector_lock:
        - module_id: tarragon_pluglock
          implementation_id: connector_lock
      powermeter_grid_side:
        - module_id: powermeter
          implementation_id: main
  energy_manager:
    module: EnergyManager
    connections:
      energy_trunk:
      - module_id: grid_connection_point
        implementation_id: energy_grid
  grid_connection_point:
    module: EnergyNode
    config_module:
      fuse_limit_A: 16
      phase_count: 3
    connections:
      energy_consumer:
      - implementation_id: energy_grid
        module_id: connector

SerialCommunicationHub always waits for timeout before returning the result

I was investigating why reading the values from the meter always take a while. And it looks like the tiny_modbus_rtu is implemented in the way, that we always return when the response timeout is reached and not earlier.

This maybe not a problem with quick devices, but some devices like Bauer Meter, may have long response time sometimes. So we need to keep the timeout large.

Expected behaviour:

serial communication hub return the response, as fast as it is received.

PacketSniffer: Incomplete trace in case of a SIGTERM

Environment:
everest-core:
3e5c467

Test Sequence:

Start a trace
Restart everest while a high-level communication session is running

Expected Behavior:
In case of a SIGTERM the modul should stop recording immediately and write the pcap file completely. There should be no error message in the log of EVerest.

Observed Behavior:

Currently the traces are incomplete in case of a unexpected EVerest restart trough a SIGTERM. This is quite annoying when trying to analyze an unexpected restart of EVerest

Additional note:

Furthermore, an error message seems to appear in the log after every v2g charging session

Feb 01 10:03:11 tarragon manager[2951]: 2024-02-01 10:03:11.640330 [ERRO] packet_sniffer: void module::PacketSniffer::capture(const string&, const string&) :: Error reading packets from interface: eth1, error:

Support signed meter in EvseManager/Charger

The Power Meter Bauer BSM-WS36A issues the signed meter values on both start transaction and stop transaction.
To handle it the EvseManager should start the transaction on power meter and wait for the signed meter values.

Additionally: we experienced large waiting times on the Bauer BSM-WS36A meter, that may lead to unexpected behavior when requesting the signed meter synchronously. So the transaction on the meter should start asynchronously to the Auth<->OCPP<->evse_manager interactions.

I'll create a draft PR with some Ideas how to implement it.

IEC 61851-23: 2023 CableCheck changes

Describe the problem

A new version of IEC61851-23: 2023 was released and will replace the 2014 version. A few things have been changed that touches EVerest in the cable check phase:

CableCheck:

It is now mandatory to do IMD self testing in CableCheck Phase, doing it periodically in between charging sessions is no longer allowed
Voltage used during cablecheck is no longer a constant but depends on the max voltage requested by vehicle
At the end of cable check, voltage needs to drop below 60V

These changes will make user experience significantly worse as cablecheck phase will take quite long on many popular hardware. Anyway, we will need to implement this.

EVerest Domain

Charge Control

Affected EVerest Module

EvseManager, IMDSimulator, isolation monitor interface

Describe your solution

We should extend the isolation monitor interface with e.g. a self test command to be able to trigger self testing at a dedicated point in time. Changes in EvseManager cablecheck logic are required to fulfill the other changes.

Additional context

No response

Reservation Handling for no specific EVSE / connector#0

The reservation handler in the Auth module does currently not support reservations of connector 0 (reservations for the whole charging station and not for a specific EVSE/connector).

The goal of this issue is to implement support so that the requirement of OCPP1.6 and OCPP2.0.1 for this use case is fullfiled:

H01.FR.07 of OCPP 2.0.1 Edition 2 FINAL, 2022-12-15:

When the Charging Station has Accepted a ReserveNowRequest without evseId
The Charging Station SHALL make sure that at any time during the validity of the reservation, one EVSE remains available for the reserved IdTokenType.

OCPP1.6 edition 2 FINAL, 2017-09-28:

If the connectorId in the reservation request is 0, then the Charge Point SHALL NOT reserve a specific connector, but SHALL make sure that at any time during the validity of the reservation, one connector remains available for the reserved idTag

libiso15118: TLS 1.3 EOF error while performing handshake with libiso15118

Environment:
everest-core:
3e5c467
libiso15118:
EVerest/libiso15118@0f34d53

EV: Trialog Testsystem

Test Sequence:

Start of TLS 1.3 session

Expected Behavior:

TLS handshake runs through and v2g communication starts

Observed Behavior:

TLS handshake fails with error message 1:

Feb 01 10:58:57 tarragon01 manager[20097]: 2024-02-01 10:58:57.484532 [INFO] connector_1:Evs :: EVSE ISO SLAC MATCHED
Feb 01 10:58:57 tarragon01 manager[20097]: 2024-02-01 10:58:57.517753 [INFO] connector_1:Evs :: EVSE ISO D-LINK_READY (true)
Feb 01 10:59:03 tarragon01 manager[20097]: 2024-02-01 10:59:03.906353 [INFO] connector_1:Evs :: EVSE ISO Change HLC Limits: 11040W/200A, target_voltage 0, actual_voltage 2, hack_bpt false
Feb 01 10:59:05 tarragon01 manager[20097]: 2024-02-01 10:59:05.342393 [INFO] connector_1:Evs :: EVSE ISO Change HLC Limits: 11040W/200A, target_voltage 0, actual_voltage 0, hack_bpt false
Feb 01 10:59:05 tarragon01 manager[20105]: 2024-02-01 10:59:05.833929 [INFO] iso15118_charge :: Got SDP request
Feb 01 10:59:06 tarragon01 manager[20105]: 2024-02-01 10:59:06.864023 [ERRO] iso15118_charge virtual void module::charger::ISO15118_chargerImpl::ready() :: D20Evse chrashed: Failed to mbedtls_ssl_handshake() (SSL - The connection indicated an EOF)
Feb 01 10:59:06 tarragon01 manager[20105]: 2024-02-01 10:59:06.864738 [INFO] iso15118_charge :: Shutting down SDP server!

TLS handshake fails with error message 2:

Feb 01 10:58:23 tarragon01 manager[12619]: 2024-02-01 10:58:23.580968 [INFO] connector_1:Evs :: EVSE ISO SLAC MATCHED
Feb 01 10:58:23 tarragon01 manager[12619]: 2024-02-01 10:58:23.604079 [INFO] connector_1:Evs :: EVSE ISO D-LINK_READY (true)
Feb 01 10:58:29 tarragon01 manager[12626]: 2024-02-01 10:58:29.900146 [INFO] iso15118_charge :: Got SDP request
Feb 01 10:58:29 tarragon01 manager[12626]: 2024-02-01 10:58:29.912135 [ERRO] iso15118_charge virtual void module::charger::ISO15118_chargerImpl::ready() :: D20Evse chrashed: Failed to mbedtls_net_bind() (NET - Binding of the socket failed)
Feb 01 10:58:29 tarragon01 manager[12626]: 2024-02-01 10:58:29.919936 [INFO] iso15118_charge :: Shutting down SDP

Additional note:

because of data privacy it is not possible to add traces (recorded on testing symposium in Arnhem January 2024)
Cipher Suite: TLS_AES_256_GCM_SHA384
in pcap trace EV terminates the connection [FIN, ACK]
error message 2 occurs only sporadically
module crashes with a SEG-fault (Module iso15118_charger exited with status: 11. Terminating all modules)

Everest crashes when sending an OCPP201 InstallCertificate call from OCPP server with invalid data

Describe the bug

When running latest build of Everest-core (commit fb24707) and an OCPP server using OCPP 2.0.1, Everest crashes when receiving an InstallCertificate call with an invalid certificate_type value. In this case, an empty string:

InstallCertificate(certificate_type='', certificate='-----BEGIN CERTIFICATE-----\nMIIBwzCCAWigAwIBAgICMDkwCgYIKoZIzj0EAwIwSDESMBAGA1UEAwwJVjJHUm9v\ndENBMRAwDgYDVQQKDAdFVmVyZXN0MQswCQYDVQQGEwJERTETMBEGCgmSJomT8ixk\nARkWA1YyRzAeFw0yMzEwMjcxMzEwNDdaFw0yNDEwMjYxMzEwNDdaMEgxEjAQBgNV\nBAMMCVYyR1Jvb3RDQTEQMA4GA1UECgwHRVZlcmVzdDELMAkGA1UEBhMCREUxEzAR\nBgoJkiaJk/IsZAEZFgNWMkcwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAR8yvxy\nBJNJh0WHbOLqgWp4JRNeuKPQid2Ha255X9w/Xc5bFDQG9AacXr3ED/MOdFqSQi/8\nzS1Ez82SbqH9U3xRo0IwQDAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIB\nBjAdBgNVHQ4EFgQUDE1ff14OrOE2RsHt9Rg/L6WKrXwwCgYIKoZIzj0EAwIDSQAw\nRgIhAIwKjJ+kafFE0ETE6s9ffmoD6OWX+cnGVySu4bCkSTBLAiEAxJGgTDUdMQK/\ngP+u0NMyffVs8TH/BGgleeieAHDo2Fo=\n-----END CERTIFICATE-----\n', custom_data=None)

Everest logs:


2024-04-20 13:55:56.743403 [INFO] ocpp:OCPP201     :: Received message over TLS websocket polling for process: [2,"314c960a-0a98-401c-87db-45b45f0041d6","InstallCertificate",{"certificateType":"","certificate":"-----BEGIN CERTIFICATE-----\nMIIBwzCCAWigAwIBAgICMDkwCgYIKoZIzj0EAwIwSDESMBAGA1UEAwwJVjJHUm9v\ndENBMRAwDgYDVQQKDAdFVmVyZXN0MQswCQYDVQQGEwJERTETMBEGCgmSJomT8ixk\nARkWA1YyRzAeFw0yMzEwMjcxMzEwNDdaFw0yNDEwMjYxMzEwNDdaMEgxEjAQBgNV\nBAMMCVYyR1Jvb3RDQTEQMA4GA1UECgwHRVZlcmVzdDELMAkGA1UEBhMCREUxEzAR\nBgoJkiaJk/IsZAEZFgNWMkcwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAR8yvxy\nBJNJh0WHbOLqgWp4JRNeuKPQid2Ha255X9w/Xc5bFDQG9AacXr3ED/MOdFqSQi/8\nzS1Ez82SbqH9U3xRo0IwQDAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIB\nBjAdBgNVHQ4EFgQUDE1ff14OrOE2RsHt9Rg/L6WKrXwwCgYIKoZIzj0EAwIDSQAw\nRgIhAIwKjJ+kafFE0ETE6s9ffmoD6OWX+cnGVySu4bCkSTBLAiEAxJGgTDUdMQK/\ngP+u0NMyffVs8TH/BGgleeieAHDo2Fo=\n-----END CERTIFICATE-----\n"}]
2024-04-20 13:55:56.743863 [INFO] ocpp:OCPP201     :: Successfully sent last message over TLS websocket!
terminate called after throwing an instance of 'std::out_of_range'
  what():  Provided string  could not be converted to enum of type InstallCertificateUseEnum
2024-04-20 13:55:56.955979 [CRIT] manager         int boot(const boost::program_options::variables_map&) :: Module ocpp (pid: 131088) exited with status: 134. Terminating all modules.
2024-04-20 13:55:56.957800 [INFO] manager          :: SIGTERM of child: api (pid: 131066) succeeded.
2024-04-20 13:55:56.957956 [INFO] manager          :: SIGTERM of child: auth (pid: 131067) succeeded.
2024-04-20 13:55:56.958003 [INFO] manager          :: SIGTERM of child: energy_manager (pid: 131068) succeeded.
2024-04-20 13:55:56.958025 [INFO] manager          :: SIGTERM of child: ev_manager_1 (pid: 131069) succeeded.
2024-04-20 13:55:56.958053 [INFO] manager          :: SIGTERM of child: ev_manager_2 (pid: 131070) succeeded.
2024-04-20 13:55:56.958224 [INFO] manager          :: SIGTERM of child: evse_manager_1 (pid: 131072) succeeded.
2024-04-20 13:55:56.958386 [INFO] manager          :: SIGTERM of child: evse_manager_2 (pid: 131073) succeeded.
2024-04-20 13:55:56.958424 [INFO] manager          :: SIGTERM of child: evse_security (pid: 131079) succeeded.
2024-04-20 13:55:56.958467 [INFO] manager          :: SIGTERM of child: grid_connection_point (pid: 131080) succeeded.
2024-04-20 13:55:56.958497 [INFO] manager          :: SIGTERM of child: iso15118_car (pid: 131086) succeeded.
2024-04-20 13:55:56.958537 [INFO] manager          :: SIGTERM of child: iso15118_charger (pid: 131087) succeeded.
2024-04-20 13:55:56.958559 [INFO] manager          :: SIGTERM of child: slac (pid: 131090) succeeded.
2024-04-20 13:55:56.958597 [INFO] manager          :: SIGTERM of child: system (pid: 131091) succeeded.
2024-04-20 13:55:56.958628 [INFO] manager          :: SIGTERM of child: token_provider_1 (pid: 131092) succeeded.
2024-04-20 13:55:56.958654 [INFO] manager          :: SIGTERM of child: yeti_driver_1 (pid: 131098) succeeded.
2024-04-20 13:55:56.958675 [INFO] manager          :: SIGTERM of child: yeti_driver_2 (pid: 131099) succeeded.
2024-04-20 13:55:56.958689 [CRIT] manager         int boot(const boost::program_options::variables_map&) :: Exiting manager.

EVerest Domain

OCPP2.0.1, Simulation

Affected EVerest Module

The bug seems to come from the module OCPP201

To Reproduce

Run everest
Run an OCPP 2.0.1 server with the standard implementation of call/call_result for InstallCertificate
Send an InstallCertificate call with empty string for certificate_type
Observe Everest logs

Anything else?

This is my first issue and I'm a newbie with everest, so I'm sorry if this isn't formatted correctly. Please let me know of any problem that needs fixing in this issue or in general, as well as any missing information that's needed.

	std::string v2g_root_cert_path = conn->ctx->certs_path + "/ca/v2g/V2G_ROOT_CA.pem";
	std::string mo_root_cert_path = conn->ctx->certs_path + "/ca/mo/MO_ROOT_CA.pem";

everest / everest-core Goto Github PK

everest-core's Introduction

Build & Install

Community

Contributing

Governance

Reporting Issues

Licensing

everest-core's People

Contributors

Stargazers

Watchers

Forkers

everest-core's Issues

How to reproduce the issue

Describe the bug

EVerest Domain

Affected EVerest Module

To Reproduce

Anything else?

Describe the bug

EVerest Domain

Affected EVerest Module

To Reproduce

Anything else?

Describe the bug

EVerest Domain

Affected EVerest Module

To Reproduce

Anything else?

Describe the bug

EVerest Domain

Affected EVerest Module

To Reproduce

Anything else?

Describe the bug

EVerest Domain

Affected EVerest Module

To Reproduce

Anything else?

Describe the bug

EVerest Domain

Affected EVerest Module

To Reproduce

Anything else?

Describe the bug

EVerest Domain

Affected EVerest Module

To Reproduce

Anything else?

Describe the bug

EVerest Domain

Affected EVerest Module

To Reproduce

Anything else?

Describe the bug

EVerest Domain

Affected EVerest Module

To Reproduce

Anything else?

Describe the bug

EVerest Domain

Affected EVerest Module

To Reproduce

Anything else?

Describe the bug

EVerest Domain

Affected EVerest Module

To Reproduce

Anything else?

Describe the problem

EVerest Domain

Affected EVerest Module

Describe your solution

Additional context

Describe the bug

EVerest Domain

Affected EVerest Module

To Reproduce

Anything else?