open_evse_esp32 Release v5.1.5 bug - no way to disable charing with Energy limit set

[eagle360]

OpenEVSE 8.2.2
OpenEVSE Wifi v5.1.5

Setting an Energy Limit on the main control screen forces OpenEVSE to activate charging outside of schedule times. And on top of that the "activate" "auto" "deactivate" control is dimmed so there is no way to deactivate the charger at all. Only way to deactivate it is to delete the Energy limit.

Reverted to v5.1.4

http://openevse/limit
type "energy"
value 1000
auto_release true

http://openevse/status
mode "STA"
wifi_client_connected 1
eth_connected 0
net_connected 1
ipaddress "192.168.5.45"
macaddress "xx:xx:xx:xx:xx:xx"
emoncms_connected 0
packets_sent 0
packets_success 0
mqtt_connected 1
ocpp_connected 0
rfid_failure 0
ohm_hour "NotConnected"
free_heap 133728
comm_sent 531
comm_success 525
rapi_connected 1
evse_connected 1
amp 5940
voltage 241.22
power 1432.8468
pilot 6
max_current 25
temp 75
temp_max 75
temp1 false
temp2 75
temp3 false
temp4 false
state 3
status "active"
flags 1344
vehicle 1
colour 6
manual_override 1
freeram 133728
divertmode 1
srssi -69
time "2026-01-12T02:49:19Z"
local_time "2026-01-11T21:49:19-0500"
offset "-0500"
uptime 181
session_elapsed 353
session_energy 332.9487604
total_energy 3986.786292
total_day 0.386231798
total_week 0.386231798
total_month 0.386231798
total_year 0.386231798
total_switches 2231
elapsed 353
wattsec 1198615.538
watthour 3986786.292
gfcicount 0
nogndcount 4
stuckcount 0
solar 0
grid_ie 2473
charge_rate 0
divert_update 1
divert_active false
shaper 0
shaper_live_pwr 2473
shaper_cur -2.23925541
shaper_updated true
service_level 2
limit true
ota_update 0
config_version 1
claims_version 5
override_version 3
schedule_version 2
schedule_plan_version 3
limit_version 2
vehicle_state_update 181
tesla_vehicle_count false
tesla_vehicle_id false
tesla_vehicle_name false

[peibolm]

I encountered the same problem by using battery percentage limit. It overrides any existing schedule and starts charging. Also reverted to 5.1.4

[jeremypoulter]

This is expected behaviour those limits act as a kind of boost and start charging right away, the previous behaviour was a bug. You probably want to set a persistent limit in the settings that will apply to all sessions

[peibolm]

That's right. My car doesn't have any clean/easy way to limit the SOC so I let the oevse do it. I've been testing some mods in limit.cpp in order to get the previous behaviour, but unless you change your mind I won't create a pull request. Respect!

[jeremypoulter]

Have you tried setting the limits in the settings? I think this will do what you want and you won't have to set it up every time you connect the vehicle

[peibolm]

Yes, my limit doesn't go away after every session. The problem is that with the persistent limit up everytime I arrive home and plug the car it starts charging in expensive hours. I guess the only thing that would fix this issue would be to have an option to prioritize schedule over limits or not, depending on the behaviour needed.

[jeremypoulter]

Ok there is a bug there then, while the limit on the main page should take immediate effect, the persistent limit should not and should work with the schedule/divert etc

[eagle360]

I'm not sure what the use case would be for limits on the main page to override schedules. If you wanted this behavior you would set the limit and then set the charge mode to Enabled. Otherwise you set the charge limit and Auto controls charging. I would think v5.1.4 would be the expected behavior.

In our case we use the main limit (temporary) to set how much to charge during the next session based on the schedules (nighttime). With the v5.1.5 behavior there is no way to achieve this since the charging will start when the limit is set during peak rates.

As a side note if the persistent connection issues with WiFi could be resolved then a remote HA system could control this behavior independent of the built in controls. As it is the built in controls need to function properly for the regular times the WiFi connection drops out.

[jeremypoulter]

The expected use case for the limit of the home screen is a kind of boost, eg you are on empty and need to do a small charge for an hour or so. IIRC the process you suggested won't work as that disables all the automated features including the Limit but I would have to double check the priorities.

[eagle360]

The process I suggested does work and has worked since v5.1.2. This "boost" functionality that your are describing is completely new in v5.1.5 and if this was intended to be a "boost" function then it should be named Boost not Limit. And in that case it should be an additional function to the existing Limit function as they are two completely different functions. Don't eliminate a useful functional to implement a new function. Add it as a new function.

[KipK]

I'm agree this new behavior feels inapropriate and should be addressed. It also completely break many use cases ( charge only at low cost hours, when the home battery is full , etc )
Limits had been ported from the evse fw to wifi fw, keeping the same behavior.
It has not much sense to assimilate Limits now to a Boost feature.

There's already a Boost button that has been added on the new incoming UI from @RAR,that will be pretty confusing. ( double boost ? :) )

[jeremypoulter]

I agree that it has caused confusion and does need to be resolved, but I don't agree that it is a separate feature, was in there from day one as a use case of limits. Also going right back when limits were implemented in the safty firmware, these could only be set when changing. The difference is just if the charge starts right way or the limit is applied to the next session. I would still argue that the correct way to apply a limit to the next session is to use the settings so they persist, but that is not how people want to do it.

So in summary the limits pre-5.1.5 were not for for either boost (didn't start the charge) or temporary limit to the next session (not saved) so we just need to let the client select which of the 3 modes the limit should be, right away, next session only or all sessions. You can present that however you wish in the UI.

I would however be interested to know how you are implementing boost without using limits? I assume you are just setting a manual override that clears after the session? That would indeed work but have difficulty seen chargers where you can also limit the change by time/power/etc as part of the 'boost'

[RAR]

Its browser side. so it carries a obvious negative: Refresh mid-boost and the timer is lost — the charger stays in "On" until the user flips the mode manually.

1. Defensively clear any user /limit first. A residual limit claim (priority 1100) silently holds state ownership even when /limit returns {}, which would mask the override and keep the device sleeping. (System/default limits are never deleted — firmware only re-applies those at boot or config write, so deleting would silently discard the configured limit.)
2. Snapshot the current /override so it can be restored later (empty = "Auto").
3. POST /override with { state: 'active', charge_current: max_current_soft, auto_release: false }. The auto_release: false is critical — the device defaults to true when omitted, which (verified on live hardware) releases the manual claim shortly after acceptance, letting a residual limit claim re-emerge and pin state=disabled.When the duration elapses (or the user hits Cancel): a client-side setTimeout fires and restores the snapshotted override (re-uploaded with auto_release: false) or clears the override entirely if there was none.

So @jeremypoulter's solution is WAY better, "set override active + time limit (apply right away)", survives page refreshes and composing with energy limits.

[KipK]

@jeremy I get your point with the persistent limit. But the use case we're talking about is not about next session but current one. I consider a new session when the car is plugued in. That's when we set the limit, IE you arrive home, plug your car, set the limit according your needs for next day, get to sleep and let the thing doing its job when its appropriated.
I haven't thought yet on how we can solve booth worlds, for sure there's a solution we can figure out.
For now it looks broken for this usage.

Add the persistent option on main limit for this won't be really talkative to users for such common use case as we're talking about the current session, and we perhaps set different limits every day.