search

EVerest / everest-demo

EVerest demo: Dockerized demo with software in the loop simulation
Apache License 2.0
11 stars 13 forks source link

🚩 Enable PnC with OCPP 201 #35

Open shankari opened 3 months ago

shankari commented 3 months ago

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

shankari commented 3 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

shankari commented 3 months ago

@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

shankari commented 3 months ago

Here are the errors that I currently see with the EVerest + MaEVe MRE

AC 3ph 16A - charges ``` 2024-03-27 19:29:58.535984 [INFO] car_simulator_1 :: { cmd: 'sleep', args: [ 1 ], exec: [Function (anonymous)] } 2024-03-27 19:29:59.787339 [INFO] car_simulator_1 :: { cmd: 'iec_wait_pwr_ready', args: [], exec: [Function (anonymous)] } 2024-03-27 19:30:00.045576 [INFO] evse_manager_1: :: SYS Session logging started. 2024-03-27 19:30:00.045819 [INFO] evse_manager_1: :: EVSE IEC Session Started: EVConnected 2024-03-27 19:30:00.904600 [INFO] token_provider_ :: Publishing new dummy token: {"id_token":{"value":"DEADBEEF","type":"ISO14443"},"authorization_type":"RFID","prevalidated":false,"connectors":[1]} 2024-03-27 19:30:00.905934 [INFO] auth:Auth :: Received new token: { "authorization_type": "RFID", "connectors": [ 1 ], "id_token": { "type": "ISO14443", "value": "DEADBEEF" }, "prevalidated": false } 2024-03-27 19:30:00.949437 [INFO] ocpp:OCPP201 :: Found invalid entry in AuthCache: Sending new request 2024-03-27 19:30:00.977911 [INFO] auth:Auth :: Providing authorization to connector#1 2024-03-27 19:30:01.021761 [INFO] auth:Auth :: Result for token: DEADBEEF: ACCEPTED 2024-03-27 19:30:01.051450 [INFO] evse_manager_1: :: EVSE IEC EIM Authorization received 2024-03-27 19:30:01.052224 [INFO] evse_manager_1: :: EVSE IEC Transaction Started (0 kWh) 2024-03-27 19:30:01.053450 [INFO] evse_manager_1: :: EVSE IEC AC mode, HLC disabled. We are in X1 so we can go directly to nominal PWM. 2024-03-27 19:30:01.054361 [INFO] evse_manager_1: :: EVSE IEC Charger state: Wait for Auth->PrepareCharging 2024-03-27 19:30:01.055537 [INFO] evse_manager_1: :: EVSE IEC Set PWM On (33.33333432674408%) took 0 ms 2024-03-27 19:30:01.299438 [INFO] car_simulator_1 :: { cmd: 'sleep', args: [ 1 ], exec: [Function (anonymous)] } 2024-03-27 19:30:02.552925 [INFO] car_simulator_1 :: { cmd: 'draw_power_regulated', args: [ 16, 3 ], exec: [Function (anonymous)] } 2024-03-27 19:30:02.553519 [INFO] car_simulator_1 :: { cmd: 'sleep', args: [ 36000 ], exec: [Function (anonymous)] } 2024-03-27 19:30:02.762512 [INFO] evse_manager_1: :: CAR IEC Event CarRequestedPower 2024-03-27 19:30:02.764185 [INFO] evse_manager_1: :: EVSE IEC Charger state: PrepareCharging->Charging 2024-03-27 19:30:03.011993 [INFO] evse_manager_1: :: EVSE IEC Event PowerOn ```
AC ISO 15118-2 (stuck in PrepareCharging because EV did not transition to state C) ``` 2024-03-27 19:31:59.063549 [INFO] car_simulator_1 :: { cmd: 'sleep', args: [ 1 ], exec: [Function (anonymous)] } 2024-03-27 19:32:00.434078 [INFO] car_simulator_1 :: { cmd: 'iso_wait_slac_matched', args: [], exec: [Function (anonymous)] } 2024-03-27 19:32:00.707643 [INFO] evse_manager_1: :: SYS Session logging started. 2024-03-27 19:32:00.708011 [INFO] evse_manager_1: :: EVSE IEC Session Started: EVConnected 2024-03-27 19:32:02.211203 [INFO] evse_security:E :: TPM Key: false 2024-03-27 19:32:02.221328 [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:32:02.247820 [INFO] ocpp:OCPP201 :: libocpp: Updating OCSP cache on 2 certificates 2024-03-27 19:32:02.353932 [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-27 19:32:02.375542 [INFO] token_provider_ :: Publishing new dummy token: {"id_token":{"value":"DEADBEEF","type":"ISO14443"},"authorization_type":"RFID","prevalidated":false,"connectors":[1]} 2024-03-27 19:32:02.377216 [INFO] auth:Auth :: Received new token: { "authorization_type": "RFID", "connectors": [ 1 ], "id_token": { "type": "ISO14443", "value": "DEADBEEF" }, "prevalidated": false } 2024-03-27 19:32:02.380813 [INFO] ocpp:OCPP201 :: Found invalid entry in AuthCache: Sending new request 2024-03-27 19:32:02.420947 [INFO] auth:Auth :: Providing authorization to connector#1 2024-03-27 19:32:02.463764 [INFO] auth:Auth :: Result for token: DEADBEEF: ACCEPTED 2024-03-27 19:32:02.513495 [INFO] evse_manager_1: :: EVSE IEC EIM Authorization received 2024-03-27 19:32:02.513925 [INFO] evse_manager_1: :: EVSE IEC Transaction Started (0 kWh) 2024-03-27 19:32:02.514674 [INFO] evse_manager_1: :: EVSE IEC AC mode, HLC disabled. We are in X1 so we can go directly to nominal PWM. 2024-03-27 19:32:02.515188 [INFO] evse_manager_1: :: EVSE IEC Charger state: Wait for Auth->PrepareCharging 2024-03-27 19:32:02.516020 [INFO] evse_manager_1: :: EVSE IEC Set PWM On (33.33333432674408%) took 0 ms 2024-03-27 19:32:32.584624 [INFO] evse_manager_1: :: EVSE IEC EV did not transition to state C, trying one legacy wakeup according to IEC61851-1 A.5.3 2024-03-27 19:32:32.585052 [INFO] evse_manager_1: :: EVSE IEC Charger state: PrepareCharging->T_step_EF 2024-03-27 19:32:32.585289 [INFO] evse_manager_1: :: EVSE IEC Enter T_step_EF 2024-03-27 19:32:32.585509 [INFO] evse_manager_1: :: EVSE IEC Set PWM F ```
DC ISO 15118-2 (same, stuck in PrepareCharging because EV did not transition to state C) ``` 2024-03-27 19:42:21.966157 [INFO] evse_manager_1: :: EVSE IEC EIM Authorization received 2024-03-27 19:42:21.966727 [INFO] evse_manager_1: :: EVSE IEC Transaction Started (0 kWh) 2024-03-27 19:42:21.967707 [INFO] evse_manager_1: :: EVSE IEC AC mode, HLC disabled. We are in X1 so we can go directly to nominal PWM. 2024-03-27 19:42:21.968182 [INFO] evse_manager_1: :: EVSE IEC Charger state: Wait for Auth->PrepareCharging 2024-03-27 19:42:21.969481 [INFO] evse_manager_1: :: EVSE IEC Set PWM On (33.33333432674408%) took 0 ms 2024-03-27 19:42:21.969878 [INFO] auth:Auth :: Result for token: DEADBEEF: ACCEPTED 2024-03-27 19:42:52.041236 [INFO] evse_manager_1: :: EVSE IEC EV did not transition to state C, trying one legacy wakeup according to IEC61851-1 A.5.3 2024-03-27 19:42:52.041565 [INFO] evse_manager_1: :: EVSE IEC Charger state: PrepareCharging->T_step_EF 2024-03-27 19:42:52.041953 [INFO] evse_manager_1: :: EVSE IEC Enter T_step_EF 2024-03-27 19:42:52.042342 [INFO] evse_manager_1: :: EVSE IEC Set PWM F 2024-03-27 19:42:52.568280 [INFO] evse_security:E :: TPM Key: false 2024-03-27 19:42:52.577468 [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:42:52.605590 [INFO] ocpp:OCPP201 :: libocpp: Updating OCSP cache on 2 certificates 2024-03-27 19:42:52.722513 [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-27 19:42:56.139256 [INFO] evse_manager_1: :: EVSE IEC Exit T_step_EF 2024-03-27 19:42:56.139610 [INFO] evse_manager_1: :: EVSE IEC Set PWM On (33.33333432674408%) took 0 ms 2024-03-27 19:42:56.183460 [INFO] evse_manager_1: :: EVSE IEC Charger state: T_step_EF->PrepareCharging 2024-03-27 19:42:56.364121 [INFO] evse_manager_1: :: CAR IEC Event CarRequestedStopPower 2024-03-27 19:42:56.364550 [INFO] evse_manager_1: :: CAR IEC Event CarPluggedIn 2024-03-27 19:42:56.364889 [INFO] evse_manager_1: :: CAR IEC Event EFtoBCD ```
Checking if it is OCPP by using the DC ISO 15118-2 demo (works) ``` $ bash demo-iso15118-2-dc.sh 2024-03-27 12:36:40 2024-03-27 19:36:40.004714 [INFO] iso15118_charge :: Protocol negotiation was successful. Selected protocol is ISO15118 2024-03-27 12:36:40 2024-03-27 19:36:40.046311 [INFO] evse_manager:Ev :: CAR ISO V2G SupportedAppProtocolReq 2024-03-27 12:36:40 2024-03-27 19:36:40.088060 [INFO] evse_manager:Ev :: EVSE ISO V2G SupportedAppProtocolRes 2024-03-27 12:36:41 2024-03-27 12:36:41 2024-03-27 19:36:41.221266 [INFO] iso15118_charge :: SessionSetupReq.EVCCID: 02:42:AC:1F:00:03 2024-03-27 12:36:41 2024-03-27 12:36:41 2024-03-27 19:36:41.221395 [INFO] iso15118_charge :: No session_id found or not equal to the id from the preceding v2g session. Generating random session id. 2024-03-27 12:36:41 2024-03-27 12:36:41 2024-03-27 19:36:41.221461 [INFO] iso15118_charge :: Created new session with id 0x4170189213534930141 2024-03-27 12:36:41 2024-03-27 19:36:41.224595 [INFO] evse_manager:Ev :: CAR ISO V2G SessionSetupReq 2024-03-27 12:36:41 2024-03-27 19:36:41.304837 [INFO] evse_manager:Ev :: EVSE ISO V2G SessionSetupRes 2024-03-27 12:36:42 2024-03-27 19:36:42.220400 [INFO] evse_manager:Ev :: CAR ISO V2G ServiceDiscoveryReq 2024-03-27 12:36:42 2024-03-27 19:36:42.283853 [INFO] evse_manager:Ev :: EVSE ISO V2G ServiceDiscoveryRes 2024-03-27 12:36:43 2024-03-27 12:36:43 2024-03-27 19:36:43.099552 [INFO] iso15118_charge :: SelectedPaymentOption: ExternalPayment 2024-03-27 12:36:43 2024-03-27 19:36:43.142218 [INFO] evse_manager:Ev :: CAR ISO V2G PaymentServiceSelectionReq 2024-03-27 12:36:43 2024-03-27 19:36:43.220091 [INFO] evse_manager:Ev :: EVSE ISO V2G PaymentServiceSelectionRes 2024-03-27 12:36:44 2024-03-27 19:36:44.047467 [INFO] evse_manager:Ev :: CAR ISO V2G AuthorizationReq 2024-03-27 12:36:44 2024-03-27 19:36:44.099166 [INFO] evse_manager:Ev :: EVSE ISO V2G AuthorizationRes 2024-03-27 12:36:44 2024-03-27 19:36:44.816378 [INFO] evse_manager:Ev :: CAR ISO V2G AuthorizationReq 2024-03-27 12:36:44 2024-03-27 19:36:44.922486 [INFO] evse_manager:Ev :: EVSE ISO V2G AuthorizationRes 2024-03-27 12:36:45 2024-03-27 12:36:45 2024-03-27 19:36:45.593423 [INFO] iso15118_charge :: Parameter-phase started 2024-03-27 12:36:45 2024-03-27 12:36:45 2024-03-27 19:36:45.595806 [INFO] iso15118_charge :: Selected energy transfer mode: DC_extended 2024-03-27 12:36:45 2024-03-27 19:36:45.803719 [INFO] evse_manager:Ev :: CAR ISO V2G ChargeParameterDiscoveryReq 2024-03-27 12:36:45 2024-03-27 19:36:45.816104 [INFO] evse_manager:Ev :: EVSE ISO V2G ChargeParameterDiscoveryRes 2024-03-27 12:36:45 2024-03-27 19:36:45.938356 [INFO] car_simulator:J :: { cmd: 'sleep', args: [ 36000 ], exec: [Function (anonymous)] } 2024-03-27 12:36:46 2024-03-27 19:36:46.130199 [INFO] evse_manager:Ev :: CAR IEC Event CarRequestedPower 2024-03-27 12:36:46 2024-03-27 19:36:46.401503 [INFO] evse_manager:Ev :: EVSE ISO Start cable check... 2024-03-27 12:36:46 2024-03-27 19:36:46.401896 [INFO] evse_manager:Ev :: CAR ISO DC HLC Close contactor (in CableCheck) 2024-03-27 12:36:46 2024-03-27 19:36:46.401911 [INFO] evse_manager:Ev :: CAR ISO V2G CableCheckReq 2024-03-27 12:36:46 2024-03-27 19:36:46.497247 [INFO] evse_manager:Ev :: EVSE ISO V2G CableCheckRes 2024-03-27 12:36:46 2024-03-27 19:36:46.676449 [INFO] evse_manager:Ev :: EVSE IEC Event PowerOn 2024-03-27 12:36:46 2024-03-27 19:36:46.703097 [INFO] evse_manager:Ev :: EVSE IEC DC power supply set: 500V/2A, requested was 500V/2A. 2024-03-27 12:36:46 2024-03-27 19:36:46.774869 [INFO] evse_manager:Ev :: EVSE IEC DC power supply: switch ON called 2024-03-27 12:36:46 2024-03-27 19:36:46.819311 [INFO] imd:IMDSimulato :: Started simulated isolation monitoring with 1000 ms interval 2024-03-27 12:36:46 2024-03-27 19:36:46.860844 [INFO] evse_manager:Ev :: EVSE IEC Isolation measurement R_F 900000. 2024-03-27 12:36:47 2024-03-27 19:36:47.223966 [INFO] evse_manager:Ev :: CAR ISO V2G CableCheckReq 2024-03-27 12:36:47 2024-03-27 19:36:47.288295 [INFO] evse_manager:Ev :: EVSE ISO V2G CableCheckRes 2024-03-27 12:36:47 2024-03-27 19:36:47.520382 [INFO] evse_manager:Ev :: EVSE ISO Change HLC Limits: 22080W/200A, target_voltage 0, actual_voltage 500, hack_bpt false 2024-03-27 12:36:47 2024-03-27 19:36:47.837642 [INFO] evse_manager:Ev :: EVSE IEC Isolation measurement R_F 900000. 2024-03-27 12:36:47 2024-03-27 19:36:47.838234 [INFO] evse_manager:Ev :: EVSE IEC DC power supply set: 500V/2A, requested was 500V/2A. 2024-03-27 12:36:47 2024-03-27 19:36:47.881679 [INFO] evse_manager:Ev :: EVSE IEC Isolation measurement Ok R_F 900000. 2024-03-27 12:36:48 2024-03-27 19:36:48.008372 [INFO] evse_manager:Ev :: CAR ISO V2G CableCheckReq 2024-03-27 12:36:48 2024-03-27 19:36:48.115195 [INFO] evse_manager:Ev :: EVSE ISO V2G CableCheckRes 2024-03-27 12:36:48 2024-03-27 19:36:48.793493 [INFO] evse_manager:Ev :: CAR ISO V2G CableCheckReq 2024-03-27 12:36:48 2024-03-27 19:36:48.837725 [INFO] evse_manager:Ev :: EVSE IEC Isolation measurement R_F 900000. 2024-03-27 12:36:48 2024-03-27 19:36:48.892130 [INFO] evse_manager:Ev :: EVSE ISO V2G CableCheckRes 2024-03-27 12:36:49 2024-03-27 12:36:49 2024-03-27 19:36:49.513400 [INFO] iso15118_charge :: Precharge-phase started 2024-03-27 12:36:49 2024-03-27 19:36:49.515884 [INFO] evse_manager:Ev :: EVSE IEC DC power supply set: 400V/1A, requested was 400V/0A. 2024-03-27 12:36:49 2024-03-27 19:36:49.603316 [INFO] evse_manager:Ev :: CAR ISO V2G PreChargeReq 2024-03-27 12:36:49 2024-03-27 19:36:49.648064 [INFO] evse_manager:Ev :: EVSE ISO V2G PreChargeRes 2024-03-27 12:36:49 2024-03-27 19:36:49.717331 [INFO] evse_manager:Ev :: EVSE ISO Change HLC Limits: 22080W/44.16A, target_voltage 400, actual_voltage 500, hack_bpt false 2024-03-27 12:36:49 2024-03-27 19:36:49.775247 [INFO] evse_manager:Ev :: EVSE IEC DC power supply set: 400V/1A, requested was 400V/0A. 2024-03-27 12:36:49 2024-03-27 19:36:49.876117 [INFO] evse_manager:Ev :: EVSE IEC Isolation measurement R_F 900000. 2024-03-27 12:36:50 2024-03-27 19:36:50.380651 [INFO] evse_manager:Ev :: CAR ISO V2G PreChargeReq 2024-03-27 12:36:50 2024-03-27 19:36:50.478065 [INFO] evse_manager:Ev :: EVSE ISO V2G PreChargeRes 2024-03-27 12:36:50 2024-03-27 19:36:50.876329 [INFO] evse_manager:Ev :: EVSE IEC Isolation measurement R_F 900000. 2024-03-27 12:36:50 2024-03-27 19:36:50.967311 [INFO] evse_manager:Ev :: EVSE ISO Change HLC Limits: 22080W/55.2A, target_voltage 400, actual_voltage 400, hack_bpt false 2024-03-27 12:36:51 2024-03-27 19:36:51.051125 [INFO] evse_manager:Ev :: EVSE IEC DC power supply set: 400V/1A, requested was 400V/0A. 2024-03-27 12:36:51 2024-03-27 19:36:51.228362 [INFO] evse_manager:Ev :: CAR ISO V2G PowerDeliveryReq 2024-03-27 12:36:51 2024-03-27 19:36:51.274959 [INFO] evse_manager:Ev :: EVSE ISO V2G PowerDeliveryRes 2024-03-27 12:36:51 2024-03-27 19:36:51.689093 [INFO] evse_manager:Ev :: EVSE IEC DC power supply set: 400V/20A, requested was 400V/20A. 2024-03-27 12:36:51 2024-03-27 19:36:51.722719 [INFO] evse_manager:Ev :: EVSE IEC Charger state: PrepareCharging->Charging 2024-03-27 12:36:51 2024-03-27 19:36:51.766659 [INFO] evse_manager:Ev :: CAR ISO V2G CurrentDemandReq 2024-03-27 12:36:51 2024-03-27 19:36:51.784738 [INFO] evse_manager:Ev :: EVSE ISO V2G CurrentDemandRes 2024-03-27 12:36:51 2024-03-27 19:36:51.876850 [INFO] evse_manager:Ev :: EVSE IEC Isolation measurement R_F 900000. 2024-03-27 12:36:52 2024-03-27 19:36:52.186964 [INFO] evse_manager:Ev :: CAR ISO V2G CurrentDemandReq 2024-03-27 12:36:52 2024-03-27 19:36:52.255803 [INFO] evse_manager:Ev :: EVSE ISO V2G CurrentDemandRes 2024-03-27 12:36:52 2024-03-27 19:36:52.646836 [INFO] evse_manager:Ev :: CAR ISO V2G CurrentDemandReq ```

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

