Refactor parameter constants into configuration classes

[liudger]

This pull request refactors how constants are organized and accessed in the bsblan codebase. The main improvement is the grouping of related constants into dedicated classes (CircuitConfig, Validation, and HotWaterParams) instead of using module-level variables. This change improves code clarity, maintainability, and encapsulation, and all usages throughout the codebase and tests have been updated accordingly.

Refactoring and Encapsulation of Constants:

• Introduced CircuitConfig class in constants.py to encapsulate all circuit-related constants, such as valid circuit numbers, section mappings, thermostat parameters, probe/status parameters, and inactive marker. All references to these constants in bsblan.py were updated to use the new class attributes. [1] [2] [3] [4] [5] [6] [7] [8] [9]
• Introduced Validation class in constants.py to group validation-related constants such as valid HVAC modes and valid year ranges. All usages in bsblan.py now reference these via the class. [1] [2] [3]
• Introduced HotWaterParams class in constants.py for all hot water parameter groups and mappings (essential, config, schedule, settable, and time programs). All usages in bsblan.py and test_constants.py were updated to use this class. [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16]

Test Updates:

• Updated all references in test_constants.py to use the new HotWaterParams class attributes instead of the old module-level constants. [1] [2] [3] [4] [5]

These changes are purely organizational and do not alter any functional logic, but they make the codebase more modular and easier to maintain.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.89%. Comparing base (fc9bb94) to head (2af66e2).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1433   +/-   ##
=======================================
  Coverage   99.89%   99.89%           
=======================================
  Files           6        6           
  Lines         987      990    +3     
  Branches      139      139           
=======================================
+ Hits          986      989    +3     
  Partials        1        1           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Copilot]

Pull request overview

This PR refactors bsblan.constants by grouping previously module-level constants into focused configuration classes (CircuitConfig, Validation, HotWaterParams) and updates the client and tests to reference these class attributes, improving organization and encapsulation across the library.

Changes:

• Introduced CircuitConfig, Validation, and HotWaterParams classes to organize circuit, validation, and hot water constant groups.
• Updated BSBLAN client logic to use the new class-based constants (circuits, HVAC mode validation, hot water parameter grouping, DHW time program mappings).
• Updated constants-related tests to reference the new HotWaterParams groups.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
src/bsblan/constants.py	Replaces several module-level constant groupings with CircuitConfig, Validation, and HotWaterParams classes.
src/bsblan/bsblan.py	Updates constant imports/usages to the new class attributes for circuit probing, validation, and hot water operations.
tests/test_constants.py	Updates tests to validate hot water group completeness/overlap/counts via HotWaterParams.

[Copilot]

CircuitConfig.VALID hard-codes {1, 2} while the module also defines MIN_CIRCUIT/MAX_CIRCUIT (now unused). This duplicates the source of truth and can drift if circuit support changes; consider either removing MIN_CIRCUIT/MAX_CIRCUIT or deriving CircuitConfig.VALID from them (and/or using them consistently in validation/error messages).

Suggested change

	VALID: Final[set[int]] = {1, 2}
	VALID: Final[set[int]] = set(range(MIN_CIRCUIT, MAX_CIRCUIT + 1))

[Copilot]

The comment still references DHW_TIME_PROGRAM_PARAMS, but the code now uses HotWaterParams.TIME_PROGRAMS. Updating this avoids misleading future maintenance (especially since this method is part of the public schedule-setting API).

Suggested change

	# Invert DHW_TIME_PROGRAM_PARAMS to get day_name -> param_id mapping
	# Invert HotWaterParams.TIME_PROGRAMS to get day_name -> param_id mapping