❇️ Smart charging demo at CharIN

[shankari]

In a few short weeks, we are going to try to pull together a demo for CharIN, to be held in Cleveland from June 11-14. Given that we have been working on smart charging recently, the goal is to try and demo basic, end to end smart charging.

So this flow diagram:

[shankari]

We also need to be able to limit the power for testing at NREL (and potentially elsewhere). Now, we would do this using the micromegawatt charger BSP https://lfenergy.zulipchat.com/#narrow/stream/417678-EVerest.3A-Framework-.26-Tools/topic/Configuring.20the.20uMWC/near/442699434

But the version of everest currently installed on the uMWC is older and does not support that config option. https://github.com/EVerest/everest-core/commit/867f83ee70cf991f1bcafa3517315c0c3631b38f

We are trying the switch_to_minimum_voltage_after_cable_check flag instead. That should use the min_export_voltage_V, which should be 100V

                        float minvoltage =
                            (config.switch_to_minimum_voltage_after_cable_check ? caps.min_export_voltage_V
                                                                                : config.dc_isolation_voltage_V);

[shankari]

@couryrr-afs has created an updated image, but it is built off the current head. So we need to address the simulator and node-red changes that were introduced in the interim. These are primarily:

• switching from JsCarSimulator to JsEvManager https://github.com/EVerest/everest-core/pull/549/files#diff-f5b2ea6489dea72491ca125ee1579b39f5bffc379d9ddac617ca9267a79b646a This results in the iso_start_v2g_session having only one parameter
• switching the iso_start_v2g_session energy transfer parameter to "ac" or "dc", with the phases coming from a config option in the module https://github.com/EVerest/everest-core/commit/993a60c07965f0a51e2d65bc3ea3899652a99174
• A new validation check added in https://github.com/EVerest/libocpp/pull/553 that checks that the device model has the same number of EVSEs as connectors. Note that we can try to fix this by adding a new EVSE, but that will run into https://github.com/EVerest/everest-demo/issues/44#issuecomment-2156366829 So let's try to edit the device model instead.

Given that none of these are related to certs and it would be desirable to demo PnC and smart charging together, let's try to fix these three issues tonight and focus on getting SP3 MaEVe to work.

[shankari]

@couryrr-afs @drmrd I am a bit confused about the version of libocpp in the docker image that @couryrr-afs created. As @drmrd knows, I created several just-in-time patches to get the smart charging demo to not crash. In order to figure out what the patches were, I:

• docker cped the directory from my container to my laptop
• checked out the charin-e2e-demo
• diffed the two diff -r -uw lib /tmp/create_patches/libocpp/lib

However, this is generating several changes that I definitely did not make - including several changes in OCPP 1.6 Hasn't the image been created with the correct version of the OCPP library?

diff -r -uw lib/ocpp/common/database/database_connection.cpp /tmp/create_patches/libocpp/lib/ocpp/common/database/database_connection.cpp
--- lib/ocpp/common/database/database_connection.cpp    2024-06-12 08:52:38
+++ /tmp/create_patches/libocpp/lib/ocpp/common/database/database_connection.cpp    2024-06-11 14:29:41
@@ -63,6 +63,7 @@

     // Add special exception for databases in ram; we don't need to create a path for them
     if (this->database_file_path.string().find(":memory:") == std::string::npos and
+        this->database_file_path.string().find("mode=memory") == std::string::npos and
         !fs::exists(this->database_file_path.parent_path())) {
         fs::create_directories(this->database_file_path.parent_path());
     }
diff -r -uw lib/ocpp/common/websocket/websocket_libwebsockets.cpp /tmp/create_patches/libocpp/lib/ocpp/common/websocket/websocket_libwebsockets.cpp
--- lib/ocpp/common/websocket/websocket_libwebsockets.cpp   2024-06-12 08:52:38
+++ /tmp/create_patches/libocpp/lib/ocpp/common/websocket/websocket_libwebsockets.cpp   2024-06-11 14:29:41
@@ -208,7 +208,7 @@

 WebsocketTlsTPM::WebsocketTlsTPM(const WebsocketConnectionOptions& connection_options,
                                  std::shared_ptr<EvseSecurity> evse_security) :
