max_current in claim or override not taken into account if set before starting charge

[KipK]

spotted a bug on claim engine, if you set a claim with max_current set to a lower value than max_current_soft , then when upgrading the claim state to active, it will start the charge with full power ignoring the max_current properties in the claim. Resending a claim after set state: active will then works.

how to reproduce:

• POST a claim ( over http or mqtt) with {state: "disable"}
• plug the car
• POST a claim with only {max_current: 6}
• POST a claim with {state: "disable"} Charge will start at 32A or what your max_current_soft is set in config instead of 6A
• POST a claim with {max_current: 6}
• now it charges OK at 6A

[pdhoogh]

This looks similar to #450 ?

[jeremypoulter]

@KipK This will behave differently over HTTP vs MQTT I believe due to the issues you point out in #376, but I am not totally sure I get what you are trying to accomplish, should the second POST {state: "disable"} be {state: "active"} ? is so what you are reporting is exactly what I would expect for HTTP.

Can you get the content of /claims after each step, think you will see the POST with {state: "disable"} overriding the {max_current: 6}

[KipK]

@jeremypoulter nope I don't think it's related. it's the same result with HTTP or MQTT. Forget the merged point ( for HTTP i send all the attributes ), I've checked the claims before and after using http api, all the parameters are ok in the claims but it always ignore the max_current settings first.

