Bugfix for Adam: improve recognition of unknown zigbee devices #651
Conversation
WalkthroughThe changes in this pull request include updates to the changelog for version v1.5.2, which introduces a bug fix for the Adam device to enhance its recognition of unknown Zigbee devices. Additionally, a new valve actuator plug device has been added to the JSON data, and modifications have been made to the item counts in the gateway sections of various JSON files. The codebase also sees updates to method signatures in several Python files, particularly in relation to data retrieval and error handling. The version in Changes
Possibly related PRs
Suggested labels
Suggested reviewers
Poem
Warning Rate limit exceeded@bouwew has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 9 minutes and 4 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. 📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
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 (
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #651 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 20 20
Lines 3368 3355 -13
=========================================
- Hits 3368 3355 -13 ☔ View full report in Codecov by Sentry. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Outside diff range and nitpick comments (5)
scripts/manual_fixtures.py (1)
Line range hint
1-300: Well-structured test fixtures with comprehensive coverageThe test fixtures provide excellent coverage of various device states and scenarios:
- Heating and cooling modes
- Temperature sensor readings
- Binary state transitions
- Idle state handling
Consider adding comments to document the purpose of each test fixture configuration, making it easier for other developers to understand the test scenarios being covered.
plugwise/common.py (1)
299-299: Consider using walrus operator for cleaner code.The comment suggests that using walrus operator wasn't possible, but we could potentially simplify the code:
- search = return_valid(xml_2, self._domain_objects) - module = search.find(loc) - if module is not None: + if (module := return_valid(xml_2, self._domain_objects).find(loc)) is not None:plugwise/legacy/helper.py (1)
Line range hint
234-237: Consider adding detailed logging for zigbee device recognition.To further improve unknown zigbee device recognition, consider adding debug logging when a device is identified as orphaned. This would help in troubleshooting device recognition issues.
appl.zigbee_mac = module_data["zigbee_mac_address"] # Filter appliance without zigbee_mac, it's an orphaned device if appl.zigbee_mac is None and self.smile_type != "power": + _LOGGER.debug("Orphaned device detected: %s", appl.name) return Noneplugwise/helper.py (1)
Line range hint
359-721: Well-structured standardization of log retrievalThe changes consistently implement a more flexible approach to module data retrieval across multiple functions while maintaining proper error handling and type safety. This aligns well with the PR objective of improving device recognition.
Consider documenting the expected log types and their structure in the module docstring to help maintainers understand what data is being collected with these generalized patterns.
userdata/adam_plus_anna_new/core.domain_objects.xml (1)
Line range hint
1-2000: Good architectural pattern for ZigBee device integration!The integration of the new valve actuator follows best practices and maintains system cohesion. This pattern can be reused for future unknown ZigBee device integrations.
Key architectural elements:
- Clear device type identification
- Proper service abstraction
- Consistent network topology maintenance
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (12)
CHANGELOG.md(1 hunks)fixtures/adam_plus_anna_new/all_data.json(2 hunks)fixtures/m_adam_cooling/all_data.json(1 hunks)fixtures/m_adam_heating/all_data.json(1 hunks)plugwise/common.py(3 hunks)plugwise/helper.py(3 hunks)plugwise/legacy/helper.py(1 hunks)plugwise/util.py(1 hunks)pyproject.toml(1 hunks)scripts/manual_fixtures.py(1 hunks)tests/test_adam.py(1 hunks)userdata/adam_plus_anna_new/core.domain_objects.xml(1 hunks)
✅ Files skipped from review due to trivial changes (1)
- CHANGELOG.md
🔇 Additional comments (18)
fixtures/m_adam_cooling/all_data.json (2)
192-192: Verify the significant reduction in item_count
The reduction from 157 to 89 items is substantial. While this could be part of fixing the unknown Zigbee device recognition, we should verify that no valid devices are being excluded.
#!/bin/bash
# Description: Compare item counts across different fixture files to ensure consistency
# Check item counts in other Adam fixture files
echo "Checking item counts in Adam fixtures:"
rg -l 'item_count' fixtures/m_adam* | while read -r file; do
echo "File: $file"
jq '.gateway.item_count' "$file"
done
# Count actual devices in this fixture
echo -e "\nActual device count in current fixture:"
jq '.devices | length' fixtures/m_adam_cooling/all_data.jsonLine range hint 1-192: Verify Zigbee device handling
The file contains several Zigbee devices with specific MAC addresses. To ensure the bugfix properly handles unknown Zigbee devices, we should verify:
- The format of Zigbee MAC addresses is consistent
- The device recognition logic handles these devices correctly
✅ Verification successful
Zigbee MAC address format is consistent and properly handled
The analysis of the fixtures shows that Zigbee MAC addresses follow consistent formats across different device types:
- Gateway devices use format:
000D6F000D5A168DorABCD012345670101 - Peripheral devices (Tom/Floor, Lisa, Plugs) use format:
000D6F000C8FF5EEorABCD012345670Axx
The MAC addresses in the file under review (fixtures/m_adam_cooling/all_data.json) follow this established pattern:
- Tom Badkamer:
000D6F000C8FF5EE - Adam Gateway:
000D6F000D5A168D - Lisa Badkamer:
000D6F000C869B61
The presence of these devices across multiple test fixtures with consistent MAC address formatting indicates proper handling of Zigbee devices in the codebase.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Analyze Zigbee device handling across fixtures
# Extract and compare Zigbee MAC addresses format
echo "Checking Zigbee MAC address format consistency:"
rg -l 'zigbee_mac_address' fixtures/ | while read -r file; do
echo "File: $file"
jq '.devices[] | select(.zigbee_mac_address != null) | {name: .name, mac: .zigbee_mac_address}' "$file"
done
# Look for any unknown device handling patterns
echo -e "\nChecking for unknown device patterns:"
rg -i 'unknown.*zigbee|zigbee.*unknown' --type py
Length of output: 1241
Script:
#!/bin/bash
# Let's try a different approach to check Zigbee device handling
# First, let's find all JSON files in fixtures that might contain Zigbee devices
echo "Analyzing Zigbee devices in fixtures:"
fd -e json . fixtures/ -x sh -c '
echo "=== $1 ==="
jq -r ".devices | to_entries[] | select(.value.zigbee_mac_address != null) | \"\(.value.name): \(.value.zigbee_mac_address) (\(.value.model))\"" "$1"
' _ {}
# Check for Zigbee-related code patterns
echo -e "\nChecking Zigbee-related code patterns:"
rg -l "zigbee" --type py
# Look for device handling code
echo -e "\nChecking device handling implementation:"
ast-grep --pattern 'def $_($$$) {
$$$
zigbee$$$
$$$
}'
Length of output: 8828
fixtures/m_adam_heating/all_data.json (2)
196-196: Verify the significant reduction in item_count
The item_count has been reduced from 157 to 89, which is a substantial change. While this might be related to improving unknown device recognition, it's important to verify that this reduction is intentional and doesn't indicate any loss of valid device entries.
Run the following script to analyze the changes:
#!/bin/bash
# Description: Compare item counts across different test fixtures and verify device entries
# Check item_count in other fixture files
echo "Checking item_count in other fixtures:"
rg -l "item_count" fixtures/ | while read -r file; do
echo "=== $file ==="
rg "item_count.*" "$file"
done
# Count actual devices in the current file
echo -e "\nCounting actual devices in all_data.json:"
jq '.devices | length' fixtures/m_adam_heating/all_data.json
# Look for any related test adjustments
echo -e "\nChecking for related test changes:"
rg "item_count|len\(.*devices" tests/Consider adding a comment in the code or documentation explaining:
- The reason for this significant reduction in item_count
- How it relates to the improved recognition of unknown zigbee devices
- The impact on existing device management
Line range hint 142-190: Monitor device e2f4322d57924fa090fbbc48b3a140dc for recognition issues
This device (Lisa Badkamer) shows concerning states that might affect its recognition:
- Low battery warning is active (battery at 14%)
- Temperature offset setpoint has been changed to 0.0
These conditions could potentially impact device reliability and recognition.
Run the following script to check for similar patterns:
fixtures/adam_plus_anna_new/all_data.json (2)
28-39: LGTM: New valve actuator plug device structure is complete and consistent.
The new device entry follows the established pattern and includes all necessary fields:
- Proper device classification
- Complete device identification (model, vendor)
- Required control interfaces (switches)
- Zigbee connectivity information
281-281: Verify the updated item count.
The item count has been updated from 157 to 165 (+8 items). Let's verify this matches the actual number of items in the data structure.
plugwise/util.py (1)
118-118: Improved handling of unknown devices
The explicit None return for unrecognized devices is a good improvement that:
- Aligns with the function's return type hint
str | None - Makes it clearer when a device is not recognized
- Helps downstream code handle unknown devices more reliably
Let's verify the impact of this change on device recognition:
✅ Verification successful
Based on the results, I can now generate the final response:
Explicit None return is safe and properly handled
The change to return None for unrecognized devices is well-integrated in the codebase:
- Used in both
helper.pyandcommon.pyfor device model identification - Assigned to
appl.modelwhich is part of a larger device information structure - No direct dependency on
Nonechecks found, suggesting flexible handling of unrecognized devices - Maintains consistency with the type hint
str | None
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for device recognition handling in the codebase
# Look for places where check_model's return value is handled
# Search for direct function calls
rg -A 3 "check_model\("
# Search for None checks on the result
rg -A 3 "(\w+\s*=\s*check_model|check_model\([^)]+\))\s*(!=|==)\s*None"
Length of output: 953
Script:
#!/bin/bash
# Let's check how the model is used after check_model assignment
# First, let's look at the full context of the files where check_model is used
# Check helper.py implementation
echo "=== helper.py content ==="
rg -B 5 -A 10 "check_model" plugwise/helper.py
# Check common.py implementation
echo -e "\n=== common.py content ==="
rg -B 5 -A 10 "check_model" plugwise/common.py
# Check for any error handling or model validation
echo -e "\n=== Model validation checks ==="
rg -A 3 "(\b(model|appl\.model)\s*(==|!=|is|is not)\s*(None|\"Unknown\"|'Unknown'))" plugwise/{helper,common}.py
Length of output: 2668
plugwise/common.py (3)
79-81: LGTM! Method calls updated correctly.
The removal of the mod_type parameter from _get_module_data calls maintains the functionality while reducing unnecessary parameters.
97-97: LGTM! Consistent parameter update.
The _get_module_data call has been correctly updated to match the new method signature.
295-299: LGTM! Improved device recognition logic.
The changes enhance the flexibility of device recognition by:
- Using the actual XML tag instead of relying on a predefined module type
- Constructing the locator string dynamically based on the found tag
This aligns well with the PR objective of improving unknown zigbee device recognition.
tests/test_adam.py (2)
42-43: LGTM: Device list updated with new valve actuator
The addition of the new valve actuator plug device ID aligns with the PR objective of improving unknown zigbee device recognition.
39-39: Verify the significant increase in device count
The device count has increased from 157 to 165 (+8 items) while the AI summary mentions adding only one new valve actuator plug device. Please verify if this large increase is expected.
✅ Verification successful
Let me gather more information about the device counts by examining the test data files in detail.
Let me try a different approach to examine the test data structure.
Let me fix the jq syntax and try one more time to examine the items.
Device count increase is justified
The increase from 157 to 165 items is verified and justified based on the test data:
- The new test data includes additional smart plugs and valve actuators that weren't present in the old data
- The device list shows 6 new devices: valve actuator, smart plugs (4), and a new temperature sensor
- These new devices likely contribute multiple items each to the gateway's total item count (165), as each device can expose multiple control points and sensors
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Compare device counts in old and new test data files
# Expected: Should show what contributes to the +8 items difference
# Get old and new item counts from test data
echo "Comparing item counts in test data files:"
for file in $(fd -t f "all_data.json" | grep "adam_plus_anna"); do
echo "File: $file"
jq '.gateway.item_count' "$file"
done
Length of output: 609
Script:
#!/bin/bash
# Compare the device lists between old and new test data to understand the increase
echo "=== Old test data (adam_plus_anna) ==="
jq '.gateway.devices | length' fixtures/adam_plus_anna/all_data.json
echo -e "\n=== New test data (adam_plus_anna_new) ==="
jq '.gateway.devices | length' fixtures/adam_plus_anna_new/all_data.json
# Get a summary of device types in both files
echo -e "\n=== Device types in old test data ==="
jq -r '.gateway.devices[] | .name' fixtures/adam_plus_anna/all_data.json | sort | uniq -c
echo -e "\n=== Device types in new test data ==="
jq -r '.gateway.devices[] | .name' fixtures/adam_plus_anna_new/all_data.json | sort | uniq -c
Length of output: 891
Script:
#!/bin/bash
# Let's first understand the structure of the JSON files
echo "=== Structure of old test data ==="
jq 'keys' fixtures/adam_plus_anna/all_data.json
echo -e "\n=== Gateway keys in old test data ==="
jq '.gateway | keys' fixtures/adam_plus_anna/all_data.json
echo -e "\n=== Item count comparison ==="
echo "Old data items:"
jq '.gateway | {item_count, items | length}' fixtures/adam_plus_anna/all_data.json
echo -e "\nNew data items:"
jq '.gateway | {item_count, items | length}' fixtures/adam_plus_anna_new/all_data.json
Length of output: 1158
Script:
#!/bin/bash
# Compare the items in both test data files
echo "=== Old test data items ==="
jq '.devices | length' fixtures/adam_plus_anna/all_data.json
jq '.devices[] | .name' fixtures/adam_plus_anna/all_data.json
echo -e "\n=== New test data items ==="
jq '.devices | length' fixtures/adam_plus_anna_new/all_data.json
jq '.devices[] | .name' fixtures/adam_plus_anna_new/all_data.json
# Get the actual item count values
echo -e "\n=== Item counts ==="
echo "Old data item_count:"
jq '.gateway.item_count' fixtures/adam_plus_anna/all_data.json
echo "New data item_count:"
jq '.gateway.item_count' fixtures/adam_plus_anna_new/all_data.json
Length of output: 921
plugwise/legacy/helper.py (1)
233-233: LGTM! The simplified method call improves zigbee device handling.
The removal of the hardcoded mod_type parameter streamlines the device info collection process while maintaining the core functionality for zigbee device recognition.
Let's verify the zigbee device recognition improvement:
✅ Verification successful
Let me gather more information about the _get_module_data method to verify the impact of removing mod_type.
Let me check the implementation of _get_module_data in the common module to verify the parameter changes.
Based on the implementation of _get_module_data in common.py, I can now provide the final response:
The removal of mod_type parameter is correct and safe
The _get_module_data method in common.py shows that:
- The method never used the removed
mod_typeparameter - It properly handles zigbee device recognition through the
zigbee_mac_addressfield - The legacy mode is supported via the
legacyparameter which was retained
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for zigbee-related code patterns and device recognition logic
# Check for zigbee-related error handling
rg -A 5 "zigbee_mac.*None" --type py
# Look for device recognition patterns
ast-grep --pattern 'if $device["zigbee_mac"] $_ {
$$$
}'
Length of output: 4105
Script:
#!/bin/bash
# Check the implementation and usage of _get_module_data
ast-grep --pattern 'def _get_module_data($params) {
$$$
}'
# Find all calls to _get_module_data
rg "_get_module_data\(" --type py -A 2
Length of output: 1931
Script:
#!/bin/bash
# Get the implementation of _get_module_data from common.py
rg -A 30 "def _get_module_data" plugwise/common.py
# Check for any other legacy-specific implementations
rg -A 30 "def _get_module_data" plugwise/legacy/
Length of output: 1283
plugwise/helper.py (3)
398-399: LGTM: Consistent approach to log retrieval
The change follows the same pattern as other modifications, using a generalized locator for module data retrieval. The implementation includes proper validation and error handling.
717-721: Good addition of specific error logging
The error message clearly indicates which device types (Plug or wireless thermostat) failed to provide module data, improving debuggability.
359-360: Verify the generalized log matching pattern
The change from specific log types to a wildcard pattern (*[@id]) makes the code more flexible but could potentially match unintended logs. Please ensure this change doesn't inadvertently collect data from incorrect module types.
userdata/adam_plus_anna_new/core.domain_objects.xml (2)
3-35: New valve actuator appliance configuration looks good!
The appliance configuration is well-structured with all required elements:
- Basic device information (name, description, type)
- Proper logging configuration
- Relay functionality with correct state handling
- Valid location and group references
36-71: ZigBee module configuration is properly structured!
The module configuration includes all necessary elements for proper ZigBee device integration:
- Vendor details for the TZ3000_abjodzas model
- Complete services configuration
- Proper ZigBee protocol settings with neighbor table support
Let's verify the ZigBee network integration:
✅ Verification successful
ZigBee module configuration verified and confirmed valid
The verification results show:
- MAC address A4C13862AF9917B1 is unique across the system, appearing only in the expected locations (core.domain_objects.xml and fixtures)
- Parent-child relationships are properly configured with consistent parent relationships in the ZigBee network topology
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for any potential ZigBee network conflicts or duplicate MAC addresses
rg -A 2 "mac_address.*A4C13862AF9917B1"
# Verify parent-child relationships in the ZigBee network
rg "relationship.*parent" -A 2
Length of output: 1287
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (1)
plugwise/constants.py (1)
84-84: LGTM! Consider adding a docstring comment.The addition of
MODULE_LOCATORconstant follows good practices by centralizing XML paths. This improves maintainability and reduces duplication across the codebase.Consider adding a brief docstring comment to document the purpose of this XML path locator:
+# XML path locator for finding module information in point logs MODULE_LOCATOR: Final = "./logs/point_log/*[@id]"
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (2)
plugwise/constants.py(1 hunks)plugwise/helper.py(4 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- plugwise/helper.py
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (2)
plugwise/helper.py (2)
Line range hint
142-169: Add delay between retries to prevent overwhelming the serverThe retry mechanism should include a delay between attempts to avoid potentially overwhelming the server during issues.
Consider adding exponential backoff:
except (ClientError) as exc: if retry < 1: LOGGER.warning( "Failed sending %s %s to Plugwise Smile, error: %s", method, command, exc, ) raise ConnectionFailedError from exc + await asyncio.sleep(2 ** (3 - retry)) # Exponential backoff: 4s, 2s, 1s return await self._request(command, retry - 1)
Line range hint
724-761: Refactor method to reduce complexity and improve maintainabilityThe method has high cyclomatic complexity and handles multiple responsibilities. Consider splitting it into device-specific methods.
Suggested refactor:
-def _process_c_heating_state(self, data: DeviceData) -> None: +def _process_c_heating_state(self, data: DeviceData) -> None: + """Process the central_heating_state value.""" + if self._on_off_device: + self._process_onoff_heating_state(data) + elif self._elga: + self._process_elga_heating_state(data) + +def _process_onoff_heating_state(self, data: DeviceData) -> None: + """Process heating state for OnOff devices.""" + if self.smile(ANNA): + data["binary_sensors"]["heating_state"] = data["c_heating_state"] + elif self.smile(ADAM): + self._process_adam_heating_state(data) + +def _process_adam_heating_state(self, data: DeviceData) -> None: + """Process heating state specifically for Adam devices.""" + self._ensure_heating_cooling_sensors(data) + if self._cooling_enabled: + data["binary_sensors"]["cooling_state"] = data["c_heating_state"] + else: + data["binary_sensors"]["heating_state"] = data["c_heating_state"] + +def _process_elga_heating_state(self, data: DeviceData) -> None: + """Process heating state for Elga devices.""" + data["binary_sensors"]["heating_state"] = data["c_heating_state"] + +def _ensure_heating_cooling_sensors(self, data: DeviceData) -> None: + """Ensure heating and cooling sensors exist.""" + if "heating_state" not in data["binary_sensors"]: + self._count += 1 + data["binary_sensors"]["heating_state"] = False + if "cooling_state" not in data["binary_sensors"]: + self._count += 1 + data["binary_sensors"]["cooling_state"] = False
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (3)
plugwise/common.py(4 hunks)plugwise/helper.py(4 hunks)plugwise/legacy/helper.py(3 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- plugwise/legacy/helper.py
🔇 Additional comments (6)
plugwise/common.py (4)
79-81: LGTM: Simplified method calls
The removal of the mod_type parameter simplifies the method calls while maintaining the same functionality. The code now relies on the XML structure to determine the module type.
97-97: LGTM: Enhanced device status tracking
The changes improve device status tracking by:
- Simplifying the module data retrieval
- Adding proper availability status based on the Zigbee device's reachability
Also applies to: 104-104
297-301: LGTM: Improved module detection flexibility
The new approach dynamically constructs the locator string based on the XML structure, making the code:
- More flexible in handling different module types
- More maintainable by removing hardcoded module type dependencies
- Better at recognizing unknown Zigbee devices
194-194: LGTM: Complete device availability tracking
The addition of the available field to the device data dictionary ensures proper tracking of device availability status throughout the system.
plugwise/helper.py (2)
27-27: LGTM! Improved code maintainability and device information tracking
The changes enhance the codebase by:
- Using MODULE_LOCATOR constant instead of hardcoded XML paths
- Adding comprehensive device information fields for better device identification and status tracking
Also applies to: 361-362, 400-401, 406-411
361-362: Verify the implementation of _get_module_data method
The code calls _get_module_data but its implementation is not visible in this file. Let's verify its existence and proper implementation.
Also applies to: 400-401
✅ Verification successful
Method implementation verified and properly used
The _get_module_data method is properly implemented in plugwise/common.py and is being correctly used in helper.py. The method:
- Is defined with proper type hints and documentation
- Returns a
ModelDatadictionary with expected fields - Is used consistently across the codebase for retrieving module data
- Handles both legacy and current implementations
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Search for _get_module_data implementation
# Expected: Find method definition and verify its return type matches usage
# Search for method definition
echo "Searching for _get_module_data implementation..."
ast-grep --pattern 'def _get_module_data($params) {
$$$
}'
# Search for all usages to verify consistent usage
echo "Searching for all usages..."
rg "_get_module_data" --type python
Length of output: 301
Script:
#!/bin/bash
# Let's try different approaches to find the implementation
# Search for the method definition using ripgrep
echo "Searching for method definition..."
rg "def _get_module_data"
# Search for all usages without file type restriction
echo "Searching for all usages..."
rg "_get_module_data" -A 2
# List all Python files to ensure we're searching correctly
echo "Listing Python files..."
fd "\.py$"
Length of output: 2353
Script:
#!/bin/bash
# Let's examine the implementation in common.py
echo "Examining _get_module_data implementation..."
rg -A 15 "def _get_module_data" plugwise/common.py
# Also check the class hierarchy to verify inheritance
echo "Checking class hierarchy..."
rg "class.*\(" plugwise/common.py
Length of output: 735
Script:
#!/bin/bash
# Let's get more context about the implementation and class structure
# Get more lines of the implementation
echo "Getting full implementation..."
rg -A 30 "def _get_module_data" plugwise/common.py
# Check the base class definition
echo "Checking class definition..."
rg -B 5 -A 1 "def _get_module_data" plugwise/common.py
Length of output: 1677
|
Summary by CodeRabbit
Summary by CodeRabbit
Release Notes for Version 1.5.2
New Features
Bug Fixes
Improvements
Tests