Citrine demo that is broken but downloads and runs all docker contain…

[shankari]

…ers successfully

[shankari]

The failure is because Citrine needs node 18, and I have node 13 installed by default. But for the one-line demo, we can't assume that the users have node 18 installed. We should also not upgrade their default version of node without letting them know. We should use a docker container for the citrine build as well, not just for the citrine dependencies.

[shankari]

@louisg1337 I switched this to port 8081 and am able to connect the station to the CSMS

2024-05-27 18:00:17.998582 [INFO] ocpp:OCPP201     :: OCPP client successfully connected to plain websocket server
2024-05-27 18:00:18.033248 [INFO] ocpp:OCPP201     :: libocpp: Updating OCSP cache on 0 certificates
2024-05-27 18:00:18.033443 [INFO] ocpp:OCPP201     :: libocpp: Done updating OCSP cache
2024-05-27 18:00:18.087564 [INFO] ocpp:OCPP201     :: Received BootNotificationResponse: {
    "currentTime": "2024-05-27T18:00:18.079Z",
    "interval": 60,
    "status": "Accepted"
}
with messageId: 6debe3d6-0e00-4d41-9277-7f7770924583

However, when I try to authenticate, the token is not registered. @louisg1337 can you see how to configure the token?

2024-05-27 18:08:23.748918 [INFO] auth:Auth        :: Received new token: {
    "authorization_type": "RFID",
    "connectors": [
        1
    ],
    "id_token": {
        "type": "ISO14443",
        "value": "DEADBEEF"
    },
    "prevalidated": false
}
2024-05-27 18:08:23.811961 [INFO] auth:Auth        :: Result for token: DEADBEEF: REJECTED

[shankari]

I interpret the instructions here https://github.com/EVerest/everest-demo/issues/44#issuecomment-2133897049 as using the "Monitoring" section of the API.

You can set this VariableAttribute on the CSMS side using the Variable Attribute CRUD endpoints on the Monitoring module. You can set this VariableAttribute on the Charging Station side using the SetVariables message, which can be sent from CitrineOS using the Monitoring module’s message API.

I used the Swagger API to make a GET for cp001 and got

curl -X 'GET' \
  'http://localhost:8080/data/monitoring/variableAttribute?stationId=cp001' \
  -H 'accept: */*'

And got this response

``` [ { "id": 2, "stationId": "cp001", "type": "Actual", "dataType": "boolean", "value": "true", "mutability": "ReadOnly", "persistent": false, "constant": false, "variableId": 2, "componentId": 1, "evseDatabaseId": null, "createdAt": "2024-05-27T18:00:18.136Z", "updatedAt": "2024-05-27T18:00:18.136Z", "bootConfigId": null, "component": { "id": 1, "name": "ChargingStation", "instance": null, "evseDatabaseId": null, "createdAt": "2024-05-27T18:00:18.088Z", "updatedAt": "2024-05-27T18:00:18.088Z", "evse": null }, "variable": { "id": 2, "name": "Available", "instance": null, "createdAt": "2024-05-27T18:00:18.132Z", "updatedAt": "2024-05-27T18:00:18.132Z", "variableCharacteristics": null }, "statuses": [] }, { "id": 5, "stationId": "cp001", "type": "Actual", "dataType": null, "value": "", "mutability": "ReadOnly", "persistent": true, "constant": true, "variableId": 5, "componentId": 1, "evseDatabaseId": null, "createdAt": "2024-05-27T18:00:18.169Z", "updatedAt": "2024-05-27T18:00:18.169Z", "bootConfigId": null, "component": { "id": 1, "name": "ChargingStation", "instance": null, "evseDatabaseId": null, "createdAt": "2024-05-27T18:00:18.088Z", "updatedAt": "2024-05-27T18:00:18.088Z", "evse": null }, "variable": { "id": 5, "name": "VendorName", "instance": null, "createdAt": "2024-05-27T18:00:18.164Z", "updatedAt": "2024-05-27T18:00:18.164Z", "variableCharacteristics": null }, "statuses": [] }, { "id": 4, "stationId": "cp001", "type": "Actual", "dataType": null, "value": "", "mutability": "ReadOnly", "persistent": true, "constant": true, "variableId": 4, "componentId": 1, "evseDatabaseId": null, "createdAt": "2024-05-27T18:00:18.157Z", "updatedAt": "2024-05-27T18:00:18.157Z", "bootConfigId": null, "component": { "id": 1, "name": "ChargingStation", "instance": null, "evseDatabaseId": null, "createdAt": "2024-05-27T18:00:18.088Z", "updatedAt": "2024-05-27T18:00:18.088Z", "evse": null }, "variable": { "id": 4, "name": "Model", "instance": null, "createdAt": "2024-05-27T18:00:18.149Z", "updatedAt": "2024-05-27T18:00:18.149Z", "variableCharacteristics": null }, "statuses": [] }, { "id": 1, "stationId": "cp001", "type": "Actual", "dataType": "boolean", "value": "true", "mutability": "ReadOnly", "persistent": false, "constant": false, "variableId": 1, "componentId": 1, "evseDatabaseId": null, "createdAt": "2024-05-27T18:00:18.112Z", "updatedAt": "2024-05-27T18:00:18.112Z", "bootConfigId": null, "component": { "id": 1, "name": "ChargingStation", "instance": null, "evseDatabaseId": null, "createdAt": "2024-05-27T18:00:18.088Z", "updatedAt": "2024-05-27T18:00:18.088Z", "evse": null }, "variable": { "id": 1, "name": "Present", "instance": null, "createdAt": "2024-05-27T18:00:18.109Z", "updatedAt": "2024-05-27T18:00:18.109Z", "variableCharacteristics": null }, "statuses": [] }, { "id": 3, "stationId": "cp001", "type": "Actual", "dataType": "boolean", "value": "true", "mutability": "ReadOnly", "persistent": false, "constant": false, "variableId": 3, "componentId": 1, "evseDatabaseId": null, "createdAt": "2024-05-27T18:00:18.144Z", "updatedAt": "2024-05-27T18:00:18.144Z", "bootConfigId": null, "component": { "id": 1, "name": "ChargingStation", "instance": null, "evseDatabaseId": null, "createdAt": "2024-05-27T18:00:18.088Z", "updatedAt": "2024-05-27T18:00:18.088Z", "evse": null }, "variable": { "id": 3, "name": "Enabled", "instance": null, "createdAt": "2024-05-27T18:00:18.142Z", "updatedAt": "2024-05-27T18:00:18.142Z", "variableCharacteristics": null }, "statuses": [] } ] ```

