search

EVerest / everest-framework

Apache License 2.0
21 stars 19 forks source link

Expose mappings of requirements, provides and modules to modules #206

Closed hikinggrass closed 3 weeks ago

hikinggrass commented 1 month ago

EVerest modules and even individual interface implementations can have mappings assigned to them. These mappings are inspired by the OCPP 3-tier model.

Modules can access the mapping information in the following ways depending on which specific information is required, all of these return an optional Mapping struct If the mapping of a requirement is of interest it can be accessed via a get_mapping() function of a requirments: r_name_of_the_requirement->get_mapping()

If the mapping of an interface implementation is of interest it can also be accessed via a get_mapping() function: p_name_of_an_implementation->get_mapping()

If the mapping of the current module is of interest it can be accessed via the module info: this->info.mapping

Mapping information is also available in error reporting via "error.origin.mapping":

const auto error_handler = [this](const Everest::error::Error& error) {
    const auto evse_id = error.origin.mapping.has_value() ? error.origin.mapping.value().evse : 0;
};
hikinggrass commented 1 month ago

I would like to request some documentation in the commit message about what has been implemented here.

Added to the PR description which will be in the squashed commit message, it's also already available in the documentation: https://everest.github.io/nightly/general/05_existing_modules.html#tier-module-mappings (the code snippets didn't render, should be fixed soon)