Difficulty Setting Charging Profile After Clearing an Existing Profile for Dynamic Load Balancing

[maneshwarantino]

Hello Mikuso,

I am encountering an issue when trying to set a charging profile dynamically during an ongoing charging session. Specifically, after clearing an existing profile, I'm finding it challenging to set a new profile, which is crucial for my dynamic load balancing logic.

My Load Balancing Logic:

Determine the Load Balancing Requirement:

• Initially, I fetch the charging station's status to see if load balancing is activated.
• If load balancing is enabled, I proceed to fetch all the active charging sessions for the station.

Calculate the Available and Current Load:

• I calculate the available load for the charging station and also the load currently being outputted by all active charging points.
• Then, I loop through the list of active charging sessions to determine which one started first. The intention behind this is to prioritize and potentially avoid load balancing for the earliest charging session.

Apply Load Balancing Logic:

• If the total current load and the calculated load for a new session exceed the available load, load balancing is triggered.
• For each active charging client, I attempt to clear their existing charging profile using makeClearChargingProfileRequest.
• Post clearing, I try to set a new charging profile using makeSetChargingProfileRequest with a new, calculated limit.

The crux of the problem lies here:

• After successfully clearing the profile during an active session, setting a new profile isn't succeeding.

Questions:

1. Is my load balancing logic sound concerning the workings of OCPP and the library? If not, please provide guidance on any modifications or best practices.

2. Why might the setting of a new profile fail after clearing an existing one during an ongoing session? Are there any intricacies or restrictions in the OCPP standard or this library that I might be overlooking?

I appreciate any assistance or insights you can offer.
This functionality is pivotal to our system's performance and user experience.
Thank you in advance!

Logs and what kind of different profiles and scenarios I have tried till now

• Before charging: https://docs.google.com/document/d/1bM5v0ncpPov5f-Kpj3iZSaZP87kTkPlt3izNzdgbrVY/edit?usp=sharing
• While charging: https://docs.google.com/document/d/1Y8yzEFXPCnDUGzpTqww9IQv6aIXf9FSSVHx7Qh5HqII/edit#heading=h.juem9rjx6ycr

[mikuso]

This issue is out of scope for this module, but I'll try to help if I can.

Assuming you have the strictMode option enabled on the RPCServer, then you can be sure that your payloads are at least syntactically valid.

I cannot see anything obviously wrong in the charging profiles in your scenario docs. My initial impression is that this may simply be a case of a poor implementation of smart charging by the charge point (- this is more common than you might think). It may be that the charger only supports setting charging profiles outside of a transaction.

Here's a few things you could investigate:

• Is the initial profile being respected? (i.e. are you seeing the rate limits being applied as you'd expect for this initial charging profile?)
• Are you able to set a TxDefaultProfile for the connector using SetChargingProfile before any transaction is started? (- you should be able to)
• Can you try testing using Amps instead of Watts as the charging rate unit?

[maneshwarantino]

Hey @mikuso

I've come back after further investigations.

1. Initial profile is being respected i.e. when making a RemoteStartTransaction request, whatever limit I give is being respected by the charger, and the expected limit is being applied.
2. ABB chargers are failing to accept the default profile with this default request.
   7.4kw, 22kw

{
    "connectorId": 1,
    "csChargingProfiles": {
        "chargingProfileId": 1,
        "stackLevel": 1,
        "chargingProfilePurpose": "TxDefaultProfile",
        "chargingProfileKind": "Relative",
        "chargingSchedule": {
            "chargingRateUnit": "A",
            "chargingSchedulePeriod": [
                {
                    "startPeriod": 0,
                    "limit": 16
                }
            ]
        }
    }
}

3. Previously when using Watts in RemoteStartTransaction it was even failing to respect the limit. But since I'm using Amps now that problem got solved. Thanks for that. Still, the SetChargingProfile doesn't work even though I use Amps.