shankari commented 3 months ago

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

sahabulh commented 3 months ago

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?

shankari commented 3 months ago

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

sahabulh commented 3 months ago

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 commented 3 months ago

@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?

shankari commented 3 months ago

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.

sahabulh commented 3 months ago

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.
sahabulh commented 3 months ago

Yep, using the AC ISO 15118-2 Plug&Charge from the dropdown menu, I got the same certificate installation error reported before.

sahabulh commented 3 months ago

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.

shankari commented 3 months ago

My recommendation would be the following:

  1. 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
  2. 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

sahabulh commented 3 months ago

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?

shankari commented 3 months ago

@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.

sahabulh commented 3 months ago

My recommendation would be the following:

  1. 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
  2. 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?

shankari commented 3 months ago

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.

sahabulh commented 3 months ago

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?

shankari commented 3 months ago

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

shankari commented 3 months ago

@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

sahabulh commented 3 months ago

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: ``` 2024-03-29 00:47:27.840633 [INFO] ocpp:OCPP201 :: OCPP certificates path: /workspace/dist/etc/everest/certs 2024-03-29 00:47:27.929207 [INFO] ocpp:OCPP201 :: Established connection to device model database successfully: "/workspace/dist/share/everest/modules/OCPP201/device_model_storage.db" 2024-03-29 00:47:27.986398 [INFO] ocpp:OCPP201 :: Successfully retrieved Device Model from DeviceModelStorage 2024-03-29 00:47:28.078463 [INFO] ocpp:OCPP201 :: Logging OCPP messages to log file: /tmp/everest_ocpp_logs/2024-03-29T00:47:28.078Z.log 2024-03-29 00:47:28.078544 [INFO] ocpp:OCPP201 :: Logging OCPP messages to html file: /tmp/everest_ocpp_logs/2024-03-29T00:47:28.078Z.html 2024-03-29 00:47:28.078574 [INFO] ocpp:OCPP201 :: Logging SecurityEvents to file 2024-03-29 00:47:28.079071 [INFO] ocpp:OCPP201 :: TxStartPoint from device model: PowerPathClosed 2024-03-29 00:47:28.132853 [INFO] evse_manager_2: :: Ignoring BSP Event, BSP is not enabled yet.2024-03-29 00:47:28.132853 [INFO] evse_manager_1: :: Ignoring BSP Event, BSP is not enabled yet. 2024-03-29 00:47:28.137394 [INFO] evse_manager_2: :: Max AC hardware capabilities: 32A/3ph 2024-03-29 00:47:28.277123 [INFO] evse_manager_2: :: 🌀🌀🌀 Ready to start charging 🌀🌀🌀 2024-03-29 00:47:28.364811 [INFO] ocpp:OCPP201 :: EVSE 2 ready. 2024-03-29 00:47:28.372706 [INFO] evse_manager_1: :: Max AC hardware capabilities: 32A/3ph 2024-03-29 00:47:28.424956 [INFO] evse_manager_1: :: AC HLC mode enabled. 2024-03-29 00:47:28.605218 [INFO] evse_manager_1: :: 🌀🌀🌀 Ready to start charging 🌀🌀🌀 2024-03-29 00:47:28.649516 [INFO] ocpp:OCPP201 :: EVSE 1 ready. 2024-03-29 00:47:28.649681 [INFO] ocpp:OCPP201 :: All EVSE ready. Starting OCPP2.0.1 service 2024-03-29 00:47:28.931689 [INFO] ocpp:OCPP201 :: Connecting to plain websocket at uri: ws://localhost:9000/cp001 with security profile: 1 2024-03-29 00:47:28.933941 [ERRO] ocpp:OCPP201 void ocpp::WebsocketBase::log_on_fail(const std::error_code&, const boost::system::error_code&, int) :: Failed to connect to websocket server, error_code: 2, reason: Underlying Transport Error, HTTP response code: 0, category: websocketpp.transport, transport error code: 0, Transport error category: system 2024-03-29 00:47:28.934256 [INFO] ocpp:OCPP201 :: Reconnecting in: 3000ms, attempt: 1 2024-03-29 00:47:28.995027 [INFO] evse_security:E :: TPM Key: false 2024-03-29 00:47:29.002625 [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-29 00:47:29.029026 [INFO] ocpp:OCPP201 :: libocpp: Updating OCSP cache on 2 certificates 2024-03-29 00:47:29.029227 [WARN] ocpp:OCPP201 void ocpp::v201::OcspUpdater::updater_thread_loop() :: libocpp: Got unexpected message type from CSMS, expected: GetCertificateStatusResponse, got: InternalError, will retry. 2024-03-29 00:47:31.936503 [INFO] ocpp:OCPP201 :: Reconnecting to plain websocket at uri: ws://localhost:9000/cp001 with security profile: 1 2024-03-29 00:47:31.938174 [ERRO] ocpp:OCPP201 void ocpp::WebsocketBase::log_on_fail(const std::error_code&, const boost::system::error_code&, int) :: Failed to connect to websocket server, error_code: 2, reason: Underlying Transport Error, HTTP response code: 0, category: websocketpp.transport, transport error code: 0, Transport error category: system 2024-03-29 00:47:31.938391 [INFO] ocpp:OCPP201 :: Reconnecting in: 7000ms, attempt: 2 2024-03-29 00:47:34.032144 [INFO] evse_security:E :: TPM Key: false 2024-03-29 00:47:34.036821 [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-29 00:47:34.072912 [INFO] ocpp:OCPP201 :: libocpp: Updating OCSP cache on 2 certificates 2024-03-29 00:47:34.073046 [WARN] ocpp:OCPP201 void ocpp::v201::OcspUpdater::updater_thread_loop() :: libocpp: Got unexpected message type from CSMS, expected: GetCertificateStatusResponse, got: InternalError, will retry. ```

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.

