Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adapt Everest/ccc guide regarding EVerest 2024.9.0 release #28

Merged
merged 5 commits into from
Jan 10, 2025
Merged

Adapt Everest/ccc guide regarding EVerest 2024.9.0 release #28

Show file tree
Hide file tree
Changes from 4 commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
bb88fcf
Improve documentation clarity for EVerest configuration and module ma…
FaHaGit Jan 7, 2025
7b4d8da
Add missing information about EVerest modules, eMMC Partitioning and …
FaHaGit Jan 9, 2025
11b1aa3
Adapt troubleshooting documentation for OCPP 2.0.1 to EVerest 2024.9…
FaHaGit Jan 9, 2025
1830eca
Remove unnecessary blank lines in firmware and troubleshooting docume…
FaHaGit Jan 9, 2025
6cf08f7
Fix typos and improve code block formatting in documentation
FaHaGit Jan 9, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 22 additions & 2 deletions docs/source/everest_charging_stack.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -102,6 +102,25 @@ can be utilized. This module is a driver for plug lock control and implements
It is designed to support all types of plug locks on connector X9 of the Charge Control C. Check
section :ref:`locking_motor` to understand how to connect the locking motor to the Charge Control C.

**API** (`view on GitHub <https://github.com/EVerest/everest-core/tree/main/modules/API>`__)

This module is not mandatory for an EVSE setup using Charge Control C in EVerest. However, the module
:code:`API` is responsible to provide a simple MQTT based API to EVerest internals.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
:code:`API` is responsible to provide a simple MQTT based API to EVerest internals.
:code:`API` is responsible for providing a simple MQTT based API to EVerest internals.


**ErrorHistory** (`view on GitHub <https://github.com/EVerest/everest-core/tree/main/modules/ErrorHistory>`__)

This module is not mandatory for an EVSE setup using Charge Control C in EVerest. This module is responsible
for storing EVerest error events in a database file. The location of the database file can be defined
over a configuration parameter.

**OCPP** (`view on GitHub <https://github.com/EVerest/everest-core/tree/main/modules/OCPP>`__)

This module implements and integrates OCPP 1.6 support within EVerest.

**OCPP201** (`view on GitHub <https://github.com/EVerest/everest-core/tree/main/modules/OCPP201>`__)

This module implements and integrates OCPP 2.0.1 support within EVerest.

Further reading
===============

Expand All @@ -119,5 +138,6 @@ are maintained by chargebyte.
For interesting discussions and solutions to common problems, visit the EVerest community's
`Zulip <https://lfenergy.zulipchat.com/>`_ channels.

For support and issues related to the EVerest modules developed by chargebyte, refer to section X for
instructions on how to report problems and insights on contribution.
For support and issues related to the EVerest modules developed by chargebyte, please check the
:ref:`troubleshooting.rst` section of the documentation first. If you can't find the answer, please don't
hesitate to contact chargebyte's support team (:ref:`contact`).
4 changes: 1 addition & 3 deletions docs/source/firmware.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@

********
Firmware
********

Check warning on line 5 in docs/source/firmware.rst

View workflow job for this annotation

GitHub Actions / build 

Duplicate explicit target name: "rauc".

Introduction to Yocto
=====================
Expand Down Expand Up @@ -258,7 +258,7 @@
- 1 GB
- Root file system B
* - /dev/mmcblk0p3
-
- 1.3 GB
- Extended Partition Container
* - /dev/mmcblk0p5
- 1 GB
Expand Down Expand Up @@ -563,5 +563,3 @@
mount-other-rootfs /mnt

Note, that this helper script does not modify any RAUC status information regarding this slot.


71 changes: 42 additions & 29 deletions docs/source/getting_started.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -159,57 +159,70 @@ Just type "less /etc/everest/bsp-only.conf" to see the content of the configurat
:language: yaml
:linenos:

In general, the EVerest charging stack consists of different modules, each of which fulfills a
specific task. An EVerest module provides and requests interfaces. The configuration file shows
which EVerest modules are activated, how they are configured and how they are connected to each
other over the interfaces. The following figure illustrates how the EVerest modules are connected
to each other:
In general, the EVerest charging stack consists of different modules, each designed for a specific task.
An EVerest module provides and requests interfaces and defines module-specific configuration parameters.
The EVerest configuration file specifies the activated modules, their configurations, and their connections
via these interfaces. The following figure illustrates how the EVerest modules are connected to each
other in the bsp-only.yaml configuration file:

.. figure:: _static/images/admin_panel_bsp_only.png
:width: 500pt
:name: admin_panel_bsp_only

Figure: EVerest admin panel view of the bsp-only.yaml configuration

However, not all configuration parameters of the modules are shown here. Only the configuration
parameters that do not match the default configuration of the respective module need
to be specified here. Depending on the installed hardware components, the configuration file may
need to be adapted. The hardware related tasks are mainly handled by the CbTarragonDriver module.
The configuration of the CbTarragonDriver module can be found in "/usr/libexec/everest/modules/CbTarragonDriver"
directory.
However, not all configuration parameters of the modules are shown here. Only those that deviate from
the module's default configuration need to be specified.

Each module has a specific configuration file. This file is called "manifest.yaml" and is stored
in the main directory of the module.
Here you can also see all other configuration parameters of the respective module.
Now please type "less /usr/libexec/everest/modules/CbTarragonDriver/manifest.yaml" to see the
content of the configuration file and check whether the configuration fits to your hardware setup.
Each module has a specific configuration file called "manifest.yaml", located in the module's main directory
("/usr/libexec/everest/modules/{module_name}"). This file is used by the EVerest stack to verify configuration
consistency and to load the default module configuration. As a user the manifest.yaml can also be used
in order to check which configurations are possible and how the default values are set.