There is no SecurityCtrlr component listed. I guess we try to set one using the POST version of that command. Let's try with BasicAuth and see if it creates the station automatically for that case as well.

[shankari]

I think we can pause this for now since Citrine does not support Security Profile 3 anyway. But I think that if/when we get back to this, it will work.

[shankari]

For the record, I figured out an option to add tokens (this is using the DirectUS admin UI at http://localhost:8055 We can add variable attributes and tokens. We should be able to figure out the API calls to set the variable attributes and tokens by seeing what calls the admin UI generates.

[shankari]

Alas, I can't figure out where to put in the token string through the UI. But we are even closer!

[shankari]

I am not able to edit this branch directly, so I have added the 3 line patch here for the record. get_the_connection_to_work_without_auth.patch

Testing done: https://github.com/EVerest/everest-demo/pull/45#issuecomment-2133901916

[ChrisWeissmann]

Hi @shankari and @louisg1337 , for some local testing on my end I had forked this repo and run it with citrine. To add a location and password I created a small init script. See here: https://github.com/ChrisWeissmann/everest-demo/blob/main/citrineos/init.sh Here is my start script: https://github.com/ChrisWeissmann/everest-demo/blob/main/citrine-demo-ac-plus-ocpp.sh which just re-uses what you did and adds in the citrine docker compose.

However since I was not working on SP3 things, I did not put in the effort to add support for it in the single line script.

[shankari]

@louisg1337 you also need to address the DCO

[louisg1337]

I just pushed out a working version of the one line demo that will run Citrine and connect to EVerest using SP1 (thanks to @ChrisWeissmann). There are a few things to note.

• In order to run this you need docker, Node 18, and jq installed
• If you run MaEVe first using SP2 or SP3, then you will need to delete the everest-ac-demo Docker cluster, before re-running the script for Citrine.
  • For some reason, if you run MaEVe SP2 or SP3 first, and then try to run Citrine using SP1, EVerest thinks it is still using the previous SP2/SP3, which Citrine doesn't support yet.
• I have yet to get the charging session to work as the token authentication keeps on failing. If you run the command below it adds in our DEADBEEF token, yet it still doesn't work.

  curl -X 'PUT' \
  'http://localhost:8080/data/evdriver/authorization?idToken=DEADBEEF&type=ISO14443' \
  -H 'accept: */*' \
  -H 'Content-Type: application/json' \
  -d '{
  "idToken": {
    "customData": {
      "vendorId": "string"
    },
    "idToken": "DEADBEEF",
    "type": "ISO14443"
  },
  "idTokenInfo": {
    "status": "Accepted",
    "cacheExpiryDateTime": "2024-05-28T16:47:28.566Z",
    "chargingPriority": 0,
    "language1": "string",
    "evseId": [
      0
    ],
    "groupIdToken": {
      "customData": {
        "vendorId": "string"
      },
      "idToken": "DEADBEEF",
      "type": "ISO14443"
    },
    "language2": "string",
    "personalMessage": {
      "format": "ASCII",
      "language": "string",
      "content": "string"
    }
  }
}'

Testing Done

• From a fresh slate (all docker containers removed), all of the commands below successfully connected to EVerest
  • bash ./demo-iso15118-2-ac-plus-ocpp.sh -c -1 (Citrine SP1)
  • bash ./demo-iso15118-2-ac-plus-ocpp.sh -1 (MaEVe SP1)
  • bash ./demo-iso15118-2-ac-plus-ocpp.sh -2 (MaEVe SP2)
  • bash ./demo-iso15118-2-ac-plus-ocpp.sh -3 (MaEVe SP3)

[louisg1337]

Sounds good to all the above. I just addressed the changes requested, so we should be all good.

[shankari]

@louisg1337 there is an indentation issue caught by the static code analysis

[shankari]

I don't see this getting fixed. I think it is a false positive. I am just going to merge this and we can fix (if needed) in the next PR. I don't want to waste our valuable time futzing around with this.

[shankari]

Squash merging to have a clean commit history; @louisg1337 please pull appropriately.