sahabulh commented 3 months ago

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.

sahabulh commented 3 months ago

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%.

sahabulh commented 3 months ago

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.
activeshadow commented 3 months ago

@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?

shankari commented 3 months ago

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

sahabulh commented 3 months ago

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.

sahabulh commented 3 months ago

@shankari @activeshadow I am talking with Cornelius here in case you want to participate or just observe.

activeshadow commented 3 months ago

@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?

shankari commented 3 months ago

@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

activeshadow commented 3 months ago

@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.

shankari commented 3 months ago

select the PnC option from the dropdown below Connector 1

activeshadow commented 3 months ago

@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.

activeshadow commented 3 months ago

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)
shankari commented 3 months ago

@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

shankari commented 3 months ago

@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 commented 3 months ago

@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.

sahabulh commented 3 months ago

@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.

activeshadow commented 3 months ago

@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 commented 3 months ago

@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?

shankari commented 3 months ago

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)
Screenshot 2024-04-01 at 10 19 05 PM Screenshot 2024-04-01 at 10 20 11 PM

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.

ISO15118.html.gz OCPP201.html.gz

shankari commented 3 months ago

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...

shankari commented 3 months ago

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

sahabulh commented 3 months ago

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?

shankari commented 3 months ago

@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.

sahabulh commented 2 months ago

@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.

sahabulh commented 2 months ago

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.

shankari commented 2 months ago

@sahabulh

  1. Yes, please file an issue for the SIL to be fixed
  2. Yes, please create a new issue for the EonTI certs

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.

sahabulh commented 2 months ago

@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.

sahabulh commented 2 months ago

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?