The hardware related tasks are mainly handled by the CbTarragonDriver module. To view the content of
the module's manifest file, use the following command:

.. code-block:: sh

less /usr/libexec/everest/modules/CbTarragonDriver/manifest.yaml

If you want to change a configuration parameter of a module, which is not part of your EVerest YAML
configuration file, just copy the specific configuration key from the "manifest.yaml" file of the
module to the module specific "config_module" space in your EVerest configuration and adjust the
value. Please note if you change it directly in the "manifest.yaml" file of a module, the changes
will be get lost after a software update.
value. If a default value in the manifest file meets your requirements, there is no need to redefine
it in your EVerest configuration.

Here is an excerpt of an EVerest configuration to change the parameter "connector_type" to
"IEC62196Type2Cable" of the CbTarragonDriver module.
.. note::
Do not modify the manifest.yaml file directly to change default behavior. Always make adjustments
in your EVerest configuration file to override the default values of the module parameters.

Here is an example of how to change the "connector_type" parameter of the CbTarragonDriver module to
"IEC62196Type2Cable" in the EVerest configuration file.

Snippet of a EVerest configuration file:

.. code-block:: sh
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could this be formatted as YAML, or would that active peculiar colors?

Suggested change
.. code-block:: sh
.. code-block:: yaml

I can't seem to find a proper list of supported languages. I looked at this list. I hope it's the one that applies. sh isn't even mentioned, nor is console.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yaml is working

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also have changed the types of the other console outputs from sh -> console


tarragon_bsp:
module: CbTarragonDriver
config_module:
contactor_1_feedback_type: none
relay_2_name: none
connector_type: IEC62196Type2Cable
tarragon_bsp:
module: CbTarragonDriver
config_module:
contactor_1_feedback_type: none
relay_2_name: none
connector_type: IEC62196Type2Cable

By following these guidelines, you can now customize and manage your EVerest charging stack configuration
to suit your hardware and application requirements. After adjusting the configuration file, you have
to restart the EVerest charging stack to apply the changes:

.. code-block:: sh

After adjusting the configuration file, you have to restart the EVerest charging stack to apply the
changes. Just type "systemctl restart everest" to restart the EVerest charging stack.
systemctl restart everest

.. note::
You can also use the `EVerest admin panel <https://github.com/EVerest/everest-admin-panel>`_
to adjust the EVerest configuration in a GUI. This tool must currently be installed manually on your
developer computer, because the resources on the board are limited.
developer computer, because the resources on the board are limited. Please note that the tool can
only display a configuration correctly if all interface and module descriptions are provided.

.. note::
If you have made a mistake in the configuration file, the EVerest charging stack will not
Expand Down
67 changes: 36 additions & 31 deletions docs/source/troubleshooting.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -71,35 +71,41 @@ Please note that the implementation is still under development and integrated in
How do I set up OCPP 2.0.1 on Charge Control C with EVerest?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Unfortunately, some manual steps on a development PC are necessary. First, check out the
libocpp and change into the OCPP 2.0.1 config directory:

.. code-block:: console

git clone https://github.com/EVerest/libocpp.git
cd libocpp/config/v201

Now adapt OCPP 2.0.1 config.json to your needs (e.g. NetworkConnectionProfiles):

.. code-block:: console

gedit config.json

After that you can create the device model database and insert the configuration:

.. code-block:: console

python3 init_device_model_db.py --db device_model_storage.db --schemas component_schemas/ init
python3 init_device_model_db.py --db device_model_storage.db --schemas component_schemas/ --config config.json insert

Then copy the device model database onto the Charge Control C (adapt IP address to your environment):

.. code-block:: console

scp device_model_storage.db root@<ip-address>:/var/lib/everest/ocpp201

Finally make sure the DeviceModelDatabasePath in your global YAML configuration points to
/var/lib/everest/ocpp201/device_model_storage.db and then restart EVerest on the Charge Control C.
To support OCPP 2.0.1, the EVerest OCPP201 module must be integrated into the EVerest configuration.
This module uses the `libocpp library <https://github.com/EVerest/libocpp>`_ to implement the OCPP 2.0.1
protocol.
The `OCPP201 module documentation <https://github.com/EVerest/everest-core/blob/main/modules/OCPP201/doc.rst>`_
already contains some information about the module parameters, the provided and required interfaces,
and the initial creation of the OCPP 2.0.1 database.

The most important points are summarised here:

1. The OCPP201 module must be included in your EVerest configuration.
2. The CbSystem module can be used to fulfill the requirement of the system interface.
3. 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.
4. The `CoreDatabasePath` is used, among other things, to store OCPP transaction data.
5. 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 the `DeviceModelDatabasePath`.
6. 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 the
place a `component config file <https://github.com/EVerest/libocpp/tree/v0.16.2/config/v201/component_config>`_
in the same directory structure in the DeviceModelConfigPath and change the values accordingly.
Importent 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 <https://github.com/EVerest/libocpp/blob/main/doc/v201/ocpp_201_device_model_initialization.md>`_.

I tried to compile chargebyte's Hardware EVerest Modules, but it fails to build. How can it fix this?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Expand All @@ -119,6 +125,7 @@ EVerest already has a module which takes care of Modbus communication. Please ha
`SerialCommHub <https://everest.github.io/nightly/_generated/modules/SerialCommHub.html>`_,
and let your module interact with this module via the `serial_communication_hub` interface.

.. _contact:

Contact
-------
Expand Down Expand Up @@ -148,5 +155,3 @@ Bitterfelder Straße 1-5
Germany

Website: `<https://chargebyte.com>`_


Loading