CCY web page style change

docs/source/_static/js/cb_theme.js

@@ -0,0 +1,98 @@
+(function () {
+  var STORAGE_KEY = "cb-docs-theme";
+  var root = document.documentElement;
+
+  function readStoredTheme() {
+    try {
+      var stored = window.localStorage.getItem(STORAGE_KEY);
+      if (stored === "light" || stored === "dark") {
+        return stored;
+      }
+    } catch (error) {
+      return "light";
+    }
+
+    return "light";
+  }
+
+  function currentTheme() {
+    return root.getAttribute("data-theme") === "dark" ? "dark" : "light";
+  }
+
+  function nextTheme(theme) {
+    return theme === "dark" ? "light" : "dark";
+  }
+
+  function applyTheme(theme, persist) {
+    root.setAttribute("data-theme", theme);
+    root.style.colorScheme = theme;
+
+    if (persist) {
+      try {
+        window.localStorage.setItem(STORAGE_KEY, theme);
+      } catch (error) {
+        /* Ignore storage failures. */
+      }
+    }
+
+    syncToggleButton();
+  }
+
+  function syncToggleButton() {
+    var button = document.querySelector(".cb-theme-toggle");
+    if (!button) {
+      return;
+    }
+
+    var theme = currentTheme();
+    var targetTheme = nextTheme(theme);
+    var label = targetTheme === "dark" ? "Switch to dark mode" : "Switch to light mode";
+    var hiddenText = button.querySelector(".cb-visually-hidden");
+
+    if (hiddenText) {
+      hiddenText.textContent = label;
+    }
+
+    button.setAttribute("aria-label", label);
+    button.setAttribute("title", label);
+    button.setAttribute("aria-pressed", theme === "dark" ? "true" : "false");
+    button.setAttribute("data-theme-target", targetTheme);
+  }
+
+  function handleToggleClick() {
+    applyTheme(nextTheme(currentTheme()), true);
+  }
+
+  function mountToggle() {
+    var relatedNav = document.querySelector(".related ul");
+    if (!relatedNav || relatedNav.querySelector(".cb-theme-toggle-item")) {
+      syncToggleButton();
+      return;
+    }
+
+    var item = document.createElement("li");
+    item.className = "cb-theme-toggle-item";
+
+    var button = document.createElement("button");
+    button.type = "button";
+    button.className = "cb-theme-toggle";
+    button.addEventListener("click", handleToggleClick);
+
+    var hiddenText = document.createElement("span");
+    hiddenText.className = "cb-visually-hidden";
+    button.appendChild(hiddenText);
+
+    item.appendChild(button);
+    relatedNav.appendChild(item);
+
+    syncToggleButton();
+  }
+
+  applyTheme(readStoredTheme(), false);
+
+  if (document.readyState === "loading") {
+    document.addEventListener("DOMContentLoaded", mountToggle);
+  } else {
+    mountToggle();
+  }
+})();

docs/source/conf.py

@@ -39,6 +39,9 @@
 html_css_files = [
     'css/cb_theme.css',
 ]
+html_js_files = [
+    'js/cb_theme.js',
+]
 
 # Disable link "index"
 html_use_index = False
@@ -50,3 +53,8 @@
 # https://www.sphinx-doc.org/en/master/usage/configuration.html#options-for-the-linkcheck-builder
 
 linkcheck_anchors = False
+# workaround for https://github.com/sphinx-doc/sphinx/issues/9383, unfixed in sphinx <= 9.1.0
+# "Linkcheck marks local links broken when they reference files produced later, during in HTML building"
+linkcheck_ignore = [
+    r'.*/chargebyte-keyring\.pem$',
+]

docs/source/everest_bsp.rst

@@ -1,5 +1,3 @@
-.. _everest_bsp.rst:
-
 EVerest Board Support Package Module
 ------------------------------------
 

docs/source/everest_charging_stack.rst

@@ -20,18 +20,6 @@ The use case described in this configuration file includes the following:
 
 An overview of the EVerest modules is shown in the next section.
 
