OCPP version 1.5 requires firmware ≥276 to function properly
Free charging requires firmware ≥300
This version mostly contains the capability for partners to use the self-service portal.
Other changes are bug fixes :
UnlockConnector request SHOULD NOT be used to remotely stop a running transaction, use the RemoteStopTransaction instead.<firmware>/<ocpp-software>. For example 289/1.5.2.0, meaning firmware version 289 on the charger and using OCPP software version 1.5.2.0.0/1 values to configure chargers but our OCPP software would reject these values. This release allows using 0 and 1 as possible values for OCPP configuration keys, in addition to JSON true or false.true and read-only, to allow this policy.Authorise(idTag,0) when an idTag is not authorised. Prior to this, a DeAuthorize(,0) command would be sent instead but that would not result in red LED flash on the charger.A situation could arise where processing of messages from a central system would stop amidst processing offline transactions. This has been resolved by allowing more time to synchronise transaction processing to and from the central systems.
Chargers that have not been connected to Easee cloud (Masterloop) will not be added to the OCPP layer. These caused unneccesary connections to central systems (which end up with rejections, adds noise to logs, and cause confusion).
When retrieving snapshots for a charger, snapshots that only contain old observations are considered stale and will result in the charger being skipped from the OCPP layer. Such an example is a charger that has not connected to Easee cloud and has not been seen on OCPP for 28 days. As soon as a timestamp on an observation is greater than 28 days in the past, a charger will attempt to contact the central system.
Typically, observations update frequently, for example temperature measurements or RSSI values, so the default staleness of 28 days is a safe start and is configurable via an environment setting. We will monitor and tune this in case of false positives.
A severe memory leak was detected after 1.5.1.4 which would eventually take down an OCPP environment given time. For large partners, this means reconnects.
We will allow chargers without a detected power grid type to be added. This has an implication that meter values for energy measurands requiring the power grid type cannot be sent to the central systems until DetectedPowerGridType (observation 21) is received.
Measurands requiring power grid type: Measurand.CurrentImport, Measurand.Voltage
This was a reasonable compromise to 1.5.1.2 where a charger won't be added to OCPP until the DetectedPowerGridType was set.
Shortly after 1.5.1.3 was released our caching infrastructure experienced a lot of timeouts that resulted in crashes in our environments. After adding an additional node to scale the infrastructure, the code around calls to this layer was bolstered with error handling with retries.
We use power grid type in voltage calculations in the OCPP meter registry. Missing enumaration values 34 and 35 caused a some chargers to appear offline. These were added and the chargers can be seen online on OCPP.
PowerGridType 35 = WARNING_IT_1_PHASE_GND_FAULT_L3
PowerGridType 34 = WARNING_IT_3_PHASE_GND_FAULT_L3Although both values are warnings, the charger is still operational. (1.5.1.2 would flag these chargers as offline)
When a charger sends an observation, most of the frequent ones being meter value-related observations, e.g TempMax and RSSI values (cell,WiFi, radio) we update a timestamp and use it to detect the last known online state. A charger is deemed offline if this period is greater than 17 minutes.
Configuration keys from Masterloop were not parsed correctly when compared to string value "true" where the types were boolean and instead set to "1".
BootNotifications are not sent on device reconnect. It is now only sent if one of the following occurrs:
Listen to observations from charger and update OCPP configuration with config changes sent from other sources than OCPP.
Reworked consumption to get raw consumption from charger based start / stop. Requires firmware ≥276.
Two new DataTransfer messages to allow operators to list and import Easee charge sessions if OCPP failed to forward usage, or the CSMS did not accept the initial transaction for any reason.
ListEaseeSessions - Returns an array of session objects similar to OCPP sessions with Start and Stop information, and sequence numbers as set by the device.
ImportEaseeSessions - Returns just DataTransfer status, but will immediately pull in and schedule sessions in the specified timeframe to be reported next time any offline sessions would be reported. Note! Import does not do any checks to see if these sessions have already been reported, use "ListEaseeSessions" to refine timeframe and target only sessions the CSMS failed to receive, or does not know about.
See documentation for full description of example requests and payloads
Added configuration key "MeterValueInTxnSampleData" to provide additional measurands while transactions are active.
Added configuration key "OperatorMaxCurrent" to allow OCPP operator access to "MaxChargerCurrent".
Note!This setting is also available in the local WiFi interface, so can be changed by Home users with a pin code.
{
public enum ReasonForNoCurrent
{
OK = 0, // charger is allocated current
MaxCircuitCurrentTooLow = 1,
MaxDynamicCircuitCurrentTooLow = 2,
MaxDynamicOfflineFallbackCircuitCurrentTooLow = 3,
CircuitFuseTooLow = 4,
WaitingInQueue = 5,
WaitingInFully = 6, // charged queue (charger assumes one of: EV uses delayed charging, EV charging complete)
IllegalGridType = 7,
PrimaryUnitHasNotReceivedCurrentRequestFromSecondaryUnit = 8,
SecondaryUnitNotRequestingCurrent = 50, // no car connected...
MaxChargerCurrentTooLow = 51,
MaxDynamicChargerCurrentTooLow = 52,
ChargerDisabled = 53,
PendingScheduledCharging = 54,
PendingAuthorization = 55,
ChargerInErrorState = 56,
Undefined = 100,
}
}
The list of error codes is likely to be expanded in the near future with new values related to communication with the Equalizer. This these values should be made available in the general API / Partner documentation
OCPP 1.3.0 requires firmware ≥195 to work.