-
Notifications
You must be signed in to change notification settings - Fork 74
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor Energy Management integration of OCPP and API modules #872
Conversation
config/config-sil-ocpp.yaml
Outdated
- module_id: evse_manager_1_sink | ||
implementation_id: external_limits |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This kind of solution, i.e. to plugin one more instance of an EnergyNode mode in between the energy flow graph is pretty overkill! It is a complete running process, which won't do more than just receive a command and forward it as some limits. Maybe we should consider to have a single module for the energy flow which has a much more flexible and expressive configuration.
faeef1e
to
b88570e
Compare
78f2c21
to
a904613
Compare
9a2164b
to
85c918b
Compare
interface: external_energy_limits | ||
min_connections: 0 | ||
max_connections: 1 | ||
max_connections: 129 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
verify that the evse_sink vector does not contain multiple elements with the same evse mapping
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just some typos found while browsing the doc markdown.
…erface This adapts for the following PR in everest-core: - EVerest/everest-core#872 - EVerest/everest-core#924 Signed-off-by: Michael Heimpold <mhei@heimpold.de>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From perspective of code style, I can approve this PR.
If possible I might factor out the duplicated code, but it is not clear yet how to do that - i.e. how multiple modules can share some unit of functionality.
auto& evse_energy_sink = this->get_evse_sink_by_evse_id(evse_id); | ||
|
||
this->mqtt.subscribe(cmd_set_limit, [&evse_manager_check = this->evse_manager_check, | ||
&evse_energy_sink = evse_energy_sink](const std::string& data) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
&evse_energy_sink = evse_energy_sink
should be the same as &evse_energy_sink
…terface This adapts for the following PR in everest-core: - EVerest/everest-core#872 Signed-off-by: Michael Heimpold <mhei@heimpold.de>
b2d33cf
to
126a345
Compare
* Remove set_external_limits from evse_manager inteface * Change requirement to apply limits of API and OCPP modules from evse_manager to external_energy_limits TODOs: * Adjust all EVerest configuration files * Add documentation to API and OCPP modules * EnergyManager currently seg faults Signed-off-by: pietfried <pietgoempel@gmail.com>
Signed-off-by: pietfried <pietgoempel@gmail.com>
Signed-off-by: Piet Gömpel <pietgoempel@gmail.com>
Signed-off-by: Kai-Uwe Hermann <kai-uwe.hermann@pionix.de>
…of children to unique_ptr Signed-off-by: Piet Gömpel <pietgoempel@gmail.com>
…r the energy management * Using the mapping of the requirement to determine the connect requirement to call based on the evse id Signed-off-by: Piet Gömpel <pietgoempel@gmail.com>
Signed-off-by: Piet Gömpel <pietgoempel@gmail.com>
TODO: needs updates in dependencies.yaml for everest-framework and everest-utils (once versions are tagged there) that would be: |
Signed-off-by: Piet Gömpel <pietgoempel@gmail.com>
…g external_energy_limits reference by evse id Signed-off-by: Piet Gömpel <pietgoempel@gmail.com>
@@ -1,4 +1,5 @@ | |||
add_subdirectory(can_dpm1000) | |||
add_subdirectory(external_energy_limits) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@hikinggrass probably we can include this only when either API, OCPP or OCPP201 are build but Im not quite sure how. Can you help with that?
Signed-off-by: Kai-Uwe Hermann <kai-uwe.hermann@pionix.de>
Signed-off-by: Kai-Uwe Hermann <kai-uwe.hermann@pionix.de>
Signed-off-by: Kai-Uwe Hermann <kai-uwe.hermann@pionix.de>
Signed-off-by: Kai-Uwe Hermann <kai-uwe.hermann@pionix.de>
Signed-off-by: Kai-Uwe Hermann <kai-uwe.hermann@pionix.de>
Signed-off-by: Kai-Uwe Hermann <kai-uwe.hermann@pionix.de>
Signed-off-by: Kai-Uwe Hermann <kai-uwe.hermann@pionix.de>
Signed-off-by: Kai-Uwe Hermann <kai-uwe.hermann@pionix.de>
…tegration-ocpp-and-api # Conflicts: # lib/staging/CMakeLists.txt Signed-off-by: Kai-Uwe Hermann <kai-uwe.hermann@pionix.de>
will review today! |
Signed-off-by: Kai-Uwe Hermann <kai-uwe.hermann@pionix.de>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good for Rust & Bazel.
Signed-off-by: Kai-Uwe Hermann <kai-uwe.hermann@pionix.de>
Signed-off-by: Kai-Uwe Hermann <kai-uwe.hermann@pionix.de>
This PR refactors the energy management integration of the API module and the OCPP modules.
A little bit of energy management background
The
evse_manager
interface exposed a commandset_external_limits
to apply EVSE specific limits received from the OCPP CSMS or the API module. If both modules (API, OCPP) use this command to write limits, they override each other. This command was therefore removed from theevse_manager
interface.The Energymanagement implementation was already designed to use the
external_energy_limits
interface and EnergyNode modules instead of that to build up energy trees. This design is more flexible and can be customized for different charging station setups. The API and OCPP modules have been changed to require theexternal_energy_limits
interface and use this to populate the charging limits they receive via their respective channels.This introduces a breaking change to the Energymanagement integration in EVerest. It is now required to connect modules that implement the
external_energy_limits
interface to the API and OCPP modules in order to apply the received limits.A recommended setup is to load one EnergyNode module per EVSE and an additional one representing the energy sink for the whole charging station (addressed by EVSE id zero in OCPP). These EnergyNode modules must be configured with an EVSE mapping in order to allow the API or OCPP modules to retrieve the correct evse id:
https://everest.github.io/nightly/general/05_existing_modules.html#tier-module-mappings
Summary of changes
external_energy_limits
interfaceRelated PRs
EVerest/everest-framework#206
EVerest/everest-utils#154
Issue ticket number and link
Checklist before requesting a review