Skip to content

Tesla inverter: charge_stop_service fires after discharge_start_service in the same cycle, clobbering operation_mode back to Self-Powered every discharge attempt #4641

Description

@greg1609

Using the TESLA inverter type (tesla_custom, Powerwall 3) with select.predbat_mode = Control charge & discharge. During every planned discharge/export window tonight, Predbat correctly identifies the window and calls discharge_start_service, but within ~0.4 seconds also calls charge_stop_service for the same cycle — and the charge-side call runs second, overwriting select.my_home_operation_mode back to Self-Powered immediately after discharge_start_service had just set it to Time-Based Control. Net result: select.my_home_energy_exports stays Everything (harmless on its own) but operation_mode never actually holds Time-Based Control, so the Gateway never exports — it just load-follows. Real power telemetry confirms zero net grid export across every attempt: sensor.my_home_grid_power stayed ~0W while sensor.my_home_battery_power tracked sensor.my_home_load_power almost exactly, for the full duration of every window.

Log evidence (repeated identically at 17:20, 17:25, 17:50, 18:50, 18:55 ×3, and 21:50 — 100% of attempts across the evening):

21:50:56.708 Inverter 0 Calling service discharge_start_service ... select.my_home_energy_exports -> Everything
21:50:57.130 Inverter 0 Calling service discharge_start_service ... select.my_home_operation_mode -> Time-Based Control
21:50:57.538 Inverter 0 Calling service charge_stop_service ... select.my_home_operation_mode -> Self-Powered <-- clobbers it
21:50:58.004 Inverter 0 Calling service charge_stop_service ... number.my_home_backup_reserve -> 0

Apparent cause: the charge-window adjustment and discharge-window adjustment appear to be evaluated independently each cycle. When the current time isn't inside a charge window, the charge-side logic unconditionally calls charge_stop_service (which sets the Tesla mode select to Self-Powered) — with no check for whether a discharge window is concurrently active and has already set a different mode intentionally moments earlier in the same cycle.

Expected: if a discharge window is active this cycle, the charge-side adjustment should not call charge_stop_service in a way that overwrites the mode select the discharge-side adjustment just set — or the two should be sequenced/reconciled so the discharge-active setting wins.

Setup: Predbat v8.50.0, inverter_type: TESLA, has_reserve_soc: False, has_target_soc: False, control via tesla_custom select entities (charge_start_service/charge_stop_service/discharge_start_service/discharge_stop_service) per the standard Tesla apps.yaml template. Happy to attach full apps.yaml (Tesla-control block) and further log excerpts if useful.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions