Setpoint and mode-change methods force pump enable (start=True default), can turn pump on unexpectedly

[eman]

Origin

Companion issue to eman/esphome-alpha-hwr#45, filed against this repo because the ESPHome component's identical behavior is a direct port of this client's ControlService methods.

Problem

Every setpoint setter and set_mode() calls _send_control_request() with the enable flag hardwired to True, so writing a setpoint or changing mode always turns the pump on — even if the caller only intended to change a stored setting while the pump is off.

Evidence

• services/control.py:582-585 — set_constant_pressure() → self._send_control_request(ControlMode.CONSTANT_PRESSURE, setpoint=value_pa)
• services/control.py:613-617 — set_constant_speed() → self._send_control_request(ControlMode.CONSTANT_SPEED, setpoint=value_rpm)
• services/control.py:645-649 — set_constant_flow() → self._send_control_request(ControlMode.CONSTANT_FLOW, setpoint=value_m3h)
• services/control.py:362 — set_mode() → self._send_control_request(mode_val, start=True)
• services/control.py:235-238 — _send_control_request(self, mode_val, start: bool = True, setpoint=None): none of the calls above pass start=False, so they all use the default True.
• Because the GENIbus frame fuses mode + setpoint + on/off state into a single 12-byte write (services/control.py:259-276), there's no way to write a setpoint without specifying some on/off value in this frame — confirmed by the frame layout [Flag][Mode][Suffix(4)] at line 244-245, where Flag is the 0=start/1=stop byte. The fix has to be "pass the pump's actual current on/off state" rather than "omit the field."
• Cross-repo confirmation: esphome-alpha-hwr#23 bench-tested this directly — a setpoint change while the pump is off turns it on, and (per the issue) this can leave the pump running with the client's own "enabled" state tracking believing it's still off, since none of these setters update any local enabled-state cache either.

Suggested fix

Track the pump's last-known on/off state (from get_mode()'s is_running/operation_mode, or from the caller) and pass it as start=<current_state> in the setpoint/mode-change calls above, instead of hardcoding True. If the current state isn't confidently known, consider doing a get_mode() read first.

References

• eman/esphome-alpha-hwr#23 (original report, Control Problems #3/#4)
• eman/esphome-alpha-hwr#45 (companion issue in the ESPHome component)