-    WebsocketBase(), evse_security(evse_security) {
+    WebsocketBase(), evse_security(evse_security), stop_deferred_handler(false) {

I double checked the code and:

• US-JOET/charin-e2e-demo: ` if (this->database_file_path.string().find(":memory:") == std::string::npos and
• US-JOET/main: if (this->database_file_path.string().find(":memory:") == std::string::npos and this->database_file_path.string().find("mode=memory") == std::string::npos and
• everest/main: if (this->database_file_path.string().find(":memory:") == std::string::npos and this->database_file_path.string().find("mode=memory") == std::string::npos and
• my container: path /ext/cache/cpm/libocpp/6502037f667273b3f55e917ec94a3fe0a2d27720/libocpp if (this->database_file_path.string().find(":memory:") == std::string::npos and this->database_file_path.string().find("mode=memory") == std::string::npos and

So it seems pretty clear that the container does not seem to have pulled from the correct branch, and I wonder if this is the cause of the demo issues we have had. I am going to switch back to main and find the diffs and see if they are more meaningful. But somebody needs to check the resulting container and verify that the correct code is actually in place.

EDIT: There are also significant differences from main. I don't know where this branch came from. So I will cherry-pick my changes only as a patch.

EDIT: Spun up a new container, copied out the libocpp and used diff -r -uw libocpp_unmod/lib libocpp/lib. This seems to give the correct diffs.

[shankari]

At this point, the SIL demo works for me although it is definitely "patchy" 🩹 And AFS needs to fix the 1ph versus 3ph issue that results in the current drawn being much lower than the value set in the profile https://github.com/US-JOET/everest-demo/pull/4#issuecomment-2164322416

Then we need to start the long and tedious process of incorporating the patches in actual code and backing them out of the demo script. In the meanwhile, I will move on to the HIL 🤞

[drmrd]

Glad this is coming together @shankari! I'm working on a patch this morning for the 1ph vs. 3ph issue we encountered when running E2E yesterday. I'll reach out or come find you if I have build questions.

[drmrd]

@shankari: I haven't been able to test that this actually works E2E, but the following (very hacky) patch for everest-core should™:

diff --git a/modules/EvseManager/EvseManager.cpp b/modules/EvseManager/EvseManager.cpp
index 8f8cd979..19df5119 100644
--- a/modules/EvseManager/EvseManager.cpp
+++ b/modules/EvseManager/EvseManager.cpp
@@ -1045,6 +1045,7 @@ bool EvseManager::updateLocalEnergyLimit(types::energy::ExternalLimits l) {
             updateLocalMaxWattLimit(get_powersupply_capabilities().max_export_power_W);
         }
     } else {
+        EVLOG_info << "Setting the following external limits on energy node" << l;
         // apply external limits if they are lower
         local_energy_limits = l;
     }
diff --git a/modules/OCPP201/OCPP201.cpp b/modules/OCPP201/OCPP201.cpp
index ca859750..833ed213 100644
--- a/modules/OCPP201/OCPP201.cpp
+++ b/modules/OCPP201/OCPP201.cpp
@@ -583,13 +583,18 @@ void OCPP201::set_external_limits(const std::map<int32_t, ocpp::v201::CompositeS
             types::energy::LimitsReq limits_req;
             const auto timestamp = start_time.to_time_point() + std::chrono::seconds(period.startPeriod);
             schedule_req_entry.timestamp = ocpp::DateTime(timestamp).to_rfc3339();
+            auto limit = period.limit;
             if (schedule.chargingRateUnit == ocpp::v201::ChargingRateUnitEnum::A) {
-                limits_req.ac_max_current_A = period.limit;
                 if (period.numberPhases.has_value()) {
                     limits_req.ac_max_phase_count = period.numberPhases.value();
+                    // Hack to address single phase AC charging
+                    if (period.numberPhases.value() == 1) {
+                        limit *= 3;
+                    }
                 }
+                limits_req.ac_max_current_A = limit;
             } else {
-                limits_req.total_power_W = period.limit;
+                limits_req.total_power_W = limit;
             }
             schedule_req_entry.limits_to_leaves = limits_req;
             schedule_import.push_back(schedule_req_entry);

It'd also be worth testing if AC 3ph or DC profiles work as expected. The main issue here is that we have yet to work through the card that addresses power limit calculations, since it requires adding plumbing in everest-core:

https://github.com/US-JOET/base-camp/issues/111

[shankari]

@drmrd As I indicated, I am busy with setting up HIL. Can AFS please make all the changes and test them so that I can have a good build to put on the HIL? I am also fine with skipping the hack if it works for AC 3-phase, but I would like that to be tested, and the appropriate config provided to me.

[shankari]

The smart charging demo works with multiple patches and will be demoed at the JO All-Hands in the next couple of works. It is very patchy and hacky but it works. The patches are being submitted to various repos (https://github.com/EVerest/everest-demo/issues/61) We will continue hardware testing in and follow-ons in separate issues