-
Notifications
You must be signed in to change notification settings - Fork 48
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
Incorrect profile selection for GetCompositeSchedule.req handler #819
Comments
I don't think this the correct solution. Profiles can be invalidated by internal changes to the system, such as changes to EVSEs, ongoing transactions, or device model configuration values. So we should check that all profiles we compile into a composite schedule are valid. 1.6 has a With regards to the bug:
Generally when comparing profiles, we ensure that we let pairs of profiles with the same So the proper solution would be to add a check in |
If you would like to check for yourself, these are the tests: TEST_F(SmartChargingHandlerTestFixtureV201, K01_ValidateChargingStationMaxProfile_AllowsExistingMatchingProfile) {
auto profile =
SmartChargingTestUtils::get_charging_profile_from_file("max/ChargingStationMaxProfile_grid_hourly.json");
auto res = handler.validate_and_add_profile(profile, STATION_WIDE_ID);
ASSERT_THAT(res.status, testing::Eq(ChargingProfileStatusEnum::Accepted));
auto sut = handler.validate_charging_station_max_profile(profile, STATION_WIDE_ID);
EXPECT_THAT(sut, testing::Eq(ProfileValidationResultEnum::Valid));
}
TEST_F(SmartChargingHandlerTestFixtureV201, K01_ValidateTxDefaultProfile_AllowsExistingMatchingProfile) {
auto profile = SmartChargingTestUtils::get_charging_profile_from_file("singles/Absolute_301.json");
auto res = handler.validate_and_add_profile(profile, DEFAULT_EVSE_ID);
ASSERT_THAT(res.status, testing::Eq(ChargingProfileStatusEnum::Accepted));
auto sut = handler.validate_tx_default_profile(profile, DEFAULT_EVSE_ID);
EXPECT_THAT(sut, testing::Eq(ProfileValidationResultEnum::Valid));
}
TEST_F(SmartChargingHandlerTestFixtureV201, K01_ValidateTxProfile_AllowsExistingMatchingProfile) {
auto profile = SmartChargingTestUtils::get_charging_profile_from_file("baseline/TxProfile_1.json");
this->evse_manager->open_transaction(DEFAULT_EVSE_ID, profile.transactionId.value());
auto res = handler.validate_and_add_profile(profile, DEFAULT_EVSE_ID);
ASSERT_THAT(res.status, testing::Eq(ChargingProfileStatusEnum::Accepted));
auto sut = handler.validate_tx_profile(profile, DEFAULT_EVSE_ID);
EXPECT_THAT(sut, testing::Eq(ProfileValidationResultEnum::Valid));
} The first two pass, and the last one fails with |
The stackLevel - chargingProfileKind- evseId although
|
OCPP Version
OCPP2.0.1
Describe the bug
Bug
Currently the
GetCompositeSchedule.req
handler does not include all required profiles of purposeTxDefaultProfile
andTxProfile
in its calculation.Reason
This is an excerpt of the
GetCompositeSchedule.req
handler:The issue is inside
get_charging_profiles_for_evse
which is called inget_valid_profiles
:This function calls
validate_profile
with a profile that has already been validated when it was added. This leads to the fact that evse specific profiles are not returned as part ofget_valid_profiles
because reasons likeDuplicateProfileValidityPeriod
orTxProfileConflictingStackLevel
occur since the profiles are basically compared to themselves.To Reproduce
Run OCTT test case TC_K_41_CS
Anything else?
While I'm not completely aware of all implications, I think this can simply be solved by removing the
validate_profile
call insideget_valid_profiles_for_evse
to avoid the repeated validation with the consequences described above.We can then also think of naming this function
get_profiles
rather thenget_valid_profiles
assuming that all profiles that have been added previously are valid.This would require us to drop
K08_GetValidProfiles_IfInvalidProfileExists_ThenThatProfileIsNotReturned
.I think we should make
add_profile
private and only providevalidate_and_add_profile
as part of the public API.The text was updated successfully, but these errors were encountered: