-
Notifications
You must be signed in to change notification settings - Fork 56
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
SmartChargingHandler: Add validation for TxProfiles #452
SmartChargingHandler: Add validation for TxProfiles #452
Conversation
d14ff09
to
ff0316b
Compare
Codacy is saying a private member field ( |
a667350
to
26746ac
Compare
c803315
to
f27f30c
Compare
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.
Let's discuss tomorrow, but I think now is the time to norm on a naming convention for tests that verify FRs from the 2.0.1 spec.
f27f30c
to
f7db302
Compare
Thanks for adding the FRs! I went ahead and added an issue that we can point to in the future regarding the functional requirement naming convention: #467. |
@christopher-davis-afs Could you link to #467 and #468 from the PR description? They provide additional context for future developers that motivates how we are implementing functionality for 2.0.1. |
Done |
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.
Glad to see the new naming convention in place here!
b9bda6b
to
8c748bc
Compare
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 looks good to me except for some requested changes.
Two more general comments in addition to the inline comments:
In general we try to use snake_case for our variable and function definitions. I see some inconsistencies between snake_case and camelCase.
As already mentioned in the cloud working group meeting we would like to keep the scope of PRs as small as possible so we would rather see the ComponentStateManagerInterface refactor as a separate PR to the changes for SmartCharging. For this PR we can keep, but please consider this for future PRs.
Splits the ComponentStateManager API out into an interface so that it's easier to write unit tests that make use of its functionality. Co-authored-by: Gianfranco Berardi <[email protected]> Signed-off-by: Christopher Davis <[email protected]>
In `transaction_metervalues_insert ()`, we were accessing the first element of a list, then checking whether or not it was empty. This causes an exception since if this list *is* empty, there's no element to access. This commit shifts the code around so that the empty check occurs before accessing any elements of the list. Co-authored-by: Gianfranco Berardi <[email protected]> Signed-off-by: Christopher Davis <[email protected]>
8c748bc
to
47f612d
Compare
ce6b167
to
710d489
Compare
710d489
to
d48f4d6
Compare
Creates a skeleton for SmartChargingHandler and adds a method to validate TxProfiles and TxProfiles only. This method ensures that a given profile (assumed to be TxProfile) fits all of the functional requirements specific to TxProfiles per K01. The function, `validate_tx_profile ()`, takes a profile and an EVSE, and returns a variant of `ProfileValidationResultEnum`. This enum allows us to have detailed responses for the different types of invalid profiles, and eventually will let us log *why* a profile is invalid if the general validation fails. Part of the prerequisites for EVerest#361 Co-authored-by: Gianfranco Berardi <[email protected]> Signed-off-by: Christopher Davis <[email protected]>
d48f4d6
to
49f4725
Compare
Thanks for the reviews, @Pietfried, @hikinggrass, and @marcemmers! When can we expect this to be merged? |
Creates a skeleton for SmartChargingHandler and adds a method
to validate TxProfiles and TxProfiles only. This method
ensures that a given profile (assumed to be TxProfile) fits all of
the functional requirements specific to TxProfiles per K01.
The function,
validate_tx_profile ()
, takes a profile and anEVSE, and returns a variant of
ProfileValidationResultEnum
.This enum allows us to have detailed responses for the different types
of invalid profiles, and eventually will let us log why a profile
is invalid if the general validation fails.
Part of the prerequisites for #361
Related to #467 and #468