❗️
OCPP version 1.5 requires firmware ≥276 to function properly
Free charging requires firmware ≥300

1.5.6

Added Easee One to free charging
Fixed bug when reporting session energy without disconnecting the car between sessions

1.5.5

Consolidated the use of KWh and Wh in reporting
Added support for AllowOfflineTxForUnknownId
Added back off time to reconnect attempts, reducing the amount of failing connections from a charger
Automatically poll chargers for the power grid type if it is unknown
Fixed bug where only latest offline transaction would be processed
Added support for free charging
Updates to scheduling, using api instead of masterloop

1.5.3

This version mostly contains the capability for partners to use the self-service portal.
Other changes are bug fixes :

Fix crash when reboot received observation is received
Fix crash when remote transaction stop is confirmed

1.5.2

*Bug fixes

Unlock connector

Central System can request a Charge Point to unlock a connector. In case of malfunction of the Connector cable retention, this feature helps drivers who have problems unplugging their cable from the charge point.
- Note 1: If the car is still connected and charging when unlock connector is requested, the connector would eventually unlock when it is safe - unplug the cable from the car.
- Note 2: The UnlockConnector request SHOULD NOT be used to remotely stop a running transaction, use the RemoteStopTransaction instead.

Boot notification with version

Occasionally the firmware version would omit the OCPP software version when responding to a firmware update event. This has been fixed in 1.5.2 and all boot notifications will have the firmware reported in the full format: <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.

Offline transaction processing

A situation would occur where offline charging session(s) from the charger would be submitted to the cloud and cause a breakdown of communication between the charger and the central system. Restarting the OCPP service was the only remedy in 1.5.1.8. This has now been fixed. Offline charging sessions will continue to be submitted outside active charging sessions (state Finishing or Available).
- Note: Please utilise DataTransfer (if available on the central system) to import missing charging sessions, in case this bug caused some gaps in data.

Send deauthorize commands with idTags

Most stop charging (deauthorize) commands sent to the charger would have a missing idTag. This made it difficult to track which idTag stopped the charging session. Version 1.5.2 will now try to collect/re-collect any idTag information and append them to the commands, where possible.

*Improvements

Boot notification detection

It was previously possible not to send a boot notification when one was required. This version will always check our persistence for last boot information.

Better information in logs

In most log entries, for better filtering and metrics we will now add:
- Partner name and Id
- OCPP software version
- Serial number (Use this simplified view for OCPP logs)

Service shutdown

During maintenance when an OCPP service is being shutdown or restarted, chargers will now attempt to gracefully disconnect from central systems. This avoids a scenario where a new connection may not be established before the prior one is terminated.

Boolean configuration values

We spotted that some central systems use 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.

Engineering

Run on latest version of dotnet (v6.0) meaning better CPU and memory performance all-round
Reduce the size of the containerized OCPP software image. The 1.5.2 image is 3 times smaller than version 1.5.1.8, leading to quicker deployments - less data downloaded for each environment.
Improve the security of the containerized OCPP software image
Move OCPP code repository to a new independent structure. This should unlock better automation, more testing and ability to run on different dotnet framework versions.

*Features

Offline charging

Always allow offline charging when Easee Cloud/ OCPP central system connection is unreachable. The (OCPP) AllowOfflineTxForUnknownId configuration key is now set to true and read-only, to allow this policy.

Flash red LED when authorisation rejected

This version sends the charger a command 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.

Easee One charger support

Version 1.5.2 allows the Easee One charger to be correctly identified during boot via the model number forwarded in the Boot Notification request message.

Initial OCPP self-service portal support

A lot of engineering effort was undertaken to allow implementation of the upcoming OCPP self-service portal for partners.
- Introduce a more stable persistence that can be shared with the self-service portal. This will allow the whole environment or individual chargers to be controlled, leading to better operation and troubleshooting for partners.

1.5.1.8

Fix communication loss
- An issue (similar to 1.5.1.6) would arise where the OCPP software would stop communicating with the central system.
Online detection
- For every observation received from the charger, we will update a timestamp so that OCPP software can detect the presence of a charger.
- Related, if we do not receive any telemetry from the charger within 17 minutes, the OCPP software will transition to an offline state (disconnect from the central system to save resources). A regression was introduced, meaning the previous software would keep chargers online indefinitely. (Expect a more accurate state to be reflected after this release)
- When charger is disabled (Availability = Inoperative), the software did not allow the charger to transition to an offline state. This has been rectified.
Clean up unsupported features
- GetDiagnostics and Reservation OCPP features are not currently implemented. Requesting these features would previously not return a call error message nor reply. We will now indicate (according to the 1.6 standard) that we do not support them.
  - GetDiagnostics: return empty file name if charge point is not configured to report GetDiagnostics
  - ReserveNow: reject status in confirmation message if reservation feature is not available.
Fix missing boot notification
- At times, when recovering from offline state, rebooting the charger did not result in a boot notification. This has been fixed.

1.5.1.7

Fix start/stop transaction reporting issues
- Chargers could get stuck on SuspendedEVSE and hold on to their transactions for offline processing. They awaited to get to Available or Finishing status before reporting the stop transaction event, but never got to these states due to being stuck SuspendedEVSE.
Fix remote start/stop issues
- A situation could occur where the web socket connection could stop receiving messages from the central system. A fix implemented to make sure an error during message processing does not stop the subscription to receive web socket channel.
- We now also allow remote start to attempt to start charging even though we are in SuspendedEVSE.
- Fix missing de-authorise transaction when authorisation is revoked after a transaction has started
Upgrade to latest version of Masterloop Plugin Application (cloud-to-device channel)

1.5.1.6

Unable to process offline transactions

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.

Uninstalled chargers

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).

Old snapshots

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.

1.5.1.5

Memory leak and meter values

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.

1.5.1.4

Error handling and retries after Redis scale out

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.

1.5.1.3

Update to Detected Power Grid Type

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_L3

Although both values are warnings, the charger is still operational. (1.5.1.2 would flag these chargers as offline)

Any power grid types outside the known range, including empty or 0 will cause the charger not to be added to the OCPP layer. These are usually non-installed chargers, e.g in storage.

1.5.1.2

Charger online detection via meter values

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.

Parse Central System device URLs from configuration (known issue introduced after 1.5.0) thus allowing custom URL schemes to work
Add subscription to Command SetMaxChargerCurrent

1.5.1.1

Fix configuration keys read back

Configuration keys from Masterloop were not parsed correctly when compared to string value "true" where the types were boolean and instead set to "1".

1.5.0

BootNotifications are not sent on device reconnect. It is now only sent if one of the following occurrs:
1. Device has never successfully booted in OCPP
2. Device CSMS endpoint changes
3. On Observation from the device that the device has physically rebooted
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.

Default configuration is now "MeterValues" are only sent while transactions are active. If RSSI, Temp etc. are desired outside of transactions let us know.
Fixes an issue where Status goes to Available if charger is rebooted in state Unavailable.
Added a readonly key "ChargerRAT" to allow observation of the radio access technology (RAT) the charger is using. (Cellular=0, WiFi=1)