FAQ

Three prerequisites to connect a charger:

• the charger has a stable internet connection (wired network preferred);
• the charger has an administration tool you can access to change the CSMS URL;
• the charger runs up-to-date firmware before its first connection to the CSMS.

The charger can be updated remotely only after its first connection. Warning: a firmware update can cause malfunctions or regressions. We always recommend testing the firmware on a test charger first.

If the charger uses a local network, the IT team must allow outbound traffic from the chargers to the domain charge-angels.com (TCP port 443) and disable the outbound firewall, or whitelist the IP addresses of our server (to be requested from an administrator).

The network should be wired whenever possible, to avoid distance and bandwidth limits. The tolerated network latency must be below 500 ms.

Chargers can use several communication modes: LAN (Ethernet) or WAN (Wi-Fi). In most cases, the charger talks by default to the DHCP (Dynamic Host Configuration Protocol) of the local network and gets an IP address automatically; otherwise, a manual IP address must be set in the charger. The internet box (router) connects to the internet through the customer’s provider: ADSL, fibre or GSM.

If you prefer a 4G network, you will need M2M SIM cards (dedicated to IoT), preferably with roaming. For data throughput, count 200 kBytes per charge point.

• The APN configuration depends on the operator.
• SIM cards with roaming enabled are preferable: the best network is chosen in real time. Roaming can be France or worldwide, depending on your needs.
• In general, plan a 200 MB data plan per charge point for intensive use.
• A VPN is not useful if the charger communicates over WSS.

ChargeAngels uses a secure WebSocket (WSS) connection between the charger and the backend. We only support TLS 1.3 (TLS 1.2 being deprecated). ChargeAngels supports RSA and ECDSA SSL certificates. We use Node.js with the uWebSockets.js library to handle WebSockets.

• Created in 2011, WebSocket (WS) is an application-layer network protocol that is “bidirectional, asynchronous and full-duplex” between client and server, standardised by the IETF in RFC 6455 and by the W3C.
• WebSocket opens a permanent full-duplex connection between the client and the server: the server can send data to a client on its own initiative, unlike the HTTP protocol.
• WebSocket Security (WSS) uses the TLS transport layer, like HTTPS, to encrypt communications: it is therefore more secure.

As described in the specification “OCPP 1.6 security whitepaper edition 3”, we support:

• Security Profile 1: WS with Basic Authentication (user / password or Authorization Key, your choice);
• Security Profile 2: Basic Authentication or WSS TLS with the server Root Certificate (ISRG Root X1);
• Security Profile 3: WSS TLS on both the charge point and the server side (tested, but not officially in production).

OCA tests: test cases TC_085_CSMS (basic authentication, valid username / password combination) TC_086_CSMS (TLS, valid server-side certificate) and TC_087_CSMS (TLS, valid client-side certificate) are passed with the Open Charge Alliance test tool.

Authorization Key: minimum 16 characters and hexadecimal encoding, between 20 and 40 characters.

We recommend always testing the first connection of the charger with Security Profile 1 (WS), then 2 (WS and WSS), then 3 (WSS).

A Tenant is a sub-space of the main domain, for example cpo1.charge-angels.com.

• If you chose the SaaS solution, you organise your Tenant in the “Organisation” tab of the CSMS.
• If you chose the Full Cloud solution, you have access to the “Master Tenant” and can create as many “Cloud Tenants” as needed.

The Tenant has a common user database, whose central key is the e-mail address. It can be broken down into several hierarchical levels: Companies, Sites and Zones.

• Sites can be different geographical areas for one and the same customer (for example bus depots).
• Sites can also be different sub-customers that share a common user database.
• A Zone is a group of chargers; it defines the physical topology of the place: a zone can be equal to a main low-voltage panel (TGBT) or to a power subscription (for example a 220 kVA supply).
• SmartCharging is separated by Zone (maximum power declared at the main panel).

A “Token” is a WSS connection URL used by the charger to connect to the ChargeAngels CSMS servers. The token is unique and specific to a Zone.

Once your organisation is created, you can create one or more connection tokens to the backend from the “Charger” menu, then “Connect a charger”: create it, add a title, a validity date and a Zone, then save.

