Everest Charge Control C 1.6.0

README.rst

@@ -1,72 +1,81 @@
 Charge Control C Product Documentation
 ======================================
 
-This is the product documentation project for Charge Control C, a product of chargebyte GmbH.
-This documentation is intended for users, developers, and administrators of Charge Control C.
-This documentation is hosted on Read the Docs and can be accessed at
-https://chargebyte-docs.readthedocs.io/en/latest/.
+This repository contains the source files for the Charge Control C user documentation.
+The documentation is written in reStructuredText and built with Sphinx.
 
+The published documentation is available on Read the Docs:
+https://chargebyte-docs.readthedocs.io/projects/everest-charge-control-c/en/
 
-Contents
---------
 
-- Charge Control C User Guide
+Repository Structure
+--------------------
 
+The main documentation sources are located in:
 
-Repo Initialization
--------------------
+- `docs/source`
 
-This repository is using git submodules to share documents between the user guides.
-After cloning of the project please execute the following commands:
+Shared content is maintained in the git submodule:
 
-git checkout everest/charge_control_c
+- `includes`
 
-git submodule update --init --force --remote
+
+Repository Initialization
+-------------------------
+
+This repository uses git submodules. After cloning, initialize and update them with:
+
+.. code-block:: bash
+
+   git submodule update --init --recursive
 
 
 Building the Documentation Locally
 ----------------------------------
 
-To build the documentation locally, you need to have Python and pip installed on your system.
-You can install the required dependencies by running the following command:
+Install the Python dependencies first:
 
-pip install -r docs/requirements.txt
+.. code-block:: bash
 
-After installing the dependencies, you can build the documentation by running the following command:
+   pip install -r docs/requirements.txt
 
-sphinx-build -a docs/source {output_directory}
+Then build the HTML documentation from the `docs` directory:
 
-The output directory is the directory where the generated HTML files will be stored.
+.. code-block:: bash
+
+   cd docs
+   sphinx-build -b html source _build/html
+
+The generated HTML files are written to `docs/_build/html`.
 
 
 Contributing
 ------------
 
 If you would like to contribute to the documentation, please fork the repository and create a pull
-request with your changes. Please make sure to follow the guidelines for contributing to the
-documentation:
+request with your changes. Please keep changes aligned with the existing repository structure and writing style:
 
-- The branch name for the pull request should be `everest/ccc_{your_branch_name}`.
-- Maximum line length should be 120 characters (Preferably 100 characters).
-- Images should be stored in the `docs/source/_static/images` directory
-- CSS files should be stored in the `docs/source/_static/css` directory
-- Source and config files should be stored in the `docs/source/_static/files` directory
-- A documentation file should be written in reStructuredText format
-- A documentation file should start with referenceable label of the file name (e.g. ".. _hardware.rst:")
-- Sections and chapters should be separated by one blank line after the title and two blank lines before the title
-- Sections with a chapter title before, need to have only one blank line before the title
-- First letters of section and chapter titles should be capitalized (e.g. "Charge Control C User Guide")
+- Documentation sources belong in `docs/source`.
+- Images belong in `docs/source/_static/images`.
+- CSS files belong in `docs/source/_static/css`.
+- Static files such as example configurations belong in `docs/source/_static/files`.
+- Shared include files belong in the `includes` submodule.
+- Documentation files should be written in reStructuredText.
+- Documentation files should start with a referenceable label, for example `.. _hardware.rst:`.
+- Keep line length at 120 characters maximum, preferably around 100 characters.
+- Sections and chapters should be separated by one blank line after the title and two blank lines before the title.
+- Sections with a chapter title before them should have only one blank line before the title.
+- Capitalize section and chapter titles consistently.
 
 
 License
 -------
 
-See the LICENSE file for license rights and limitations (Apache 2.0).
+See `LICENSE` for license rights and limitations (Apache 2.0).
 
 
 Contact
 -------
 
-If you have any questions or inquiries, please contact our support team at https://chargebyte.com/support.
-
-Thank you for using products from chargebyte GmbH!
+For support and product-related questions, please visit:
+https://chargebyte.com/support

docs/source/_static/files/bsp-only.yaml

@@ -21,9 +21,6 @@ active_modules:
       evse_manager:
         - module_id: connector
           implementation_id: evse
-      energy_listener:
-        - module_id: connector
-          implementation_id: energy_grid
       evse_energy_sink:
         - module_id: grid_connection_point
           implementation_id: external_limits

docs/source/everest_charging_stack.rst

@@ -28,7 +28,7 @@ An overview of the EVerest modules that are defined within a configuration file
 **CbTarragonDriver** (`view on GitHub <https://github.com/chargebyte/everest-chargebyte/tree/main/modules/CbTarragonDriver>`__)
 
 This is the Hardware Abstraction Layer (HAL) for Charge Control C in EVerest. It implements
