Adding Charging Powercurve Selection for EV Charging

[the-bay-kay]

Context

This PR builds off @shankari and I's work in Issue #64 . This work will be done on the functional DepartureTime demos.

High Level Goal:

... to present the user with multiple charging profiles, which they then can select and use for their current charging session

Subsequent Goals:

Edit: Updated timeline to reflect 2-week sprint goals. Multiple SASchedules is a stretch goal, implementation of power curve selection is higher priority.

EDIT 2: Changed goals to reflect implementation adjustments.

• [x] Test options for including a power-curve visualization, including (i) plotting coefficients, and (ii) Sending an image (S
  • [x] Add MQTT Broadcast of data
  • [x] New NodeRED component giving curb visualization
  • [x] Add "listener"
• [x] Incorporate Power Curve algorithm, including "choose algorithm" flag and inputs
  • [x] Incorporate Algorithm in Node-RED
  • [x] Incorperate in PyJosEv
• [x] Add commands to MQTT server
• [x] Two Stages of visualization (Performed via working method determined above):
  • [x] When setting algorithm, add dynamic view of power curve
  • [x] After initiating a charging session, broadcast the power curve that meets grid constraints
• [x] Allow user to select from a list of power curves / algorithms

[the-bay-kay]

Tasks for Demo Cleanup

Now that we've got a 90% working demo, there are several steps we need to take in order to make this production worthy / "showroom" worthy. Below is a list of the changes that need to take place in order to finish this current iteration (roughly in order):

• [x] Fix schedule send through PowerDeliveryRequest
  • (currently, schedule is generated w/o exchange... I seem to have broke it at some point during curve selection changes)
• [x] Fix powercurve visualization
  • There are two ways of going about this:
  • (i) continue to use the chart node, fixing the user scale / presentation
  • (ii) Use MatPlotLib to visualize the charts as we do in the sample script, and find a way to present images in the dashboard
• Fix LQR algorithm by:
  • [x] Fixing the distribution in schedule splicing
• [x] Add Option to skip mid-charge selection
• [x] Fix Timeout Issues
  • Mid-Process Algorithm Selection times out after ~30 Seconds
• [ ] Integrate other optimizer functions beyond LQR
• [x] Clean up code, standardize naming conventions, etc.
• [ ] Build & Push relevant docker image, reverting compose file changes
• Update the "one-line" demo script & Dockerfiles to include:
  • [ ] The updated Node-RED flows
  • [ ] Pip installation / operation for Node-RED manager

Future Work

There are some other ways in which we can improve this functionality. Because these projects have a much larger scale (implementing entirely new portions of ISO15118), I've separated them out into their own list.

• [ ] Adoption of multiple SASchedules
• [ ] Integration of Tariffs ("pay more to charge fast, pay less to charge slow", etc.)

[the-bay-kay]

... Add Option to skip mid-charge selection

Facing a bizarre issue trying to implement this. Below is a video: TL;DR, the MQTT exchange I've set up works perfect the first time the Node-RED UI is loaded, and then fails subsequent charging sessions.

I've spent a few hours trying fixes -- this issue has never occurred with the algorithm selection process, which made me think it was a timing issue. Delaying the messages to avoid race conditions (e.g., node-red publication prior to simulator subscription), re-arranging messages, and none of it seems to work.... will update accordingly once I find the cause.

MQTT exchange issue

https://github.com/user-attachments/assets/0f5b4236-b809-4347-8a90-45be279b34a0

[the-bay-kay]

We've made the change to selecting our algorithm prior to the charging session (as opposed to during the PowerDeliveryReq handshake). While this works most of the time, we're still running into the bizarre issue described in my last comment.

EDIT: It seems my intuition was correct, but my method of execution was wrong. Adding a Node-Red "Delay" node fixed the issue, no need to futz with setTimeout(). Keeping the text below for debugging context!

---

I've included a timing chart with my current theory as to the cause of this issue. Because of the behavior when re-publishing the message, I believe the issue may be that we subscribe to the confirm message after it has already been sent -- this "race condition: then causes us to stall out. I'm not sold this is the cause, as adding a delay to the confirmAlgorithm() does not eliminate this bug. Likewise, I'm confused as to why re-deploying Node-RED "fixes" the issue temporarily. I don't have many leads yet, but I will continue to diagnose...

Timing Sequence & Screen Recording

 Below is a video of the behavior occurring. First, we "stall out" on waiting for the publication of `confirmAlgorithm`. By injecting the value -- and thus, re-publishing the MQTT message -- we successfully restart the charging process, and perform as expected. Then, I re-delploy the Node-RED flow, and charge with the same settings - except a different algorithm. This charging session occurs as expected. I have ruled out the algorithm choice as being a confounding variable -- the error has occurred with both the "smooth" and "aggressive" curves. https://github.com/user-attachments/assets/b97ab9c4-68cd-4b9b-8d15-d23e0e6e411b