Skip to content

feat: make setpoint step size configurable#137

Closed
PetePeter wants to merge 1 commit into
bvweerd:devfrom
PetePeter:feature/configurable-setpoint-step
Closed

feat: make setpoint step size configurable#137
PetePeter wants to merge 1 commit into
bvweerd:devfrom
PetePeter:feature/configurable-setpoint-step

Conversation

@PetePeter
Copy link
Copy Markdown

@PetePeter PetePeter commented May 11, 2026

Summary

  • add a dedicated Setpoint Step config number entity beside each PID setpoint
  • keep the repository default setpoint step at 0.01, matching the upstream base behavior
  • allow the config step entity to persist the chosen increment and reload the PID entry so the main setpoint number uses the new step
  • make the PR label workflow work for fork-based pull requests by using pull_request_target

Verification

  • python -m pre_commit run --all-files
  • python -m pytest --cov=custom_components --cov-report=xml -q

Solves

Notes

  • The pytest run was exercised locally through a small wrapper that bypasses pytest_socket's Windows-only event-loop bootstrap conflict. The integration code and test suite both completed green after that workaround.
  • The GitHub-only hacs/action and hassfest jobs still run in hosted Actions on the draft PR.

@PetePeter PetePeter force-pushed the feature/configurable-setpoint-step branch 3 times, most recently from 8fd54a0 to 2614cee Compare May 11, 2026 01:18
@bvweerd
Copy link
Copy Markdown
Owner

bvweerd commented May 11, 2026

The SetpointStepNumber entity introduces an architectural problem: every time the user changes the step value, sync_set_native_value triggers a full integration reload (async_reload). This tears down and recreates all entities, briefly interrupting the PID controller — which is undesirable for what is essentially a configuration tweak.

The options flow already covers this use case correctly: it persists CONF_SETPOINT_STEP in entry.options and HA handles the reload after the user submits the form. The SetpointStepNumber entity is therefore redundant and adds complexity without benefit.

Please Remove SetpointStepNumber, SETPOINT_STEP_ENTITY, and the async_reload logic entirely. The options flow change is sufficient — ControlParameterNumber already reads CONF_SETPOINT_STEP from entry.options on init, so the step will be applied correctly after the user saves options.

@PetePeter
Copy link
Copy Markdown
Author

@bvweerd hey thanks for the feedback. ive never done a HA integration so i do rely on AI to cook it all. These options, are these the "attributes" that ha entities have? if so, you're saying that the integration you provide doesnt need my pr because the user can change that attribute , by changing it here?
image

but as an end user i'd love it if i dont have to unpack attributes with Dev mode, instead i'm hoping to see the step change in the number picker settings much like when i make a number input helper and i can change min max step.

@PetePeter
Copy link
Copy Markdown
Author

in here
image

@bvweerd
Copy link
Copy Markdown
Owner

bvweerd commented May 11, 2026

Hi @PetePeter,

I can see you're relying on AI to produce the code, that's okay, but you have to be really careful in relying on what it produces.

You'll need the code change to solve your issue, but only a small portion of it.

If you want to learn more about the code, feel free to change your PR with AI, but make sure to steer it in an architectural correct solution strategy.

Otherwise please let your PR here, and I'll pick it up later.

@bvweerd
Copy link
Copy Markdown
Owner

bvweerd commented May 12, 2026

See #138

@bvweerd bvweerd closed this May 12, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Feature request: make setpoint step size configurable

2 participants