Closed
Conversation
update to demo-iso15118-2-ocpp-201.sh from deprecated demo-iso15118-2-ac-plus-ocpp.sh Signed-off-by: Abby Wheelis <54848919+Abby-Wheelis@users.noreply.github.com>
AC -> DC Signed-off-by: Abby Wheelis <54848919+Abby-Wheelis@users.noreply.github.com>
It looks like the limits applied to the JsYetiSimulator are on a per-phase basis, although limits applied elsewhere are not. This makes things very confusing. We will fix this by configuring everything to a per-phase limit of 16A Please see EVerest#92 (comment) to EVerest#92 (comment) Locations changed: - config - JsYetiSimulator - SmartCharging OCPP defaults Also fix the disable_iso_tls patch to not have a starting `/` Add a new patch file to enable limit logging but don't enable it by default. This may help future efforts to debug this. Signed-off-by: Shankari <k.shankari@driveelectric.gov>
Consistent with EVerest#92 (comment) History starts at: EVerest#92 (comment) Also show dots in the chart Also convert the time range to/from local time so it makes sense Signed-off-by: Shankari <k.shankari@driveelectric.gov>
Signed-off-by: Shankari <k.shankari@driveelectric.gov>
🔧 configure limits in a way that is consistent and makes sense
- Do not throttle the SASchedule from the EV based on departure time, only transmit the composite pmax schedule. The EV will deareate based on departure time - Show the values in the current power delivery request instead of the progress towards the eamount so that we can see the impact of curtailing the pmax - Pass in the pmax to the power curve computation algo, although it is currently a NOP This fixes: EVerest#92 (comment) Signed-off-by: Shankari <k.shankari@driveelectric.gov>
+ configure the chart to display kW + convert relative timestamps to display timestamps by adding to the start time of the charge session Signed-off-by: Shankari <k.shankari@driveelectric.gov>
Signed-off-by: Shankari <k.shankari@driveelectric.gov>
Make the EV-computed curve more meaningful
Updates to ReadME for 1-line demos
…hanges Changes: - EVerest manager uses the changes to receive a limit through the API, pass it through to the OCPP module, store it in the database and use it to influence the power limits - Node-red sends the correct MQTT messages - MaEVe manager has an NOP implementation of notify limit The actual changes/patches are listed here and will need to be merged in one step at a time EVerest#101 (comment) Testing done: ``` $ bash demo-iso15118-2-ocpp-201.sh -1 -r $(pwd) -m $ docker exec -it everest-ac-demo-manager-1 /bin/bas (container) $ sh /ext/build/run-scripts/run-sil-ocpp201-pnc.sh ``` Then - moved the slider to various points, the max current changed - plugged in car, handshake was successful - moved the slider while the car was plugged in, max current changed and power drawn changed - cleared limit, max current went to 16 and max power went to 11kW Signed-off-by: Shankari <k.shankari@driveelectric.gov>
💩 🔧 Configure the demo to use pre-built images for the notify limit c…
required for demo functionality after switching to one phase so charging will actually initiate Signed-off-by: Abby Wheelis <54848919+Abby-Wheelis@users.noreply.github.com>
…onfig add three_phases to JsEVManager
three_phase -> three_phases
not sending intermittent EA and DT updates, only using for start of charging session for now includes externalPayment to be compatible with other patches
- Use the new arm64-specific image from @catarial - Remove all `linux/x86_64` platform links - Change the build to specify platforms manually (only arm64 for now since the amd64 build fails without Rosetta EVerest#113 (comment)) - Modify the patches to work with the new codebase - Change the path to the library files - Switch the class/namespace structure At this point, everything compiles and runs without error on amd64. However, the charge session fails with EVerest#103 (EVerest#113 (comment)) Going to improve the dev workflow before fixing that, and adding other patches for the notify_limit Signed-off-by: Shankari <k.shankari@driveelectric.gov>
As more folks from US-JOET start working on everest, and we start making changes that are not just "hacks", we are running into issues because of the current process for making changes. This process involves launching the containers and then editing the code in them directly using vim. This is slow and painful, requires manually copy-pasting commands for the final configuration, and does not allow developers to use modern IDEs. This refactors the docker process to pull out the setup and compile functions into separate scripts. The scripts are then used by the Dockerfile for the pre-build images, but can also be run by a developer to recompile and rebuild. This also creates a "dev" docker-compose, which mounts the specified source directory as a volume, allowing us to edit it on the host using more sophisticated editors. Finally, it edits the README to provide the steps for a developer to use this new functionality. Testing done: - Re-built manager images, re-launched, was able to start up manager - Deployed dev image, ran steps in README, compiled, was able to start up manager Signed-off-by: Shankari <k.shankari@driveelectric.gov>
This hasn't been an issue with the pre-built container, but with the dev containers, we will likely apply the same patches over and over again using the setup scripts, on the same codebase. The second time, the patches would already have been applied. Passing in `patch -N` (aka --forward) skips reverse patches instead of pausing and asking for a resolution. Testing done: - Ran the script in the dev environment without errors; started the manager after install Signed-off-by: Shankari <k.shankari@driveelectric.gov>
Before this, the charge station was hardcoded as `cp001`, which was convenient for testing, but made running in more complex scenarios. In particular, with the recent addition of the "dev" environment, it may be useful to run dev and prebuilt environments side-by-side, so that we can verify behavior with and without changes. This commit plumbs through the charge station in both dev and prebuilt environments. - In the dev environment, the `CHARGE_STATION_ID` is in the `docker-compose` - In the pre-built environment, it is passed in as a command line argument, defaulting to `cp001` Note that in the `dev` environment, the new `CHARGE_STATION_ID` needs to be added manually using the `DEMO_VERSION=sp1 CHARGE_STATION_ID=cpdev bash maeve/add-charger-and-rfid-card.sh` command. The README has been updated to clarify these instructions. If run through the `demo-XXX.sh` script, the script will automatically add the station. Testing done: - Ran the dev environment with station `cpdev`; manager was able to connect to the CSMS - Ran the `demo` script with station `cpdemo`; manager was able to connect to the CSMS Signed-off-by: Shankari <k.shankari@driveelectric.gov>
Signed-off-by: Shankari <k.shankari@driveelectric.gov>
Bump up to the most recent release
Since we will use this in the US Testival, where we expect to have cars that are set up to accept single phase. - Configure the hardcoded value in the EVSE - Change the config to support single phase in the car (EV) Signed-off-by: Shankari <k.shankari@driveelectric.gov>
🔧 Switch to single phase AC for the demo
While implementing the departure time hack, we removed the nominal voltage
population because we already had the nom_voltage but did not put it in
anywhere.
This caused it to be populated with a default value of zero hours
`EVSENominalVoltage":{"Multiplier":0,"Unit":"h","Value":0}`
which failed validation.
Simply restoring that change and regenerating the diff fixes the issue
This fixes EVerest#103
Signed-off-by: Shankari <k.shankari@driveelectric.gov>
🚑️ Fix regression; fill in the `EVSENominalVoltage`
So we can start using the next release... Signed-off-by: Shankari <k.shankari@driveelectric.gov>
Signed-off-by: Shankari <k.shankari@driveelectric.gov>
To allow the defaults in the config to take hold, we want to be able to send -1 as the EA
I took it out in my local copy, since that was not part of this change to be submitted to EVerest, but it will be present here
Collaborator
Author
|
These changes correspond with: #40 in ext-switchev-iso15118 Will I need to submit those PRs as patches to this repo too? Or will we update once they are merged |
Collaborator
Author
|
double checked, this does resend the |
Collaborator
|
I think we can update after they are merged. I also think that we might want to discuss a combined flow with modules and options instead of having people start a new flow every time. I can see that we want to have separate configs since it represents the station. But I don't see any reason why the simulation needs to be static, and have people restart every time to get a new configuration. Let's discuss what the demos should look like and start bringing it up to the community |
Collaborator
Author
|
outdated |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
not sending intermittent EA and DT updates, only using for start of charging session for now
includes externalPayment to be compatible with other patches