thoughtworks / maeve-csms

MaEVe is an experimental EV Charge Station Management System (CSMS)
Apache License 2.0
86 stars 22 forks source link

EVerest Config Option #45

Open louisg1337 opened 4 months ago

louisg1337 commented 4 months ago

Hello again! In case anyone didn't see my last PR, I am on a team that is working on setting up software simulated demos for the charging software EVerest.

In some of those demos, we have patch files that we use to get MaEVe to work with EVerest. Our idea was that we could create some type of config within MaEVe for future use by whomever wants to setup a MaEVe and EVerest environment. This PR is our attempt at that, creating a single script that would be ran before running docker compose up, and would apply all the patches.

We would greatly appreciate suggestions against this to see if there are any better, more eloquent ways to create this config option.

louisg1337 commented 4 months ago

Thank you @shankari for the feedback on all of this. I just pushed out two commits that addresses the following issues.

LB Patch

config/everest/maeve-csms-no-lb.patch I think that this is already in the maeve docker compose. We may want to just move to a newer commit on maeve to pick up the change. We will then need to re-create the patches that fail and re-test, but we can remove this patch.

You were totally right as per my response to the comment above. In the first commit, I removed the lb patch from the directory and script.

WSS Patch

config/everest/maeve-csms-no-wss.patch Instead of applying this patch, we should change the maeve code so that instead of crashing the entire program if no certs are defined, it only stops listening to wss https://github.com/US-JOET/base-camp/issues/14#issuecomment-1980213695

To work around this issue, I added in a check before the WSS initialization that determines whether or not any certs were provided. If at least one was provided, we can go through to the initialization, but if none were provided, then we skip over the initialization.

When approaching this problem, the main issue I struggled with was how to determine whether or not the user wanted to use SP1 or SP2/3. In my implementation, I am assuming that if the user provided no certificates at all, they didn't plan on using SP2/3. On the flip side, if they supplied at least one certificate, then we know they at least tried to provide something, implying they would want to use SP2/3. From there, the error handling in place already would pick up the slack and determine if they supplied all the correct ones or not.

Testing Done

For the WSS change, I ran our everest-demo/demo-iso15118-2-ac-plus-ocpp.sh script twice, once on SP1 and once on SP3. The gateway container successfully started both times and they both successfully connected to EVerest.

shankari commented 4 months ago

LGTM, let's see what the MaEVe community thinks!