What can I do to ensure that all stations I receive are relevant for my drivers?

If you are facing one of the following situations, you may want to adjust the way you pull EVSEdata:

1. EV drivers cannot charge because they are directed to stations that are not accessible to them
2. Drivers may be directed to testing stations that are not accessible to the public
3. EMPs will receive stations in the middle of the ocean
4. Drivers directed to private stations, opening the door to conflicts with the station owner

All these points cause a negative user experience for the EMP user.

Recommended Solution

• Optional field in the OICP protocol in the PullEVSEdata: Accessibility
  • Drivers only see relevant stations as the EMP can filter out irrelevant stations
  • CPOs have less incentive to intentionally push stations in the middle of the sea, as drivers will only be directed to relevant stations

Features

This solution can be implemented by EMPs/EMP backend providers by adding an optional field in the PullEVSEdata body. This field is already mandatory for all CPOs using OICP, so the information will always be present.

There are four values for Accessibility:

1. Free publicly accessible: majority of stations are this, the EV driver can reach the charging point without paying a fee or passing a barrier
2. Restricted access: selected few stations that are accessible to only a permitted few, e.g. for fleet users
3. Paying publicly accessible: accessible to everyone, but for payment – e.g. in a paid parking facility – should be indicated to avoid frustration
4. Test station: station is only for roaming testing purposes – station may be located inside a workshop and is not generally available for charging, should not be shown to the EV driver

This allows EMPs to direct their users with privileged access rights to their e.g. fleet chargers but will prevent the public from ending up at a closed barrier with an empty battery, unable to charge.

Implement the accessibility field and use it to filter out irrelevant stations. Read more about it in our OpenAPI specification on Github and ask your backend provider if they support the use of this field.