Charge_session switch reverts to off within seconds when toggled manually with surplus mode disabled

[SergioMonC]

Environment

• Integration version: 2.23.0
• Home Assistant: 2026.8.2 (Home Assistant OS 18.2, Supervisor 2026.07.5)
• Charger: 7.4 kW single-phase, profile depow_v2, protocol 3.5

Description

Wednesday afternoon, at a site with little sun left: I started a charging session. With solar surplus mode on, charging speed was very slow, as expected with minimal surplus. I then disabled solar surplus mode (Enable solar surplus mode unchecked) to charge normally instead — this paused the charger.

I tried to resume by turning the charge_session switch on manually from Home Assistant (card_role: charge_session; I've renamed the entity on my instance to switch.cargador_ev_charging_session). When I toggle it:

1. All the integration's entities briefly go Unavailable, as if the integration reloads or the coordinator restarts.
2. A couple of seconds later everything comes back, and the switch has reverted to off.

This happens repeatably — every manual attempt to turn it on ends the same way.

Expected

With surplus mode disabled, toggling the charge_session switch on should start and hold a normal charging session, without the entities going unavailable and without the switch reverting on its own.

Actual

The charging session switch cannot be turned on manually while surplus mode is disabled in this scenario — it flips back to off within seconds of every attempt, entities go Unavailable in between, which suggests something is reloading in response to the toggle.

Notes

• I found tuya_ev_charger.force_charge_for ("Force charge for a duration") in Developer Tools → Actions. Its description reads "Charge unconditionally for a number of minutes, ignoring surplus regulation", and it takes an optional fixed Current parameter. Does it still respect Maximum inverter output / Maximum house power in this scenario, per the fix described in Feature request: cap charging current against total inverter output, not just grid import #22 for 2.13.1? I haven't tested it yet and want to confirm the intended behaviour first.
• Separately: would it be worth surfacing force-charge somewhere more visible, e.g. a button or field directly in the integration's options/device page, rather than only as an action under Developer Tools? I only found it by searching there — it's not obvious it exists otherwise, and it seems like a natural fallback when the switch doesn't behave as expected.
• Happy to pull logs from around a toggle attempt, or diagnostics, if useful. Let me know what would help most given the Unavailable symptom — that part especially doesn't feel like normal surplus-mode gating.

[sailorontherocks]

I have an issue related to this. I'll document it here as soon as I have time.

[sailorontherocks]

So looping back here on my previous comment:

Context:

• I use the portable V2 charger with the integration, with the schedule set to my EV charging off-peak hours.
• I track charging costs daily, weekly, monthly, yearly, highlighting peak and off-peak. I do that custom in HA, and use the instant power readings from the charger to calculate the consumption and cost over time.
• I also monitor and control the charging & costs on a LCD screen in my house, thanks to the fantastic espcontrol project from James Tenniswood.
• Among those controls, I created custom scripts which leverage the integration, to force-start charging the car outside of the defined off-peak hours.

This is an example of a script I use to force a charging session for 6H at 9A. I can trigger the scrip directly from my espcontrol screen, which is great:

force_charge_ev_6h_9a:
  alias: Force charge EV for 6 hours at 9A
  description: Temporarily bypass scheduling and restore its previous state
  mode: restart

  sequence:
    - variables:
        schedule_was_enabled: >
          {{ is_state('switch.tuya_ev_charger_scheduled_charging', 'on') }}

    - action: switch.turn_off
      target:
        entity_id: switch.tuya_ev_charger_scheduled_charging

    - delay:
        seconds: 4

    - action: tuya_ev_charger.force_charge_for
      data:
        duration_minutes: 360
        current_a: 9

    - delay:
        hours: 6

    - if:
        - condition: template
          value_template: "{{ schedule_was_enabled }}"
      then:
        - action: switch.turn_on
          target:
            entity_id: switch.tuya_ev_charger_scheduled_charging

The few seconds delay is needed for the charger to be ready for the next action.

This is the best way I have found to reliably start a charging session, and put things back to where they were when the session is over.
This works in v2.22.0 but not anymore in v2.23.0. I had to rollback to v2.22.0.

[lachand]

Thanks both for the detail here — two separate things to answer.

@SergioMonC, on the switch reverting to off: I found a real mechanism, though I can't yet fully confirm it's exactly what you hit. switch.surplus_mode is backed by a config-entry option, not just a runtime flag — flipping it calls hass.config_entries.async_update_entry(...), and this integration's update listener reloads the entire integration on any options change (same for every number/select option and two services). That's the "all entities briefly Unavailable" symptom, and it's not new to this release — it's been there a long time.

charge_session itself doesn't touch options, and the surplus-disabled gate is inert (writes nothing) once surplus mode is off, so nothing in the regulation logic should be fighting your manual toggle on its own. The most likely explanation is a race: the charger accepts exactly one local connection, and if your charge_session toggle lands while the reload from disabling surplus mode is still tearing down/rebuilding that connection, the write can get lost, and the freshly-rebuilt coordinator's first poll then reports the charger's real (still off) state — which reads exactly as "reverted."

One thing that would help pin it down: does the revert happen every time you try charge_session, even well after disabling surplus mode (which would rule out the race), or specifically in the few seconds right after (which would confirm it)? I've logged the blanket-reload-on-any-option-write behavior as its own roadmap item regardless, since it's worth narrowing on its own merits — but I'd rather not touch write/reload behavior around an active charging session on a guess, especially with the charger currently unreachable from my dev setup.

Also, to answer your question directly: yes, force_charge_for still respects max_inverter_power_w / max_house_power_w — that was fixed in 2.13.1 (#22) specifically so forcing a charge never bypasses physical limits, only scheduling. And surfacing it more visibly than a Developer Tools action is a fair ask — noting it as a small roadmap item.

@sailorontherocks, on the script that worked in 2.22.0 but broke in 2.23.0: I checked the diff between those releases and it's a single commit (the off-peak-sensor feature, #32) that doesn't touch switch.py, charge_gates.py, or anything on the force_charge_for path — so I can't yet see how it would affect your setup unless you've since configured the new Off-peak sensor option. Could you confirm (a) whether that option is set, and (b) what exactly fails in 2.23.0 — nothing starts at all, switch.tuya_ev_charger_scheduled_charging won't go back to its prior state, or there's an error in the log? Without a concrete failure mode I don't have anything to go on yet.

[SergioMonC]

Thanks for digging into this — the reload-on-any-option-write mechanism explains the Unavailable flashes well, and good to hear force_charge_for already respects the physical caps.

I'll test what you asked: disable surplus mode, wait several minutes (well past any reload), then try charge_session. Will report back with which of the two it turns out to be.

Worth noting why I'm disabling surplus mode in the first place: it's tied to the other issue I posted (#31/#22 thread) — surplus mode won't charge at all once there's no sun and it's outside off-peak, so turning it off and toggling charge_session manually is my only way to force a session right now. So the two problems compound: I disable surplus mode because it won't charge on its own, and then can't get charge_session to hold either.