You can copy the token for later or immediate use (for example “OCPP 1.6 JSON”). It can be passed on to the teams deploying chargers in the field. For cybersecurity reasons, ChargeAngels chose to create dynamic tokens with a validity date, unlike other CSMS.

The token (or URL) is made of 4 parts

• the prefix: HTTP / HTTPS / WS or WSS;
• “OCPP16” or “OCPP201”, depending on the OCPP version;
• the first part of the token is the unique identifier of the tenant;
• the second part is the identifier of the token itself, linked to a zone;
• the last part is the name of the charger: the ChargeBoxID.

wss://charge-angels.com/OCPP16/<tenant-id>/<token-id>/CHARGER-01

Once the token is copied into the charger’s administration, the charger opens a socket towards the CSMS servers. The charger (here CHARGER-01) appears automatically in the dashboard, with no action required on the backend side. Once the charger is visible, edit its attributes (maximum power, location, connectors, etc.).

In the administration of some chargers, the URL and the ChargeBoxID are split into several fields: “Host”, “Port”, “Path” and “ChargeBoxID” (the name of the charger). You sometimes need to check the URL built this way (mind the different slashes).

Naming your chargers

We recommend setting a naming convention for chargers. The ChargeBoxID is linked in the database to all the charger’s information and charging history: you cannot change it later without losing this history. Example of a convention: “CITY-PLACE-CHARGER-01”. Warning: the ChargeBoxID is limited to 48 characters (Gireve limit).

Once the token and the charger name are added, the charger points to the tenant, the token and therefore the zone concerned. You sometimes need to restart the charger for these settings to be taken into account. As long as the charger does not appear in the dashboard, either the URL is malformed or the charger is offline: check the logs.

Token expiry

CHARGER-01 must be commissioned and connected with the created token before the token expires, otherwise the OCPP BootNotification will be rejected. Once the charger has been accepted by the backend for the first time, the token is stored in the database: even after expiry, the charger can reboot without any problem.

We recommend keeping tokens, even expired ones: for other commissionings, you only need to extend their validity date. On the other hand, you can delete unused tokens, which avoids errors.

We advise monitoring the ChargeAngels logs during commissioning, and checking them regularly.

Some chargers need the Root certificate of our server: ISRG Root X1 (Let’s Encrypt). We can provide it on request, but you can also get it from a Linux or macOS command prompt by typing the following command:

curl https://letsencrypt.org/certs/isrgrootx1.pem

Copy the certificate displayed in the response (ISRG Root X1), paste it into a text file, then save it as “ISRG Root X1.crt”. Save it locally and in the charger: when it restarts, the charger will use this certificate and the WSS URL to connect to the backend.

This certificate is used in OCPP with Security Profile 2 and the Server Side Certificate.

Once the charger is connected to the backend, you can change all OCPP parameters remotely. Some parameters are standardised in the OCPP specification, others are optional or even custom.

List of parameters to check, depending on your needs:

Some chargers have a “CSMS URL” and “ChargeBoxID” field: it allows the backend URL or the charger name to be changed remotely, without entering the charger’s configuration on site.

You can export all OCPP parameters to compare them later with those of other chargers. Some keys are read-only.

The first thing to monitor when commissioning is the stability of the WebSockets. Opening a WebSocket is solely the initiative of the charger, not of the CSMS.

Logs are available in the “Log” section of the CSMS, where you can filter by charger, severity and action. Two families of logs are useful: WebSocket logs (connection) and OCPP logs (exchanged messages), detailed in the next two questions.

If the WebSockets are not stable (unwanted openings and closings), the charger cannot boot properly through OCPP and will be in an uncertain state.

In the “Log” section, filter the actions WsServerConnectionOpen and WsServerConnectionClose.

• WsServerConnectionClose indicates that the socket was closed on the charger side (at the charger’s initiative), for example: Close > WS Connection ID 'FsRi9' closed with code '1000', reason: 'Normal closure'.
• The CSMS has no further information on the reason for this disconnection. Most often it is due to a network outage (the closing and opening times are then the same for all chargers) or a power outage.
• You can monitor the number of WsServerConnectionClose events: there should be no more than a few per day.

The CSMS sends a “ping” to the charger every 60 seconds; if 2 pings fail, we close the WebSocket. The charger also pings our server every 30 seconds. The ping frequency can be adjusted with the OCPP parameter WebSocketPingInterval.