For info, we use max_current to set a lower charge max for the session, while shaper use charge_current ( and if there's a max_current claim, it will modulate inbetween this new max_current )

Try to set a claim with disable and max_current set to a lower value. Then set the claim to enable keeping max_current value too,, it will start at full charge. /claims looks ok: ( the max_current claim is the 65537 client

[
    {
        "client": 65540,
        "priority": 10,
        "state": "disabled",
        "auto_release": false
    },
    {
        "client": 65537,
        "priority": 500,
        "state": "active",
        "max_current": 12,
        "auto_release": false
    },
    {
        "client": 65548,
        "priority": 5000,
        "charge_current": 39,
        "auto_release": false
    }
]

[jeremypoulter]

The current shaper should really be using the max_current as well so it can interoperate with the solar PV for example. Maybe the max_current should behave slightly differently to the rest of the properties and the lowest value should win rather than the highest priority? I couldn't replicate the issue however, there is defiantly some weird interaction between starting charge and the current

[KipK]

That could be a good idea yes. I don't know if there could have some collaterals therefore.

Here are the claims when stopped:

   {
        "client": 65540,
        "priority": 100,
        "state": "active",
        "auto_release": false
    },
    {
        "client": 65548,
        "priority": 5000,
        "charge_current": 34,
        "auto_release": false
    },
    {
        "client": 65537,
        "priority": 500,
        "state": "disabled",
        "max_current": 6,
        "auto_release": true
    }

Then the claims when activated ( start charging at 32A)

	[
    {
        "client": 65540,
        "priority": 100,
        "state": "active",
        "auto_release": false
    },
    {
        "client": 65548,
        "priority": 5000,
        "charge_current": 39,
        "auto_release": false
    },
    {
        "client": 65537,
        "priority": 500,
        "state": "active",
        "max_current": 6,
        "auto_release": true
    }
]

and the claims when I set again the max_current , charge ok at 6A ( exactly the same ):

[
    {
        "client": 65540,
        "priority": 100,
        "state": "active",
        "auto_release": false
    },
    {
        "client": 65548,
        "priority": 5000,
        "charge_current": 41,
        "auto_release": false
    },
    {
        "client": 65537,
        "priority": 500,
        "state": "active",
        "max_current": 6,
        "auto_release": true
    }
]

Disabling shaper still brings the same issue btw

[jeremypoulter]

@KipK thanks, can you also let me know the /status and /claims/target ?

[KipK]

I have removed shaper on this one:

• When Stopped:

• /claims [ { "client": 65540, "priority": 10, "state": "disabled", "auto_release": false }, { "client": 65537, "priority": 500, "state": "disabled", "max_current": 6, "auto_release": true } ]

• /claims/target:

{ "properties": { "state": "disabled", "max_current": 6, "auto_release": false }, "claims": { "state": 65537, "max_current": 65537 } }

• /status

{ "mode": "STA", "wifi_client_connected": 1, "eth_connected": 0, "net_connected": 1, "ipaddress": "192.168.1.8", "emoncms_connected": 0, "packets_sent": 0, "packets_success": 0, "mqtt_connected": 1, "ocpp_connected": 0, "rfid_failure": 0, "ohm_hour": "NotConnected", "free_heap": 197912, "comm_sent": 85349, "comm_success": 85348, "rapi_connected": 1, "evse_connected": 1, "amp": 0, "voltage": 225, "pilot": 6, "wh": 541430, "session_energy": 0, "total_energy": 541.43, "temp": 225, "temp_max": 225, "temp1": false, "temp2": 225, "temp3": false, "temp4": 370, "state": 254, "status": "disabled", "flags": 1792, "vehicle": 1, "colour": 6, "manual_override": 1, "freeram": 197912, "divertmode": 1, "srssi": -81, "time": "2022-10-25T08:48:08Z", "offset": "+0100", "elapsed": 0, "wattsec": 0, "watthour": 541430, "gfcicount": 0, "nogndcount": 0, "stuckcount": 0, "solar": 0, "grid_ie": 0, "charge_rate": 0, "divert_update": 38176, "divert_active": false, "shaper": 0, "shaper_live_pwr": 342, "shaper_chg_cur": 40, "service_level": 2, "ota_update": 0, "config_version": 0, "schedule_version": 2, "schedule_plan_version": 4, "vehicle_state_update": 16023, "tesla_vehicle_count": false, "tesla_vehicle_id": false, "tesla_vehicle_name": false, "battery_level": 90, "battery_range": 354, "time_to_full_charge": 0 }

• When Active:

• /claims: [ { "client": 65540, "priority": 10, "state": "disabled", "auto_release": false }, { "client": 65537, "priority": 500, "state": "active", "max_current": 6, "auto_release": true } ]

• /claims/target:

{ "properties": { "state": "active", "max_current": 6, "auto_release": false }, "claims": { "state": 65537, "max_current": 65537 } }

• /status

{ "mode": "STA", "wifi_client_connected": 1, "eth_connected": 0, "net_connected": 1, "ipaddress": "192.168.1.8", "emoncms_connected": 0, "packets_sent": 0, "packets_success": 0, "mqtt_connected": 1, "ocpp_connected": 0, "rfid_failure": 0, "ohm_hour": "NotConnected", "free_heap": 197504, "comm_sent": 85364, "comm_success": 85363, "rapi_connected": 1, "evse_connected": 1, "amp": 0, "voltage": 224, "pilot": 6, "wh": 541430, "session_energy": 0, "total_energy": 541.43, "temp": 226, "temp_max": 226, "temp1": false, "temp2": 226, "temp3": false, "temp4": 375, "state": 2, "status": "active", "flags": 1792, "vehicle": 1, "colour": 3, "manual_override": 1, "freeram": 197504, "divertmode": 1, "srssi": -80, "time": "2022-10-25T08:49:48Z", "offset": "+0100", "elapsed": 0, "wattsec": 0, "watthour": 541430, "gfcicount": 0, "nogndcount": 0, "stuckcount": 0, "solar": 0, "grid_ie": 0, "charge_rate": 0, "divert_update": 38276, "divert_active": false, "shaper": 0, "shaper_live_pwr": 362, "shaper_chg_cur": 40, "service_level": 2, "ota_update": 0, "config_version": 0, "schedule_version": 2, "schedule_plan_version": 4, "vehicle_state_update": 16123, "tesla_vehicle_count": false, "tesla_vehicle_id": false, "tesla_vehicle_name": false, "battery_level": 90, "battery_range": 354, "time_to_full_charge": 0 }

Same outputs goes when sending again max_power while Active & charging correctly at 6A

[fhteagle]

"Maybe the max_current should behave slightly differently to the rest of the properties and the lowest value should win rather than the highest priority?" Reference #401 : This is the easiest for end users to comprehend, to be sure.

If claim priority is going to continue to be the driver in the logic, then ordering the rows inside of the Mode: AUTO section of the new GUI by descending priority would greatly help user comprehension of what is going on.

[pdhoogh]

Hmmmm.... I am of a slightly different opinion. Max current should be the high current limit in any mode. In FAST mode, the EVSE puts in Max current. In ECO mode, the EVSE works as intended and as it did in 4.1.4. : PV Divert. In a new TBD mode, EVSE puts in current up to a set limit on import power and limited to Max current.

That is in my humble opinion best for customer understanding. As the option is called "Current Shaper" and following similar logic to PV Divert, TBD could be "Shaper".

FAST is if you need the charge now and ASAP. ECO is if you want to minimize cost of charge. SHAPE is if you want to limit grid load, following new legislation.

It remains to be seen if legislation will force SHAPE to be ON at all times. In that case, we may indeed need to combine the limits and have a Max Current and a Max Gridload limit simultaneously active at all times. Then the used limit should be the minimum of both Max Current and the result of the current shaper without the need for an etra mode. I agree that would indeed be the better approach in case the shaper function becomes mandatory.

[fhteagle]

Hi @pdhoogh , I referenced issue #401 , which is a fresh start rethink of the GUI. If I am reading what you wrote correctly, I think you have similar ideas to what is discussed there already. But you may be seeing it differently enough to have a better idea yet. Please read and comment on #401 if you get a chance. Thanks.

[KipK]

This bug has bad consequencies. All charge will always start at full amp ignoring Shaper max_current until shaper report a new claim. I could see my 9kw power plan going to 14kw for 30 sec until shaper report a new one.