EPIC: As e-mobility providers we want to start sharing our data through the open standard OCPI, so to not have to mantain the custom API defined with NOI years ago #5
Comments
|
Here the full response data from {
"data": [
{
"country_code": "CZ",
"party_id": "123",
"id": "abcd60780f9f4b9a60002fe67cd4",
"publish": true,
"name": "Circontrol 02",
"address": "Hráského 123/99",
"city": "Praha 4 - Chodov",
"postal_code": "14900",
"country": "CZE",
"coordinates": {
"latitude": "50.2085230",
"longitude": "15.8282000"
},
"evses": [
{
"uid": "43111552d9da4d4bb7eea3b2",
"evse_id": "CZ*123*E123105886*2",
"status": "OUTOFORDER",
"capabilities": [
"REMOTE_START_STOP_CAPABLE",
"RFID_READER"
],
"connectors": [
{
"id": "1",
"standard": "IEC_62196_T2",
"format": "SOCKET",
"power_type": "AC_1_PHASE",
"last_updated": "2024-09-10T07:07:17.016Z",
"max_voltage": 230,
"max_amperage": 30,
"max_electric_power": 22000,
"tariff_ids": [
"66a2aa0876532100513e77da"
]
}
],
"last_updated": "2024-09-10T07:07:17.016Z"
},
{
"uid": "fa79dae522654d0488fcf812",
"evse_id": "CZ*123*E123105886*6",
"status": "OUTOFORDER",
"capabilities": [
"REMOTE_START_STOP_CAPABLE",
"RFID_READER"
],
"connectors": [
{
"id": "1",
"standard": "CHADEMO",
"format": "SOCKET",
"power_type": "DC",
"last_updated": "2024-09-10T07:07:17.020Z",
"max_voltage": 230,
"max_amperage": 80,
"max_electric_power": 55000,
"tariff_ids": [
"66a2aa0876532100513e77da"
]
}
],
"last_updated": "2024-09-10T07:07:17.020Z"
}
],
"time_zone": "Europe/Prague",
"opening_times": {
"twentyfourseven": true
},
"last_updated": "2024-09-10T07:07:17.020Z",
"directions": []
},
{
"country_code": "CZ",
"party_id": "123",
"id": "abcd632b333c7d17380028153cef",
"publish": true,
"name": "Circontrol 03",
"address": "Hráského 123/99",
"city": "Praha 4 - Chodov",
"postal_code": "14900",
"country": "CZE",
"coordinates": {
"latitude": "50.1077990",
"longitude": "14.4536890"
},
"evses": [
{
"uid": "f97c099870b048eea0342e09",
"evse_id": "CZ*123*E123522125*5",
"status": "OUTOFORDER",
"capabilities": [
"REMOTE_START_STOP_CAPABLE"
],
"connectors": [
{
"id": "1",
"standard": "CHADEMO",
"format": "CABLE",
"power_type": "DC",
"last_updated": "2024-09-10T07:07:17.023Z",
"max_voltage": 230,
"max_amperage": 80,
"max_electric_power": 50000,
"tariff_ids": [
"66a2aa0876532100513e77da"
]
}
],
"last_updated": "2024-09-10T07:07:17.023Z"
}
],
"time_zone": "Europe/Prague",
"opening_times": {
"twentyfourseven": true
},
"last_updated": "2024-09-10T07:07:17.023Z",
"directions": []
},
{
"country_code": "CZ",
"party_id": "123",
"id": "abcd5eedaea95b979e0027e1ace8",
"publish": true,
"name": "Circontrol 01 ",
"address": "HOTEL STERZINGER MOOS*** / Via Palude - Moosweg 4",
"city": "VIPITENO - STERZING",
"postal_code": "39040",
"country": "ITA",
"coordinates": {
"latitude": "50.2085389",
"longitude": "15.8282950"
},
"evses": [
{
"uid": "f5c59007cbee4798ad1ec20f",
"evse_id": "CZ*123E123619367*1",
"status": "OUTOFORDER",
"capabilities": [
"REMOTE_START_STOP_CAPABLE"
],
"connectors": [
{
"id": "1",
"standard": "IEC_62196_T3A",
"format": "CABLE",
"last_updated": "2024-09-10T07:07:17.026Z",
"max_voltage": 230,
"max_amperage": 30,
"max_electric_power": 22000,
"tariff_ids": [
"66a2aa0876532100513e77da"
]
}
],
"last_updated": "2024-09-10T07:07:17.026Z"
},
{
"uid": "fb9ad2e5a9ca49b8aec83988",
"evse_id": "CZ*123E123619367*4",
"status": "OUTOFORDER",
"capabilities": [
"REMOTE_START_STOP_CAPABLE"
],
"connectors": [
{
"id": "1",
"standard": "IEC_62196_T2_COMBO",
"format": "SOCKET",
"power_type": "DC",
"last_updated": "2024-09-10T07:07:17.029Z",
"max_voltage": 230,
"max_amperage": 72,
"max_electric_power": 50000,
"tariff_ids": [
"66a2aa0876532100513e77da"
]
}
],
"last_updated": "2024-09-10T07:07:17.029Z"
}
],
"time_zone": "Europe/Prague",
"opening_times": {
"twentyfourseven": true
},
"last_updated": "2024-09-10T07:07:17.029Z",
"directions": [
{
"language": "en",
"text": "1023"
}
]
}
],
"status_code": 1000,
"status_message": "Success",
"timestamp": "2024-09-10T13:06:20.530Z",
"pageInfo": {
"pageIndex": 0,
"pageSize": 1000,
"total": 3
},
"httpStatusCode": 200,
"uuAppErrorMap": {}
} |
|
And here the DRIWE locations response {
"data": [
{
"opening_times": {
"regular_hours": [],
"exceptional_openings": [],
"exceptional_closings": []
},
"energy_mix": {
"energy_sources": [],
"environ_impact": []
},
"facilities": [],
"id": "326a6041-ac5c-4f38-911b-ef3e93f5e34d",
"country_code": "IT",
"party_id": "DWR",
"publish": true,
"name": "SportHotel Exclusive San Vigilio",
"address": "Strada al Plan Dessora",
"city": "San Vigilio",
"postal_code": "39030",
"country": "ITA",
"coordinates": {
"latitude": "46.698061",
"longitude": "11.934766"
},
"time_zone": "Europe/Rome",
"evses": [
{
"capabilities": [],
"parking_restrictions": [],
"uid": "DW-000027-1",
"evse_id": "IT*DWR*E1a867309-fd64-4bbc-9d12-c64beec5748c",
"coordinates": {
"latitude": "46.698061",
"longitude": "11.934766"
},
"connectors": [
{
"tariff_ids": [],
"id": "DW-000027-1",
"standard": "IEC_62196_T2",
"format": "SOCKET",
"power_type": "AC_1_PHASE",
"max_voltage": 400,
"max_amperage": 16,
"max_electric_power": 11000,
"last_updated": "2024-02-02T11:20:00.000Z"
}
],
"status": "AVAILABLE",
"last_updated": "2024-04-07T08:28:44.000Z",
"status_schedule": [],
"directions": [],
"images": []
}
],
"last_updated": "2024-02-02T11:20:00.000Z",
"publish_allowed_to": [],
"related_locations": [],
"directions": [],
"images": []
}
],
"status_code": 1000,
"timestamp": "2024-09-11T07:54:36.408Z"
} |
|
@rcavaliere While you are working on the mapping, I wanted to finish the data collector side for this. I've seen that Simon's code exposes a REST API to do the whole token exchange (A,B,C) and so on. Am I remembering right that this won't be needed? |
|
@clezag yes, this part won't be necessary |
|
@rcavaliere I've tried to make some test calls, driwe works fine, but neogy initially worked, then I tried making a massive I can start implementing driwe as a polling-style data collector in the meantime, but not sure if it will work for neogy. |
|
I've put up an MVP for DRIWE on the new infrastructure: It's just loading the basic fields of a station, we can then extend this as we go along. |
|
@clezag I would give priority to Neogy since in their case they have done a hard migration, so currently we don't receive data from them. I have prepared the useful specification document, at the end the integration is quite simple despite the open standard use. I have put the document also in the main description of the issue. |
@clezag with Neogy we can't do this since they have too many stations. As I remember they implement a paging mechanism, which we need to implement on our side. Let us check in the OCPI specification how we can call locations method by providing the paging fields as input in the request |
|
@rcavaliere As of now, the endpoint of Neogy goes in timeout with every single request (locations, versions, no matter the parameters), so I cannot work on it. Do we have a contact there? |
|
@clezag yes I have contacts. Let me write them, I put you in CC |
|
@clezag we have the details of the new end-point to use for Neogy (see mail that we just received), can you please test it and proceed with this implementation? |
|
@rcavaliere Unfortunately they once again sent us only a testing endpoint without any real data, and crucially without enough data to implement/test the paging mechanism. {
"data": [
{
"country_code": "IT",
"party_id": "NEO",
"id": "64df6650817640d503003700384e",
"publish": true,
"name": "000 - ChargeUp Test Station",
"address": "Via Lorenz Böhler Straße 5",
"city": "BOLZANO - BOZEN",
"postal_code": "39100",
"country": "ITA",
"coordinates": {
"latitude": "46.4997770",
"longitude": "11.3101790"
},
"evses": [
{
"uid": "b358280a0f79408784c29df7",
"evse_id": "IT*NEO*E206790697*1",
"status": "BLOCKED",
"capabilities": [
"REMOTE_START_STOP_CAPABLE",
"RFID_READER"
],
"connectors": [
{
"id": "1",
"standard": "IEC_62196_T2_COMBO",
"format": "CABLE",
"power_type": "DC",
"last_updated": "2024-10-15T07:54:49.230Z",
"max_voltage": 0,
"max_amperage": 0,
"max_electric_power": 125000,
"tariff_ids": [
null
]
}
],
"last_updated": "2024-10-15T07:54:49.230Z"
},
{
"uid": "c05c5a2fd5be447190a3d0fb",
"evse_id": "IT*NEO*E206790697*2",
"status": "BLOCKED",
"capabilities": [
"REMOTE_START_STOP_CAPABLE",
"RFID_READER"
],
"connectors": [
{
"id": "1",
"standard": "IEC_62196_T2_COMBO",
"format": "SOCKET",
"power_type": "DC",
"last_updated": "2024-10-15T07:54:51.164Z",
"max_voltage": 0,
"max_amperage": 0,
"max_electric_power": 125000,
"tariff_ids": [
null
]
}
],
"last_updated": "2024-10-15T07:54:51.164Z"
}
],
"time_zone": "Europe/Rome",
"opening_times": {
"twentyfourseven": true
},
"last_updated": "2024-10-15T07:54:51.164Z",
"directions": []
}
],
"status_code": 1000,
"status_message": "Success",
"timestamp": "2024-10-15T09:21:47.462Z",
"pageInfo": {
"pageIndex": 0,
"pageSize": 100,
"total": 1
},
"httpStatusCode": 200,
"uuAppErrorMap": {}
}I'll do my best to start implementation work with what we have here, but it's not sufficient to complete the data collector side of things |
|
@clezag ok, let's try to implement the Data Collector by considering the specifications I have proposed in the user story description. Once we have done the work, I hope it is just a topic of changing end-point |
|
@rcavaliere Regarding the data types, In the spec document from what I understand plugs only have the new |
The reason would be this, as written in my document: Yes, it's true that we need to change the implementation of the web-component, but actually we have more information that we can display, so we can improve the UX that is currently implemented |
|
@rcavaliere first version is up in testing: https://mobility.api.opendatahub.testingmachine.eu/v2/tree/EChargingPlug/*/latest?where=sorigin.eq.Neogy |
|
@clezag wonderful! Completed the check of Neogy, works perfectly. Now we have to manage with the Data Provider the provision of the productive end-point, since this is just a demo OCPI end-point what we have... I will then check Driwe as well. |
|
Just updating with what was exchanged via email: We will get all locations about once a day for the station details and states. In addition, we need to supply a "eMSP" type endpoint where they can push state changes of single stations. |
|
@rcavaliere I've set up a POC of the OCPI EVSE receiver interface and sent you the connection details via mail |
|
We're received positive feedback from Chargeup, the POC does work, now i'll implement it as a full data collector |
|
@rcavaliere I've put up a fairly complete implementation in testing, data is visible in analytics, too: https://mobility.api.opendatahub.testingmachine.eu/v2/tree/EChargingStation/*/latest?where=sorigin.eq.Neogy
It's set up in a way that driwe and neogy have separate endpoints, currently driwe polls every 10 minutes, neogy every 4h, and gets status updates via push. |
|
@clezag thanks for your work, I will test this carefully in the next days in order to give you feedback and decide how to manage these points. |
|
@clezag here my feedback after some more detailed analysis:
Once you fix this, I think we can go in production with the Data Collector of Neogy. Next week let's try to complete also Driwe end-point |
|
@clezag just one more thing, can you log if we are receiving real-time updates with this push mechanism? I would like to be share that also this part is properly configured on their side. |
Yes, this is all on the new infrastructure, so we have the raw data. We are already receiving push updates with quite a high frequency. I'll implement the last batch of changes within this week, they should be quick fixes |
|
@rcavaliere I've cleaned up the old testing data and done a fresh import. There are a few details which we have not discussed, I'll mention them for completeness sake, and if we want to tackle these in the future: inactive stationsIn contrast to the previous data collector, now there is no mechanism that sets stations inactive. It would be technically possible to implement this , but for now I'll leave it as is, once we get to the point where stations have to be pruned, we have a better idea about how the data patterns look like, and maybe there is a simple way to add it. update frequencyThe way push notifications work, we only get state CHANGES, which means that if a station is not used for 3 hours, there will be no new data point for 3 hours. BUT: The regular station polling full update always writes the current state. e.g. for neogy, we poll every 4 hours, so at minimum there is one data point every 4 hours. DRIWE polls every 10 minutes, so there is a data point at least every 10 minutes. That's why the data update patterns will be a bit strange, a mix between random updates and periodic. We could do this in another way: |
|
@clezag I think we are ready to go to production with Neogy (for Driwe, let me check this more in detail first, I didn't do this yet). Regarding the points of your last post:
So, let's go in production with Neogy, let me know when you have done this! |
|
@rcavaliere It's now up in production, I've contacted the data provider to switch over the push updates, too. Currently it's only polling every 4 hours. Should I set all the old |
|
@clezag good point. I suggest to first put completely in production Neogy Data Collector, than we switch off the Data Collector Alperia. It's important that stations of Alperia remain available over the API, but set as inactive |
|
@rcavaliere I've set all the alperia stations inactive in testing: update station set active=false where stationtype in ('EChargingStation','EChargingPlug') and origin = 'ALPERIA'On analytics they are still visible, because it does not filter for active=true If you confirm, I will do the same in production. |
|
@clezag thanks for the excellent work here!!! Yes please, change this also in production |
|
@rcavaliere ok done, now waiting for news on DRIWE. |
|
@clezag I checked the DRIWE implementation, it looks everything OK. How is currently the implementation here? Do we get push from them or we just make a pull? So that we can finalize also this integration in cooperation with them. |
|
@rcavaliere Currently we are just polling all stations every 10 minutes. But it is set up like Neogy, so if we communicate them the endpoint and token they can push data and it should just work (assuming they are pushing the same PATCH evse messages as Neogy does). If you want, we can go into production now with the polling, and in parallel test the push with them (I will send you the coordinates). |
|
@clezag let me talk to DRIWE, so that we can first implement the final solution, test and then deploy it. |
|
@clezag DRIWE answered me to just foresee for an initial phase the PULL modality only, e.g. let's ask the status of the charging stations every 5 minutes. They are implementing the PUSH mechanism, so we will implement the Neogy approach also for DRIWE at a later stage. So, we can go in production also with DRIWE, but let's do this after the Christmas period (we don't have stress on this...) |
|
@rcavaliere Deployed in production. |
|
@clezag thanks for the update. Maybe it could be a good strategy to set a different origin and to put the old Data Collector on-hold? For the records provided: the end-point is productive, but currently is limited to the stations in South Tyrol. I am discussing with DRIWE to provide all stations that they have. |
|
@rcavaliere Sure, what origin should I set it to? |
|
@clezag for example DRIWE-OCPI? |
|
@rcavaliere Done. I've left the old data collector (without the transformer) running, so we still have the raw data from the old data collector in case we want to load it. |
The first e-mobility providers that have shared an OCPI end-points are Neogy and Driwe.
Reference specifications for the implementation of an OCPI-compliant Data Collector are provided in the specification document below.
Details of the connection end-points are available and will be documented / provided separately.
Tasks to be foreseen:
Test connections (in relation to the modules that are interesting for us, see available specification module) and share example response data
Specification documents for Neogy and Driwe, prepared by @rcavaliere -> 241004_SpecificheIntegrazione_NeogyOCPI_NOI_v1.1.pdf
Data Collector implementation - probably we need a single OCPI-compliant module that manages the connection with all external data sources?
230308_OCPIProfileSouthTyrol_NOI.pdf
The text was updated successfully, but these errors were encountered: