Open shankari opened 5 months ago
I start this process by bumping the images up to 2024.3.0-rc1
which has all the changes required
https://github.com/EVerest/everest-demo/pull/36
@jhoshiko @sahabulh @activeshadow the new images do work now. I merged the PR at 11:04, so I guess the images had not been built and tagged correctly at the time of the demo.
$ git branch
change_base_expose_admin_panel
* main
turn_on_basic_testing
$ docker compose -f docker-compose.yml up
everest-demo-manager-1 | 2024-03-27 19:10:38.939593 [INFO] manager :: 🚙🚙🚙 All modules are initialized. EVerest up and running [12680ms] 🚙🚙🚙
everest-demo-manager-1 | 2024-03-27 19:10:39.201290 [INFO] connector_1:Evs :: Ignoring BSP Event, BSP is not enabled yet.
everest-demo-manager-1 | 2024-03-27 19:10:39.519746 [INFO] connector_1:Evs :: Max AC hardware capabilities: 32A/3ph
everest-demo-manager-1 | 2024-03-27 19:10:39.622471 [INFO] connector_1:Evs :: AC HLC mode enabled.
everest-demo-manager-1 | 2024-03-27 19:10:39.711235 [INFO] connector_1:Evs :: 🌀🌀🌀 Ready to start charging 🌀🌀🌀
@sahabulh you can start testing
@sahabulh just to summarize what we discussed, I think we should start by getting PnC to work with the everest OCPP CSMS and the everest certs. Basically, have an MRE for https://github.com/EVerest/EVerest/blob/main/docs/tutorials/how_to_plug_and_charge/index.rst so that we can all verify that it works and/or get support to get it to work. Note that this will involve swapping out MaEVe with the everest-ocpp
Here are the errors that I currently see with the EVerest + MaEVe MRE
So the ISO 15118-2 failures are probably some issue with OCPP, unless the messages sent are different in the two nodered UIs or there is some other config SIL issue
To use OCPP 201 PnC, we need to change the demo script to launch the PnC SIL
The correct way (after all this is working) is change the last line of the demo-iso15118-2-ac-plus-ocpp.sh
script.
For debugging, I just used the following
$ docker exec -it everest-ac-demo-manager-1 /bin/bash
80c64be33b3c:/workspace# ps -aef
PID USER TIME COMMAND
1 root 0:00 tail -f /dev/null
20 root 0:00 sh /workspace/build/run-scripts/run-sil-ocpp201.sh
80c64be33b3c:/workspace# pkill 20
80c64be33b3c:/workspace# sh /workspace/build/run-scripts/run-sil-ocpp201-pnc.sh
with this, I can launch the PnC SIL demo but it fails with the following error
2024-03-27 19:50:39.385065 [INFO] evse_manager_1: :: EVSE ISO V2G PaymentServiceSelectionRes
2024-03-27 19:50:40.473354 [INFO] iso15118_charge :: CertificateInstallation-phase started
2024-03-27 19:50:40.475812 [INFO] iso15118_charge :: Waiting for the CertInstallationExiRes msg
2024-03-27 19:50:41.520308 [INFO] evse_security:E :: TPM Key: false
2024-03-27 19:50:41.531967 [WARN] evse_security:E static std::string evse_security::OpenSSLSupplier::x509_get_responder_url(evse_security::X509Handle*) :: Could not retrieve OCSP Responder URL from certificate
2024-03-27 19:50:41.556340 [INFO] ocpp:OCPP201 :: libocpp: Updating OCSP cache on 2 certificates
2024-03-27 19:50:43.013342 [CRIT] manager int boot(const boost::program_options::variables_map&) :: Module iso15118_charger (pid: 628) exited with status: 11. Terminating all modules.
On re-running, I got more details - I am not sure if this is an artifact of fact that we are re-running on the same EVSE (due to stored stated from the previous run).
2024-03-27 19:54:29.592371 [INFO] evse_manager_1: :: EVSE ISO V2G PaymentServiceSelectionRes
2024-03-27 19:54:30.674003 [INFO] iso15118_charge :: CertificateInstallation-phase started
2024-03-27 19:54:30.675022 [INFO] iso15118_charge :: Waiting for the CertInstallationExiRes msg
2024-03-27 19:54:35.175801 [ERRO] iso15118_charge void dlog_func(dloglevel_t, const char*, int, const char*, const char*, ...) :: CertificateInstallationRes timeout occured
2024-03-27 19:54:35.176044 [ERRO] iso15118_charge void dlog_func(dloglevel_t, const char*, int, const char*, const char*, ...) :: Failed response code detected for message "Certificate Installation", error: Response FAILED
2024-03-27 19:54:35.178897 [WARN] iso15118_charge void dlog_func(dloglevel_t, const char*, int, const char*, const char*, ...) :: Response message (type 10) not configured within 98 ms (took 4505 ms)
2024-03-27 19:54:35.180075 [INFO] evse_manager_1: :: CAR ISO V2G CertificateInstallationReq
2024-03-27 19:54:35.182786 [INFO] evse_manager_1: :: EVSE ISO V2G CertificateInstallationRes
2024-03-27 19:54:35.273141 [ERRO] iso15118_car pybind11_init_everestpy(pybind11::module_&)::<lambda(const std::string&)> :: EXI message (ns=urn:iso:15118:2:2013:MsgDef) where validation failed: 8098020ed0f57f3ed7de5f906082002400402000020000201000
2024-03-27 19:54:36.739655 [CRIT] manager int boot(const boost::program_options::variables_map&) :: Module iso15118_charger (pid: 1112) exited with status: 11. Terminating all modules.
2024-03-27 19:54:36.741794 [INFO] manager :: SIGTERM of child: api (pid: 1090) succeeded.
2024-03-27 19:54:36.742117 [INFO] manager :: SIGTERM of child: auth (pid: 1091) succeeded.
@sahabulh would be interesting to see if you get the same error from the OCPP-CSMS, or whether that works correctly.
Given that the error seems to be with validating the EXI message for the CertificateInstallationRes
, it may well be a CSMS issue, since with OCPP enabled, the CSMS sends the certificate to the EVSE and then to the car. Maybe we haven't set up the EVCC leaf cert correctly in the CSMS?
Also @crr-snl for visibility
Here are the errors that I currently see with the EVerest + MaEVe MRE
AC 3ph 16A - charges AC ISO 15118-2 (stuck in PrepareCharging because EV did not transition to state C) DC ISO 15118-2 (same, stuck in PrepareCharging because EV did not transition to state C) Checking if it is OCPP by using the DC ISO 15118-2 demo (works) So the ISO 15118-2 failures are probably some issue with OCPP, unless the messages sent are different in the two nodered UIs or there is some other config SIL issue
What steps did you follow here for these four tests?
What steps did you follow here for these four tests?
$ bash demo-iso15118-2-ac-plus-ocpp.sh -3
Then in the UI, select the connection mode using the dropdown Check with @jhoshiko if you have questions - he was able to run them and got the same results
What steps did you follow here for these four tests?
$ bash demo-iso15118-2-ac-plus-ocpp.sh -3
Then in the UI, select the connection mode using the dropdown Check with @jhoshiko if you have questions - he was able to run them and got the same results
I got the exact same results. Works for the first and the last. Stuck at prepare charging with the "didn't transition to state C" error.
@sahabulh would be interesting to see if you get the same error from the OCPP-CSMS, or whether that works correctly. Given that the error seems to be with validating the EXI message for the
CertificateInstallationRes
, it may well be a CSMS issue, since with OCPP enabled, the CSMS sends the certificate to the EVSE and then to the car. Maybe we haven't set up the EVCC leaf cert correctly in the CSMS?
For this, did you use the demo-iso15118-2-ac-plus-ocpp.sh
script and only changed the script in the last line from run-sil-ocpp201.sh
to run-sil-ocpp201-pnc.sh
? But we have to follow this to start the default CSMS, right?
For this, did you use the demo-iso15118-2-ac-plus-ocpp.sh script and only changed the script in the last line from run-sil-ocpp201.sh to run-sil-ocpp201-pnc.sh? But we have to follow this to start the default CSMS, right?
I did not test with the default CSMS. I only tested with MaEVe. That is why I said
would be interesting to see if you get the same error from the OCPP-CSMS, or whether that works correctly.
Okay. I tried to run with the only change being in the last line (run-sil-ocpp201.sh
changed to run-sil-ocpp201-pnc.sh
). What is weird is that it still waits for the RFID swap. And it works after the swap. Why is it waiting for RFID swap? With PnC shouldn't it automatically connect after the car plugs in? Maybe I should try the AC ISO 15118-2 Plug&Charge
from the dropdown? Let me try that.
Here is my log:
2024-03-28 00:16:58.285193 [INFO] ocpp:OCPP201 :: All EVSE ready. Starting OCPP2.0.1 service
2024-03-28 00:16:58.480805 [WARN] ocpp:OCPP201 ocpp::v201::GetVariableStatusEnum ocpp::v201::DeviceModel::request_value_internal(const ocpp::v201::Component&, const ocpp::v201::Variable&, const ocpp::v201::AttributeEnum&, std::string&, bool) :: unknown variable in InternalCtrlr.VerifyCsmsCommonName
2024-03-28 00:16:58.481011 [WARN] ocpp:OCPP201 ocpp::v201::GetVariableStatusEnum ocpp::v201::DeviceModel::request_value_internal(const ocpp::v201::Component&, const ocpp::v201::Variable&, const ocpp::v201::AttributeEnum&, std::string&, bool) :: unknown variable in InternalCtrlr.UseTPM
2024-03-28 00:16:58.481114 [WARN] ocpp:OCPP201 ocpp::v201::GetVariableStatusEnum ocpp::v201::DeviceModel::request_value_internal(const ocpp::v201::Component&, const ocpp::v201::Variable&, const ocpp::v201::AttributeEnum&, std::string&, bool) :: unknown variable in InternalCtrlr.VerifyCsmsAllowWildcards
2024-03-28 00:16:58.486054 [INFO] ocpp:OCPP201 :: Connecting TLS websocket to uri: wss://host.docker.internal/ws/cp001 with security-profile 3
2024-03-28 00:16:58.542558 [INFO] evse_security:E :: TPM Key: false
2024-03-28 00:16:58.543000 [INFO] evse_security:E :: TPM Key: false
2024-03-28 00:16:58.543731 [WARN] evse_security:E evse_security::GetKeyPairResult evse_security::EvseSecurity::get_key_pair_internal(evse_security::LeafCertificateType, evse_security::EncodingFormat) :: CSMS leaf requires full bundle, but full bundle not found at path: "/workspace/dist/etc/everest/certs/client/csms"
2024-03-28 00:16:58.544256 [INFO] ocpp:OCPP201 :: Using certificate: "/workspace/dist/etc/everest/certs/client/csms/CSMS_LEAF.pem"
2024-03-28 00:16:58.544652 [INFO] ocpp:OCPP201 :: Using key file: "/workspace/dist/etc/everest/certs/client/csms/CSMS_LEAF.key"
2024-03-28 00:16:58.585111 [INFO] evse_security:E :: Building new certificate hierarchy!
2024-03-28 00:16:58.633034 [INFO] evse_security:E :: Requesting certificate file: [CSMS] file:"/workspace/dist/etc/everest/certs/ca/v2g/V2G_ROOT_CA.pem"
2024-03-28 00:16:58.588785 [DEBG] ocpp:OCPP201 :: Loading ca csms bundle to verify server certificate: /workspace/dist/etc/everest/certs/ca/v2g/V2G_ROOT_CA.pem
2024-03-28 00:16:58.721267 [INFO] evse_security:E :: Requesting certificate file: [CSMS] file:"/workspace/dist/etc/everest/certs/ca/v2g/V2G_ROOT_CA.pem"
2024-03-28 00:16:58.793384 [INFO] ocpp:OCPP201 :: OCPP client successfully connected to TLS websocket server
2024-03-28 00:16:58.799108 [INFO] ocpp:OCPP201 :: Received BootNotificationResponse: {
"currentTime": "2024-03-28T00:16:58.000Z",
"interval": 300,
"status": "Accepted"
}
with messageId: b69bd176-6415-4462-9395-617d1aaa75d1
2024-03-28 00:16:58.826974 [INFO] evse_security:E :: TPM Key: false
2024-03-28 00:16:58.832650 [WARN] evse_security:E static std::string evse_security::OpenSSLSupplier::x509_get_responder_url(evse_security::X509Handle*) :: Could not retrieve OCSP Responder URL from certificate
2024-03-28 00:16:58.869118 [INFO] ocpp:OCPP201 :: libocpp: Updating OCSP cache on 2 certificates
2024-03-28 00:16:59.357461 [WARN] ocpp:OCPP201 void ocpp::v201::OcspUpdater::updater_thread_loop() :: libocpp: OCSP status update failed: CSMS rejected certificate status update: (No status info provided), will retry.
2024-03-28 00:17:04.413110 [INFO] evse_security:E :: TPM Key: false
2024-03-28 00:17:04.427248 [WARN] evse_security:E static std::string evse_security::OpenSSLSupplier::x509_get_responder_url(evse_security::X509Handle*) :: Could not retrieve OCSP Responder URL from certificate
2024-03-28 00:17:04.445052 [INFO] ocpp:OCPP201 :: libocpp: Updating OCSP cache on 2 certificates
2024-03-28 00:17:04.530943 [WARN] ocpp:OCPP201 void ocpp::v201::OcspUpdater::updater_thread_loop() :: libocpp: OCSP status update failed: CSMS rejected certificate status update: (No status info provided), will retry.
2024-03-28 00:17:09.579638 [INFO] evse_security:E :: TPM Key: false
2024-03-28 00:17:56.018370 [WARN] evse_security:E static std::string evse_security::OpenSSLSupplier::x509_get_responder_url(evse_security::X509Handle*) :: Could not retrieve OCSP Responder URL from certificate
2024-03-28 00:17:56.036945 [INFO] ocpp:OCPP201 :: libocpp: Updating OCSP cache on 2 certificates
2024-03-28 00:17:56.122307 [WARN] ocpp:OCPP201 void ocpp::v201::OcspUpdater::updater_thread_loop() :: libocpp: OCSP status update failed: CSMS rejected certificate status update: (No status info provided), will retry.
2024-03-28 00:17:58.860548 [INFO] ocpp:OCPP201 :: Checking if CSMS client certificate has expired
2024-03-28 00:17:58.909636 [INFO] evse_security:E :: TPM Key: false
2024-03-28 00:17:58.911874 [INFO] evse_security:E :: TPM Key: false
2024-03-28 00:17:58.915443 [WARN] evse_security:E evse_security::GetKeyPairResult evse_security::EvseSecurity::get_key_pair_internal(evse_security::LeafCertificateType, evse_security::EncodingFormat) :: CSMS leaf requires full bundle, but full bundle not found at path: "/workspace/dist/etc/everest/certs/client/csms"
2024-03-28 00:17:58.919243 [INFO] ocpp:OCPP201 :: CSMS client certificate is still valid.
2024-03-28 00:18:01.167070 [INFO] evse_security:E :: TPM Key: false
2024-03-28 00:18:01.172253 [WARN] evse_security:E static std::string evse_security::OpenSSLSupplier::x509_get_responder_url(evse_security::X509Handle*) :: Could not retrieve OCSP Responder URL from certificate
2024-03-28 00:18:01.173282 [INFO] ocpp:OCPP201 :: libocpp: Updating OCSP cache on 2 certificates
2024-03-28 00:18:01.259220 [WARN] ocpp:OCPP201 void ocpp::v201::OcspUpdater::updater_thread_loop() :: libocpp: OCSP status update failed: CSMS rejected certificate status update: (No status info provided), will retry.
2024-03-28 00:18:06.306875 [INFO] evse_security:E :: TPM Key: false
2024-03-28 00:18:06.311643 [WARN] evse_security:E static std::string evse_security::OpenSSLSupplier::x509_get_responder_url(evse_security::X509Handle*) :: Could not retrieve OCSP Responder URL from certificate
2024-03-28 00:18:06.348985 [INFO] ocpp:OCPP201 :: libocpp: Updating OCSP cache on 2 certificates
2024-03-28 00:18:06.434725 [WARN] ocpp:OCPP201 void ocpp::v201::OcspUpdater::updater_thread_loop() :: libocpp: OCSP status update failed: CSMS rejected certificate status update: (No status info provided), will retry.
2024-03-28 00:18:06.870924 [INFO] car_simulator_1 :: { cmd: 'sleep', args: [ 1 ], exec: [Function (anonymous)] }
2024-03-28 00:18:08.236743 [INFO] car_simulator_1 :: { cmd: 'iec_wait_pwr_ready', args: [], exec: [Function (anonymous)] }
2024-03-28 00:18:08.577190 [INFO] evse_manager_1: :: SYS Session logging started.
2024-03-28 00:18:08.577327 [INFO] evse_manager_1: :: EVSE IEC Session Started: EVConnected
2024-03-28 00:18:11.444435 [INFO] evse_security:E :: TPM Key: false
2024-03-28 00:18:11.452260 [WARN] evse_security:E static std::string evse_security::OpenSSLSupplier::x509_get_responder_url(evse_security::X509Handle*) :: Could not retrieve OCSP Responder URL from certificate
2024-03-28 00:18:11.486184 [INFO] ocpp:OCPP201 :: libocpp: Updating OCSP cache on 2 certificates
2024-03-28 00:18:11.576637 [WARN] ocpp:OCPP201 void ocpp::v201::OcspUpdater::updater_thread_loop() :: libocpp: OCSP status update failed: CSMS rejected certificate status update: (No status info provided), will retry.
2024-03-28 00:18:12.673179 [INFO] token_provider_ :: Publishing new dummy token: {"id_token":{"value":"DEADBEEF","type":"ISO14443"},"authorization_type":"RFID","prevalidated":false,"connectors":[1]}
2024-03-28 00:18:12.673765 [INFO] auth:Auth :: Received new token: {
"authorization_type": "RFID",
"connectors": [
1
],
"id_token": {
"type": "ISO14443",
"value": "DEADBEEF"
},
"prevalidated": false
}
2024-03-28 00:18:12.717353 [INFO] ocpp:OCPP201 :: Found invalid entry in AuthCache: Sending new request
2024-03-28 00:18:12.764985 [INFO] auth:Auth :: Providing authorization to connector#1
2024-03-28 00:18:12.782011 [INFO] evse_manager_1: :: EVSE IEC EIM Authorization received
2024-03-28 00:18:12.782261 [INFO] evse_manager_1: :: EVSE IEC Transaction Started (0 kWh)
2024-03-28 00:18:12.782671 [INFO] evse_manager_1: :: EVSE IEC AC mode, HLC enabled(X1), matching already started. We are in X1 so we can go directly to nominal PWM.
2024-03-28 00:18:12.782751 [INFO] evse_manager_1: :: EVSE IEC Charger state: Wait for Auth->PrepareCharging
2024-03-28 00:18:12.782992 [INFO] evse_manager_1: :: EVSE IEC Set PWM On (33.33333432674408%) took 0 ms
2024-03-28 00:18:12.812947 [INFO] auth:Auth :: Result for token: DEADBEEF: ACCEPTED
2024-03-28 00:18:12.989675 [INFO] car_simulator_1 :: { cmd: 'sleep', args: [ 1 ], exec: [Function (anonymous)] }
2024-03-28 00:18:14.240989 [INFO] car_simulator_1 :: {
cmd: 'draw_power_regulated',
args: [ 16, 3 ],
exec: [Function (anonymous)]
}
2024-03-28 00:18:14.241208 [INFO] car_simulator_1 :: { cmd: 'sleep', args: [ 36000 ], exec: [Function (anonymous)] }
2024-03-28 00:18:14.407407 [INFO] evse_manager_1: :: CAR IEC Event CarRequestedPower
2024-03-28 00:18:14.407660 [INFO] evse_manager_1: :: EVSE IEC Charger state: PrepareCharging->Charging
2024-03-28 00:18:14.660076 [INFO] evse_manager_1: :: EVSE IEC Event PowerOn
2024-03-28 00:18:32.094872 [INFO] evse_security:E :: TPM Key: false
2024-03-28 00:18:32.099614 [WARN] evse_security:E static std::string evse_security::OpenSSLSupplier::x509_get_responder_url(evse_security::X509Handle*) :: Could not retrieve OCSP Responder URL from certificate
2024-03-28 00:18:32.136943 [INFO] ocpp:OCPP201 :: libocpp: Updating OCSP cache on 2 certificates
2024-03-28 00:18:32.223925 [WARN] ocpp:OCPP201 void ocpp::v201::OcspUpdater::updater_thread_loop() :: libocpp: OCSP status update failed: CSMS rejected certificate status update: (No status info provided), will retry.
2024-03-28 00:18:33.408519 [INFO] car_simulator_1 :: { cmd: 'unplug', args: [], exec: [Function (anonymous)] }
2024-03-28 00:18:33.683883 [INFO] evse_manager_1: :: EVSE IEC Event PowerOff
2024-03-28 00:18:33.900909 [INFO] evse_manager_1: :: EVSE ISO SLAC UNMATCHED
2024-03-28 00:18:33.901120 [INFO] evse_manager_1: :: EVSE ISO D-LINK_READY (false)
2024-03-28 00:18:33.902827 [INFO] evse_manager_1: :: CAR IEC Event CarUnplugged
2024-03-28 00:18:33.902933 [INFO] evse_manager_1: :: EVSE IEC Charger state: Charging->StoppingCharging
2024-03-28 00:18:33.903119 [INFO] evse_manager_1: :: EVSE IEC Set PWM Off
2024-03-28 00:18:33.945031 [INFO] evse_manager_1: :: EVSE IEC Charger state: StoppingCharging->Finished
2024-03-28 00:18:33.945369 [INFO] evse_manager_1: :: EVSE IEC Transaction Finished: EVDisconnected (0.054 kWh)
2024-03-28 00:18:34.033137 [INFO] evse_manager_1: :: EVSE IEC Session Finished
2024-03-28 00:18:34.033280 [INFO] evse_manager_1: :: SYS Session logging stopped.
Yep, using the AC ISO 15118-2 Plug&Charge
from the dropdown menu, I got the same certificate installation error reported before.
We can actually turn off the certificate installation service in the config yaml file. Should we try that? We can use a patch in that case for the initial test.
My recommendation would be the following:
In both cases, as I said, I would start with the recommended OCPP-CSMS and get help if needed to get that to work. Once we have a working solution, we can try the more complicated MaEVe CSMS
I did try the OCPP-CSMS first. But it throws a JSON validation error when I try to start it. That's why I was doing what you did to see if I get the same results. Anyways, I will post the error I am getting when I return home. In the meantime, can anyone please try to start the OCPP-CSMS and check if any error happens?
@sahabulh can you please update this issue with your findings from yesterday so that I can take over? You may recall that the plan was for me to work on it today and for @activeshadow to work on it tomorrow.
My recommendation would be the following:
First get ISO 15118-2 to work with OCPP with EIM
- Currently ISO 15118-2 without OCPP and with EIM works
- ISO 15118-2 with OCPP and with EIM does not work
- Then get ISO 15118-2 to work with OCPP and PnC
In both cases, as I said, I would start with the recommended OCPP-CSMS and get help if needed to get that to work. Once we have a working solution, we can try the more complicated MaEVe CSMS
So, by "ISO 15118-2 with OCPP and with EIM does not work" you mean it is not working with the AC ISO 15118-2
selected from the dropdown, right? Because the default AC 3ph 16A
works. The AC ISO 15118-2
wasn't working in the previous (2024.2.0
) version also.
So, when we are using AC 3ph 16A
, although it says ISO15118
at the top, it is not actually using ISO 15118
, right? Is it using DIN SPEC 70121
? If that is true, what we have now in the main
, is an MRE because it works for AC 3ph 16A
, but not for AC ISO 15118-2
. As I said earlier, same thing happened before the last merge. I never tried AC ISO 15118-2
, only AC 3ph 16A
. Did you test AC ISO 15118-2
?
Yes, the default AC 3ph 16A is what I mean. I do not think it supports ISO 15118-2; you can verify from the logs or from the node-red config on the messages sent to the MQTT server.
Yes, it was not working in a previous version also. However, EVerest with ISO 15118-2 and OCPP 201 (at least PnC) was not expected to work in a previous release. As you can see from the first message in this issue (https://github.com/EVerest/everest-demo/issues/35#issue-2211002442), the EVerest team has now implemented https://github.com/EVerest/everest-core/pull/588 this support. So we should be able to test it.
I am suggesting starting with ISO 15118-2 EIM instead of PnC since it is simpler and should be easier to get working. Concretely, EIM should not require any special contract certs on the EV. One less cert = simpler!
In general, while validating, it is good to test all the options in the dropdown since they test various scenarios.
But I don't think AC ISO 15118-2
uses PnC. When we test the old version before the recent bump, we were using EIM. But AC ISO 15118-2
still didn't work. Another dropdown option named AC ISO 15118-2 Plug&Charge
was added. I thought that was meant for the PnC, and the old one for the EIM? AC 3ph 16A
with OCPP and EIM is working. I don't know what to do to make AC ISO 15118-2
work. Should I post it on Zulip?
I did not say that AC ISO 15118-2
uses PnC. It uses EIM.
I don't know what to do to make AC ISO 15118-2 work. Should I post it on Zulip?
Sure.
Or you can try to look at the differences between ISO 15118-2 with OCPP (does not work) and ISO 15118-2 without OCPP (works). The issue is almost certainly something related to OCPP.
EDIT: You can also try it with OCPP-CSMS first. See my note above on steps to proceed: https://github.com/EVerest/everest-demo/issues/35#issuecomment-2024220819
@sahabulh any updates on timeline? I want to work on this a bit tonight (before @activeshadow starts working on it tomorrow) but don't want to duplicate your work
Sorry, I am juggling two things at once. That's why it is taking so long. I have an MRE here where I am testing OCPP-CSMS. It is producing this error. Please see if I am doing something wrong. You will have to clone the repo and run the script from there.
I wish the websocket errors were more details. It is difficult to understand what the codes mean. On the other hand, MaEVe's errors are very detailed.
I will post the issues in Zulip later tonight. Posting it now will not help much as it is past midnight there. Meanwhile, I will try to compare the files you suggested.
I am trying to build EVerest from scratch and test the OCPP-CSMS. If it works, we will know there is something wrong with the demo.
Update: Nope, building from scratch is not working. It fails at 79%.
Sorry, I am juggling two things at once. That's why it is taking so long. I have an MRE here where I am testing OCPP-CSMS. It is producing this error. Please see if I am doing something wrong. You will have to clone the repo and run the script from there.
Log: I wish the websocket errors were more details. It is difficult to understand what the codes mean. On the other hand, MaEVe's errors are very detailed.
Update on this: I thought maybe I should try SP 0 which is mentioned here as this doesn't apparently require any authentication. But when I tested it produced the following error:
2024-03-29 01:46:25.419132 [INFO] evse_manager_1: :: 🌀🌀🌀 Ready to start charging 🌀🌀🌀
2024-03-29 01:46:25.461963 [INFO] ocpp:OCPP201 :: EVSE 1 ready.
2024-03-29 01:46:25.462222 [INFO] ocpp:OCPP201 :: All EVSE ready. Starting OCPP2.0.1 service
terminate called after throwing an instance of 'std::invalid_argument'
what(): security_profile = 0 not officially allowed in OCPP 2.0.1
2024-03-29 01:46:25.808518 [CRIT] manager int boot(const boost::program_options::variables_map&) :: Module ocpp (pid: 141) exited with status: 134. Terminating all modules.
@shankari or @sahabulh how do I configure the connection URI that libocpp will use to connect to the CSMS (OCPP server)? I wondering if right now it's defaulting to localhost:9000
, which won't work if the EVSE and the CSMS aren't running in the same network namespace.
I've found documentation on configuring the OCPP module in the EVerest manager but I'm not seeing anything about the CSMS URI. Is it a config option or a setting in the DB?
It is a setting in the DB (e.g. https://github.com/EVerest/everest-demo/issues/25#issuecomment-1987368280) The current version uses a different variable ID (it should be in the issue but I can't find it now) but should be the same otherwise
d documentation on configuring the OCPP module in the EVerest manager but I'm not seeing anything about the CSMS URI. Is it a config option or a setting in the DB?
@activeshadow , you will have to change the address and port here if you want to it on the server side.
@shankari @activeshadow I am talking with Cornelius here in case you want to participate or just observe.
@sahabulh @shankari okay so I think my version of Sahabul's MRE (here) is getting further along now, but I'm not sure how to test the actual PnC stuff...
I Dockerized the EVerest OCPP-CSMS implementation and then updated the EVerest EVSE manager to use OCPP 2.0.1 SP 1 and it seems to be communicating now. I haven't tried SP 2 or SP 3 yet.
From the looks of the Zulip conversations though it looks like you have already moved on to MaEVe?
@activeshadow testing PnC: https://github.com/EVerest/everest-demo/issues/35#issuecomment-2023858854 @sahabulh was testing with MaEVe (likely due to lack of time). I think that starting with OCPP-CSMS is a better solution since it is more likely to actually work
@shankari thanks for the link to the comment, but what do I do in the UI to test PnC, since right now from what I can tell it's still making me do the RFID swipe to authenticate.
select the PnC option from the dropdown below Connector 1
@shankari okay yeah I did that and it's waiting for auth so I assume I'm hitting a cert issue where the EV is missing a MO cert or it's not getting transmitted as expected.
I'll keep digging.
Yup, missing certs. I will debug this more, just posting it here for documentation.
Starting software in the loop simulation using script run-sil-ocpp201-pnc.sh
2024-03-29 19:47:47.315311 [INFO] manager :: ________ __ _
2024-03-29 19:47:47.315383 [INFO] manager :: | ____\ \ / / | |
2024-03-29 19:47:47.315394 [INFO] manager :: | |__ \ \ / /__ _ __ ___ ___| |_
2024-03-29 19:47:47.315403 [INFO] manager :: | __| \ \/ / _ \ '__/ _ \/ __| __|
2024-03-29 19:47:47.315411 [INFO] manager :: | |____ \ / __/ | | __/\__ \ |_
2024-03-29 19:47:47.315419 [INFO] manager :: |______| \/ \___|_| \___||___/\__|
2024-03-29 19:47:47.315427 [INFO] manager ::
2024-03-29 19:47:47.315436 [INFO] manager :: Using MQTT broker mqtt-server:1883
2024-03-29 19:47:47.337469 [INFO] everest_ctrl :: Launching controller service on port 8849
2024-03-29 19:47:47.358939 [INFO] manager :: Loading config file at: /ext/source/config/config-sil-ocpp201-pnc.yaml
2024-03-29 19:47:47.705870 [INFO] manager :: Config loading completed in 371ms
2024-03-29 19:48:04.054125 [INFO] auth:Auth :: Module auth initialized [16197ms]
2024-03-29 19:48:04.060131 [INFO] api:API :: Module api initialized [16295ms]
2024-03-29 19:48:06.858030 [INFO] energy_manager: :: Module energy_manager initialized [17392ms]
2024-03-29 19:48:07.751391 [INFO] evse_manager_1: :: Module evse_manager_1 initialized [17396ms]
2024-03-29 19:48:12.251491 [INFO] evse_manager_2: :: Module evse_manager_2 initialized [20499ms]
2024-03-29 19:48:18.554437 [WARN] evse_security:E evse_security::EvseSecurity::EvseSecurity(const evse_security::FilePaths&, const std::optional<std::__cxx11::basic_string<char> >&, const std::optional<long unsigned int>&, const std::optional<long unsigned int>&, const std::optional<std::chrono::duration<long int> >&, const std::optional<std::chrono::duration<long int> >&) :: Could not find configured V2G bundle file at: /workspace/dist/etc/everest/certs/ca/v2g/V2G_ROOT_CA.pem, creating default!
2024-03-29 19:48:18.559398 [WARN] evse_security:E evse_security::EvseSecurity::EvseSecurity(const evse_security::FilePaths&, const std::optional<std::__cxx11::basic_string<char> >&, const std::optional<long unsigned int>&, const std::optional<long unsigned int>&, const std::optional<std::chrono::duration<long int> >&, const std::optional<std::chrono::duration<long int> >&) :: Could not find configured MO bundle file at: /workspace/dist/etc/everest/certs/ca/mo/MO_ROOT_CA.pem, creating default!
2024-03-29 19:48:18.648055 [WARN] evse_security:E evse_security::EvseSecurity::EvseSecurity(const evse_security::FilePaths&, const std::optional<std::__cxx11::basic_string<char> >&, const std::optional<long unsigned int>&, const std::optional<long unsigned int>&, const std::optional<std::chrono::duration<long int> >&, const std::optional<std::chrono::duration<long int> >&) :: Could not find configured MF bundle file at: /workspace/dist/etc/everest/certs/ca/mf/MF_ROOT_CA.pem, creating default!
2024-03-29 19:48:18.754874 [INFO] grid_connection :: Module grid_connection_point initialized [22906ms]
2024-03-29 19:48:18.854660 [INFO] evse_security:E :: Module evse_security initialized [25803ms]
2024-03-29 19:48:22.956284 [INFO] iso15118_charge :: TCP server on eth0 is listening on port [fe80::42:acff:fe13:4%160]:61341
2024-03-29 19:48:22.956555 [INFO] iso15118_charge :: TLS server on eth0 is listening on port [fe80::42:acff:fe13:4%160]:64109
2024-03-29 19:48:22.956696 [INFO] iso15118_charge :: SDP socket setup succeeded
2024-03-29 19:48:22.957213 [INFO] iso15118_charge :: Module iso15118_charger initialized [20905ms]
2024-03-29 19:48:23.849121 [INFO] ocpp:OCPP201 :: Module ocpp initialized [18087ms]
2024-03-29 19:48:25.663325 [INFO] system:System :: Module system initialized [17104ms]
2024-03-29 19:48:25.953887 [INFO] token_provider_ :: Module token_provider_1 initialized [14805ms]
2024-03-29 19:48:27.359436 [INFO] manager :: 🚙🚙🚙 All modules are initialized. EVerest up and running [40047ms] 🚙🚙🚙
2024-03-29 19:48:27.364200 [INFO] ocpp:OCPP201 :: OCPP certificates path: /workspace/dist/etc/everest/certs
2024-03-29 19:48:27.552843 [INFO] ocpp:OCPP201 :: Established connection to device model database successfully: "/workspace/dist/share/everest/modules/OCPP201/device_model_storage.db"
2024-03-29 19:48:27.569391 [INFO] ocpp:OCPP201 :: Successfully retrieved Device Model from DeviceModelStorage
2024-03-29 19:48:27.663066 [INFO] evse_manager_1: :: Ignoring BSP Event, BSP is not enabled yet.
2024-03-29 19:48:27.769178 [INFO] ocpp:OCPP201 :: Logging OCPP messages to log file: /tmp/everest_ocpp_logs/2024-03-29T19:48:27.769Z.log
2024-03-29 19:48:27.769394 [INFO] ocpp:OCPP201 :: Logging OCPP messages to html file: /tmp/everest_ocpp_logs/2024-03-29T19:48:27.769Z.html
2024-03-29 19:48:27.769521 [INFO] ocpp:OCPP201 :: Logging SecurityEvents to file
2024-03-29 19:48:27.771755 [INFO] ocpp:OCPP201 :: TxStartPoint from device model: PowerPathClosed
2024-03-29 19:48:27.949557 [INFO] evse_manager_2: :: Ignoring BSP Event, BSP is not enabled yet.
2024-03-29 19:48:28.065309 [INFO] evse_manager_2: :: Max AC hardware capabilities: 32A/3ph
2024-03-29 19:48:28.203459 [INFO] evse_manager_2: :: 🌀🌀🌀 Ready to start charging 🌀🌀🌀
2024-03-29 19:48:28.287028 [INFO] ocpp:OCPP201 :: EVSE 2 ready.
2024-03-29 19:48:28.327823 [INFO] evse_manager_1: :: Max AC hardware capabilities: 32A/3ph
2024-03-29 19:48:28.419715 [INFO] evse_manager_1: :: AC HLC mode enabled.
2024-03-29 19:48:28.550976 [INFO] evse_manager_1: :: 🌀🌀🌀 Ready to start charging 🌀🌀🌀
2024-03-29 19:48:28.594617 [INFO] ocpp:OCPP201 :: EVSE 1 ready.
2024-03-29 19:48:28.594792 [INFO] ocpp:OCPP201 :: All EVSE ready. Starting OCPP2.0.1 service
2024-03-29 19:48:28.773090 [WARN] ocpp:OCPP201 ocpp::v201::GetVariableStatusEnum ocpp::v201::DeviceModel::request_value_internal(const ocpp::v201::Component&, const ocpp::v201::Variable&, const ocpp::v201::AttributeEnum&, std::string&, bool) :: unknown variable in InternalCtrlr.VerifyCsmsCommonName
2024-03-29 19:48:28.773260 [WARN] ocpp:OCPP201 ocpp::v201::GetVariableStatusEnum ocpp::v201::DeviceModel::request_value_internal(const ocpp::v201::Component&, const ocpp::v201::Variable&, const ocpp::v201::AttributeEnum&, std::string&, bool) :: unknown variable in InternalCtrlr.UseTPM
2024-03-29 19:48:28.773339 [WARN] ocpp:OCPP201 ocpp::v201::GetVariableStatusEnum ocpp::v201::DeviceModel::request_value_internal(const ocpp::v201::Component&, const ocpp::v201::Variable&, const ocpp::v201::AttributeEnum&, std::string&, bool) :: unknown variable in InternalCtrlr.VerifyCsmsAllowWildcards
2024-03-29 19:48:28.775132 [INFO] ocpp:OCPP201 :: Connecting to plain websocket at uri: ws://host.docker.internal/ws/cp001 with security profile: 1
2024-03-29 19:48:28.778314 [WARN] evse_security:E evse_security::GetKeyPairResult evse_security::EvseSecurity::get_key_pair_internal(evse_security::LeafCertificateType, evse_security::EncodingFormat) :: Could not find any key pair
2024-03-29 19:48:28.778442 [ERRO] evse_security:E evse_security::OCSPRequestDataList evse_security::EvseSecurity::get_v2g_ocsp_request_data() :: Could not get key pair, for v2g ocsp request!
2024-03-29 19:48:28.779216 [INFO] ocpp:OCPP201 :: OCPP client successfully connected to plain websocket server
2024-03-29 19:48:28.787497 [INFO] ocpp:OCPP201 :: Received BootNotificationResponse: {
"currentTime": "2024-03-29T19:48:28.786Z",
"interval": 300,
"status": "Accepted"
}
with messageId: 75f34dca-d0f3-4b10-ac48-01fb4bcbfbec
2024-03-29 19:48:28.818793 [INFO] ocpp:OCPP201 :: libocpp: Updating OCSP cache on 0 certificates
2024-03-29 19:48:28.818913 [INFO] ocpp:OCPP201 :: libocpp: Done updating OCSP cache
2024-03-29 19:49:26.846370 [INFO] car_simulator_1 :: { cmd: 'sleep', args: [ 1 ], exec: [Function (anonymous)] }
2024-03-29 19:49:28.197119 [INFO] car_simulator_1 :: {
cmd: 'iso_wait_slac_matched',
args: [],
exec: [Function (anonymous)]
}
2024-03-29 19:49:28.640558 [INFO] evse_manager_1: :: SYS Session logging started.
2024-03-29 19:49:28.640954 [INFO] evse_manager_1: :: EVSE IEC Session Started: EVConnected
2024-03-29 19:49:31.029010 [INFO] evse_manager_1: :: EVSE ISO SLAC MATCHED
2024-03-29 19:49:31.029551 [INFO] evse_manager_1: :: EVSE ISO D-LINK_READY (true)
2024-03-29 19:49:31.201259 [INFO] car_simulator_1 :: {
cmd: 'iso_start_v2g_session',
args: [ 'contract', 'ac_three_phase_core' ],
exec: [Function (anonymous)]
}
2024-03-29 19:49:31.245125 [INFO] car_simulator_1 :: { cmd: 'iso_wait_pwr_ready', args: [], exec: [Function (anonymous)] }
2024-03-29 19:49:33.786101 [INFO] iso15118_charge :: Received packet from [fe80::42:acff:fe13:4]:42455 with security 0x00 and protocol 0x00
2024-03-29 19:49:33.786282 [INFO] iso15118_charge :: SDP requested TLS, announcing TLS
2024-03-29 19:49:33.786419 [INFO] iso15118_charge :: sendto([fe80::42:acff:fe13:4]:42455) succeeded
2024-03-29 19:49:33.793436 [ERRO] iso15118_car pybind11_init_everestpy(pybind11::module_&)::<lambda(const std::string&)> :: SSLError when trying to connect to host fe80::42:acff:fe13:4 and port 64109
Traceback (most recent call last):
File "/workspace/dist/libexec/everest/modules/PyEvJosev/../../3rd_party/josev/iso15118/evcc/comm_session_handler.py", line 420, in start_comm_session
self.tcp_client = await TCPClient.create(
File "/workspace/dist/libexec/everest/modules/PyEvJosev/../../3rd_party/josev/iso15118/evcc/transport/tcp_client.py", line 43, in create
self = TCPClient(session_handler_queue, port, is_tls)
File "/workspace/dist/libexec/everest/modules/PyEvJosev/../../3rd_party/josev/iso15118/evcc/transport/tcp_client.py", line 30, in __init__
self.ssl_context = get_ssl_context(False, self.ciphersuites)
File "/workspace/dist/libexec/everest/modules/PyEvJosev/../../3rd_party/josev/iso15118/shared/security.py", line 184, in get_ssl_context
ssl_context.load_verify_locations(
ssl.SSLError: [X509: NO_CERTIFICATE_OR_CRL_FOUND] no certificate or crl found (_ssl.c:4149)
@activeshadow it is stuck in waiting for auth because the server crashed during auth. Please see the output that I got at https://github.com/EVerest/everest-demo/issues/35#issuecomment-2023858854
Note that this is with MaEVe. I would suggest reproducing this, and then seeing if the behavior is different with OCPP-CSMS
@activeshadow and @sahabulh it looks like both of you are still working on this. When you are done, can you please submit a PR of where you are so I can pick up from there? At least for me, working on the same task as others gets very confusing.
@activeshadow it is stuck in waiting for auth because the server crashed during auth. Please see the output that I got at #35 (comment)
Note that this is with MaEVe. I would suggest reproducing this, and then seeing if the behavior is different with OCPP-CSMS
@shankari my error looks to be different. It's not a program termination error, rather it's a certificate not found error. I'm looking into it now.
@shankari @activeshadow I am done. It is working with MaEVe + AC ISO 15118-2 + PnC. Did little hack to ignore OCSP temporarily. I also disabled CertificateInstallation. For details, check the Zulip topic linked previously. I will submit a PR as soon as possible.
@sahabulh I'm not able to reproduce but that's okay. I'll wait for your PR then go from there.
Can you explain why you chose to disable certificate installation in the EV Car module? It may be in the Zulip chat but would also be great to have it documented here (or in the PR) so we know where to go from there.
I'm seeing an issue with the EV Car module (Josev) not being able to find certificates. The V2G certificate it can't load is in the container, so I'm wondering if the prefix path Josev is using is not correct, but I didn't have a chance to run that to ground yet. I'm wondering if you disabling certificate installation gets around this, but if so I'd be curious as to why.
@sahabulh I'm not able to reproduce but that's okay. I'll wait for your PR then go from there.
I submitted the PR.
Can you explain why you chose to disable certificate installation in the EV Car module? It may be in the Zulip chat but would also be great to have it documented here (or in the PR) so we know where to go from there.
Craig was against it given that we have limited time before the virtual demo. MaEVe currently uses hubject to handle CertificateInstallation request. We don't want that. Which means additional work to make the local handling work.
I'm seeing an issue with the EV Car module (Josev) not being able to find certificates. The V2G certificate it can't load is in the container, so I'm wondering if the prefix path Josev is using is not correct, but I didn't have a chance to run that to ground yet. I'm wondering if you disabling certificate installation gets around this, but if so I'd be curious as to why.
What error are you getting? Can you please post a log?
The related PR is here: #38. It works fine in terms of the state machine, and we end up in the Charging
state, but the power drawn is zero (see screenshot below).
Charging, but no power drawn | Values coming from the power meter (powermeter/TotalKWattHr or powermeter/totakKw ) |
---|---|
I am not sure where those logs come from. I also checked the logs, and there is a negotiation that happens in the ISO protocol V2G PaymentServiceSelectionReq/Res
, then Transaction Started (0 kWh)
and then V2G ChargeParameterDiscoveryReq/Res
and then Event CarRequestedPower
(see attached HTML with EXI messages). But I can't find an online EXI decoder to understand what the messages represent.
Tried to install https://github.com/FlUxIuS/V2Gdecoder to decode EXI.
$ java -jar /tmp/V2Gdecoder.jar -s "..."
WARNING: sun.reflect.Reflection.getCallerClass is not supported. This will impact performance.
com.siemens.ct.exi.core.exceptions.EXIException: XML Schema document (./schemas/V2G_CI_MsgDef.xsd) not found.
at com.siemens.ct.exi.grammars.EXIContentModelBuilder.loadGrammars(EXIContentModelBuilder.java:161)
at com.siemens.ct.exi.grammars.EXIContentModelBuilder.loadGrammars(EXIContentModelBuilder.java:197)
Trying to compile instead resulted in
$ mvn compile assembly:single
[INFO] Scanning for projects...
[INFO]
[INFO] -----------------< com.fluxlus.V2Gdecoder:V2Gdecoder >------------------
[INFO] Building V2Gdecoder 1.0-SNAPSHOT
[INFO] from pom.xml
[INFO] --------------------------------[ jar ]---------------------------------
[WARNING] The POM for com.v2gclarity.risev2g:rise-v2g-shared:jar:1.2.6 is missing, no dependency information available
[WARNING] The POM for com.sun.xml.bind:jaxb-core:jar:2.2.11 is invalid, transitive dependencies (if any) will not be available, enable debug logging for more details
[WARNING] The POM for com.sun.xml.bind:jaxb-impl:jar:2.2.11 is invalid, transitive dependencies (if any) will not be available, enable debug logging for more details
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 0.367 s
[INFO] Finished at: 2024-04-01T22:41:20-07:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal on project V2Gdecoder: Could not resolve dependencies for project com.fluxlus.V2Gdecoder:V2Gdecoder:jar:1.0-SNAPSHOT: The following artifacts could not be resolved: com.v2gclarity.risev2g:rise-v2g-shared:jar:1.2.6 (absent): com.v2gclarity.risev2g:rise-v2g-shared:jar:1.2.6 was not found in file:///Users/kshankar/Desktop/data/joet-everest/V2Gdecoder/src/lib/ during a previous attempt. This failure was cached in the local repository and resolution is not reattempted until the update interval of project-local-repo has elapsed or updates are forced -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException
Trying to run the precomputed jar from the releases against the checked out schema from the repo...
That doesn't give an error, but it doesn't decode either. I just get a null
value as the result.
Let's try to incorporate the ISO 15118-2 decoder into this node-red
Piet told me here that there is an issue with the SIL which causes this. As we are seeing the ChargingStatusReq/Res
pairs going back and forth between the EV and EVSE, it means that ISO 15118 with PnC
is working. Maybe we can ignore this for now? Or ask them about their plan to fix it?
I think the priority now should be on the EonTi certs and make the OCSP response or revocation status checking work. I plan to work on this in the weekend and maybe create a new pull request. Is it okay?
@sahabulh we should file an issue for the SIL to be fixed. This is not a super-high priority, in fact, Piet told me that the related developer was out on vacation, but I don't want it to fall through the cracks.
@shankari Sorry, for the late response. Yes, we should file an issue. Please let me know how you want us to do that.
On a different note, do you want to close this issue and create another one for discussing the problems regarding the EonTi certs? I tested with the wrongly named CSMS cert and it indeed created the same error. So, I guess it is the FQDN
and CN
issue. So, what should we do now? I think we will have to ask EonTi to create a CSMS cert with the FQDN
(host.docker.internal
) in the CN
. It will make the certificate not usable when the FQDN
is different but I think that is how it is meant to be. Please check OCPP 2.0.1 Part 2 Specification Page 27 Requirement A00.FR.510
. I think EVerest is validating this requirement but not the A00.FR.511
requirement because we have been using the same cert for both the CSMS server and client.
About how I tested it, I changed nothing except for the CSMS_LEAF.pem
and the CSMS_LEAF.key
files. I just regenerated these using the old CPO SUB CA 2
where the CN
is CSMSCert
rather than host.docker.internal
.
@sahabulh
You can put in the details from https://github.com/EVerest/everest-demo/issues/35#issuecomment-2062619392 and this comment into the new issue.
wrt next steps on the EonTI issue, I would suggest asking EonTI to generate certs with the modified CN host.docker.internal
to verify that this is the only issue.
Having done that, you should notify Craig, Ryan and EonTI (please make sure to cc me as well). This should be part of Craig's upcoming work around best practices for PKI infrastructure.
@shankari Joshua had opened an issue for testing EonTi certs, so rather than creating a new one, I am just reusing that issue.
I have also sent an email to Francis requesting a new CSMS cert with host.docker.internal
as the CN
. You are already included there.
Having done that, you should notify Craig, Ryan and EonTI (please make sure to cc me as well). This should be part of Craig's upcoming work around best practices for PKI infrastructure.
I didn't understand you here fully. What should I say?
The EVerest team has enabled PnC for OCPP 201 https://github.com/EVerest/everest-core/pull/588
They have also added documentation on how to configure the EvseSecurity module https://github.com/EVerest/everest-core/blob/main/modules/EvseSecurity/doc.rst and a simple HOWTO guide https://github.com/EVerest/EVerest/blob/main/docs/tutorials/how_to_plug_and_charge/index.rst
More details are at: https://github.com/EVerest/EVerest/commit/03f1039724653a7272b03850f4df8c861810684e#diff-c18cbe481f4e2f2cc3c9c5992561e64464244edcbcda0c2d08bbb0e0987ef23a
Note that the simple guide uses a simple CSMS, created in the EVerest org, that is based on the MobilityHouse package and the
CertificateInstallationResponse
from josev.This issue will track the steps required to enable PnC, first with the toy CSMS and then with a real CSMS such as MaEVe
@jhoshiko @activeshadow @sahabulh for visibility and collaboration