Implemented cloud-support for ChargingProfile purpose type 'TxProfile'

Caveats:

• TxProfile functionality limited to online chargers
• No stacking support for TxProfile
• Only absolute schedule type is supported
• Prior behaviour of ChargePointMaxProfile and TxDefaultProfile remains unchanged
• Schedules (periods and limits) created by TxDefaultProfile are not removed/reset and can interfere with TxProfile limits. In case of conflicts, attempt to clear these limits and re-apply TxProfile.

FAQs/Remarks:

This is a best effort implementation for ChargingProfile of type TxProfile meaning we support a basic implementation that does not cover all hardened scenarios.

Due to the cloud proxy architecture, the resulting current limits set by TxProfile requests will be propagated to the chargers as soon as they appear online, and the scheduled period is relevant. We will forward the request to the chargers and retry up to 3 times.

There could be other current limits competing with the TxProfile for example through an API call (a non-OCPP path) to the same charger with different current limits or limits set by an external/local energy management device. In this case the lowest limit takes precedence. Multiple chargers on the same circuit can use their load balancing functionality and therefore the effect might not be what the TxProfile limits intended.

We will continue to monitor and improve this feature but are aware that the direct OCPP implementation path is superior and has less issues to a cloud proxy implementation.

Examples can be found Here

• Changed the handling of the 'MeterValuesSampledData' configuration key to configure which measurands are sent. As before, we only send configured measurands during transactions and if 'MeterValueSampleInterval' is configured and non-zero. By default, as per OCPP 1.6 spec, we will send the Energy.Active.Import.Register measurand. Custom configuration value 'MeterValuesInTxnSampledData' is not required anymore and marked as 'NotSupported'. (2025-01-13)
• Added new configuration key 'SampledDataSignReadings' to specify if charging session signature should be included within 'StopTransaction' requests, with default value set to false. See more information here https://developer.easee.com/docs/supported-configuration (2025-01-13)
• Send 'BootNotification' message when a charger is paired to an operator, even when the charger was paired to the operator at some point in the past (2025-04-09)
• Fixed chargers changing state to 'Available' when fatal error was detected. Such chargers will remain in state 'Faulted' until error is resolved (2025-07-14)

• Improved resource management for WebSocket connections by disposing a connection before creating a new one. (2023-11-06)
• Improved the transaction retry mechanism by removing duplicate checks and by starting timeout count down after message is sent via WebSocket. Previously, transactional messages timed-out and retried after a fixed period of 2 minutes. Then, the value of TransactionMessageRetryInterval from configuration was used to determine timeout. With this improvement, only the values of TransactionMessageRetryInterval and TransactionMessageAttempts are used for retries. (2023-11-06)
• Added retry mechanism to offline transactions. (2023-11-06)
• Removed bounce back delay on chargers going online. Charger will be displayed as online within few minutes upon establishing successful WebSocket connection. Previously, there was a delay of 15 minutes or more. (2024-03-05)
• Added additional internal error codes to StatusNotification VendorErrorCode property. If you get these, please contact our partner integration team to get explanation. (2024-06-05)
• Added support for chargers running on local ocpp, so that operator can use both cloud and local solutions under the same registration. (2024-06-05)
• Added support for Charge Max, which as a MID compliant charging device signs charging sessions and submits the signatures for end user verification. The signature is included in StopTransaction request message as additional MeterValue item in transactionData property (2024-09-18)

To cover a potential security issue, we are updating our authentication/authorization services to correctly handle refresh tokens.
This change, will likely cause issues with integrations that have cached refresh tokens.
Because this is an area that can be exploited we urge any integration operator/partner using our APIs to use standard practice and request a new refresh token, and implement fall back logic if they fail to obtain valid tokens.

Questions and answers

My refresh token is still not expired, but yet I fail to get a new access token. Is this a bug?

A refresh token might not have expired yet, but it could still be rejected by our Auth system for a variety of reasons:

• A refresh token can be used only once. After that, the newest refresh token must be used the next time.
• A refresh token is always linked to a session in our Auth system. The token will be rejected if the related session has been removed for whatever reason (session has been idle for too long, or it has been explicitly revoked, or lost due a technical error, etc)

Whenever you fail to obtain a new pair of tokens using your refresh tokens you should fallback to username and password again.

Does this mean users have to re-enter their credentials in third party apps?

It depends. Only do this if experiencing issues. We do not recommend using Easee credentials on any other system or app other than ones owned or recommended by Easee. If your integration does not work, you will need to re-authorize to gain new credentials.

Do I need to renew all tokens?

No. There is a chance that sessions will be revoked in this update. When that happens, your integration will likely see errors. You should implement retry-logic and catch these scenarios and after some failures, request new tokens.

What other alternatives do we have?

We are exploring industry standards e.g OAuth when it comes to authN/Z. We will update you when this is decided along with a date and timeline.

1.7.3

• Added support for RegistrationStatus types Pending and Rejected on BootNotification confirmation (2023-05-25)
• Fixed residual OCPP configurations for chargers that have moved from one operator to another. When operator pairing events are received, we will clear OCPP configuration and wait to receive a new set (2023-06-28)
• Fixed BootNotification retry mechanisms for chargers that have not being previously accepted by the servers. (2023-08-04)
  • More details: Previously the same BootNotification message could be sent several times, with this fix a new one is sent with increased timeout from 1 minute to 3 minutes
• Fixed concurrent offline charging session handling. Charging session (start/stop) events arriving with the same timestamps will be added to an offline buffer and handled appropriately (2023-08-07)
  • More details: Sometimes start and stop charging sessions arrive from the charger with the same timestamp. This has ended up sending two StartTransaction requests for the same session. With this fix, we wait a bit before sending a StartTransaction request to give central system more time to reply.

1.7.2

• Improved handling of UnlockConnector command (available with firmware version 310)
• Improved reconnection
• Added StatusNotification for ConnectorId = 0 with TriggerMessage command (configurable and turned off by default)
• Extended AuthReason with FreeCharging in StartTransactionReq
• Added a fix for chargers which entered Preparing state before going offline that would transition to SuspendedEVSE after coming back online
• Fixed transaction stop duplication check, it will not send multiple requests for the same charging session anymore

1.7.1

• Added support for larger partners
• Added stricter control on change between FreeCharging/AuthorizationRequired
• Fixed OCPP behaviour when charger is set to Unavailable
• Fixed memory leak causing crashes
• Fixed bug where OCPP would go to wrong state when a transaction times out while car is connected
• Fixed bugs that could produce duplicate transaction messages
• Other various bug fixes

SignalR URI Change.

• The SignalR URI has changed from api.easee.cloud/hubs to streams.easee.com/hubs
  Please ensure you update your records to reflect this change.

1.7.0

• Internal infrastructure changes
• Fixed bug where wrong transaction id could stop charging
• Fixed bug where charging schedules were not being cleared correctly
• Other various bug fixes

1.6.0

• Added new OCPP Websocket connection layer (OCPP Proxy)
• Batch connecting of chargers when OCPP service starts
• Fixed bug with high precision time formats
• Fixed bug where charger could get in a offline/booting loop
• Fixed bug where OCPP service would crash for larger partners
• Other various bug fixes