API for EVerest API clients implementing evse board support, AC RCD and connector lock.
default local MQTT
The ID of the module as defined in the EVerest config file.
Direction: EVerest to Module
Available only on servers:
Accepts the following message:
Enables or disables the charging port. Typically disabled results in control pilot state F. It must not accept cars for new charging sessions if disabled.
True: enabled. False: disabled.
Direction: EVerest to Module
Available only on servers:
Accepts the following message:
Turns PWM on with duty cycle (in percent)
PWM duty cycle
Direction: EVerest to Module
Available only on servers:
Accepts the following message:
Turn PWM off (constant high voltage)
Direction: EVerest to Module
Available only on servers:
Accepts the following message:
Turn PWM off with error F (constant negative voltage)
Direction: EVerest to Module
Available only on servers:
Accepts the following message:
Sets allow_power_on flag. If false, Relais must never be switched on.
Flag and context for switching power on/off. In some architectures e.g. DC power train needs to know whether it should switch on with limited current or full current on the output contactors.
{
"allow_power_on": true,
"reason": "DCCableCheck"
}
Direction: EVerest to Module
Available only on servers:
Accepts the following message:
Optional, in case of doubt do not implement. Report in hardware_capabilites if this command is supported. This command switches between one and three phase operation during an active charging session. Some cars can be permanently destroyed by that, so the bsp needs to implement a special sequence for the switching. The exact sequence can be defined by the BSP, but one example would be a C2->C1->B1->F->B1->B2->C2 or similar. Use with caution.
Number of active phases for AC charging
ThreePhases
Direction: EVerest to Module
Available only on servers:
Accepts the following message:
Optional, in case of doubt do not implement. Special command initiate a virtual replug sequence of adjustable duration without restarting session. Emits a EvseReplugStarted event if supported and started. BSP will take care to not emit other events such as CarPluggedIn/Out during that time. Once finished it will emit a EvseReplugFinished. This is mainly for testing purposes, don't implement for production use.
Duration in milliseconds (ms)
Direction: EVerest to Module
Available only on servers:
Accepts the following message:
Many chargers implement a fast over current shutdown directly in the hardware that triggers if the EV draws more current than the PWM allows. If the hardware does not have this functionality, just ignore this command. Do not use it to set the PWM duty cycle. Otherwise this command reports a value that should be used for the overcurrent detection. A margin needs to be added to avoid false triggers. Do not use the PWM duty cycle to infer the current limit in the BSP, as this will not work with HLC.
Electrical current in ampere (A)
Accepts the following message:
Event from ControlPilot signal/out relais
Event stream from ControlPilot signal/relais.
{
"event": "A"
}
Direction: Module to EVerest
Available only on servers:
Accepts the following message:
Instantaneous phase count available to car
Number of phases
Direction: Module to EVerest
Available only on servers:
Accepts the following message:
Hardware capabilities/limits. Initially EvseManager will call get_hw_capabilities once to fetch the limits and caches the limits internally. The BSP module does not have to publish this variable at all, then the initially fetched capabilities will be used. The BSP may publish this variable to update limits in case they change during runtime, e.g. if the maximum current changes because the hardware gets too hot.
Hardware capabilities / limits
{
"max_current_A_import": 5,
"min_current_A_import": 1,
"max_phase_count_import": 3,
"min_phase_count_import": 1,
"max_current_A_export": 10,
"min_current_A_export": 1,
"max_phase_count_export": 3,
"min_phase_count_export": 1,
"supports_changing_phases_during_charging": true,
"max_plug_temperature_C": 80,
"connector_type": "IEC62196Type2Cable"
}
Accepts the following message:
Current carrying capacity of the connected cable in ampere for AC charging with a socket. Publish whenever it changes. This has no meaning for DC or AC charging with a fixed attached cable, it does not need to be implemented and the returned value is not used in those cases.
Current capability (ampacity) of the cable
{
"ampacity": "None"
}
Direction: Module to EVerest
Available only on servers:
Accepts the following message:
Publish to stop the transaction gracefully (e.g. user pressed the stop button)
Request for a stop transaction containing the reason and an optional id tag
{
"reason": "Local"
}
Accepts the following message:
Executes a self test of the RCD. If it fails, an error of type Selftest should be raised.
Accepts the following message:
Reply to provided topic.
{
"headers": {
"replyTo": "everest_api/1.0/{interface_type}/{module_id}/e2m/{operation_name}/{uuid}"
}
}
Accepts the following message:
Resets the RCD after a trigger. May not be supported by actual hardware.
Success: true, failure: false
Direction: Module to EVerest
Available only on servers:
Accepts the following message:
Residual current in mA. Note that this does not trigger anything, it is merely for reporting.
Electrical current in milliampere (mA)
Accepts the following message:
Accepts the following message:
Unlock connector lock. (e.g. normal unlaock or enforced by OCPP)
Direction: Module to EVerest
Available only on servers:
Accepts the following message:
Signal to EVerest that an error happened.
Errors for the evse_board_support interface. All error codes that begin with MREC needs to be implemented to fulfill the Minimum Required Error Codes defined by the ChargeX consortium: https://inl.gov/content/uploads/2023/07/ChargeX_MREC_Rev5_09.12.23.pdf
{
"type": "DiodeFault",
"sub_type": "string",
"message": "string"
}
Accepts the following message:
Signal to EVerest that a previously raised error is no longer active.
Errors for the evse_board_support interface. All error codes that begin with MREC needs to be implemented to fulfill the Minimum Required Error Codes defined by the ChargeX consortium: https://inl.gov/content/uploads/2023/07/ChargeX_MREC_Rev5_09.12.23.pdf
{
"type": "DiodeFault",
"sub_type": "string",
"message": "string"
}
Direction: EVerest to Module
Available only on servers:
Accepts the following message:
Heartbeat produced by EVerest as configured via cfg_heartbeat_interval_ms in the EVerest configuration
64bit unsigned integer. The id of every heartbeat increases by 1 and overflows when the maximum representable value is reached
Heartbeat
Accepts the following message:
Signal to EVerest that communication is good or check shall be stopped
Send 'true' at least every 'cfg_communication_check_to_s' seconds to signal module is alive. Send 'false' to stop communication check'
Enables or disables the charging port. Typically disabled results in control pilot state F. It must not accept cars for new charging sessions if disabled.
True: enabled. False: disabled.
Turns PWM on with duty cycle (in percent)
PWM duty cycle
Turn PWM off (constant high voltage)
Turn PWM off with error F (constant negative voltage)
Sets allow_power_on flag. If false, Relais must never be switched on.
Flag and context for switching power on/off. In some architectures e.g. DC power train needs to know whether it should switch on with limited current or full current on the output contactors.
Optional, in case of doubt do not implement. Report in hardware_capabilites if this command is supported. This command switches between one and three phase operation during an active charging session. Some cars can be permanently destroyed by that, so the bsp needs to implement a special sequence for the switching. The exact sequence can be defined by the BSP, but one example would be a C2->C1->B1->F->B1->B2->C2 or similar. Use with caution.
Number of active phases for AC charging
Optional, in case of doubt do not implement. Special command initiate a virtual replug sequence of adjustable duration without restarting session. Emits a EvseReplugStarted event if supported and started. BSP will take care to not emit other events such as CarPluggedIn/Out during that time. Once finished it will emit a EvseReplugFinished. This is mainly for testing purposes, don't implement for production use.
Duration in milliseconds (ms)
Many chargers implement a fast over current shutdown directly in the hardware that triggers if the EV draws more current than the PWM allows. If the hardware does not have this functionality, just ignore this command. Do not use it to set the PWM duty cycle. Otherwise this command reports a value that should be used for the overcurrent detection. A margin needs to be added to avoid false triggers. Do not use the PWM duty cycle to infer the current limit in the BSP, as this will not work with HLC.
Electrical current in ampere (A)
Event from ControlPilot signal/out relais
Event stream from ControlPilot signal/relais.
Instantaneous phase count available to car
Number of phases
Hardware capabilities/limits. Initially EvseManager will call get_hw_capabilities once to fetch the limits and caches the limits internally. The BSP module does not have to publish this variable at all, then the initially fetched capabilities will be used. The BSP may publish this variable to update limits in case they change during runtime, e.g. if the maximum current changes because the hardware gets too hot.
Hardware capabilities / limits
Current carrying capacity of the connected cable in ampere for AC charging with a socket. Publish whenever it changes. This has no meaning for DC or AC charging with a fixed attached cable, it does not need to be implemented and the returned value is not used in those cases.
Current capability (ampacity) of the cable
Publish to stop the transaction gracefully (e.g. user pressed the stop button)
Request for a stop transaction containing the reason and an optional id tag
Executes a self test of the RCD. If it fails, an error of type Selftest should be raised.
Reply to provided topic.
Resets the RCD after a trigger. May not be supported by actual hardware.
Success: true, failure: false
Residual current in mA. Note that this does not trigger anything, it is merely for reporting.
Electrical current in milliampere (mA)
Unlock connector lock. (e.g. normal unlaock or enforced by OCPP)
Signal to EVerest that an error happened.
Errors for the evse_board_support interface. All error codes that begin with MREC needs to be implemented to fulfill the Minimum Required Error Codes defined by the ChargeX consortium: https://inl.gov/content/uploads/2023/07/ChargeX_MREC_Rev5_09.12.23.pdf
Signal to EVerest that a previously raised error is no longer active.
Errors for the evse_board_support interface. All error codes that begin with MREC needs to be implemented to fulfill the Minimum Required Error Codes defined by the ChargeX consortium: https://inl.gov/content/uploads/2023/07/ChargeX_MREC_Rev5_09.12.23.pdf
Heartbeat produced by EVerest as configured via cfg_heartbeat_interval_ms in the EVerest configuration
64bit unsigned integer. The id of every heartbeat increases by 1 and overflows when the maximum representable value is reached
Signal to EVerest that communication is good or check shall be stopped
Send 'true' at least every 'cfg_communication_check_to_s' seconds to signal module is alive. Send 'false' to stop communication check'
Number of active phases for AC charging
Event stream from ControlPilot signal/relais.
Electrical current in milliampere (mA)
Duration in milliseconds (ms)
True: enabled. False: disabled.
Hardware capabilities / limits
Electrical current in ampere (A)
Number of phases
Flag and context for switching power on/off. In some architectures e.g. DC power train needs to know whether it should switch on with limited current or full current on the output contactors.
Current capability (ampacity) of the cable
PWM duty cycle
Success: true, failure: false
Type of error
Errors for the evse_board_support interface. All error codes that begin with MREC needs to be implemented to fulfill the Minimum Required Error Codes defined by the ChargeX consortium: https://inl.gov/content/uploads/2023/07/ChargeX_MREC_Rev5_09.12.23.pdf
Send 'true' at least every 'cfg_communication_check_to_s' seconds to signal module is alive. Send 'false' to stop communication check'
64bit unsigned integer. The id of every heartbeat increases by 1 and overflows when the maximum representable value is reached