-.. include:: ../../includes/everest_overview_of_everest_modules.inc
-
-**DCSupplySimulator** (`view on GitHub <https://github.com/EVerest/everest-core/blob/main/modules/Simulation/DCSupplySimulator/manifest.yaml>`__)
-
-This module simulates a DC power supply device.
-
-**CbParsleyDriver** (`view on GitHub <https://github.com/chargebyte/everest-chargebyte/tree/main/modules/CbParsleyDriver>`__)
-
-This is the Hardware Abstraction Layer (HAL) for Charge Control Y in EVerest. It implements
-the `evse_board_support <https://github.com/EVerest/everest-core/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 Y.
+.. include:: everest_overview_of_everest_modules_ccy.inc
 
 .. include:: ../../includes/everest_further_reading.inc

docs/source/everest_overview_of_everest_modules_ccy.inc

@@ -0,0 +1,117 @@
+Overview of EVerest modules
+============================
+
+As seen from the previous configuration file, some modules are required in order to use EVerest.
+Which modules are required is highly dependent on the use case you want to release. The following
+is a list of modules that are part of the chargebyte EVerest charging software:
+
+This list is not complete and focuses mainly on modules that are particularly relevant for chargebyte
+systems, including chargebyte-specific modules. A complete list of the open source EVerest modules is
+available in the `EVerest module reference <https://everest.github.io/nightly/reference/modules/index.html>`_.
+
+**EvseManager** (`view on GitHub <https://github.com/EVerest/EVerest/tree/main/modules/EVSE/EvseManager>`__)
+
+The main module in a charging infrastructure EVerest setup. It manages a single EVSE (i.e., one connector for
+charging a car) and may control multiple connectors under some circumstances. It handles charging
+logic (basic charging and HLC), gathers all relevant data for the charging session, such as energy
+delivered during the session, and provides control over the charging port/session. For more information about
+its capabilities, refer to the `module documentation <https://everest.github.io/nightly/reference/modules/EVSE/EvseManager/autogenerated.html>`__.
+
+**EvseV2G** (`view on GitHub <https://github.com/EVerest/EVerest/tree/main/modules/EVSE/EvseV2G>`__)
+
+This module implements DIN 70121 and the ISO 15118-2 charging protocols. For more information about its capabilities and
+configuration, refer to the `module documentation <https://everest.github.io/nightly/reference/modules/EVSE/EvseV2G/autogenerated.html>`__.
+
+**Evse15118D20** (`view on GitHub <https://github.com/EVerest/EVerest/tree/main/modules/EVSE/Evse15118D20>`__)
+
+This module implements ISO 15118-20 charging protocol. For more information about its capabilities and configuration,
+refer to the `module documentation <https://everest.github.io/nightly/reference/modules/EVSE/Evse15118D20/autogenerated.html>`__.
+
+**IsoMux** (`view on GitHub <https://github.com/EVerest/EVerest/tree/main/modules/EVSE/IsoMux>`__)
+
+This module is currently required to support DIN 70121, ISO 15118-2, and ISO 15118-20 at the same time.
+In the future, the :code:`IsoMux` module is expected to become unnecessary once all protocols are provided by a
+single module.
+
+**EnergyManager** (`view on GitHub <https://github.com/EVerest/EVerest/tree/main/modules/EnergyManagement/EnergyManager>`__)
+
+This module is the global Energy Manager for all EVSE/Charging stations in a building.
+
+**API** (`view on GitHub <https://github.com/EVerest/EVerest/tree/main/modules/API/API>`__)
+
+This module is not mandatory for a simple EVSE setup in EVerest. However, the module
+:code:`API` is responsible for providing a simple MQTT based API to EVerest internals.
+Please note that this module is deprecated. For new integrations, the :code:`RpcApi` module
+and the EVerest interface-specific stable-API modules are recommended.
+
+**RpcApi** (`view on GitHub <https://github.com/EVerest/EVerest/tree/main/modules/API/RpcApi>`__)
+
+This module is not mandatory for a simple EVSE setup in EVerest, but it is often required by
+external applications and services. This module provides a standardized interface for external applications to interact
+with an EVerest-based charge point. It uses JSON-RPC over WebSocket to allow clients to perform various operations,
+such as starting or stopping a charging session, retrieving status information, and configuring settings.
+
+**ErrorHistory** (`view on GitHub <https://github.com/EVerest/EVerest/tree/main/modules/Misc/ErrorHistory>`__)
+
+This module is not mandatory for an EVSE setup in EVerest. This module is responsible
+for storing EVerest error events in a database file. The location of the database file can be defined
+via a configuration parameter.
+
+**ChargerInfo** (`view on GitHub <https://github.com/EVerest/EVerest/tree/main/modules/Misc/ChargerInfo>`__)
+
+This module provides a charger information interface, backed by simple key-value storage interface. With the optional
+dependency to another charger information node, it is possible to chain multiple sources of information. The module uses a
+YAML file to read charger information like manufacturer, model, serial number, firmware version, etc..
+This file is located in :code:`/etc/everest/charger_info.yaml` by default.
+
+**YamlStore** (`view on GitHub <https://github.com/EVerest/EVerest/tree/main/modules/Misc/YamlStore>`__)
+
+This module provides a read-only key-value store interface, backed by a simple YAML file. This module is used by
+the :code:`ChargerInfo` module to read charger information from a YAML file.
+
+**DummyTokenProvider** (`view on GitHub <https://everest.github.io/nightly/reference/modules/Testing/DummyTokenProvider/autogenerated.html>`__)
+
+This module is used for automatically providing an authorization token, instead of requiring e.g. an
+actual RFID reader. It listens to the AuthRequired event from evse_manager module and then publishes one token.
+
+**DummyTokenValidator** (`view on GitHub <https://everest.github.io/nightly/reference/modules/Testing/DummyTokenValidator/autogenerated.html>`__)
+
+This module always returns the same configured token validation result for every token. The
+validation result is a configuration key in the manifest of the module.
+
+**CbSystem** (`view on GitHub <https://github.com/chargebyte/everest-chargebyte/tree/main/modules/CbSystem>`__)
+
+This module is an adaptation of the "`System <https://github.com/EVerest/EVerest/tree/main/modules/Misc/System>`_"
+module in EVerest. It implements the "`system <https://github.com/EVerest/EVerest/blob/main/interfaces/system.yaml>`__"
+interface and, like the :code:`System` module, is responsible for performing system-wide operations but
+tailored for chargebyte's hardware platforms. The use of this module depends on the specific use case,
+such as if OCPP is required. In such cases, the :code:`CbSystem` module is responsible for executing
+commands from OCPP e.g. :code:`UpdateFirmware`.
+
+**OCPP** (`view on GitHub <https://github.com/EVerest/EVerest/tree/main/modules/EVSE/OCPP>`__)
+
+This module implements and integrates OCPP 1.6 support within EVerest. For configuration details, please refer to
+the `OCPP 1.6 tutorial <https://everest.github.io/nightly/tutorials/ocpp16.html>`_.
+
+.. _everest_module_ocpp201:
+
+**OCPP201** (`view on GitHub <https://github.com/EVerest/EVerest/tree/main/modules/EVSE/OCPP201>`__)
+
+This module implements and integrates OCPP 2.0.1 support within EVerest. For configuration details, please refer to
+the `OCPP 2.0.1 and 2.1 tutorial <https://everest.github.io/nightly/tutorials/ocpp2.html>`_.
+
+**AuthListValidator**
+
+This module validates if an incoming token exists in a predefined list of authorized tokens.
+
+**DCSupplySimulator** (`view on GitHub <https://github.com/EVerest/EVerest/blob/main/modules/Simulation/DCSupplySimulator/manifest.yaml>`__)
+
+This module simulates a DC power supply device.
+
+**CbParsleyDriver** (`view on GitHub <https://github.com/chargebyte/everest-chargebyte/tree/main/modules/CbParsleyDriver>`__)
+
+This is the Hardware Abstraction Layer (HAL) for Charge Control Y in EVerest. It implements
+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 Y.

