Skip to content

Conversation

@barsnick
Copy link
Contributor

Describe your changes

This introduces a new API module RpcApi, which uses JSON RPC, and WebSockets as a transport layer.

It uses both RPC Methods and Notifications.

This is the implementation according to the proposal with was discussed here on Zulip and documented here. The original proposal was slightly modified, as several details proved inconsistent, impractical, or just mis-specified.

Documentation of the current state of implementation is included in the module's docs/ subdirectory. The current (or the final merged) state will be manifested as API version 1.0.0. Future updates to the external API definition will require API version bumps.

A Python GUI test client is included under modules/API/RpcApi/tools/python-client-gui/.

Not implemented in the current state of the API:

  • DC charging
  • TLS
  • API authentication

This will be added later, with corresponding bumps of the API version (where applicable).

A non-squashed version of this work is found in the branch feature/json-rpc-api-nosquash, for reference regarding small change steps, commit messages with motivations, and so on.

Co-authored-by: Fabian Hartung [email protected]
Co-authored-by: Moritz Barsnick [email protected]

Issue ticket number and link

This is a new request after incorrect closure of #1324.

Checklist before requesting a review

  • I have performed a self-review of my code
  • I have made corresponding changes to the documentation
  • I read the contribution documentation and made sure that my changes meet its requirements

barsnick and others added 30 commits September 22, 2025 14:19
Signed-off-by: Fabian Hartung <[email protected]>
Signed-off-by: Moritz Barsnick <[email protected]>
Co-authored-by: Fabian Hartung <[email protected]>
Co-authored-by: Moritz Barsnick <[email protected]>
Signed-off-by: Moritz Barsnick <[email protected]>
…tocol_to_charge_protocol function

Signed-off-by: Fabian Hartung <[email protected]>
Signed-off-by: Moritz Barsnick <[email protected]>
As changed in the merged PR #1319.

Signed-off-by: Moritz Barsnick <[email protected]>
Signed-off-by: Fabian Hartung <[email protected]>
Signed-off-by: Fabian Hartung <[email protected]>
Add a Findjson-rpc-cxx.cmake for non-EDM builds.

The target_include_directories() directive needs to be different for EDM and
non-EDM (Yocto) builds for the header-only json-rpc-cxx.

Also remove json-rpc-cxx from target_link_libraries(), as it is header-only.

Signed-off-by: Moritz Barsnick <[email protected]>
…figuration from YAML files

Signed-off-by: Fabian Hartung <[email protected]>
Introduce a little bit more consistency.

Signed-off-by: Moritz Barsnick <[email protected]>
Only listen on all interfaces if explicitly asked via config "all".
Do not accept an empty string.

Signed-off-by: Moritz Barsnick <[email protected]>
… flag

EVSE index 0 is reserved for the charger itself and should not be used to
set/clear the EVSE error present flag. In the future, we might want to
introduce a charger error present flag.

Signed-off-by: Fabian Hartung <[email protected]>
@barsnick barsnick changed the title https://github.com/EVerest/everest-core/pull/1487 RpcApi: add new JSON RPC API module Nov 27, 2025
Signed-off-by: Moritz Barsnick <[email protected]>
Is was accidentally handled as int (copy/paste error), and thereby rounded
down.

Also rename the method argument for clarity.

Signed-off-by: Moritz Barsnick <[email protected]>
The `limits` var will be deprecated.

Signed-off-by: Moritz Barsnick <[email protected]>
@barsnick barsnick force-pushed the feature/json-rpc-api branch from 73ca4be to 873203c Compare December 1, 2025 12:52
@barsnick barsnick requested a review from florinmihut as a code owner December 1, 2025 16:06
Signed-off-by: Moritz Barsnick <[email protected]>
This takes applicable values from DIN 70121 and ISO 15118-2 ev_info, and
maps them to the display parameters originally meant for ISO 15118-20.

Most notably, the EV's SoC - also determined by "AC with SoC" - is now
exported to the API.

Signed-off-by: Moritz Barsnick <[email protected]>
The API modules don't work well without. RpcApi could partially work around
this, but it's not worth the effort right now.

Signed-off-by: Moritz Barsnick <[email protected]>
This leads to proper constification. (Noticed by cppcheck.)
Also constify an EVSEInfoStore method to now properly satisfy the const
requirement.

Signed-off-by: Moritz Barsnick <[email protected]>
(Noticed by cppcheck, but mostly cosmetic, not performance relevant.)

Signed-off-by: Moritz Barsnick <[email protected]>
(Suggested by cppcheck.)

Signed-off-by: Moritz Barsnick <[email protected]>
Lambda templates are only supported starting with C++20.

Fixes
modules/API/RpcApi/rpc/RpcHandler.cpp: In lambda function:
modules/API/RpcApi/rpc/RpcHandler.cpp:75:26: warning: lambda templates are only available with ‘-std=c++20’ or ‘-std=gnu++20’ [-Wpedantic]
   75 |         auto result = [&]<std::size_t... I>(std::index_sequence<I...>) {
      |                          ^

Signed-off-by: Moritz Barsnick <[email protected]>
Triggered with `-Wextra`.

Signed-off-by: Moritz Barsnick <[email protected]>
Signed-off-by: Moritz Barsnick <[email protected]>
@barsnick barsnick force-pushed the feature/json-rpc-api branch from df6a0f0 to 143545b Compare January 5, 2026 14:43
@barsnick
Copy link
Contributor Author

barsnick commented Jan 6, 2026

@Pietfried regarding comment #1324 (comment):
I have moved the type definitions for the JSON RPC API to lib/everest/everest_api_types/, and thereby abandoned the definition (and code generation) in types/json_rpc_api.yaml. (It is still the originally generated code though, just in the correct format for everest_api.) I hope this is satisfactory.

All other previous comments have been addressed. I have no idea why the Actions/CI is consistently stuck today though.

The EnergyNode for EVSE#1 was not chained between grid and EvseManager.

Signed-off-by: Moritz Barsnick <[email protected]>
Signed-off-by: Moritz Barsnick <[email protected]>
All members of DisplayParametersObj are optional. So if we did not assign
anything at all, pass a std::nullopt, to keep the object empty/missing.

Signed-off-by: Moritz Barsnick <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants