OpenFMBIssues #7190
Change request for the ChargingStateKind
0%
Description
*Background:
In the current definition of the “ChargingStateKind” enum within the OpenFMB specification, the value “ChargingStateKind_Idle” is assigned the value “0”. While this accurately represents the idle state of an EVSE, it introduces a functional ambiguity when used in Protocol Buffers. In protobuf, the default value of an enum field is always `0`, and this value is implicitly used when the field is unset. This makes it difficult to distinguish between an intentionally set “Idle” state and an uninitialized or unknown value.
*Current Enum Definition:
enum ChargingStateKind
{
ChargingStateKind_Idle = 0;
ChargingStateKind_Charging = 1;
ChargingStateKind_EVConnected = 2;
ChargingStateKind_SuspendedEV = 3;
ChargingStateKind_SuspendedEVSE = 4;
}
Proposed Solution
*Proposed Change:
To resolve the ambiguity and enhance clarity when handling default and unknown enum values, it is proposed to:
1. Introduce a new value “ChargingStateKind_UNDEFINED = 0” to explicitly represent an unknown or uninitialized state.
2. Bump all existing values by 1, starting with “ChargingStateKind_Idle = 1”.
*Proposed Enum Definition:
enum ChargingStateKind
{
ChargingStateKind_UNDEFINED = 0; // Represents an unknown or uninitialized state
ChargingStateKind_Idle = 1; // No connection between EV and EVSE
ChargingStateKind_Charging = 2; // Energy is flowing between EVSE and EV
ChargingStateKind_EVConnected = 3; // EV is physically connected to EVSE
ChargingStateKind_SuspendedEV = 4; // EV is connected but not drawing power
ChargingStateKind_SuspendedEVSE = 5; // EVSE is not offering energy to EV
}
Related issues
Updated by Owen Wu about 1 month ago
- Related to OpenFMBIssues #7137: 2.2 Data Model Final Testing Phase added