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 cFos Power Brain wallbox as an OCPP client in the cFos Charging Manager, this must match the ID that you entered as the "Address" in the cFos Charging Manager for the corresponding EVSE.|
|server||The URL of the OCPP backend. If you 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.|
To do this, click on "Settings" for the corresponding EVSE and enter the following:
|Device type||EVSE with OCPP 1.6|
|address||Here you have to enter the ChargeBox ID that was configured in the EVSE.|
|Id||Here you have to enter the Connector ID. For EVSEs with one charging point this is always 1, for two charging points it is 1 or 2, etc.|
Some EVSEs with OCPP, such as the Innogy eBox professional S or Mennekes Amtron, can transmit meter data that is compliant with calibration law to the OCPP backend. 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 authorization and billing and Modbus for load management. To do this, configure the OCPP client under "cFos Power Brain Configuration" and also activate Modbus. 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 have to configure the following parameters. To do this, click on "Settings" for the corresponding EVSE and enter the following:
|OCPP gateway URL||The URL of the OCPP billing backend|
|CPP gateway password||A password that the operator of the backend gives you for this EVSE|
|OCPP Gateway Client ID||The ID with which the gateway reports to the backend. The operator of the backend gives you this ID|
Certificates are used when using encrypted TLS connections between client and server. To successfully establish such a connection, the server always requires a certificate and an associated private key. The cFos Charging Manager already has a self-signed certificate on board. It is therefore not necessary to import your own certificates. However, this option exists on both the server and client side.
On the server side, you can import your own certificate and the associated private key. 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 a CA certificate. If the client has a connection to the Internet, root certificates from certification authorities that 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 level of security, a certificate can also be used in the opposite direction (OCPP Security Protocol 3). For this purpose, a certificate and the associated private key are stored in the client. Among the CA certificates, the server also receives this certificate or a root certificate that has signed the client certificate. The TLS connection is only established if the server can also verify the client certificate.
You can create certificates yourself, for example with the OpenSSL program, which is available free of charge for Windows and Linux. Here are a few examples using OpenSSL. 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 = firstname.lastname@example.org 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 -days parameter specifies how many days the certificate is valid):
openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 365 -out rootCA.crt -config rootCA.cnf -utf8
Creating a private key client.key for a client certificate:
openssl genrsa -out client.key 2048
Creating a Certificate Signing Request (CSR) client.csr for a client certificate using the client.key private key created above and the client.cnf configuration file:
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 above root certificate rootCA.crt and the associated private key rootCA.key (again, the -days parameter 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