Connecting a Hager Witty Park charger (XEV202C)

Communicating Hager Witty Park chargers — part numbers XEV2xxC, including the XEV202C — communicate with Chargekeeper over OCPP 1.5 SOAP.

They differ from more recent chargers on one point: there is neither a web interface nor a manufacturer application. The whole configuration goes through a text file loaded from a USB stick into the charger's controller.

This article details that file. For creating the token and understanding the limits of the 1.5 protocol — disconnection detection, remote commands — see the Connecting a charger over OCPP SOAP 1.5 article.

---

1. Prerequisites

• A charger in the communicating version: the part number ends with C and the charger carries a TCP/IP board. Models without that board cannot be supervised.
• The USB stick delivered with the charger (supplied only with the XEV2xx models), used to transfer the configuration to the controller.
• An Ethernet connection between the charger and the site's router, with outbound internet access open.
• The charger's controller identifier, written bxxxx by Hager. It appears in the name of the configuration files supplied with the charger.

---

2. Create the connection token

In Chargekeeper, open the Chargers module, Connect a charger tab, then Create. Fill in:

The SOAP format only appears in the list once the URL type is set to Backward compatible, and version 1.5 only appears once the SOAP format is selected. If these choices do not appear, work through the fields from left to right.

Save the token: the OCPP URL is only computed once the token is saved. Reopen it, then copy the URL with the copy button.

---

3. The configuration file

The Witty is configured through .cfg files whose name starts with the controller identifier. Depending on the firmware version, these are either separate files (bxxxx config.cfg, bxxxx manager.cfg, bxxxx network.cfg), or a single bxxxx global.cfg file gathering all the sections.

⚠️ The file name must carry the bxxxx identifier of the charger you are configuring. If the prefix does not match, the controller ignores the file with no error message and no parameter is applied. This identifier belongs to the controller: it is different from the charge point identifier entered in refcp.

[Config] section — enable supervision

[Config]
 Access_control=      2       # 2 -> OCPP-Park

[Network] section — the site's local network

[Network]
 mac=
 dhcp=                0                        # 0 -> DHCP disabled, 1 -> DHCP enabled
 ip_addr=             <charger-address>
 subnet_mask=         <network-mask>
 gateway=             <gateway-address>
 dns1=                <primary-dns>
 dns2=                <secondary-dns>

⚠️ Every value between angle brackets is a placeholder to replace with the values of the site's network. Ask the site's IT manager for them if you do not know them.

These parameters describe the charger on the site's local network, behind the router. The site's public IP address appears nowhere in this file.

• ip_addr must be a free address on the local network, in the same subnet as gateway.
• gateway is the local address of the router.
• dns1 and dns2 are reached through that gateway.

💡 If the site's addressing plan is not settled yet, set dhcp= 1 for a first attempt: the router will assign the address, which lets you validate the connection before switching back to a fixed address.

[OCPP] section — the link to Chargekeeper

[OCPP]
 login=               ""
 password=            ""
 server=              "<OCPP URL copied from Chargekeeper>"
 client=              ""
 refcp=               "<charger-identifier>"

• server takes the URL copied in step 2, between quotes, without retyping it. It has the following form, where each element between angle brackets is specific to your organisation:

  https://<ocpp-server>/OCPP15?TenantID=<organisation-id>%26Token=<token>
  

  The %26 between the two parameters is intentional: it is the encoded form of the & character.

• login and password stay empty. Chargekeeper authenticates the charger through the token contained in the URL, not through HTTP authentication.

• refcp is the charge point identifier, the one under which the charger will appear in the supervision. Left empty, the charger's MAC address is used instead. If the charger is already declared in your organisation, refcp must match the declared identifier exactly.

• client is left empty, as in every example of the Hager manual. Chargekeeper remembers the charger's callback address from the messages it sends; this field does not need to be filled in to establish the connection.

💡 HTTPS or HTTP? The OCPP 1.5 endpoint accepts both. The Hager manual only documents http://, but a Secure token remains preferable. If the charger fails to connect over HTTPS, generate a Non-secure token and replace the URL: the TLS stack of this hardware may be too old. Remember to open the matching outbound port, 443 for HTTPS or 80 for HTTP.

The slash added by the firmware

The firmware of these chargers treats the supervision URL as a base path and adds a slash to it, sometimes followed by its own reference. As the token is the last parameter of the URL, this suffix ends up stuck to its value, which arrives as <token>/ or <token>/<charger-identifier>.

Chargekeeper ignores it and extracts the parameters correctly. Copy the URL as it is, without trying to remove that slash. If you still run into a connection refusal mentioning an invalid token, contact support.

---

4. Load the configuration into the charger

1. Copy the .cfg file or files to the root of the USB stick.
2. Open the charger's outer casing and insert the stick into the controller's USB port.
3. Restart the charger so that the configuration is taken into account.
4. Read the configuration back from the charger to check that the values entered were indeed applied.

---

5. Check the connection

On its first connection, the charger sends a Boot Notification message and registers in Chargekeeper.

• Open the Chargers module: the charger must appear in the list.
• Check the OCPP logs to confirm that the Boot Notification was received, then the Heartbeats.

If no connector appears at first, this is normal: the automatic configuration of charge points waits for the OCPP status notifications, which can take several minutes after the charger restarts.

---

6. Troubleshooting

The checks common to all 1.5 chargers — URL copied in full, identifier filled in, outbound port open — are gathered in the Connecting a charger over OCPP SOAP 1.5 article. Here is what is specific to this hardware.

The charger does not appear in the supervision at all. First check the name of the configuration file: a bxxxx prefix that does not match the controller makes the file silently ignored, and none of your settings are applied. Then check that ip_addr and gateway do belong to the network the charger is plugged into.

You are reusing the file from a previous supervision. Do not keep the [Network] section as it is. The local addressing it contains was valid for the previous provider's network access — often a SIM card on a private operator APN. On another internet access, these addresses no longer match any existing network and the charger has no outbound route left.

The charger connects through a SIM card supplied by the previous supervision. It is most likely a private APN that only routes to that provider's servers. No configuration change will make Chargekeeper reachable: an open internet access is required, either the site's router or an M2M SIM card with a standard APN.

Remote commands do not work (start, stop, restart). This is a limit of the 1.5 protocol, explained in detail in the generic article. On this hardware, the Hager manual requires a fixed public IP address on the site — or a VPN tunnel if the address is dynamic — as well as a port forwarding rule on the router: external port 80 in TCP to the charger's local address, internal port 8080.