diff --git a/doc/ocmf/powermeter_start_transaction.md b/doc/ocmf/powermeter_start_transaction.md new file mode 100644 index 000000000..efb8b7c0a --- /dev/null +++ b/doc/ocmf/powermeter_start_transaction.md @@ -0,0 +1,52 @@ +```mermaid +sequenceDiagram +autonumber +participant Powermeter +participant EvseManager +participant OCPP +participant CSMS + +title Start of a Transaction + +Note over EvseManager: User plugs in EV and authorizes + +EvseManager->>OCPP: Event(SessionStarted) + +OCPP->>CSMS: StatusNotification.req(Preparing) +CSMS-->>OCPP: StatusNotification.conf + +alt successful case + EvseManager->>Powermeter: startTransaction + Powermeter-->>EvseManager: startTransaction Response (OK/ID) + + EvseManager->>OCPP: Event(TransactionStarted) + OCPP->>CSMS: StartTransaction.req + CSMS-->>OCPP: StartTransaction.conf + + Note over EvseManager: Transaction started successfully + +else startTransaction failing due to power loss + EvseManager->>Powermeter: startTransaction + Powermeter-->>EvseManager: startTransaction Response (FAIL) + + EvseManager->>OCPP: Event(Deauthorized) + + OCPP->>CSMS: StatusNotification.req(Finishing) + CSMS-->>OCPP: StatusNotification.conf + + EvseManager->>OCPP: raiseError (PowermeterTransactionStartFailed) + OCPP->>CSMS: StatusNotification.req(Finishing, PowermeterTransactionStartFailed) + CSMS-->>OCPP: StatusNotification.conf + + Note over EvseManager: Transaction did not start +end + +alt EvseManager configured to become inoperative in case of Powermeter CommunicationError + Powermeter->>EvseManager: raise_error(CommunicationError) + Note over Powermeter,EvseManager: Powermeter raises a CommunicationError
and EvseManager is registered for notification + EvseManager->>OCPP: raise_error (Inoperative) + OCPP->>CSMS: StatusNotification.req(Faulted) + CSMS-->>OCPP: StatusNotification.conf +end + +``` \ No newline at end of file diff --git a/doc/ocmf/powermeter_stop_transaction.md b/doc/ocmf/powermeter_stop_transaction.md new file mode 100644 index 000000000..5c36d14b1 --- /dev/null +++ b/doc/ocmf/powermeter_stop_transaction.md @@ -0,0 +1,46 @@ +```mermaid +sequenceDiagram +autonumber +participant Powermeter +participant EvseManager +participant OCPP +participant CSMS + +title Stopping Transaction in Error + +Note over Powermeter, CSMS: Transaction is running + +Powermeter->>Powermeter: detects a
CommunicationError +Note over Powermeter,EvseManager: Powermeter raises a CommunicationError
and EvseManager is registered for notification +Powermeter->>EvseManager: raise_error (CommunicationFault) +Powermeter->>OCPP: raise_error (CommunicationFault) + +OCPP->>CSMS: StatusNotification.req(Charging, CommunicationFault) +CSMS-->>OCPP: StatusNotification.conf + +alt EvseManager configured to become inoperative in case of PowermeterCommError + EvseManager->>EvseManager: Pause charging + EvseManager->>OCPP: raiseError (Inoperative) + OCPP->>CSMS: StatusNotification.req(Faulted) + Note over EvseManager: Note that we would just continue charging otherwise +end + +Note over Powermeter, CSMS: User stops the transaction + +alt successful case (Powermeter has no CommunicationError) + EvseManager->>Powermeter: stopTransaction (ID) + Powermeter-->>EvseManager: stopTransaction Response (OK/OCMF) + EvseManager->>OCPP: Event(TransactionFinished(OCMF)) + + OCPP->>CSMS: StopTransaction.req(OCMF) + CSMS-->>OCPP: StopTransaction.conf +else stopTransaction failing due to subsequent power loss (this applies as well when Powermeter still in CommunicationError) + EvseManager->>Powermeter: stopTransaction (ID) + Powermeter->>EvseManager: stopTransaction Response (FAIL) + EvseManager->>OCPP: Event(TransactionFinished) + + Note right of OCPP: In this case we can't stop the transaction including the OCMF + OCPP->>CSMS: StopTransaction.req() + CSMS-->>OCPP: StopTransaction.conf +end +``` \ No newline at end of file diff --git a/modules/EvseManager/Charger.cpp b/modules/EvseManager/Charger.cpp index b17c44717..8e205ad76 100644 --- a/modules/EvseManager/Charger.cpp +++ b/modules/EvseManager/Charger.cpp @@ -1205,14 +1205,15 @@ bool Charger::start_transaction() { // we can't bill the customer. if (response.status == types::powermeter::TransactionRequestStatus::UNEXPECTED_ERROR) { EVLOG_error << "Failed to start a transaction on the power meter " << response.error.value_or(""); - error_handling->raise_powermeter_transaction_start_failed_error( - "Failed to start transaction on the power meter"); - return false; + if (true == config_context.fail_on_powermeter_errors) { + error_handling->raise_powermeter_transaction_start_failed_error( + "Failed to start transaction on the power meter"); + return false; + } } } store->store_session(shared_context.session_uuid); - signal_transaction_started_event(shared_context.id_token); return true; } @@ -1324,7 +1325,8 @@ void Charger::setup(bool has_ventilation, const ChargeMode _charge_mode, bool _a bool _ac_hlc_use_5percent, bool _ac_enforce_hlc, bool _ac_with_soc_timeout, float _soft_over_current_tolerance_percent, float _soft_over_current_measurement_noise_A, const int _switch_3ph1ph_delay_s, const std::string _switch_3ph1ph_cp_state, - const int _soft_over_current_timeout_ms, const int _state_F_after_fault_ms) { + const int _soft_over_current_timeout_ms, const int _state_F_after_fault_ms, + const bool fail_on_powermeter_errors) { // set up board support package bsp->setup(has_ventilation); @@ -1344,6 +1346,7 @@ void Charger::setup(bool has_ventilation, const ChargeMode _charge_mode, bool _a config_context.switch_3ph1ph_cp_state_F = _switch_3ph1ph_cp_state == "F"; config_context.state_F_after_fault_ms = _state_F_after_fault_ms; + config_context.fail_on_powermeter_errors = fail_on_powermeter_errors; if (config_context.charge_mode == ChargeMode::AC and config_context.ac_hlc_enabled) EVLOG_info << "AC HLC mode enabled."; diff --git a/modules/EvseManager/Charger.hpp b/modules/EvseManager/Charger.hpp index e2c5e5f1d..6b6918059 100644 --- a/modules/EvseManager/Charger.hpp +++ b/modules/EvseManager/Charger.hpp @@ -106,7 +106,7 @@ class Charger { bool ac_enforce_hlc, bool ac_with_soc_timeout, float soft_over_current_tolerance_percent, float soft_over_current_measurement_noise_A, const int switch_3ph1ph_delay_s, const std::string switch_3ph1ph_cp_state, const int soft_over_current_timeout_ms, - const int _state_F_after_fault_ms); + const int _state_F_after_fault_ms, const bool fail_on_powermeter_errors); bool enable_disable(int connector_id, const types::evse_manager::EnableDisableSource& source); @@ -327,6 +327,8 @@ class Charger { int soft_over_current_timeout_ms{7000}; // Switch to F for configured ms after a fatal error int state_F_after_fault_ms{300}; + // Fail on powermeter errors + bool fail_on_powermeter_errors; } config_context; // Used by different threads, but requires no complete state machine locking diff --git a/modules/EvseManager/ErrorHandling.cpp b/modules/EvseManager/ErrorHandling.cpp index 2f6ac049e..f27b4920f 100644 --- a/modules/EvseManager/ErrorHandling.cpp +++ b/modules/EvseManager/ErrorHandling.cpp @@ -15,6 +15,7 @@ static const struct IgnoreErrors { ErrorList ac_rcd{"ac_rcd/VendorWarning"}; ErrorList imd{"isolation_monitor/VendorWarning"}; ErrorList powersupply{"power_supply_DC/VendorWarning"}; + ErrorList powermeter{}; } ignore_errors; ErrorHandling::ErrorHandling(const std::unique_ptr& _r_bsp, @@ -23,14 +24,16 @@ ErrorHandling::ErrorHandling(const std::unique_ptr& _r_b const std::vector>& _r_ac_rcd, const std::unique_ptr& _p_evse, const std::vector>& _r_imd, - const std::vector>& _r_powersupply) : + const std::vector>& _r_powersupply, + const std::vector>& _r_powermeter) : r_bsp(_r_bsp), r_hlc(_r_hlc), r_connector_lock(_r_connector_lock), r_ac_rcd(_r_ac_rcd), p_evse(_p_evse), r_imd(_r_imd), - r_powersupply(_r_powersupply) { + r_powersupply(_r_powersupply), + r_powermeter(_r_powermeter) { // Subscribe to bsp driver to receive Errors from the bsp hardware r_bsp->subscribe_all_errors([this](const Everest::error::Error& error) { process_error(); }, @@ -59,6 +62,12 @@ ErrorHandling::ErrorHandling(const std::unique_ptr& _r_b r_powersupply[0]->subscribe_all_errors([this](const Everest::error::Error& error) { process_error(); }, [this](const Everest::error::Error& error) { process_error(); }); } + + // Subscribe to powermeter to receive errors from powermeter hardware + if (r_powermeter.size() > 0) { + r_powermeter[0]->subscribe_all_errors([this](const Everest::error::Error& error) { process_error(); }, + [this](const Everest::error::Error& error) { process_error(); }); + } } void ErrorHandling::raise_overcurrent_error(const std::string& description) { @@ -102,7 +111,8 @@ void ErrorHandling::process_error() { const int error_count = p_evse->error_state_monitor->get_active_errors().size() + r_bsp->error_state_monitor->get_active_errors().size() + number_of_active_errors(r_connector_lock) + number_of_active_errors(r_ac_rcd) + - number_of_active_errors(r_imd) + number_of_active_errors(r_powersupply); + number_of_active_errors(r_imd) + number_of_active_errors(r_powersupply) + + number_of_active_errors(r_powermeter); if (error_count == 0) { signal_all_errors_cleared(); @@ -159,6 +169,13 @@ std::optional ErrorHandling::errors_prevent_charging() { } } + if (r_powermeter.size() > 0) { + fatal = is_fatal(r_powermeter[0]->error_state_monitor->get_active_errors(), ignore_errors.powermeter); + if (fatal) { + return fatal; + } + } + return std::nullopt; } diff --git a/modules/EvseManager/ErrorHandling.hpp b/modules/EvseManager/ErrorHandling.hpp index 8db687eaf..056c4a757 100644 --- a/modules/EvseManager/ErrorHandling.hpp +++ b/modules/EvseManager/ErrorHandling.hpp @@ -30,6 +30,7 @@ #include #include #include +#include #include #include "Timeout.hpp" @@ -47,7 +48,8 @@ class ErrorHandling { const std::vector>& r_ac_rcd, const std::unique_ptr& _p_evse, const std::vector>& _r_imd, - const std::vector>& _r_powersupply); + const std::vector>& _r_powersupply, + const std::vector>& _r_powermeter); // Signal that error set has changed. Bool argument is true if it is preventing charging at the moment and false if // charging can continue. @@ -77,6 +79,7 @@ class ErrorHandling { const std::unique_ptr& p_evse; const std::vector>& r_imd; const std::vector>& r_powersupply; + const std::vector>& r_powermeter; }; } // namespace module diff --git a/modules/EvseManager/EvseManager.cpp b/modules/EvseManager/EvseManager.cpp index b269d19bf..46b79f8ce 100644 --- a/modules/EvseManager/EvseManager.cpp +++ b/modules/EvseManager/EvseManager.cpp @@ -161,8 +161,13 @@ void EvseManager::ready() { bsp->set_ev_simplified_mode_evse_limit(true); } + // we provide the powermeter interface to the ErrorHandling only if we need to react to powermeter errors + // otherwise we provide an empty vector of pointers to the powermeter interface + const std::vector> empty; error_handling = std::unique_ptr( - new ErrorHandling(r_bsp, r_hlc, r_connector_lock, r_ac_rcd, p_evse, r_imd, r_powersupply_DC)); + new ErrorHandling(r_bsp, r_hlc, r_connector_lock, r_ac_rcd, p_evse, r_imd, r_powersupply_DC, + config.fail_on_powermeter_errors ? r_powermeter_billing() : empty)); + if (not config.lock_connector_in_state_b) { EVLOG_warning << "Unlock connector in CP state B. This violates IEC61851-1:2019 D.6.5 Table D.9 line 4 and " "should not be used in public environments!"; @@ -888,7 +893,7 @@ void EvseManager::ready() { config.ac_hlc_use_5percent, config.ac_enforce_hlc, false, config.soft_over_current_tolerance_percent, config.soft_over_current_measurement_noise_A, config.switch_3ph1ph_delay_s, config.switch_3ph1ph_cp_state, config.soft_over_current_timeout_ms, - config.state_F_after_fault_ms); + config.state_F_after_fault_ms, config.fail_on_powermeter_errors); } telemetryThreadHandle = std::thread([this]() { @@ -1074,7 +1079,8 @@ void EvseManager::setup_fake_DC_mode() { charger->setup(config.has_ventilation, Charger::ChargeMode::DC, hlc_enabled, config.ac_hlc_use_5percent, config.ac_enforce_hlc, false, config.soft_over_current_tolerance_percent, config.soft_over_current_measurement_noise_A, config.switch_3ph1ph_delay_s, - config.switch_3ph1ph_cp_state, config.soft_over_current_timeout_ms, config.state_F_after_fault_ms); + config.switch_3ph1ph_cp_state, config.soft_over_current_timeout_ms, config.state_F_after_fault_ms, + config.fail_on_powermeter_errors); types::iso15118_charger::EVSEID evseid = {config.evse_id, config.evse_id_din}; @@ -1113,7 +1119,8 @@ void EvseManager::setup_AC_mode() { charger->setup(config.has_ventilation, Charger::ChargeMode::AC, hlc_enabled, config.ac_hlc_use_5percent, config.ac_enforce_hlc, true, config.soft_over_current_tolerance_percent, config.soft_over_current_measurement_noise_A, config.switch_3ph1ph_delay_s, - config.switch_3ph1ph_cp_state, config.soft_over_current_timeout_ms, config.state_F_after_fault_ms); + config.switch_3ph1ph_cp_state, config.soft_over_current_timeout_ms, config.state_F_after_fault_ms, + config.fail_on_powermeter_errors); types::iso15118_charger::EVSEID evseid = {config.evse_id, config.evse_id_din}; diff --git a/modules/EvseManager/EvseManager.hpp b/modules/EvseManager/EvseManager.hpp index fc4ba9825..0a2728ff8 100644 --- a/modules/EvseManager/EvseManager.hpp +++ b/modules/EvseManager/EvseManager.hpp @@ -102,6 +102,7 @@ struct Conf { int soft_over_current_timeout_ms; bool lock_connector_in_state_b; int state_F_after_fault_ms; + bool fail_on_powermeter_errors; }; class EvseManager : public Everest::ModuleBase { @@ -136,8 +137,7 @@ class EvseManager : public Everest::ModuleBase { r_imd(std::move(r_imd)), r_powersupply_DC(std::move(r_powersupply_DC)), r_store(std::move(r_store)), - config(config) { - } + config(config){}; Everest::MqttProvider& mqtt; Everest::TelemetryProvider& telemetry; @@ -194,7 +194,7 @@ class EvseManager : public Everest::ModuleBase { const std::vector>& r_powermeter_billing(); - // FIXME: this will be removed with proper intergration of BPT on ISO-20 + // FIXME: this will be removed with proper integration of BPT on ISO-20 // on DIN SPEC and -2 we claim a positive charging current on ISO protocol, // but the power supply switches to discharge if this flag is set. std::atomic_bool is_actually_exporting_to_grid{false}; diff --git a/modules/EvseManager/doc.rst b/modules/EvseManager/doc.rst index 4fb00fc31..08927b586 100644 --- a/modules/EvseManager/doc.rst +++ b/modules/EvseManager/doc.rst @@ -6,20 +6,20 @@ EvseManager See also module's :ref:`auto-generated reference `. -The module ``EvseManager`` is a central module that manages one EVSE +The module ``EvseManager`` is a central module that manages one EVSE (i.e. one connector to charge a car). It may control multiple physical connectors if they are not usable at the same time and share one connector id, -but one EvseManager always shows as one connector in OCPP for example. So in +but one EvseManager always shows as one connector in OCPP for example. So in general each connector should have a dedicated EvseManager module loaded. -The EvseManager contains the high level charging logic (Basic charging and -HLC/SLAC interaction), collects all relevant data for the charging session -(e.g. energy delivered during this charging session) and provides control over -the charging port/session. For HLC it uses two helper protocol modules that it +The EvseManager contains the high level charging logic (Basic charging and +HLC/SLAC interaction), collects all relevant data for the charging session +(e.g. energy delivered during this charging session) and provides control over +the charging port/session. For HLC it uses two helper protocol modules that it controls (SLAC and ISO15118). -Protocol modules such as OCPP or other APIs use EvseManagers to control the +Protocol modules such as OCPP or other APIs use EvseManagers to control the charging session and get all relevant data. The following charge modes are supported: @@ -32,7 +32,7 @@ Additional features: * Autocharge support (PnC coming soon) * Seamlessly integrates into EVerest Energy Management -* The lowest level IEC61851 state machine can be run on a dedicated +* The lowest level IEC61851 state machine can be run on a dedicated microcontroller for improved electrical safety * Support for seperate AC and DC side metering in DC application @@ -47,18 +47,18 @@ AC Configuration DC Configuration ---------------- -In DC applications, the EvseManager still has an AC side that behaves similar -to a normal AC charger. The board_support module therefore still has to report +In DC applications, the EvseManager still has an AC side that behaves similar +to a normal AC charger. The board_support module therefore still has to report AC capabilities which refer to the AC input of the AC/DC power supply. If an AC -side RCD is used it also belongs to the board_support driver. -An AC side power meter can be connected and it will be used for Energy +side RCD is used it also belongs to the board_support driver. +An AC side power meter can be connected and it will be used for Energy management. In addition, on the DC side the following hardware modules can be connected: -* A DC powermeter: This will be used for billing purposes if present. +* A DC powermeter: This will be used for billing purposes if present. If not connected, billing will fall back to the AC side power meter. -* Isolation monitoring: This will be used to monitor isolation during +* Isolation monitoring: This will be used to monitor isolation during CableCheck, PreCharge and CurrentDemand steps. * DC power supply: This is the AC/DC converter that actually charges the car. @@ -68,16 +68,16 @@ Published variables session_events -------------- -EvseManager publishes the session_events variable whenever an event happens. -It does not publish its internal state but merely events that happen that can +EvseManager publishes the session_events variable whenever an event happens. +It does not publish its internal state but merely events that happen that can be used to drive an state machine within another module. -Example: Write a simple module that lights up an LED if the evse is reserved. -This module requires an EvseManager and subscribes to the session_events -variable. Internally it has only two states: Reserved (LED on), NotReserved +Example: Write a simple module that lights up an LED if the evse is reserved. +This module requires an EvseManager and subscribes to the session_events +variable. Internally it has only two states: Reserved (LED on), NotReserved (LED off). -The state machine transitions are driven by the two events from EvseManager: +The state machine transitions are driven by the two events from EvseManager: ReservationStart and ReservationEnd. All other events are ignored in this module as they are not needed. @@ -85,10 +85,10 @@ All other events are ignored in this module as they are not needed. powermeter ---------- -EvseManager republishes the power meter struct that if it has a powermeter -connected. This struct should be used for OCPP and display purposes. It comes -from the power meter that can be used for billing (DC side on DC, AC side on -AC). If no powermeter is connected EvseManager will never publish this +EvseManager republishes the power meter struct that if it has a powermeter +connected. This struct should be used for OCPP and display purposes. It comes +from the power meter that can be used for billing (DC side on DC, AC side on +AC). If no powermeter is connected EvseManager will never publish this variable. @@ -96,9 +96,9 @@ Authentication ============== The Auth modules validates tokens and assignes tokens to EvseManagers, see Auth -documentation. It will call ``Authorize(id_tag, pnc)`` on EvseManager to -indicated that the EvseManager may start the charging session. -Auth module may revoke authorization (``withdraw_authorization`` command) if +documentation. It will call ``Authorize(id_tag, pnc)`` on EvseManager to +indicated that the EvseManager may start the charging session. +Auth module may revoke authorization (``withdraw_authorization`` command) if the charging session has not begun yet (typically due to timeout), but not once charging has started. @@ -107,79 +107,79 @@ Autocharge / PnC ---------------- Autocharge is fully supported, PnC support is coming soon and will use the same -logic. The car itself is a token provider that can provide an auth token to be -validated by the Auth system (see Auth documentation for more details). +logic. The car itself is a token provider that can provide an auth token to be +validated by the Auth system (see Auth documentation for more details). EvseManager provides a ``token_provider`` interface for that purpose. -If external identification (EIM) is used in HLC (no PnC) then Autocharge is +If external identification (EIM) is used in HLC (no PnC) then Autocharge is enabled by connecting the ``token_provider`` interface to Auth module. When the -car sends its EVCCID in the HLC protocol it is converted to Autocharge format +car sends its EVCCID in the HLC protocol it is converted to Autocharge format and published as Auth token. It is based on the following specification: https://github.com/openfastchargingalliance/openfastchargingalliance/blob/master/autocharge-final.pdf -To enable PnC the config option ``payment_enable_contract`` must be set to -true. If the car selects Contract instead of EIM PnC will be used instead of +To enable PnC the config option ``payment_enable_contract`` must be set to +true. If the car selects Contract instead of EIM PnC will be used instead of Autocharge. Reservation ----------- -Reservation handling logic is implemented in the Auth module. If the Auth -module wants to reserve a specific EvseManager (or cancel the reservation) it -needs to call the reserve/cancel_reservation commands. EvseManager does not -check reservation id against the token id when it should start charging, this -must be handled in Auth module. EvseManager only needs to know whether it is +Reservation handling logic is implemented in the Auth module. If the Auth +module wants to reserve a specific EvseManager (or cancel the reservation) it +needs to call the reserve/cancel_reservation commands. EvseManager does not +check reservation id against the token id when it should start charging, this +must be handled in Auth module. EvseManager only needs to know whether it is reserved or not to emit an ReservatonStart/ReservationEnd event to notify other -modules such as OCPP and API or e.g. switch on a specific LED signal on the +modules such as OCPP and API or e.g. switch on a specific LED signal on the charging port. Energy Management ================= -EvseManager seamlessly intergrates into the EVerest Energy Management. +EvseManager seamlessly intergrates into the EVerest Energy Management. For further details refer to the documentation of the EnergyManager module. -EvseManager has a grid facing Energy interface which the energy tree uses to -provide energy for the charging sessions. New energy needs to be provided on -regular intervals (with a timeout). +EvseManager has a grid facing Energy interface which the energy tree uses to +provide energy for the charging sessions. New energy needs to be provided on +regular intervals (with a timeout). If the supplied energy limits time out, EvseManager will stop charging. -This prevents e.g. overload conditions when the network connection drops +This prevents e.g. overload conditions when the network connection drops between the energy tree and EvseManager. -EvseManager will send out its wishes at regular intervals: It sends a -requested energy schedule into the energy tree that is merged from hardware -capabilities (as reported by board_support module), EvseManager module -configuration settings -(max_current, three_phases) and external limts (via ``set_external_limits`` +EvseManager will send out its wishes at regular intervals: It sends a +requested energy schedule into the energy tree that is merged from hardware +capabilities (as reported by board_support module), EvseManager module +configuration settings +(max_current, three_phases) and external limts (via ``set_external_limits`` command) e.g. set by OCPP module. Note that the ``set_external_limits`` should not be used by multiple modules, as the last one always wins. If you have multiple sources of exernal limits -that you want to combine, add extra EnergyNode modules in the chain and +that you want to combine, add extra EnergyNode modules in the chain and feed in limits via those. -The combined schedule sent to the energy tree is the minimum of all energy +The combined schedule sent to the energy tree is the minimum of all energy limits. -After traversing the energy tree the EnergyManager will use this information -to assign limits (and a schedule) -for this EvseManager and will call enforce_limits on the energy interface. +After traversing the energy tree the EnergyManager will use this information +to assign limits (and a schedule) +for this EvseManager and will call enforce_limits on the energy interface. These values will then be used -to configure PWM/DC power supplies to actually charge the car and must not +to configure PWM/DC power supplies to actually charge the car and must not be confused with the original wishes that -were sent to the energy tree. +were sent to the energy tree. -The EvseManager will never assign energy to itself, it always requests energy +The EvseManager will never assign energy to itself, it always requests energy from the energy manager and only charges if the energy manager responds with an assignment. Limits in the energy object can be specified in ampere (per phase) and/or watt. -Currently watt limits are unsupported, but it should behave according to that +Currently watt limits are unsupported, but it should behave according to that logic: -If both are specified also both limits will be applied, whichever is lower. +If both are specified also both limits will be applied, whichever is lower. With DC charging, ampere limits apply to the AC side and watt limits apply to both AC and DC side. @@ -230,12 +230,13 @@ This module subscribes to all errors of the following requirements: * ac_rcd * isolation_monitor * power_supply_DC +* powermeter (if the config option fail_on_powermeter_errors is set true) A raised error can cause the EvseManager to become Inoperative. This means that charging is not possible until the error is cleared. If no charging session is currently running, it will prevent sessions from being started. If a charging session is currently running and an error is raised this will interrupt the charging session. -Almost all errors that are reported from the requirements of this module cause the EvseManager to become Inoperative until the error is cleared. +Almost all errors that are reported from the requirements of this module cause the EvseManager to become Inoperative until the error is cleared. The following sections provide an overview of the errors that do **not** cause the EvseManager to become Inoperative. evse_board_support @@ -265,4 +266,8 @@ power_supply_DC * power_supply_DC/VendorWarning +powermeter +---------- + +* powermeter/CommunicationFault diff --git a/modules/EvseManager/manifest.yaml b/modules/EvseManager/manifest.yaml index 1c912d700..512b5405a 100644 --- a/modules/EvseManager/manifest.yaml +++ b/modules/EvseManager/manifest.yaml @@ -192,7 +192,7 @@ config: default: 0.5 hack_fix_hlc_integer_current_requests: description: >- - Some cars request only integer ampere values during DC charging. For low power DC charging that + Some cars request only integer ampere values during DC charging. For low power DC charging that means that they charge a few hundred watts slower then needed. If enabled, this will charge at full power if the difference between EV requested current (integer) and HLC current limit is less then 1.0 type: boolean @@ -257,8 +257,8 @@ config: default: 10 switch_3ph1ph_cp_state: description: >- - CP state to use for switching. - WARNING: Some EVs may be permanently destroyed when switching from 1ph to 3ph. + CP state to use for switching. + WARNING: Some EVs may be permanently destroyed when switching from 1ph to 3ph. It is the responsibiltiy of the evse_board_support implementation to ensure the EV is capable of performing the switch. If it is not, the capabilities must set the supports_changing_phases_during_charging to false. Phase switching is only possible in basic charging mode. @@ -283,7 +283,7 @@ config: description: >- Set state F after any fault that stops charging for the specified time in ms while in Charging mode (CX->F(300ms)->C1/B1). When a fault occurs in state B2, no state F is added (B2->B1 on fault). - Some (especially older hybrid vehicles) may go into a permanent fault mode once they detect state F, + Some (especially older hybrid vehicles) may go into a permanent fault mode once they detect state F, in this case EVerest cannot recover the charging session if the fault is cleared. In this case you can set this parameter to 0, which will avoid to use state F in case of a fault and only disables PWM (C2->C1) while switching off power. This will violate IEC 61851-1:2017 however. @@ -291,6 +291,11 @@ config: This setting is only active in BASIC charging mode. type: integer default: 300 + fail_on_powermeter_errors: + description: >- + Set the EVSE Manager to an inoperative state if the powermeter requirement is configured and has reported errors + type: boolean + default: true provides: evse: interface: evse_manager