-the `evse_board_support <https://github.com/EVerest/everest-core/blob/main/interfaces/evse_board_support.yaml>`_
+the `evse_board_support <https://github.com/EVerest/EVerest/blob/main/interfaces/evse_board_support.yaml>`_
 interface, enabling communication with the :code:`EvseManager` and control of the board. The EVerest community
 often refers to these HAL modules as BSPs, such as MicroMegaWattBSP and PhyVersoBSP. This module is
 essential for controlling the Charge Control C. The term "Tarragon" in :code:`CbTarragonDriver` refers to
@@ -39,7 +39,7 @@ the Charge Control C hardware platform.
 This module is not mandatory for an EVSE setup using Charge Control C in EVerest. However, if EVerest
 is configured for an AC supply equipment with a socket connector, the module :code:`CbTarragonPlugLock`
 can be utilized. This module is a driver for plug lock control and implements
-`connector_lock <https://github.com/EVerest/everest-core/blob/main/interfaces/connector_lock.yaml>`_ interface.
+`connector_lock <https://github.com/EVerest/EVerest/blob/main/interfaces/connector_lock.yaml>`_ interface.
 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.
 
@@ -107,7 +107,7 @@ different in the physical wiring:
   it is important that only one contactor can be active at a time, i.e. they exclude each other *mutually*.
   This is ensured by the software implementation, but should already be enforced in hardware,
   e.g. by using the auxiliary contacts as shown in :numref:`switch-3ph1ph-mutual`.
-  This setup allow to use a single 400 V-rated contactor in combination with a (cheaper) 230 V-rated one.
+  This setup allows the use of a single 400 V-rated contactor in combination with a (cheaper) 230 V-rated one.
 
   .. _switch-3ph1ph-mutual:
   .. figure:: _static/images/switch-3ph1ph-mutual.drawio.svg
@@ -161,7 +161,7 @@ phase-count switching in general:
 The EnergyManager module has also additional configuration options to allow fine-tuning of the behavior, but
 all ship with reasonable default values and thus are not explained in detail here.
 A description of all these parameters can be found in the
-`EnergyManager manifest <https://github.com/EVerest/everest-core/blob/main/modules/EnergyManagement/EnergyManager/manifest.yaml>`_.
+`EnergyManager manifest <https://github.com/EVerest/EVerest/blob/main/modules/EnergyManagement/EnergyManager/manifest.yaml>`_.
 
 And also the 'EvseManager' module allows fine-tuning the switching process with two configuration parameters:
 
@@ -173,7 +173,7 @@ And also the 'EvseManager' module allows fine-tuning the switching process with
   of 'X1' should work with all cars and thus it's recommended to leave it on this default value.
 
 The full description of all these parameters can be found in the
-`EvseManager manifest <https://github.com/EVerest/everest-core/blob/main/modules/EVSE/EvseManager/manifest.yaml>`_.
+`EvseManager manifest <https://github.com/EVerest/EVerest/blob/main/modules/EVSE/EvseManager/manifest.yaml>`_.
 
 .. note::
    Phase count switching is only possible in basic charging mode.

docs/source/firmware.rst

@@ -6,7 +6,12 @@
 Partitioning
 -------------
 
-The internal eMMC storage of a chargebyte device is divided into several partitions. The main aim is to have two independent systems available, i.e. system A and system B. This allows to running firmware updates in background while performing normal charging operation, and then switching to the updated system with a fast restart of the device. This also allows to supporting a rollback mechanism in case of failures during firmware updates. In other words, during a firmware update, the active root file system switches from A to B or vice versa, leaving the other as rollback.
+The internal eMMC storage of a chargebyte device is divided into several partitions. The main aim is to
+have two independent systems available, i.e. system A and system B. This allows firmware updates to run
+in the background while normal charging operation continues, and then switches to the updated system with
+a fast restart of the device. This also supports a rollback mechanism in case of failures during firmware
+updates. In other words, during a firmware update, the active root file system switches from A to B or vice
+versa, leaving the other as the rollback system.
 
 .. list-table:: eMMC Partitioning
    :header-rows: 1
@@ -26,7 +31,7 @@ The internal eMMC storage of a chargebyte device is divided into several partiti
      - Extended Partition Container
    * - /dev/mmcblk0p5
      - 1 GB
-     - Data Partition (/srv). This partition can be accessed by both root file systems and will be not changed during update process.
+     - Data Partition (/srv). This partition can be accessed by both root file systems and will not be changed during the update process.
    * - /dev/mmcblk0p6
      - 128 MB
      - Logging file system A (/var/log)