Feature/entrypoint api by cburandt · Pull Request #1864 · EVerest/everest-core

cburandt · 2026-02-24T19:16:24Z

Describe your changes

Introduce an entrypoint_API definition which allows to query an EVerest instance for its EVerestAPI capabilities.
Also includes the EVerestAPI module providing this API and an example configuration.

Issue ticket number and link

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

hikinggrass · 2026-02-25T09:38:18Z

docs/source/reference/EVerest_API/entrypoint_API.yaml

One thing in advance concerning naming before I have a closer look: I'm not sure EVerest_API is the best name for this feature since it could quite easily be confused with the broader term we use for the "EVerest API" itself. Maybe entrypoint_API / introspection_API / metadata_API?

james-ctc

I'm not sure I follow how this is discovering the charger configuration and which API modules have been loaded by the manager.
How is the current charger configuration file detected?

My main suggestion is to try and make this as generic as possible so that new APIs can be easily added.

An alternative would be for every API instance to listen for a request and respond.
It would be nice if this solution didn't require another process to be started.
In particular this really needs to run regardless of charger configuration.

Another suggestion is to include the EVerest version in the response.

james-ctc · 2026-02-25T15:42:03Z

docs/source/reference/EVerest_API/entrypoint_API.yaml

+    ApiTypeEnum:
+      description: All known API types
+      type: string
+      enum:


I suggest using a string, otherwise changing this enum could result in breaking changes to the stable APIs. It should be safe for a new API type to be introduced without needing this file to be updated

The question is how to communicate to the client which types actually exist (e.g. is it "powermeter" or "powermeter_API"). But I see your point and maybe a string suggests a more defensive programming style to the client developer who is required to expect and handle any possible string.

james-ctc · 2026-02-25T15:42:57Z

lib/everest/everest_api_types/include/everest_api_types/entrypoint/API.hpp

+    session_cost_consumer,
+    slac,
+    system
+};


adding a new stable API would mean this needs updating. (a breaking change perhaps?)

james-ctc · 2026-02-25T15:45:22Z

lib/everest/everest_api_types/include/everest_api_types/entrypoint/API.hpp

