Chlorinator entities read "on" when production is paused by a fault (bool() over a tri-state field)

[shieldsb-hub]

What happens

ChlorinatorBinarySensor.is_on (binary_sensor.py#L196-L201) and ChlorinatorSwitch.is_on (switch.py#L163-L168) both return:

return bool(
    self.coordinator.data.get("equipment", {})
    .get("swc_0", {})
    .get("production")
)

production is not a boolean. It carries at least three values:

value	meaning
0	not producing
1	producing
2	production paused by a controller fault

bool(2) is True, so a cell the controller has stopped reports identically to one actively making chlorine. The README describes this entity as "Chlorinator running", and that is the specific claim that goes wrong.

Evidence

Taken from /api/diagnostics/config_entry/<entry_id> while the fault was active and the filter pump was running, on v0.2.0:

production   2
error_code   9          # "ORP Stop" per ERROR_CODES in api.py
orp_sp       600
sns_2        {'sensor_type': 'Orp', 'state': 1, 'value': 520}
filter_pump  {'type': 1, 'state': 1}

Throughout this, binary_sensor.*_salt_water_chlorinator and switch.*_chlorinator both read on.

Why it matters

Code 9 "ORP Stop" is raised when the ORP setpoint has not been reached after 36 cumulative hours of chlorination, so it is precisely the situation where you want to know whether the cell is still working. At present no entity distinguishes "producing" from "stopped by the controller", and the state that is visible asserts the more reassuring of the two.

The practical cost is that the reassuring reading looks like evidence. Ours sat in an ORP Stop in every production window for several weeks, and "the chlorinator entity says on" led us to two wrong conclusions about what the controller was doing before we read the raw field through the diagnostics endpoint.

Suggested fix

The binary sensor is the clear-cut one, since it claims to report whether the cell is running:

return self.coordinator.data.get("equipment", {}).get("swc_0", {}).get("production") == 1

The switch is a design call rather than a bug, as a control reasonably reflects commanded state. Some surface for the raw value would still help, whether that is an attribute on the binary sensor, a separate diagnostic sensor, or an extension of the existing error entities.

Happy to test a patch. This controller is sitting in the affected state now, so reproducing it is not a problem at this end.

---

Environment: exo_pool v0.2.0 (HACS), Home Assistant OS, Zodiac eXO iQ, firmware vr: V85R70, dual_link: 1 (pH + ORP).