docs/source/hardware.rst

@@ -205,7 +205,7 @@ Emergency Input
 
    Wiring overview for the Emergency Input
 
-This wiring diagram shows an overview of connecting the emergeny input to the Charge Control Y:
+This wiring diagram shows an overview of connecting the emergency input to the Charge Control Y:
 
 * make sure the emergency input stays between 21.6V and 26.4V for normal behavior
 * any other voltage is treated as error condition and triggers the safe state

docs/source/introduction.rst

@@ -25,7 +25,7 @@ The Charge Control Y is an MCS compliant charging controller for Electric Vehicl
 communication between EVSE and PEV it supports Charge Enable, Insertion Detection as well as 10-Base T1S Ethernet communication.
 
 The Charge Control Y is a future-proof powerhouse based on NXP's i.MX93 with universal compatibility, advanced safety
-features and lots of options for customization. It is intended to be used as the core communication coponent for MCS
+features and lots of options for customization. It is intended to be used as the core communication component for MCS
 communication, therefore it is capable of controlling and sensing temperature sensors, HV ready signals and emergency inputs.
 
 The Charge Control Y is provided with a Linux-Yocto operating system. The installed software is based on EVerest,

docs/source/safety_controller.rst

@@ -8,7 +8,7 @@ Overview
 
 The Charge Control Y is equipped with an additional MCU (aka Safety Controller) which is responsible for
 managing all low-level aspects which are critical for electrical safety. The firmware for this MCU is
