Troubleshooting¶
Frequently Asked Questions¶
Is it possible to use the Charge Control C as an EV simulator?¶
No, the Control Pilot interface on Charge Control C is not able to operate as an EV. Please look at our website for more suitable products.
Is it possible to use the Charge Control C as a DC charge controller?¶
For prototype use cases, it is possible to use the Charge Control C as DC SECC for DIN 70121 or ISO 15118. However, due to the strict timing requirements, the Charge Control C is not intended for production use in DC applications for safety reasons. The Charge Control C was designed with the AC use case in mind.
How can I use CAN with Charge Control C?¶
There is no Charge Control C with onboard CAN interface available, so we suggest to use an USB adapter, e.g. Peak System.
I want to control EVerest via CAN, how can I achieve this?¶
Currently there is no such EVerest module available, you will need to implement it on your own.
But at least there are DC power supply modules and a library, which uses the CAN interface. This might help as a starting point.
Is it possible to upgrade the firmware from proprietary stack to EVerest and vice versa?¶
Yes it is, but be aware that the configuration and database files will not be converted.
Note
Before installation of a chargebyte EVerest image, please check whether you are installing a developer or release image and prepare the Charge Control C accordingly. How to do this is explained in the Release Images vs Development Images section.
For more information, please refer to the Updating from chargebyte’s proprietary charging stack to EVerest-based charging stack section.
How can I access the EVerest admin panel on Charge Control C?¶
The Charge Control C does not have an EVerest admin panel because of its limited resources. Please use your development environment to set up your configuration file or just use a plain text editor.
How should TLS or Plug & Charge private keys be protected?¶
For TLS and especially Plug & Charge, private keys should be protected according to the requirements of the certificate authority or certificate management system. In many production environments, this means using hardware-backed key storage such as a TPM, HSM, or comparable technology.
If software-based key protection is not sufficient for your project, plan the hardware-backed approach early. Please contact chargebyte support to discuss the available integration options for Charge Control C.
Does EVerest on Charge Control C support ISO 15118-20 yet?¶
The required module for ISO 15118-20 has been included in the image since the chargebyte EVerest 1.0.0 release. Support for ISO 15118-20 is available in EVerest on Charge Control C and has significantly matured compared to earlier releases. Among other things, BPT (bidirectional power transfer) is implemented for Dynamic and Scheduled Charging Mode. The main remaining implementation gap is currently Plug & Charge related functionality.
For Plug & Charge related setup details, please also refer to the EVerest Plug & Charge tutorial.
How do I set up OCPP 2.0.1 on Charge Control C with EVerest?¶
To support OCPP 2.0.1, the EVerest OCPP201 module must be integrated into the EVerest configuration. The OCPP 2.0.1 and 2.1 tutorial already contains information about the module parameters, the provided and required interfaces, and the initial creation of the OCPP database.
The most important points are summarised here:
The OCPP201 module must be included in your EVerest configuration.
The CbSystem module can be used to fulfill the requirement of the system interface.
While configuring the OCPP 2.0.1 module, ensure that you are using OCPP configuration and database paths which are covered by the update mechanism. The following paths are recommended:
CoreDatabasePath: /var/lib/everest/ocpp201
DeviceModelDatabasePath: /var/lib/everest/ocpp201/device_model_storage.db
DeviceModelConfigPath: /var/lib/everest/ocpp201/component_config
Otherwise, if you don’t want to use a persistent storage, you can also deploy those files in your RAUC image.
The CoreDatabasePath is used, among other things, to store OCPP transaction data.
The OCPP 2.0.1 device model initialization is done automatically by the OCPP201 module after the first start of EVerest. The database is stored at the DeviceModelDatabasePath.
The component config files are stored in the DeviceModelConfigPath. Component config files are used to initialize or update the device model database. To update a component config file, just place a component config file in the same directory structure in the DeviceModelConfigPath and change the values accordingly. Important keys of the component config files are:
standardized/InternalCtrlr.json: ChargePointId: In “attributes” adapt the “value” key to configure the ChargePointId. Used to identify the Charging Station.
standardized/InternalCtrlr.json: NetworkConnectionProfiles: In “attributes” adapt the “ocppCsmsUrl” key. The URL in “ocppCsmsUrl” is used to connect to the CSMS.
standardized/SecurityCtrlr.json: SecurityCtrlrIdentity: In “attributes” adapt the “value” key to configure the SecurityCtrlrIdentity. It is the Charging Station identity.
For further information about the device model initialization, please refer to the libocpp documentation.
I tried to compile chargebyte’s Hardware EVerest Modules, but it fails to build. How can I fix this?¶
The EVerest mainline development is very dynamic and does not guarantee any stable API along the EVerest modules. So after almost every EVerest release, chargebyte needs to adapt their modules to the latest API changes.
Please have a look at the compatibility matrix to see which EVerest release works with which chargebyte EVerest Modules release.
I would like to implement a custom Modbus device in EVerest. Where should I start?¶
EVerest already has a module which takes care of Modbus communication. Please have a look at SerialCommHub, and let your module interact with this module via the serial_communication_hub interface.
The root partition of my Charge Control C is full. How can I free some space?¶
The latest EVerest development images don’t have much space left on the root partition. As a temporary solution you can remove the Boost header files, in order to free some space:
root@tarragon:~# rm -rf /usr/include/boost
After that you will no longer be able to compile Boost C++ programs on the target.
Contact¶
Support¶
EVerest is an open-source project with a lot of modules, which is supported by a big community. chargebyte is an active part of this community. However chargebyte is not able to provide support for every aspect of EVerest. In order to get quick answers, here are some suggestions:
Do you have general questions about EVerest, please use the EVerest community’s Zulip.
Do you have questions about the chargebyte BSP (incl. Yocto), please use our support desk.
Note
Before submitting a support request, make sure that all relevant log files have been captured. The chapter Logging and Debugging describes the debugging options EVerest offers and shows which logs are relevant for the respective case.
Address¶
chargebyte GmbH
Bitterfelder Straße 1-5
04129 Leipzig
Germany
Website: https://chargebyte.com