Integration of OCPP2.0.1 SmartCharging #854
Conversation
modules/OCPP201/conversions.cpp
Outdated
| types::ocpp::ChargingSchedulePeriod _period; | ||
| _period.start_period = period.startPeriod; | ||
| _period.limit = period.limit; | ||
| _period.stack_level = 0; // TODO: Find a solution for this |
There was a problem hiding this comment.
Do you know why a types::ocpp::ChargingSchedulePeriod needs a stack level to begin with? It seems like we're creating a leaky abstraction by relying on stack levels outside of libocpp.
There was a problem hiding this comment.
I agree. It is used in some EVerest applications to identify additional sources / purposes (in addition to the purposes that are defined by OCPP) of charging profiles. I saw your comment on that here and agree with the approach. I'm open to discuss possible solutions to clean this up in the future.
| types::energy::ScheduleReqEntry schedule_req_entry; | ||
| types::energy::LimitsReq limits_req; | ||
| const auto timestamp = start_time.to_time_point() + std::chrono::seconds(period.startPeriod); | ||
| schedule_req_entry.timestamp = ocpp::DateTime(timestamp).to_rfc3339(); | ||
| if (composite_schedule.chargingRateUnit == ocpp::v201::ChargingRateUnitEnum::A) { | ||
| limits_req.ac_max_current_A = period.limit; | ||
| if (period.numberPhases.has_value()) { | ||
| limits_req.ac_max_phase_count = period.numberPhases.value(); | ||
| } | ||
| } else { | ||
| limits_req.total_power_W = period.limit; | ||
| } | ||
| schedule_req_entry.limits_to_leaves = limits_req; | ||
| schedule_import.push_back(schedule_req_entry); |
There was a problem hiding this comment.
I think this function could be made more readable by moving this code into a to_schedule_request_entry(period, unit) helper (possibly in conversions?) or a custom constructor. I believe the same could be said for the analogous method in the OCPP module.
There was a problem hiding this comment.
Agreed. We'll target this change in the refactor for both modules in a subsequent PR based on this issue
Pietfried
force-pushed
the
feature/smart-charging-ocpp201
branch
3 times, most recently
from
8ed7f12 to
9438429
Compare
Pietfried
force-pushed
the
feature/smart-charging-ocpp201
branch
from
74ce0d1 to
4121c64
Compare
…Verest: * Publishing ChargingSchedules and applying limits on change (by registering set_charging_profiles callback) * Publishing ChargingSchedules and applying limits periodically based on module configuration parameters Signed-off-by: pietfried <[email protected]>
* Removed connector property since evse property is sufficient. The term connector (used in OCPP1.6) refers to the term evse in EVerest. Its not required to define evse_id and connector_id as part of a ChargingSchedule * Made stack_level optional * Added required changes due to changed type Signed-off-by: pietfried <[email protected]>
Pietfried
force-pushed
the
feature/smart-charging-ocpp201
branch
from
4121c64 to
a271a51
Compare
* Updated libocpp dependency Signed-off-by: pietfried <[email protected]>
Pietfried
requested review from
hikinggrass and
corneliusclaussen
as code owners
Signed-off-by: pietfried <[email protected]>
Describe your changes
Implementation of OCPP201 smart charging composite schedules within EVerest:
This PR additionally introdueces new configuration parameter in the OCPP201 module:
The integration of the smart charging profiles follow the same approach as in OCPP1.6. The integration will be changed for both OCPP1.6 and OCPP2.0.1 in a subsequent PR based on the design and requirements of this issue.
Issue ticket number and link
Checklist before requesting a review