-developed by chargebyte and is not open-source. The Charge Control Y is shiped with the safety controller firmware
+developed by chargebyte and is not open-source. The Charge Control Y is shipped with the safety controller firmware
 preinstalled.
 
 The host controller firmware, e.g. the Linux system, communicates with the safety controller using an UART.
@@ -72,7 +72,7 @@ Temperature Monitoring
 
 The simplified system architecture shows only one temperature input. In the real system, there are 4 independent
 temperature measurement circuits for PT1000 sensors. The safety software monitors the temperature circuit for
-hardware errors and for overtemperaure. The temperature threshold can be parameterized.
+hardware errors and for overtemperature. The temperature threshold can be parameterized.
 
 
 Reset Behaviour and Controller States
@@ -88,8 +88,14 @@ This state can only be left by a reset.
 .. figure:: _static/images/safety_controller_states.svg
    :width: 1000pt
 
+.. _safety_controller_parameterization:
+
 .. include:: safety_controller_parameterization.rst
 
+.. _safety_controller_uart:
+
 .. include:: safety_controller_uart.rst
 
+.. _safety_controller_everest_bsp:
+
 .. include:: everest_bsp.rst

docs/source/safety_controller_parameterization.rst

@@ -1,5 +1,3 @@
-.. _safety_controller_parameterization.rst:
-
 Safety Controller Parameterization
 ----------------------------------
 
@@ -156,7 +154,7 @@ To check which settings are currently used by the safety controller firmware, it
 
 .. code-block:: sh
 
-   systemctrl stop everest
+    systemctl stop everest
    ra-update -a data dump | ra-pb-dump
 
 This will print the current settings in YAML format on stdout.

docs/source/safety_controller_uart.rst

@@ -1,5 +1,3 @@
-.. _safety_controller_uart.rst:
-
 Safety Controller Communication Protocol
 ----------------------------------------
 

docs/source/troubleshooting.rst

@@ -43,9 +43,9 @@ How do I set up OCPP 2.0.1 on Charge Control Y with EVerest?
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 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
+This module uses the `libocpp library <https://github.com/EVerest/EVerest/tree/main/lib/everest/ocpp>`_ to implement the OCPP 2.0.1
 protocol.
-The `OCPP201 module documentation <https://github.com/EVerest/everest-core/blob/main/modules/EVSE/OCPP201/doc.rst>`_
+The `OCPP201 module documentation <https://github.com/EVerest/EVerest/blob/main/modules/EVSE/OCPP201/docs/index.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.
 
@@ -67,7 +67,7 @@ The most important points are summarised here:
    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
-   place a `component config file <https://github.com/EVerest/libocpp/tree/main/config/v2/component_config>`_
+   place a `component config file <https://github.com/EVerest/EVerest/tree/main/lib/everest/ocpp/config/common/component_config>`_
    in the same directory structure in the DeviceModelConfigPath and change the values accordingly.
    Important keys of the component config files are:
 
@@ -76,7 +76,7 @@ The most important points are summarised here:
    - `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/v2/ocpp_201_device_model_initialization.md>`_.
+   `libocpp documentation <https://github.com/EVerest/EVerest/blob/main/lib/everest/ocpp/doc/v2/ocpp_201_device_model_initialization.md>`_.
 
 
 I tried to compile chargebyte's Hardware EVerest Modules, but it fails to build. How can I fix this?