In the “Log” section, you can filter on your charger and on a few simple actions, for example: OcppBootNotification, OcppStatusNotification, OcppStartTransaction, OcppStopTransaction, OcppMeterValues. Logs are read from bottom to top (the most recent is the first line).

Four severity levels exist, as in any IT system:

• ERROR: critical, must never appear;
• WARNING: serious but without consequences for operation;
• INFO: readable (textual) information;
• DEBUG: debug information, with the JSON requests and responses.

In DEBUG, the message details include the direction of the requests, with the following convention:

• << = request / response from the charger to the backend;
• >> = request / response from the backend to the charger.

The same convention is used for the JSON server, OCPI, OICP, Batch or external APIs (the backend being on the right).

Logs matching OCPP JSON commands can also be read at an even lower level, by looking at the juxtaposed WebSocket messages: WsClientMessage for the request and WsServerMessage for the response, with a unique identifier (UID) for each message on the CSMS and charger sides. For example:

Message > Send WS Message Request: '[2,"f3f0e8b8-59a2-4f4c-816a-fce3b059f0a0","ClearChargingProfile",{"connectorId":1}]'

Message > Received WS Message: '[3,"f3f0e8b8-59a2-4f4c-816a-fce3b059f0a0",{"status":"Unknown"}]'

This format is sometimes required to communicate with charger manufacturers when debugging.

ChargeAngels has a common user database per Tenant. Users have 3 permission levels (roles):

• Administrator: all rights on the Tenant;
• Standard: rights for the end customers who charge electric vehicles;
• Site Administrator: a “Standard” user with administration rights over one or more Sites.

The detail of the permissions per role is described in the integration documentation, available on request.

A fourth role, “Demo”, is also available for anonymised public display. A specific role also exists for server-to-server communication (API): it can be enabled on a generic user, the “Technical user”, which cannot be used to log in from the frontend (web or mobile application).

The next three questions detail the general rules, the assignment to sites and the account states.

New users can create their account:

• through the web interface, directly on the page https://<subdomain>.charge-angels.com/auth/register;
• through the mobile application, after scanning the organisation’s QR code for “SaaS” customers, or directly when opening the application for “Full Cloud” customers.

In both cases, they must accept the “End-User Licence Agreement” (EULA), as defined in the GDPR (General Data Protection Regulation).

