-
Notifications
You must be signed in to change notification settings - Fork 7
Bump Plugwise to v1.6.4 and adapt #793
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
Warning Rate limit exceeded@bouwew has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 0 minutes and 20 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📒 Files selected for processing (13)
WalkthroughThe pull request introduces significant updates to the Changes
Possibly related PRs
Suggested labels
Suggested reviewers
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (1)
tests/components/plugwise/fixtures/anna_heatpump_heating/all_data.json (1)
65-65: Well-structured test fixtures for different operational statesThe addition of the control_state field across all three fixtures (idle, cooling, heating) provides clear state representation while maintaining consistency with binary sensors and temperature values. This supports proper testing of the Plugwise v1.6.4 adaptation.
Consider adding more edge cases to the test fixtures, such as:
- Error states
- State transitions
- Extreme temperature scenarios
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (12)
custom_components/plugwise/climate.py(0 hunks)custom_components/plugwise/manifest.json(1 hunks)tests/components/plugwise/fixtures/adam_plus_anna_new/all_data.json(5 hunks)tests/components/plugwise/fixtures/anna_heatpump_heating/all_data.json(1 hunks)tests/components/plugwise/fixtures/anna_v4/all_data.json(1 hunks)tests/components/plugwise/fixtures/legacy_anna/all_data.json(1 hunks)tests/components/plugwise/fixtures/m_adam_cooling/all_data.json(5 hunks)tests/components/plugwise/fixtures/m_adam_heating/all_data.json(5 hunks)tests/components/plugwise/fixtures/m_adam_jip/all_data.json(9 hunks)tests/components/plugwise/fixtures/m_adam_multiple_devices_per_zone/all_data.json(9 hunks)tests/components/plugwise/fixtures/m_anna_heatpump_cooling/all_data.json(1 hunks)tests/components/plugwise/fixtures/m_anna_heatpump_idle/all_data.json(1 hunks)
💤 Files with no reviewable changes (1)
- custom_components/plugwise/climate.py
✅ Files skipped from review due to trivial changes (4)
- tests/components/plugwise/fixtures/m_adam_jip/all_data.json
- tests/components/plugwise/fixtures/m_adam_multiple_devices_per_zone/all_data.json
- tests/components/plugwise/fixtures/adam_plus_anna_new/all_data.json
- tests/components/plugwise/fixtures/m_adam_heating/all_data.json
🔇 Additional comments (10)
tests/components/plugwise/fixtures/legacy_anna/all_data.json (1)
40-40: Verify control_state compatibility with older versions
The addition of "control_state": "heating" appears to be related to the version bump. Please ensure:
- Older versions can handle this new field gracefully
- The field is required for v1.6.4 functionality
Let's check for control_state usage across the codebase:
Also applies to: 47-47
✅ Verification successful
Based on the gathered evidence, I can now provide the final response:
The control_state field addition is safe and backward compatible
The evidence shows that:
- The field is only used in test fixtures and defined as a constant
- No direct usage in climate.py component logic
- The coordinator handles version checks properly
- The change coincides with v1.6.4 library update, following previous stable versions (1.6.0-1.6.3)
Since the field is not used in critical component logic and proper version handling is in place, this addition won't affect older versions.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for control_state usage in code and tests
# Test: Look for control_state references in Python files
rg -l "control_state" --type py
# Test: Check all test fixtures for control_state field
fd -e json -x jq 'walk(if type == "object" and has("control_state") then .control_state else empty end)' {} \;
Length of output: 225
Script:
#!/bin/bash
# Check the actual usage context of control_state in the Python files
rg "control_state" -B 2 -A 2 tests/components/plugwise/test_climate.py custom_components/plugwise/const.py
# Check if control_state is used in version-specific code paths
rg "1\.6\." -B 2 -A 2 custom_components/plugwise/
# Look for version compatibility handling code
rg "version" -B 2 -A 2 custom_components/plugwise/climate.py
Length of output: 1977
Script:
#!/bin/bash
# Check climate.py for control_state usage to understand how it's handled
rg "control_state" -B 5 -A 5 custom_components/plugwise/climate.py
# Check the plugwise library version history in git
gh api repos/plugwise/python-plugwise/releases --jq '.[].tag_name' | grep "^v1\."
# Look for version handling or compatibility code in coordinator
rg "control_state|version" custom_components/plugwise/coordinator.py
Length of output: 476
tests/components/plugwise/fixtures/anna_v4/all_data.json (1)
5-5: Ensure consistent control_state implementation across fixtures
The changes maintain consistency with other fixtures:
- Added
"control_state": "heating" - Reformatted arrays for improved readability
Let's verify consistency across all test fixtures:
Also applies to: 7-7, 14-14
✅ Verification successful
Let me gather more specific information about the Anna v4 fixtures to verify the consistency.
Let me check other Anna fixtures to verify the consistency of control states.
Based on the analysis of the shell script outputs, I can now provide the final response:
Control state implementation is consistent across fixtures
The verification confirms that:
- Anna v4 fixtures correctly implement
control_state: "heating"for thermostat devices - The same pattern is present in anna_heatpump_heating fixtures
- The control states are properly scoped to the relevant device objects
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify control_state consistency across fixtures
# Test: Check all Plugwise test fixtures for control_state values
fd -e json -p 'tests/components/plugwise/fixtures' -x jq -r '
[.. | objects | select(has("control_state"))] |
map({control_state, dev_class}) |
unique[]
'
Length of output: 938
Script:
#!/bin/bash
# Check control_state values specifically in Anna v4 fixtures
fd -p 'tests/components/plugwise/fixtures/anna_v4' -e json -x jq -r '
path(..|.control_state?) as $path |
select($path) |
{
file: input_filename,
path: $path,
control_state: getpath($path),
dev_class: (.. | objects | select(has("dev_class")).dev_class? // null)
}
'
Length of output: 63308
Script:
#!/bin/bash
# Check control_state values in other Anna fixtures
fd -p 'tests/components/plugwise/fixtures/anna' -e json -x jq -r '
path(..|.control_state?) as $path |
select($path) |
{
file: input_filename,
path: $path,
control_state: getpath($path),
dev_class: (.. | objects | select(has("dev_class")).dev_class? // null)
}
'
Length of output: 128842
tests/components/plugwise/fixtures/m_anna_heatpump_idle/all_data.json (1)
63-63: LGTM! Test fixture correctly represents idle state
The changes maintain internal consistency:
- control_state "idle" matches the binary sensor states (all false)
- Array formatting changes preserve the data while improving readability
Also applies to: 65-65, 72-72
tests/components/plugwise/fixtures/m_anna_heatpump_cooling/all_data.json (1)
63-63: LGTM! Test fixture accurately represents cooling state
The changes maintain internal consistency:
- control_state "cooling" aligns with binary sensors (cooling_state: true, compressor_state: true)
- Temperature values (outdoor: 28.2°C, indoor: 26.3°C) represent a realistic cooling scenario
Also applies to: 65-65, 72-72
tests/components/plugwise/fixtures/anna_heatpump_heating/all_data.json (1)
63-63: LGTM! Test fixture properly represents heating state
The changes maintain internal consistency:
- control_state "heating" aligns with binary sensors (heating_state: true, compressor_state: true)
- Temperature values (outdoor: 20.2°C, indoor: 19.3°C, intended_boiler: 35.0°C) represent a realistic heating scenario
Also applies to: 65-65, 72-72
tests/components/plugwise/fixtures/m_adam_cooling/all_data.json (5)
76-76: LGTM: Array formatting is consistent.
The gateway modes array reformatting maintains data integrity while improving readability.
151-151: LGTM: Climate configuration is valid.
The preset modes and thermostat configuration are properly structured and reference valid device IDs.
Also applies to: 165-165
184-184: LGTM: Thermostat configuration is valid.
The preset modes and thermostat assignments are properly structured with valid primary and secondary device references.
Also applies to: 198-199
179-180: Verify the climate mode and control state combination.
Please verify that the combination of climate_mode: "auto" with control_state: "cooling" is the expected behavior for the Bathroom zone when cooling is active.
✅ Verification successful
The climate mode and control state combination is valid
The combination of climate_mode: "auto" with control_state: "cooling" is consistent with other test fixtures in the codebase. This exact combination appears in both m_anna_heatpump_cooling/all_data.json and m_adam_cooling/all_data.json. The "auto" climate mode is used across different control states (cooling, heating, idle, preheating) in various test fixtures, indicating this is expected behavior.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for similar combinations in other test fixtures
rg -l --json '"climate_mode":\s*"auto".*"control_state":\s*"cooling"' tests/components/plugwise/fixtures/
Length of output: 503
Script:
#!/bin/bash
# Search for similar combinations in other test fixtures without --json flag
rg -A 1 '"climate_mode":\s*"auto"' tests/components/plugwise/fixtures/
Length of output: 2178
Line range hint 1-213: Verify cooling functionality test coverage.
Since this fixture represents a cooling-capable system, please verify that it covers all necessary test scenarios for the updated HVAC action logic mentioned in the PR description.
✅ Verification successful
Test fixture provides comprehensive cooling functionality coverage
The fixture all_data.json in m_adam_cooling directory adequately covers cooling functionality with:
- Proper cooling state representation in binary sensors
- Cooling-capable gateway configuration (
cooling_present: true) - HVAC mode transitions and states (
cool,auto,heat_cool) - Cooling action states and regulation modes
- Multiple test assertions verifying cooling behavior
The test coverage includes:
- Climate entity attributes for cooling modes
- HVAC mode transitions and cooling actions
- Regulation mode selection
- Multiple device states during cooling operation
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for cooling-related test cases
rg -l 'test.*cooling' tests/components/plugwise/test_*.py
# Check test coverage for climate mode transitions
rg -A 5 'async_set_hvac_mode.*cooling' tests/components/plugwise/test_*.py
Length of output: 1084
Script:
#!/bin/bash
# Check test_climate.py for cooling-related test cases
rg -A 10 'test.*cooling|test.*hvac.*mode' tests/components/plugwise/test_climate.py
# Check test_select.py for regulation mode tests
rg -A 10 'test.*regulation.*mode' tests/components/plugwise/test_select.py
# Check the actual test fixtures used
rg -l 'all_data.json' tests/components/plugwise/test_*.py
Length of output: 1928
Script:
#!/bin/bash
# Check the test fixtures directory for cooling-related fixtures
fd -t f . tests/components/plugwise/fixtures/m_adam_cooling/
# Check for HVAC mode and cooling-related assertions in climate tests
rg -B 2 -A 2 'assert.*hvac.*mode|assert.*cooling' tests/components/plugwise/test_climate.py
# Check for cooling-related setup in conftest
rg -A 5 'adam_cooling|cooling' tests/components/plugwise/conftest.py
Length of output: 2472
7bd5cd0 to
bff62e5
Compare
|



Summary by CodeRabbit
New Features
control_stateattributes for various devices, indicating their operational states (e.g., "heating", "cooling", "idle").Bug Fixes
Documentation
Style