Fox Cloud: support Feed-in First (freeze export) via the work-mode setting #5022

(Claude wrote this issue, posted under my account.)

Split out of #5015, which turned off support_feedin_first for FoxCloud because the Cloud path never selects the mode. This issue tracks actually adding it.

Background

The Fox hardware does have a Feed-in First work mode, and Predbat already uses it on the modbus path: templates/fox.yaml ships a discharge_freeze_service stanza that selects "Feed-in First" on select.foxess_work_mode, published by the FoxESS HA integration.

The Cloud path has no equivalent. templates/fox_cloud.yaml contains no *_service stanzas at all, so during a freeze export slot adjust_export_immediate(..., freeze=True) calls call_service_template("discharge_freeze_service", ...), finds nothing configured, falls back to discharge_stop_service (also unset), and the freeze becomes a no-op. The inverter stays in Self Use.

Same hardware, different control surface.

What makes this look implementable

The Cloud component already publishes a writable work-mode select:

• automatic_config wires inverter_mode to select.{prefix}_fox_{device}_setting_workmode (fox.py:2221)
• that entity carries enumList: OPTIONS_WORK_MODE, which includes "Feedin" (fox.py:44, fox.py:57)
• writes route select_event → write_setting_from_event → set_device_setting, a real Fox API write (fox.py:1994-2005)

So a discharge_freeze_service stanza in fox_cloud.yaml pointing at that select is plausibly most of the work — structurally the same as the modbus template, just a different entity id.

The catch

adjust_inverter_mode writes to that same inverter_mode entity and hardcodes SelfUse for any has_fox_inverter_mode inverter:

if self.inv_has_fox_inverter_mode:
    # For fox we only use selfuse as the rest is done by schedule
    new_inverter_mode = "SelfUse"

(inverter.py:2443-2444, added in #2659, Sept 2025.)

A service call setting Feedin would be reverted to SelfUse on the next cycle — the two would fight. So the template stanza alone is not sufficient; the hardcode needs to learn that freeze export is a legitimate third state. That comment's premise ("the rest is done by schedule") holds for Cloud but not for modbus, which is why one brand-named flag spanning both control paths leaves this gap.

Also worth checking whether the scheduler writer (apply_battery_schedule, which rewrites the schedule each cycle and only emits ForceCharge/ForceDischarge) would interfere.

Caveats

• The Fox Cloud integration - Freeze Export planned but has no effect #5015 reporter notes that ~200W still flows into the battery even under Feed-in Priority on their inverter, so this will not be an exact SoC hold even when working.
• write_setting_from_event only writes when the value actually changed, so ordering between the service call and adjust_inverter_mode matters.
• Needs validation on real Fox Cloud hardware — the enum lists say Feedin is accepted, but that is not proof the API takes it in this context.

Once this works, support_feedin_first can go back to True for FoxCloud in config.py.

Related

• Fox Cloud integration - Freeze Export planned but has no effect #5015 — the bug this was split from (planner modelled the mode; execute never delivered it)
• FoxESS Freeze Export mode predicts no battery charge, but the battery does charge #4207 / fix(plan): let PV surplus charge the battery during an export freeze #4425 — where the modbus Feed-in First modelling came from
• Auto-config: two vendor components silently overwrite each other's inverter args #4824, Unneccessay updates to inverter causing eeprom wear #2328 — other instances of declared capability disagreeing with observed behaviour