• The e-mail address is the unique key of a user in the database.
• For security reasons, passwords are encrypted in the database: they are not visible in clear text, even to administrators.
• A user who logs in 3 times with a wrong password is blocked; only an administrator can unblock the account on request.
• A user who forgets their password can request an automatic renewal by e-mail, from the web application (https://<subdomain>.charge-angels.com/auth/reset-password) or from the mobile application (“Forgot password?”).
• Only an administrator can raise the permissions of a “Basic” user to “Administrator” or “Basic / Site Administrator”. Likewise, a Site Administrator can designate another Site Administrator on the Site(s) they are assigned to.

Since the user database is common to the Tenant, the administrator can choose the strategy for assigning users to Sites: either the flag “Automatically assign new users to this site” is enabled on all sites, or it is disabled.

1. Flag disabled: the new user sees no charger after creating their account. The administrator (or Site Administrator) must assign this user manually. The user can then see all the charge points of the site and start a charging session.
2. Flag enabled: the new user is assigned to all sites where the flag is active; they can see all the charge points of these sites and start a charging session. The administrator (or Site Administrator) must then unassign users who should not see the site(s) concerned.

Notes:

• All “Administrator” users are assigned by default to all sites created in the Tenant.
• An administrator can create a user manually with a password of their choice. In this case, they must also assign the user manually to the sites for which they will have rights.
• The flag “This site is public” only concerns the roaming scenario (Gireve / Hubject).

You can also enable or disable, for the whole Tenant, the strategy for creating new user accounts, from the “Technical settings” / “Users” section:

• if enabled: all new users can create their account automatically;
• if disabled: a push alert and an e-mail are sent to you to decide whether or not to activate the account. You then need to check the automatic assignment on the site(s), or assign it manually, depending on the strategy defined above.

If a customer decides to create several customer accounts on the same Tenant, it is their responsibility to manage all their users (old and new) properly.

A user account can be in several states:

• Active: enabled, it benefits from all the features of the site;
• Suspended: account made inactive by an administrator, it can be reactivated later;
• Inactive: account not used for more than 6 months (no login on the platform);
• Locked: automatic block after three wrong password attempts;
• Pending: waiting for account validation by an administrator.

An automatic mechanism checks and deactivates inactive user accounts on the ChargeAngels platform, in compliance with the European GDPR regulation.

How it works

The task runs every Monday at midnight (Europe/Paris). It only targets active users with the Basic role (technical accounts are excluded). The process has two steps:

1. Warning (after 6 months of inactivity): users who have not logged in for 6 months receive a warning notification, which gives them time to log in again and avoid deactivation.
2. Deactivation (after 7 months of inactivity): if the user still has not logged in one month after the warning, the account automatically switches to Inactive status and a status-change notification is sent.

Criteria checked: date of last login, date of acceptance of the terms (EULA), date of the last charging transaction. Current configuration: inactivity threshold of 6 months, run every Monday at 00:00.

A charger can be made completely open or highly secure depending on the settings in ChargeAngels (Organisation / Zones), but above all depending on the settings of the charger (and its model).

When access control is disabled on the ChargeAngels side, whatever the charger settings, ChargeAngels accepts all charging transaction starts requested by the charger. In this case, it is impossible to block specific users or to bill.

When access control is enabled, the behaviour depends on the charger settings: FreeVending, RFID, Autocharge or Plug&Charge. ChargeAngels can manage an unlimited number of tokens of type RFID, eMAID or MAC address, automatically, manually or through CSV import.

• Gireve defines a token as a string of 4 to 7 bytes, i.e. 8 to 14 hexadecimal characters. We recommend following this rule for roaming to work properly. Only NFC/RFID badges of the MIFARE type are recommended.
• When a new user creates an account through the web interface (https://<subdomain>.charge-angels.com/auth/register) or through the mobile application, a 4-byte virtual badge is automatically created and assigned to that user.
• Tokens can be created manually, one by one, or through CSV import. If a token is created manually, the administrator must assign it to a user.
• A user can have an unlimited number of tokens, including a default one: it is the one automatically offered when a charging session starts.

Information requested when creating a token

• the Badge ID or UID: the code written inside the physical RFID badge;
• the badge number: the visible number engraved on the RFID badge;
• the description (free text);
• the user linked to the badge;
• the badge status;
• default badge: the one automatically offered when a charging session starts;
• allow this badge to start several charges simultaneously on different chargers.

How do I add a physical badge (or virtual eMAID) if I do not know its UID?

1. In the “Logs” section, add a filter on your charger and on the ERROR severity.
2. In the “Action” filter, search for the action OcppAuthorize.
3. Swipe your badge on the charger.
4. An ERROR log appears, with the UID (idTag) in the error details.

Keep this UID for later use, or go to the “Badge” menu to add it. You can also export all badges with the export button.

CSV import

An import is also possible in CSV format, with the comma as separator: create an XLS file with the mandatory properties id and visualID and the optional properties description, limitKwh, email, firstName, name, siteIDs, then save it as CSV. Run a test with a few badges before importing a list of thousands of badges.

Charger manufacturers generally offer payment terminal (POS) solutions such as these:

Principle: the POS is connected to the charger through the serial port (MDB).

1. The driver presents their bank card in front of the payment terminal integrated into the charger (Nayax, Ingenico or Payter).
2. The back office of the bank payment service checks and authorises the charging transaction.
3. The payment terminal sends a predefined token to the charger to request an authorisation, using the MDB protocol.
4. The charger sends an authorisation request with the token to the supervision backend and starts charging.

If everything is configured on the POS side (manufacturer’s cloud), when a bank card is tapped the charger sends an OCPP StartTransaction containing an idTag. This tag must be entered in the charger’s OCPP parameters: it is not a standard OCPP parameter and it differs between charger brands.

This tag must also be referenced as a virtual badge and on a virtual user (administrator), so that the supervision accepts the charging request. This user must also be assigned to the corresponding sites.

Prerequisite: the pricing configuration and the Stripe bank account. You can set up pricing independently, without enabling billing.

For captive fleets or company fleets, you can give your users directly:

1. the URL to access the web platform: https://<subdomain>.charge-angels.com/auth/login;
2. the QR codes of the mobile application:

3. the QR code of your “Organisation”, which is requested when creating an account. To find it, go to the “Technical settings” menu, then “Show QR code”. Save it as a JPG file: you will need it to create your user procedures. A poster template to customise and stick on your chargers is available on request.
4. a QR code per connector: you can also generate one per connector, to start a charge without having to look for the charger in the mobile application. The list of QR codes can be exported for each Site from the Organisation / Site menu.

Warning: the QR codes encode the full URL of the chargers (ChargeBoxID and connector ID). Renaming a charger changes its QR code: you will then need to replace it.

The first thing to monitor when commissioning is the stability of the WebSockets. Opening a WebSocket is solely the initiative of the charger, not of the CSMS. If the WebSockets are not stable (unwanted openings and closings), the charger cannot boot properly through OCPP and will be in an uncertain state.

If a charger does not appear in the web interface (dashboard), there can be many reasons:

• the charger is not powered (outage) or is in an undetermined state;
• the charger is not, or no longer, connected to the network;
• the charger goes through a secured network (outbound firewall);
• the charger goes through a local network: LAN or WAN router;
• the internet connectivity is insufficient;
• the charger firmware is not up to date.

The order of debugging

1. Charger side

• Check the physical connections: cables and routers.
• Power-cycle (5 min) the charger and the external communication devices (routers).
• If possible, check the charger-side logs from the manufacturer’s administration.

RJ45 connections are often faulty or badly wired. The best test is to connect a computer in place of the charger, with the same network settings (automatic DHCP or fixed IP).

• For a charger with a 4G modem, check that the APN and the user / password are correct, then the 4G signal state, often available from the charger or the external 4G router.
• Update the firmware with the latest official version available on the manufacturer’s website.
• First try changing the token to WS (not secured, port 80).
• Then, if that works, switch back to WSS (secured, port 443).

2. Supervision side, if everything is fine on the charger side

• Check the supervision-side logs (web interface preferably), as described in the questions about logs. If no WebSocket opening request is received, the charger is not communicating correctly, especially if other chargers are already connected on the same cloud space.
• Also check the token state (validity and revocation) from the “Charger / Connect a new charger” menu.
• Check whether the charger responds to OCPP commands (Reset, StartTransaction…) while looking at the backend logs.

When and how to contact us

If none of the chargers respond any more and the network is not at fault, there may be a bug on the supervision side. In this case, please contact us (category “Support request”) with the exact description of the problem: date of the incident, reproducibility, names of the chargers concerned, tests carried out, etc.

If the problem seems related to the chargers, to one particular charger or follows a firmware update, collect the charger-side and supervision-side logs and open a ticket with the manufacturer.

Debugging is a billable service at ChargeAngels, except for a proven and documented bug on the supervision side. Only chargers certified by ChargeAngels are covered by our support contract. In most cases, bugs are caused by a charger crash, a network problem or incorrect handling by users.

Good practices

• The best approach is to keep a “reference” charger close to your premises, for debugging and for reproducing failures or errors. A firmware update is a risky operation that can sometimes permanently break a charger. Without a dedicated test charger, run your tests on an isolated charger that is not heavily used.
• When commissioning chargers you do not know, run a commissioning test before the final installation.
• For 4G chargers, analyse the 4G network coverage beforehand (devices exist for this).
• For functional tests, charging simulators exist for AC (Type 2) chargers from Metrel. We also recommend tests with a real electric vehicle.

Reading JSON logs or any other format requires IT skills. The OCPP messages between the chargers and our server are standardised in the OCPP specification, which we recommend reading first: openchargealliance.org/my-oca/ocpp. We also provide training on this protocol, as well as operational training (reading logs and debugging), in addition to the IRVE P2/P3 qualification.

Three families of problems come up most often. They are detailed in the next questions:

• problems connecting the charger to the backend;
• session finalisation problems: no StopTransaction received;
• session finalisation problems: StopTransaction received, but wrong status.

Symptom: the charger does not appear in the ChargeAngels CSMS dashboard although the network works, or you receive WS/WSS requests but they are in error.

Explanations: opening a WebSocket is solely the initiative of the charger, not of the CSMS. If no WS or WSS request arrives on the supervision side and the network works (the charger can reach the internet, for example Google’s DNS), the URL setting in the charger is probably wrong, incorrect or incomplete. Each brand or model has specificities and sometimes needs a specific tool to set this URL: web app, mobile app, dedicated Windows application, etc.

Solutions: we recommend first reading this whole FAQ, in particular the questions about WebSocket logs. After the network, the URL setting is the cause of the problem 99% of the time: you therefore need to apply a sequential and iterative method.

A malformed URL often has several origins:

1. Some chargers only support WS: we recommend starting with that (whoever can do more can do less).
2. Some chargers only support WSS after the latest firmware update.
3. Some chargers require a first connection in WS, then a switch to WSS (Schneider, depending on the firmware).
4. Some chargers support WSS but only TLS 1.2 and not TLS 1.3.
5. Some chargers require a specific Security Profile: we do not have a specific profile, but level 2 is accepted with any password.
6. Some chargers require the CSMS Root certificate (Root CA certificate).
7. Some chargers require port 80 or 443: in this case, add it to the URL.
8. Some chargers separate the host, the port, the path and the ChargeBoxID, then concatenate the WSS URL to make outgoing calls.
9. Some chargers do not offer a ChargeBoxID: you then need to add it at the end of the URL, otherwise the call will be rejected on our side (this field is the primary key in our database).
10. Some chargers add a slash at the end of the URL, others do not (on our side there is no limitation on this).
11. Some chargers truncate the URL because it is too long (less and less frequent).

Symptom: in the Sessions / History menu you see ghost sessions, and it is impossible to stop a charging session in progress. Error log: Remote Stop Transaction has been rejected in 1.52s, reason 'Rejected'.

Sequence in the logs:

EVSE <- CSMS : remoteStartTransaction with transactionID
EVSE -> CSMS : accepted
EVSE -> CSMS : StartTransaction with tagID
EVSE <- CSMS : accepted
...
EVSE <- CSMS : remoteStopTransaction with the same transactionID
EVSE -> CSMS : rejected   <- error message: you are blocked here
EVSE -> CSMS : StopTransaction with same tagID
EVSE <- CSMS : accepted

Explanations: the session is still pending on the CSMS side, whatever the real state of the charger, since we do not know its state (no StopTransaction was received). Restarting the charger therefore has no effect on the pending session, as long as the CSMS does not receive the charger’s StopTransaction with the right transaction ID. Starting another session generates another TransactionID, i.e. another entry in our database.

Solution: you have only one option: select the “Force Stop” button available on each session in progress, from the user interface. This forces the stop on the CSMS side.

Symptom: in the Sessions / History menu you see ghost sessions, or an abnormal charger status (other than CHARGING / SUSPENDED / FAULTED / RESERVED).

Normal case when the StopTransaction is received

• StopTransaction + AVAILABLE (FINISHING optional): the transaction is stopped and finalised.
• FINISHING is not required: only AVAILABLE or PREPARING are checked (FINISHING is used for parking time).
• SUSPENDED, FAULTED and RESERVED have no influence on the process.

“Abnormal” cases that are handled automatically

1. StopTransaction received, but never a StatusNotification after X minutes: automatic “Force Stop” by a scheduled task of the CSMS (30-minute delay).
2. New StartTransaction received without a prior StopTransaction: without consumption, the transaction is deleted; with consumption, an automatic “Force Stop” is applied.
3. StatusNotification AVAILABLE without a StopTransaction just before: the transaction stays active (no immediate action). If the Stop arrives afterwards, finalisation is normal; if it does not arrive, a “Force Stop” is applied by the scheduled task (30 minutes).
4. StatusNotification AVAILABLE before the StopTransaction: the system artificially creates a StatusNotification from the current connector status (Available) and the timestamp of the StopTransaction, to compute the extra idle time correctly.

Example of a real timeline:

T1: Available received   -> no action (no StopTransaction)
T2: Stop received        -> detects connector = Available
                          -> creates a synthetic StatusNotification
                          -> finalises the transaction

Solution: in all cases other than those described above, you can stop the transaction manually from the “in progress” sessions, with the “Force Stop” button.