+struct ApiParameter {
+    ApiTypeEnum type;
+    std::string module_id;
+    std::optional<int32_t> version;


can the version be anything other than 1?
everest_api/1/entrypoint_api implies that entrypoint_api is part of API version 1.
I'm not sure it should report on other versions.
Alternatively it could be version-less inn which case everest_api/entrypoint_api returning about all modules and versions would be useful

The version-less api-discovery would be ideal (and changing the topic to your suggestion would be no problem), the problem today is, that you cannot know the other API-module's versions. (only the modules themselves know, but that piece of information isn't exposed via any interface nor via EVerest's configuration service).

cburandt · 2026-02-25T17:43:56Z

Thanks for these helpful comments.

I'm not sure I follow how this is discovering the charger configuration and which API modules have been loaded by the manager. How is the current charger configuration file detected?

My main suggestion is to try and make this as generic as possible so that new APIs can be easily added.

The manager reads the configuration file as usual (whichever it is) and provides module configuration for individual modules via the configuration service during runtime. This new module uses Everest::config::ConfigServiceClient to get the full configuration of the running EVerest instance and determines which of the loaded modules are EVerestAPI modules.
(It does so by looking them up in a list of module names known to implement the EVerestAPI - since the modules are not tagged as "implements sth. from the EVerestAPI" this is a manual process in the end; today everything named modules/API/..._API belongs to that API, but that's a coincident - maybe we should gather them in another subfolder to mark these module to somehow belong together).

An alternative would be for every API instance to listen for a request and respond. It would be nice if this solution didn't require another process to be started. In particular this really needs to run regardless of charger configuration.

You suggest that each API instance listens to the same topic (say "everest_api/entrypoint_api") and replies to the topic given by the client via the replyTo field? So instead of a single reply with an array containing all the modules, the client would receive a burst of small individual replies each with a (name,type,version)-tuple. While my current approach also doesn't need to know anything about the configuration it does

need to be added to the configuration
need a curated list of API modules (see above)
require its own process
would need some channel to determine the other module's versions

The distributed approach solves all of this, as far as I can see. Also each modules listening to the outside world will know if it's part of this API or not and the version it implements.

Another suggestion is to include the EVerest version in the response.

Yes. That's on my list.

james-ctc · 2026-02-26T08:09:52Z

Thank you for your comprehensive replies. One additional thought I had was whether the reporting could be integrated into the existing modules?
e.g.
developer -> who supports interface
each module supporting that interface responds with their version number

i.e.
publish everest-api/query-modules/evse_manager_consumer_API {"header":{"replyTo":"<required>"}}
and the evse_manager_consumer_API modules would publish
publish <replyTo> {"module-id":"<module name>","version":"1"}
The reply could also include configuration settings.

It could work alongside this approach - because this could be extended to include getting information on how EVerest is configured and not just the stable APIs. That could help identify miss-configuration e.g. there are two EVerest EvseManagers but only one of them has a stable API connection

…he everst_api_types lib Signed-off-by: Christoph Burandt <christoph.burandt@pionix.de>

- move EVerestAPI related modules to separate folder inside API/ - create a common base class for all EVerestAPI modules - change power_supply_DC_API and display_message_API modules to use common base + implement entrypoint_API for them Signed-off-by: Christoph Burandt <christoph.burandt@pionix.de>

cburandt · 2026-02-27T13:21:46Z

New approach:

Each module implements the entrypoint_API (done yet only for display_message_API and power_supply_DC_API)
moved all EVerestAPI modules into modules/API/EVerest_API
1st attempt to share common code between display_message_API & power_supply_DC_API
entrypoint_API.yaml updated - has examples for the different messages
config-EVerestAPI-entrypoint.yaml allows to quickly test the behaviour - see comments at the end of this file

Known issues:

does not yet fully support multiple API implementations per module
the everest-configuration as it's defined now, could also be part of the discover command's reply
code-sharing is incomplete
need to think about implications of later merging all API modules into a single module
charger_information is still missing (model, serial no., etc)

Happy to get more input on this (@james-ctc, @mlitre)

Signed-off-by: Christoph Burandt <christoph.burandt@pionix.de>

cburandt force-pushed the feature/entrypoint_API branch from 4e9afb1 to 2506b63 Compare February 25, 2026 08:46

hikinggrass reviewed Feb 25, 2026

View reviewed changes

cburandt force-pushed the feature/entrypoint_API branch from 2506b63 to 72c0e9f Compare February 25, 2026 14:27

james-ctc reviewed Feb 25, 2026

View reviewed changes

cburandt added 2 commits February 27, 2026 14:08

Add entrypoint_API AsyncAPI definition + types + (de)serializers to t…

0736653

…he everst_api_types lib Signed-off-by: Christoph Burandt <christoph.burandt@pionix.de>

cburandt force-pushed the feature/entrypoint_API branch from 72c0e9f to aeaae5e Compare February 27, 2026 13:14

cburandt added 2 commits March 3, 2026 16:25

Add communication monitoring parameters to entrypoint_API

a080de6

Signed-off-by: Christoph Burandt <christoph.burandt@pionix.de>

Wrap calls to mqtt provider to intercept invalid topics

68c55df

Signed-off-by: Christoph Burandt <christoph.burandt@pionix.de>

cburandt force-pushed the feature/entrypoint_API branch from 1130e16 to 68c55df Compare March 3, 2026 15:26

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Feature/entrypoint api#1864

Feature/entrypoint api#1864
cburandt wants to merge 4 commits intomainfrom
feature/entrypoint_API

cburandt commented Feb 24, 2026

Uh oh!

hikinggrass Feb 25, 2026

Uh oh!

james-ctc left a comment

Uh oh!

james-ctc Feb 25, 2026

Uh oh!

cburandt Feb 25, 2026

Uh oh!

james-ctc Feb 25, 2026

Uh oh!

cburandt Feb 25, 2026

Uh oh!

james-ctc Feb 25, 2026

Uh oh!

cburandt Feb 25, 2026

Uh oh!

cburandt commented Feb 25, 2026 •

edited

Loading

Uh oh!

james-ctc commented Feb 26, 2026 •

edited

Loading

Uh oh!

cburandt commented Feb 27, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

cburandt commented Feb 24, 2026

Describe your changes

Issue ticket number and link

Checklist before requesting a review

Uh oh!

hikinggrass Feb 25, 2026

Choose a reason for hiding this comment

Uh oh!

james-ctc left a comment

Choose a reason for hiding this comment

Uh oh!

james-ctc Feb 25, 2026

Choose a reason for hiding this comment

Uh oh!

cburandt Feb 25, 2026

Choose a reason for hiding this comment

Uh oh!

james-ctc Feb 25, 2026

Choose a reason for hiding this comment

Uh oh!

cburandt Feb 25, 2026

Choose a reason for hiding this comment

Uh oh!

james-ctc Feb 25, 2026

Choose a reason for hiding this comment

Uh oh!

cburandt Feb 25, 2026

Choose a reason for hiding this comment

Uh oh!

cburandt commented Feb 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

james-ctc commented Feb 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cburandt commented Feb 27, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

cburandt commented Feb 25, 2026 •

edited

Loading

james-ctc commented Feb 26, 2026 •

edited

Loading