You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As far as I know, a ChargeParameterDiscoveryReq must always have either the ac_ev_charge_parameter or the dc_ev_charge_parameter present and based on that we know that we need either to transit to PowerDelivery or CableCheck.
Currently, we do the right jump, but at the beginning of the ChargeParameterDiscovery, we continue to check which message have we received, when we know that if we remain in this state we will only receive a ChargeParameterDiscovery message.
classChargeParameterDiscovery(StateSECC):
""" The ISO 15118-2 state in which the SECC processes an ChargeParameterDiscoveryReq message from the EVCC. The EVCC may send one of the following requests in this state: 1. a ChargeParameterDiscoveryReq 2. a PowerDeliveryReq (AC) 3. a CableCheckreq (DC) Upon first initialisation of this state, we expect a ChargeParameterDiscoveryReq, but after that, the next possible request could be either another ChargeParameterDiscoveryReq (if EVSEProcessing=Ongoing in the ChargeParameterDiscoveryRes) or a PowerDeliveryReq. So we remain in this state until we know which is the following request from the EVCC and then transition to the appropriate state (or terminate if the incoming message doesn't fit any of the expected requests). As a result, the create_next_message() method might be called with next_state = None. """def__init__(self, comm_session: SECCCommunicationSession):
super().__init__(comm_session, Timeouts.V2G_SECC_SEQUENCE_TIMEOUT)
self.expecting_charge_parameter_discovery_req=Truedefprocess_message(
self,
message: Union[
SupportedAppProtocolReq,
SupportedAppProtocolRes,
V2GMessageV2,
V2GMessageV20,
V2GMessageDINSPEC,
],
):
msg=self.check_msg_v2(
message,
[ChargeParameterDiscoveryReq, PowerDeliveryReq, CableCheckReq],
self.expecting_charge_parameter_discovery_req,
)
ifnotmsg:
returnifmsg.body.power_delivery_req:
PowerDelivery(self.comm_session).process_message(message)
returnifmsg.body.cable_check_req:
CableCheck(self.comm_session).process_message(message)
returncharge_params_req: ChargeParameterDiscoveryReq= (
msg.body.charge_parameter_discovery_req
)
ifcharge_params_req.requested_energy_modenotin (
self.comm_session.evse_controller.get_supported_energy_transfer_modes(
Protocol.ISO_15118_2
)
): # noqa: E501self.stop_state_machine(
f"{charge_params_req.requested_energy_mode} not "f"offered as energy transfer mode",
message,
ResponseCode.FAILED_WRONG_ENERGY_TRANSFER_MODE,
)
returnself.comm_session.selected_energy_mode=charge_params_req.requested_energy_modeself.comm_session.selected_charging_type_is_ac= (
self.comm_session.selected_energy_mode.value.startswith("AC")
)
max_schedule_entries: Optional[
int
] =charge_params_req.max_entries_sa_schedule_tupleac_evse_charge_params: Optional[ACEVSEChargeParameter] =Nonedc_evse_charge_params: Optional[DCEVSEChargeParameter] =Noneifcharge_params_req.ac_ev_charge_parameter:
ac_evse_charge_params= (
self.comm_session.evse_controller.get_ac_evse_charge_parameter()
)
departure_time=charge_params_req.ac_ev_charge_parameter.departure_timeelse:
dc_evse_charge_params= (
self.comm_session.evse_controller.get_dc_evse_charge_parameter()
)
departure_time=charge_params_req.dc_ev_charge_parameter.departure_timeifnotdeparture_time:
departure_time=0sa_schedule_list=self.comm_session.evse_controller.get_sa_schedule_list(
max_schedule_entries, departure_time
)
signature=Nonenext_state=Noneifsa_schedule_list:
self.comm_session.offered_schedules=sa_schedule_listifcharge_params_req.ac_ev_charge_parameter:
next_state=PowerDeliveryelse:
next_state=CableCheck
The text was updated successfully, but these errors were encountered:
As far as I know, a ChargeParameterDiscoveryReq must always have either the
ac_ev_charge_parameter
or thedc_ev_charge_parameter
present and based on that we know that we need either to transit toPowerDelivery
orCableCheck
.Currently, we do the right jump, but at the beginning of the
ChargeParameterDiscovery
, we continue to check which message have we received, when we know that if we remain in this state we will only receive aChargeParameterDiscovery
message.The text was updated successfully, but these errors were encountered: