To do this, click on "cFos Power Brain Wallbox Configuration" and enter the following:
EVSE as OCPP Client: activate
ID | The ChargeBox ID set in the backend. If you want to operate the cFos Power Brain Wallbox as an OCPP client in the cFos Charging Manager, this must match the ID that you have entered as the "Address" in the cFos Charging Manager for the corresponding EVSE. |
Server | The URL of the OCPP backend. If you want to operate the cFos Power Brain Wallbox as an OCPP client in the cFos Charging Manager, enter the IP address of the cFos Charging Manager and the port that you have configured as the OCPP server port in the Charging Manager settings here. |
To do this, click on "Settings" of the corresponding EVSE and enter the following:
Device type | EVSE with OCPP 1.6 |
Address | Here you must enter the ChargeBox ID that was configured in the EVSE. |
Id | You must enter the connector ID here. For EVSEs with one charging point this is always 1, for two charging points it is correspondingly 1 or 2, etc. |
Some EVSEs with OCPP, such as the Innogy eBox professional S or Mennekes Amtron, can transmit meter data to the OCPP backend in compliance with calibration regulations. The OCPP gateway of the cFos Charging Manager can transparently forward such meter data to the backend.
The gateway is not required to operate a cFos Power Brain Wallbox, because the cFos Power Brain Wallbox allows the simultaneous operation of OCPP to the backend for authorisation and billing and Modbus for load management. To do this, configure the OCPP client under "cFos Power Brain Controller Configuration" and additionally activate Modbus. Then enter a cFos Power Brain Wallbox under "Start" and enter the address or COM port data and Modbus ID.
If you want to set up the gateway, you must configure the following parameters. To do this, click on "Settings" of the corresponding EVSE and enter the following:
OCPP Gateway URL | The URL of the OCPP accounting backend, e.g. ws://ocpp.backend.com/ for unencrypted connections or wss://ocpp.secure-backend.com/ for TLS-encrypted connections. For some backends, it is also necessary to specify a path, e.g. ws://ocpp.backend.com/path/to/resource/. |
CPP Gateway Password | If the backend operator specifies a password for the OCPP connection, this must be entered here. If the backend operator does not specify a password, this field can remain empty. |
OCPP Gateway Client ID | The ID with which the gateway reports to the backend. This ID should usually be specified by the operator of the backend. Some backends identify their clients via individual keys that are part of the URL, e.g. ws://xyz123.backend.com/ or ws://ocpp.backend.com/xyz123/. In this case, the client may be free to choose the client ID. |
Certificates are used when using encrypted TLS connections between client and server. To successfully establish such a connection, the server always needs a certificate and an associated private key. The cFos Charging Manager already has a self-signed certificate on board. Therefore, no own certificates have to be imported. However, this option exists on both the server and the client side.
On the server side, an own certificate and the corresponding private key can be imported. This certificate can be self-signed or signed by an official certification authority. If no CA certificate (CA = Certificate Authority) is stored in the client, a TLS connection is established in any case. If one or more CA certificates are stored in the client, the respective server certificates must match (OCPP Security Profile 2). The server certificate itself can be stored as the CA certificate. If the client has a connection to the Internet, root certificates of certification authorities that have signed the server certificate can also be stored there. However, you can also store your own root certificate that has signed the server certificate.
As an additional security level, a certificate can also be used in the opposite direction (OCPP Security Protocol 3). For this purpose, a certificate and the corresponding private key are stored in the client. The server also receives this certificate among the CA certificates or a root certificate that has signed the client certificate. This means that the TLS connection is only established if the server can also verify the client certificate.
You can create certificates yourself, e.g. with the programme OpenSSL, which is available free of charge for Windows and Linux. A few examples using OpenSSL follow. The examples use a configuration file saved in UTF8 format in conjunction with the -config parameter. This has the advantage that umlauts and other Unicode characters can also be used in the certificate. The configuration file always has the following format:
[req] prompt = no distinguished_name = dn req_extensions = ext [dn] CN = Unsere Tiefgarage emailAddress = info@tiefgarage-koeln.de O = Tiefgarage Köln GmbH OU = Abteilung 13 L = Köln C = DE [ext] subjectAltName = DNS:tiefgarage-koeln.de,DNS:*.tiefgarage-koeln.de
Creation of a private key rootCA.key for a root certificate:openssl genrsa -des3 -out rootCA.key 4096
Create a self-signed root certificate rootCA.crt using the private key rootCA.key created above and the configuration file rootCA.cnf (the parameter -days specifies how many days the certificate is valid for):openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 365 -out rootCA.crt -config rootCA.cnf -utf8
Creation of a private key client.key for a client certificate:openssl genrsa -out client.key 2048
Create a Certificate Signing Request (CSR) client.csr for a client certificate using the private key client.key created above and the configuration file client.cnf:openssl req -new -key client.key -out client.csr -config client.cnf -utf8
Creation of a client certificate client1.crt, which is signed with the root certificate rootCA.crt above and the associated private key rootCA.key (the parameter -days again specifies how long the certificate is valid):openssl x509 -req -in client.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out client.crt -days 365 -sha256
You can operate a cFos Power Brain Wallbox in parallel with Modbus and OCPP, e.g. to integrate it into the local load management via Modbus and to connect it to a billing backend via OCPP. For this purpose, "Activate Modbus" must be activated in the settings of the cFos Power Brain wallbox and a TCP port or COM parameter must be configured so that the wallbox can be addressed via Modbus. In addition, an OCPP URL to the backend, the OCPP client ID and, if applicable, the OCPP connector ID must be set under OCPP settings. OCPP then starts loading processes, i.e. transactions. It determines whether the transaction is permitted on the basis of the transmitted RFID and starts loading if necessary. If no RFID reader is available, you can configure a fixed RFID that is known to the OCPP backend. Using Modbus, the charging current can now be regulated for load management purposes, i.e. the charging current specified by the OCPP charging profile can be reduced. The charging profile specifies the maximum charging current. The charging current is therefore always the minimum of the charging currents specified via Modbus and OCPP. Charging can also be temporarily deactivated and reactivated via Modbus or OCPP. Charging only takes place if both Modbus and OCPP backend allow charging.