Optimize data collection #837
Conversation
WalkthroughFunctions across core and legacy modules were changed to stop returning/updating separate Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes
Possibly related PRs
Suggested reviewers
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: Organization UI Review profile: CHILL Plan: Pro 📒 Files selected for processing (2)
✅ Files skipped from review due to trivial changes (1)
🧰 Additional context used🧠 Learnings (1)📚 Learning: 2024-12-22T09:37:24.648ZApplied to files:
🧬 Code graph analysis (1)plugwise/legacy/helper.py (2)
🔇 Additional comments (3)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
plugwise/data.py (1)
181-183: Clarify the dual-object pattern in_get_location_data.This method uses a slightly different pattern:
zonereceives climate data via in-place mutation (line 181), whiledatafrom_get_zone_datais returned separately (line 183). The caller_update_zonesthen merges them withzone.update(data).This works correctly but is less intuitive than the pure in-place mutation pattern used elsewhere. Consider adding a brief comment explaining why climate data is written to
zonewhile sensor data comes fromdata.
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
plugwise/common.py(2 hunks)plugwise/data.py(8 hunks)plugwise/helper.py(3 hunks)plugwise/legacy/data.py(1 hunks)plugwise/legacy/helper.py(2 hunks)
🧰 Additional context used
🧠 Learnings (2)
📚 Learning: 2024-12-22T09:37:24.648Z
Learnt from: bouwew
Repo: plugwise/python-plugwise PR: 678
File: plugwise/legacy/helper.py:69-69
Timestamp: 2024-12-22T09:37:24.648Z
Learning: The code in plugwise/legacy/helper.py is fully separated from plugwise/helper.py. The user indicates that the problem signaled about the mismatch of the variable name (_home_location vs _home_loc_id) does not actually apply.
Applied to files:
plugwise/legacy/helper.py
📚 Learning: 2025-10-11T14:05:29.022Z
Learnt from: bouwew
Repo: plugwise/python-plugwise PR: 797
File: fixtures/adam_anna_new_2/data.json:1-304
Timestamp: 2025-10-11T14:05:29.022Z
Learning: In Plugwise fixture data (data.json files), location IDs referenced in device entries don't always need corresponding top-level location objects. Only climate zones (ThermoZone entries with dev_class "climate") require full top-level definitions with thermostats, schedules, and presets. Simple organizational locations that just group devices (like single plugs) can be referenced without top-level entries.
Applied to files:
plugwise/data.py
🧬 Code graph analysis (3)
plugwise/common.py (1)
plugwise/constants.py (1)
GwEntityData(527-589)
plugwise/legacy/helper.py (2)
plugwise/helper.py (1)
_get_measurement_data(324-376)plugwise/constants.py (1)
GwEntityData(527-589)
plugwise/helper.py (2)
plugwise/legacy/helper.py (1)
_get_measurement_data(252-294)plugwise/constants.py (1)
GwEntityData(527-589)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Ruff check and force
🔇 Additional comments (15)
plugwise/helper.py (2)
324-340: LGTM - Signature change and early return path are consistent.The refactor correctly updates the entity in-place before returning. The pattern of building a local
datadict and then merging viaentity.update(data)is a clean approach that maintains the existing logic while supporting in-place mutation.
375-376: LGTM - Final return path correctly mutates entity in-place.Consistent with the early return path at lines 339-340.
plugwise/legacy/helper.py (2)
252-265: LGTM - Consistent refactor with non-legacy helper.The signature change and early return path follow the same in-place mutation pattern. Based on learnings, this legacy code is fully separated from
plugwise/helper.py, so the parallel refactoring is appropriate.
293-294: LGTM - Final return path correctly mutates entity in-place.Consistent with the pattern established in the method.
plugwise/legacy/data.py (3)
31-50: LGTM - Refactor to in-place mutation is well-structured.The call order ensures
entity["switches"]is initialized by_get_measurement_data(line 39) before_entity_switching_group(line 42) accesses it. The early return on line 46 for non-thermostat entities is appropriate.
52-78: LGTM - Climate data now mutates entity directly.All assignments correctly target
entity[...]instead of a separate data dict. The logic remains unchanged.
80-89: LGTM - Anna control state logic correctly refactored.The loop variable rename from
datatodevice(line 84) improves clarity, distinguishing between the target entity being updated and the device being inspected.plugwise/data.py (7)
58-61: LGTM - Entity data and notifications now use in-place mutation.The refactor correctly removes return value handling and updates entities directly.
107-122: LGTM - Notifications method signature simplified.The method now mutates
entitydirectly, writing toentity["binary_sensors"]andentity["notifications"]. This is cleaner than the previous approach of updating a separate data dict.
185-212: LGTM - Entity data collection refactored to in-place mutation.All helper method calls correctly pass
entityfor in-place updates. The pattern is consistent with the rest of the refactor.
214-228: LGTM - Availability check now mutates entity directly.Clean refactor removing the data parameter.
230-257: LGTM - Adam data collection refactored correctly.All
entity[...]assignments are properly targeted.
259-301: LGTM - Climate data method refactored to in-place mutation.All assignments correctly target
entity[...]. The logic for determining climate mode remains unchanged.
324-341: LGTM - Schedule states method refactored correctly.The method now reads from and writes to
entitydirectly. Line 334's conditionentity["climate_mode"] == "auto"correctly references the entity's state that was set earlier in_climate_data.plugwise/common.py (1)
178-189: The concern raised is unfounded.entity["switches"]is always initialized before_entity_switching_group()is called. The_get_measurement_data()method creates and initializes theswitchesdict withentity.update(data)before control returns to_entity_switching_group(), ensuring the dict exists on the entity.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #837 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 21 21
Lines 3451 3442 -9
=========================================
- Hits 3451 3442 -9 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
plugwise/helper.py(2 hunks)plugwise/legacy/helper.py(2 hunks)
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2024-12-22T09:37:24.648Z
Learnt from: bouwew
Repo: plugwise/python-plugwise PR: 678
File: plugwise/legacy/helper.py:69-69
Timestamp: 2024-12-22T09:37:24.648Z
Learning: The code in plugwise/legacy/helper.py is fully separated from plugwise/helper.py. The user indicates that the problem signaled about the mismatch of the variable name (_home_location vs _home_loc_id) does not actually apply.
Applied to files:
plugwise/legacy/helper.pyplugwise/helper.py
🧬 Code graph analysis (2)
plugwise/legacy/helper.py (2)
plugwise/helper.py (1)
_get_measurement_data(323-373)plugwise/constants.py (1)
GwEntityData(527-589)
plugwise/helper.py (2)
plugwise/constants.py (1)
GwEntityData(527-589)plugwise/legacy/helper.py (3)
_appliance_measurements(316-344)_get_actuator_functionalities(346-379)_get_measurement_data(252-293)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Process test coverage
🔇 Additional comments (3)
plugwise/legacy/helper.py (1)
252-293: LGTM! In-place mutation pattern correctly implemented.The refactoring from returning data to mutating the provided
entityparameter in-place is consistent and reduces unnecessary data copying. The method correctly:
- Collects data in a local dict
- Updates the entity via
entity.update(data)at appropriate points (lines 264, 293)- Returns
Noneas indicated by the signatureplugwise/helper.py (2)
308-321: LGTM! Zone data collection correctly refactored for in-place mutation.The
_get_zone_datamethod has been successfully refactored to mutate the providedzoneparameter in-place rather than returning data. The implementation is clean and consistent with the broader refactoring pattern.
323-373: LGTM! Measurement data collection correctly refactored with defensive field access.The
_get_measurement_datamethod refactoring is well-implemented:
- Correctly uses
entity.get("dev_class")at line 331 for safe optional field access (sinceGwEntityDatahastotal=False)- Updates the provided
entityparameter in-place viaentity.update(data)at lines 337 and 373- Returns
Noneas indicated by the signature- Early return optimization at lines 337-338 for power-only scenarios
The defensive access pattern here is the correct approach and aligns with
GwEntityDatabeing aTypedDictwith optional keys.
|
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.