Refresh Anna Elga 2 main userdata #679
Conversation
WalkthroughThis pull request introduces several updates across multiple files in the Plugwise project. The primary changes include refreshing userdata for the Anna_Elga_2 system, updating JSON configurations, modifying test data structures, and making minor adjustments to helper methods and data processing. The modifications span across fixture files, test data, and core implementation files, with a consistent theme of renaming "entities" to "devices" in JSON structures and incrementing item counts in various configurations. Changes
Poem
Tip CodeRabbit's docstrings feature is now available as part of our Early Access Program! Simply use the command 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 #679 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 20 20
Lines 3450 3449 -1
=========================================
- Hits 3450 3449 -1 ☔ View full report in Codecov by Sentry. |
|
bouwew
changed the title
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 6
🧹 Nitpick comments (4)
tests/data/p1/smile_p1_v2_2.json (1)
2-2: LGTM! Consider updating documentation.The key renaming is consistent while maintaining valid device configurations and measurements. Consider updating any relevant documentation or test descriptions that might reference the old "entities" terminology.
Run this script to find documentation that might need updates:
#!/bin/bash # Find documentation files that might reference the old terminology rg -l "entities" --type=md docs/ tests/fixtures/anna_v4_no_tag/all_data.json (1)
93-93: Consider documenting the item count calculation methodologyThe consistent increment of
item_countfrom 58 to 59 across all Anna variants suggests a systematic change. To improve maintainability and prevent future inconsistencies, consider:
- Documenting how items are counted
- Adding automated validation to ensure item counts stay in sync
- Creating a test that verifies item counts match the actual configuration
tests/data/stretch/stretch_v31.json (1)
2-2: Consider adding JSON schema validationGiven the consistent structure across configuration files and the importance of accurate item counts, consider implementing JSON schema validation to automatically verify:
- Consistent terminology usage
- Accurate item counts
- Required fields and structure
This would help catch inconsistencies early in the development process.
Would you like me to help create a JSON schema for these configuration files?
tests/data/stretch/stretch_v23.json (1)
2-2: LGTM! Consider updating documentation to reflect terminology change.The renaming from "entities" to "devices" is consistent with other files and maintains compatibility with the v2.3 gateway configuration.
Consider updating any relevant documentation or comments that might still reference "entities" to maintain consistency with this terminology change.
Let's verify if there are any documentation files that need updating:
#!/bin/bash # Description: Check documentation files for old terminology echo "Checking documentation files for references to old terminology..." rg -i "device[_-]zones|entities" \ --type md \ --type rst \ --type txt
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (55)
CHANGELOG.md(1 hunks)fixtures/anna_elga_2/all_data.json(4 hunks)fixtures/anna_elga_2_cooling/all_data.json(1 hunks)fixtures/anna_elga_2_schedule_off/all_data.json(1 hunks)fixtures/anna_elga_no_cooling/all_data.json(1 hunks)fixtures/anna_heatpump_cooling/all_data.json(1 hunks)fixtures/anna_heatpump_cooling_fake_firmware/all_data.json(1 hunks)fixtures/anna_heatpump_heating/all_data.json(1 hunks)fixtures/anna_loria_cooling_active/all_data.json(1 hunks)fixtures/anna_loria_driessens/all_data.json(1 hunks)fixtures/anna_loria_heating_idle/all_data.json(1 hunks)fixtures/anna_v4/all_data.json(1 hunks)fixtures/anna_v4_dhw/all_data.json(1 hunks)fixtures/anna_v4_no_tag/all_data.json(1 hunks)fixtures/anna_without_boiler_fw441/all_data.json(1 hunks)fixtures/m_anna_heatpump_cooling/all_data.json(1 hunks)fixtures/m_anna_heatpump_idle/all_data.json(1 hunks)plugwise/data.py(1 hunks)plugwise/helper.py(1 hunks)tests/data/adam/adam_jip.json(1 hunks)tests/data/adam/adam_onoff_cooling_fake_firmware.json(1 hunks)tests/data/adam/adam_plus_anna_new.json(1 hunks)tests/data/adam/adam_plus_anna_new_UPDATED_DATA.json(1 hunks)tests/data/adam/adam_plus_anna_new_regulation_off.json(1 hunks)tests/data/anna/anna_elga_2.json(3 hunks)tests/data/anna/anna_elga_2_cooling.json(1 hunks)tests/data/anna/anna_elga_2_cooling_UPDATED_DATA.json(1 hunks)tests/data/anna/anna_elga_2_schedule_off.json(1 hunks)tests/data/anna/anna_elga_no_cooling.json(1 hunks)tests/data/anna/anna_heatpump_cooling.json(1 hunks)tests/data/anna/anna_heatpump_cooling_fake_firmware.json(1 hunks)tests/data/anna/anna_heatpump_heating.json(1 hunks)tests/data/anna/anna_heatpump_heating_UPDATED_DATA.json(1 hunks)tests/data/anna/anna_loria_cooling_active.json(1 hunks)tests/data/anna/anna_loria_driessens.json(1 hunks)tests/data/anna/anna_loria_heating_idle.json(1 hunks)tests/data/anna/anna_v4.json(1 hunks)tests/data/anna/anna_v4_UPDATED_DATA.json(1 hunks)tests/data/anna/anna_v4_dhw.json(1 hunks)tests/data/anna/anna_v4_no_tag.json(1 hunks)tests/data/anna/anna_without_boiler_fw441.json(1 hunks)tests/data/anna/legacy_anna.json(1 hunks)tests/data/anna/legacy_anna_2.json(1 hunks)tests/data/p1/p1v4.json(1 hunks)tests/data/p1/p1v4_442_single.json(1 hunks)tests/data/p1/p1v4_442_single_UPDATED_DATA.json(1 hunks)tests/data/p1/p1v4_442_triple.json(1 hunks)tests/data/p1/smile_p1_v2.json(1 hunks)tests/data/p1/smile_p1_v2_2.json(1 hunks)tests/data/p1/smile_p1_v2_2_UPDATED_DATA.json(1 hunks)tests/data/stretch/stretch_v23.json(1 hunks)tests/data/stretch/stretch_v27_no_domain.json(1 hunks)tests/data/stretch/stretch_v31.json(1 hunks)tests/data/stretch/stretch_v31_UPDATED_DATA.json(1 hunks)tests/test_anna.py(15 hunks)
✅ Files skipped from review due to trivial changes (8)
- tests/data/anna/anna_elga_2_cooling.json
- tests/data/adam/adam_plus_anna_new_UPDATED_DATA.json
- tests/data/adam/adam_plus_anna_new.json
- tests/data/anna/legacy_anna_2.json
- tests/data/adam/adam_jip.json
- tests/data/anna/anna_v4_UPDATED_DATA.json
- tests/data/anna/anna_heatpump_cooling_fake_firmware.json
- tests/data/stretch/stretch_v31_UPDATED_DATA.json
🔇 Additional comments (62)
plugwise/data.py (1)
316-316: Confirm correctness of incrementing the count for Anna control state.
Adding self._count += 1 helps maintain a consolidated item count; ensure that this aligns with how other increments are handled throughout the code. In particular, watch for potential off-by-one issues when the control state is reset or changed repeatedly within the same update cycle.
tests/test_anna.py (16)
33-33: Updated assertion on entity_items count to 59.
Make sure the new count is correct and reflects all added or removed data points from the Anna firmware v4 scenario.
112-112: Updated assertion on entity_items count to 59.
Same note: verify that the increment is intentional and no extra item was missed.
141-141: Updated assertion on entity_items count to 59.
Ensure the test data truly yields this count.
170-170: Updated assertion on entity_items count to 40.
Confirm alignment with newly added or removed items in the no-boiler code path.
199-199: Incremented assertion on entity_items to 68.
Ensure that newly introduced items reflect accurately in the test data (especially for heatpump heating).
229-229: Reduced assertion on entity_items to 65 after the incremental update.
Double-check that removed items, if any, are captured and consistent with the logic changes in the updated data.
255-255: Assertion of entity_items set to 65.
Confirm the test coverage includes the scenario where cooling is toggled on in a heatpump environment.
301-301: Assertion of entity_items set to 65.
Again, confirm the final item count especially regarding active cooling states.
328-328: Assertion of entity_items set to 64.
Check consistency with the non-cooling scenario where fewer items are typically expected.
347-347: Anna firmware version updated to 4.4.1.
Ensure that this matches the new dataset content and the actual firmware references in test data.
355-355: Assertion of entity_items set to 60.
Confirm the single-step increment from 59 → 60 or 64 → 60 is aligned with the new test data, especially for Anna Elga 2 idle mode.
380-380: Assertion of entity_items set to 64.
Check no unaccounted additions or deletions exist for the “schedule_off” scenario.
409-409: Assertion of entity_items set to 64.
Confirm that the newly introduced “devices” or updated data in the cooling test scenario matches this count.
463-463: Assertion of entity_items set to 67.
Ensure the data for Loria heating idle state includes all newly introduced data points.
531-531: Assertion of entity_items set to 67.
Double-check that the active cooling scenario for Loria includes the same total.
554-554: Assertion of entity_items set to 67.
Ensure the final test scenario also matches the new total count.
plugwise/helper.py (1)
971-973: Single-step XPath query merges the retrieval of 'control_state'.
The simplified approach is good for readability. Ensure that the fallback logic for absent control_state remains consistent when firmware < 3.2.0 vs ≥ 3.2.0.
tests/data/p1/smile_p1_v2_2_UPDATED_DATA.json (1)
2-2: Renamed top-level key from "entities" to "devices".
This is consistent with the PR's broader reclassification. Double-check that code references expecting entities are updated to devices accordingly.
tests/data/p1/p1v4_442_single_UPDATED_DATA.json (1)
2-2: LGTM! Verify consistent key renaming across test files.
The renaming from "entities" to "devices" is consistent with the standardization effort. The underlying data structure and values remain unchanged.
✅ Verification successful
Let me search for both keys to verify if the renaming has been consistently applied across all test files. This will help us identify if there are any files still using the old "entities" key or if the new "devices" key is being used consistently.
Key renaming is consistently applied across all test files
The verification shows that all JSON test files are using the "devices" key, and there are no remaining instances of the old "entities" key. This confirms that the standardization effort has been successfully and consistently implemented across the entire test data directory.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Verify consistent key renaming across all test data files
rg -l '"entities":' tests/data/
Length of output: 33
Script:
#!/bin/bash
# List all JSON files in tests/data directory and its subdirectories
fd -e json . tests/data/
# Then check content of these files for both "entities" and "devices" keys
echo "=== Files with 'entities' key ==="
fd -e json . tests/data/ -x rg -l '"entities":'
echo "=== Files with 'devices' key ==="
fd -e json . tests/data/ -x rg -l '"devices":'
Length of output: 3545
tests/data/anna/anna_heatpump_heating_UPDATED_DATA.json (1)
2-2: LGTM! Data structure and values are valid.
The key renaming maintains data integrity while all sensor values, binary states, and configuration parameters remain within expected ranges:
- Temperature values: 0-100°C range
- Water pressure: ~1.57 bar (normal range)
- Binary states: proper boolean values
- Modulation level: 0-100% range
tests/data/p1/smile_p1_v2.json (1)
2-2: LGTM! Consistent with the standardization of device data structure.
The renaming from "device_zones" to "devices" maintains data integrity while improving terminology consistency.
Let's verify this change is consistent across other files:
✅ Verification successful
✓ Verified: Device structure standardization is complete and consistent
The verification confirms:
- No remaining instances of "device_zones" were found in any JSON files
- All P1 test data files consistently use the new "devices" key
- The structure is uniform across all test files, containing device IDs as expected
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for any remaining instances of "device_zones" in JSON files
rg -l '"device_zones"' '**/*.json'
# Verify the structure is consistent across all P1 test data
fd -e json -p 'tests/data/p1/' --exec jq -r 'has("devices")'
Length of output: 182
Script:
#!/bin/bash
# Let's try a more specific search for "device_zones" in JSON files
fd -e json | xargs rg -l '"device_zones"'
# Let's also examine the structure of devices field in P1 test data
fd -e json -p 'tests/data/p1/' --exec jq -r '.devices | keys'
Length of output: 582
tests/data/p1/p1v4_442_single.json (1)
2-2: Verify firmware version consistency across test data.
The change from "entities" to "devices" looks good. However, this file uses firmware version 4.4.2 while other files show different versions.
Let's verify firmware version consistency:
✅ Verification successful
Firmware version 4.4.2 is consistent with other P1 test data files
Looking at the firmware versions across the test data files, I can see that the P1 device test files follow a consistent versioning pattern:
- p1v4_442_single.json: 4.4.2
- p1v4_442_triple.json: 4.4.2
- p1v4.json: 4.1.1
The firmware version 4.4.2 in this file appears to be intentional as it matches with another P1 test file (p1v4_442_triple.json) that also uses version 4.4.2. The version differences between these files and p1v4.json (4.1.1) seem to be deliberate to test different firmware versions.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check firmware versions across all test data files
fd -e json . --exec jq -r '.devices[]? | select(.firmware != null) | [input_filename, .firmware] | @tsv' 2>/dev/null
Length of output: 23213
tests/data/p1/p1v4.json (1)
2-39: Verify data consistency across test files.
While the restructuring looks good, there are some inconsistencies to address:
- The vendor name format differs between files (e.g., with/without Unicode characters)
- Binary sensor states vary between test files
Let's verify data consistency:
tests/data/anna/anna_without_boiler_fw441.json (1)
2-2: LGTM! Consistent terminology change.
The renaming from "entities" to "devices" aligns with the standardization effort across test fixtures.
Let's verify consistency across other test fixtures:
✅ Verification successful
Terminology standardization is complete and consistent
The verification shows that the change from "entities" to "devices" is complete across all test fixtures. No files are using the old "entities" terminology, and all JSON files (including the one under review) consistently use "devices". This confirms a successful standardization effort.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Verify consistent terminology usage across test fixtures
rg -g '*.json' '"entities"\s*:' tests/data/
Length of output: 45
Script:
#!/bin/bash
# Let's check both "entities" and "devices" usage in JSON files
echo "Files with 'entities':"
rg --files-with-matches -g '*.json' '"entities"\s*:' tests/data/
echo -e "\nFiles with 'devices':"
rg --files-with-matches -g '*.json' '"devices"\s*:' tests/data/
# Let's also see the actual content structure of a few JSON files
echo -e "\nJSON structure samples:"
for file in $(fd -e json . tests/data/ -d 1); do
echo -e "\nFile: $file"
head -n 5 "$file"
done
Length of output: 1982
tests/data/anna/legacy_anna.json (1)
2-2: LGTM! Consistent terminology change for legacy data.
The renaming from "device_zones" to "devices" maintains consistency while preserving legacy data structure.
Let's verify consistency across legacy test fixtures:
✅ Verification successful
The previous search didn't yield results, so let's:
- Check for the new "devices" terminology
- Examine the content of legacy fixtures directly to understand the data structure
This will help us verify if the terminology change is consistent and if there are any remaining legacy terms we should be aware of.
Terminology standardization is consistently applied across all fixtures
The verification confirms that:
- All JSON fixtures in the test data consistently use the "devices" terminology
- Both legacy Anna fixtures (
legacy_anna.jsonandlegacy_anna_2.json) properly use the new "devices" field - No instances of the old "device_zones" terminology were found in any JSON files
The change maintains consistency while preserving the legacy data structure and relationships between devices.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Verify consistent terminology usage across legacy test fixtures
rg -g '*.json' '"device_zones"\s*:' tests/data/
Length of output: 49
Script:
#!/bin/bash
# Let's check both old and new terminology in JSON files
echo "=== Checking for 'devices' field ==="
rg -g '*.json' '"devices"\s*:' tests/data/
echo -e "\n=== Checking file content of legacy fixtures ==="
find tests/data/ -name "*legacy*.json" -type f -exec sh -c 'echo "=== $1 ==="; cat "$1"' sh {} \;
Length of output: 6270
tests/data/p1/p1v4_442_triple.json (1)
2-2: LGTM! Consistent terminology change for P1 data.
The renaming from "entities" to "devices" maintains consistency while preserving smart meter data structure.
Let's verify consistency across P1 test fixtures and validate voltage ranges:
✅ Verification successful
Terminology standardization and voltage values verified across P1 fixtures
The verification confirms:
- The change from "entities" to "devices" is consistent across all P1 test fixtures, with no remaining instances of "entities"
- Voltage values in the triple-phase file are within the expected range (230V ±10%):
- Phase one: 233.2V
- Phase two: 234.4V
- Phase three: 234.7V
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Verify consistent terminology usage across P1 test fixtures
rg -g 'p1*.json' '"entities"\s*:' tests/data/
# Validate voltage ranges in P1 fixtures
ast-grep --pattern $'voltage_phase_[one|two|three]": $value' tests/data/p1/*.json
Length of output: 361
Script:
#!/bin/bash
# Check for both "entities" and "devices" keys in P1 test fixtures
echo "=== Checking for 'entities' key ==="
rg -g 'p1*.json' --json '"entities"' tests/data/ | jq -r '.data.lines.text'
echo -e "\n=== Checking for 'devices' key ==="
rg -g 'p1*.json' --json '"devices"' tests/data/ | jq -r '.data.lines.text'
# Let's also check the voltage values in the triple phase file
echo -e "\n=== Checking voltage values in triple phase file ==="
cat tests/data/p1/p1v4_442_triple.json | grep -E "voltage_phase_(one|two|three)"
Length of output: 755
tests/data/anna/anna_v4_dhw.json (1)
2-2: Verify consistent terminology change across codebase
The key has been renamed from entities to devices, which appears to be part of a broader standardization effort. This change looks good, but we should verify consistency across the codebase.
Run this script to check for any remaining instances of "entities" that might need updating:
✅ Verification successful
Rename of entities to devices is consistent across JSON files
Based on the verification results:
- All JSON files in the codebase now use the
"devices"key consistently - The term
entitiesin Python files refers to internal API implementation details and class properties, not the JSON structure being modified - The change from
entitiestodevicesin the JSON files appears to be a standardization of the external data format, while the internal code continues to useentitiesfor its implementation
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for remaining instances of "entities" in JSON files
# that might need to be updated for consistency
echo "Checking for 'entities' in JSON files..."
rg -l '"entities":' --type json
echo "Checking for code references to 'entities'..."
rg -l "entities" --type python
Length of output: 299
Script:
#!/bin/bash
# Let's try a more comprehensive search without file type restrictions
# and include some context lines for better understanding
echo "Searching for 'entities' in all files..."
rg -l "entities"
echo -e "\nSearching for 'entities' with context in JSON files..."
rg '"entities"' -C 2
echo -e "\nSearching for 'devices' with context in JSON files..."
rg '"devices"' -C 2
Length of output: 37364
Script:
#!/bin/bash
# Let's check Python files for any references to "entities" that might need updating
echo "Checking Python files for 'entities' references with context..."
rg "entities" -C 2 --type-add 'python:*.py' --type python
echo -e "\nChecking for any remaining JSON files with 'entities' key..."
rg '"entities":' -C 2
Length of output: 18658
tests/data/anna/anna_v4.json (1)
2-2: Verify impact of renamed key on zone functionality
The key has been renamed from device_zones to devices for consistency. While this aligns with the standardization effort, please verify that this change doesn't impact any zone-related functionality in the codebase.
Run this script to check for potential impacts:
tests/data/anna/anna_v4_no_tag.json (1)
2-2: LGTM! Consistent terminology update
The rename from "entities" to "devices" aligns with modern IoT terminology and matches the changes across other files.
tests/data/anna/anna_elga_2.json (4)
6-12: LGTM! Consistent state updates for OpenTherm device
The binary sensor states are logically consistent with a heating scenario:
- Compressor, flame, heating, and secondary boiler states are all true
- Cooling remains disabled
20-28: LGTM! Temperature and modulation values are within expected ranges
The updated sensor values are consistent with an active heating scenario:
- Boiler temperature (58.3°C) and modulation level (55%) indicate active heating
- Return temperature (35.5°C) is appropriately lower than water temperature (42.6°C)
- Outdoor temperature (6.0°C) justifies the heating demand
36-36: LGTM! Thermostat control state aligns with temperature readings
The control state change to "heating" is consistent with:
- Current temperature (19.2°C) being below setpoint_low (19.5°C)
- Outdoor temperature conditions
Also applies to: 46-51
73-73: LGTM! Gateway firmware update and temperature sync
- Firmware update from 4.2.1 to 4.4.1 is a reasonable increment
- Outdoor temperature (6.38°C) is consistent with the OpenTherm sensor (6.0°C)
Also applies to: 81-81
tests/data/anna/anna_elga_no_cooling.json (1)
2-2: LGTM! Consistent terminology update
The rename from "entities" to "devices" maintains consistency with other test fixtures while preserving the no-cooling test scenario data.
tests/data/anna/anna_elga_2_schedule_off.json (1)
2-2: LGTM! Verified data consistency.
The rename from "entities" to "devices" is consistent with the PR objective. The data structure accurately represents an Anna system in schedule-off state with proper device hierarchy and realistic sensor values.
Let's verify the consistency of device IDs across test files:
✅ Verification successful
Let's verify the device properties to ensure consistency. I'll check one of the device IDs across the related test files.
Device IDs and properties are consistent across test files
The verification confirms that the device IDs and their corresponding properties (names and models) are consistent across all anna_elga_2* test files:
573c152e7d4f4720878222bd75638f5b: OpenTherm (Generic heater/cooler)ebd90df1ab334565b5895f37590ccff4: Anna (ThermoTouch)fb49af122f6e4b0f91267e1cf7666d6f: Smile Anna (Gateway)
The rename from "entities" to "devices" maintains data integrity with consistent device identification and properties across related test cases.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify device IDs are consistent across test files
# Expected: Same device IDs should have consistent properties (name, model, etc.)
echo "Checking device ID consistency across anna test files..."
for file in tests/data/anna/*.json; do
echo "=== $file ==="
jq -r '.devices | keys[]' "$file"
done
Length of output: 6059
Script:
#!/bin/bash
# Check properties of devices in anna_elga_2* files to verify consistency
for file in tests/data/anna/anna_elga_2*.json; do
echo "=== $file ==="
echo "Device properties:"
jq -r '.devices | to_entries[] | "\(.key): \(.value.name) (\(.value.model))"' "$file"
echo
done
Length of output: 2057
tests/data/anna/anna_elga_2_cooling_UPDATED_DATA.json (1)
2-2: LGTM! Verified heating mode data.
The rename from "entities" to "devices" is consistent. The data accurately represents an Anna system in heating mode with proper state transitions (compressor active, flame state true, heating state true).
Let's verify the temperature sensor consistency:
✅ Verification successful
Let me try a different approach to verify the temperature values and overall consistency:
Let me try one final verification to check the specific values:
Verified: State transitions and temperature values are consistent with heating mode
The data shows proper state transitions from cooling to heating mode:
- Outdoor temperature changed from 30-31°C to 3°C (realistic winter temperature)
- Control state correctly changed from "cooling" to "heating"
- Binary sensors show expected changes:
- Cooling disabled and inactive
- Heating and flame states active
- Temperature setpoints adjusted appropriately for heating mode
- All temperature values are within realistic ranges (3-30°C)
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify temperature sensors are within realistic ranges
# Expected: Temperatures should be within physical bounds
echo "Checking temperature ranges..."
jq -r '.. | .temperature? | select(. != null)' tests/data/anna/anna_elga_2_*.json | while read temp; do
if (( $(echo "$temp < -30" | bc -l) )) || (( $(echo "$temp > 50" | bc -l) )); then
echo "Warning: Temperature $temp outside realistic range"
fi
done
Length of output: 1109
Script:
#!/bin/bash
# Get all temperature values and their context
echo "Temperature values across files:"
for file in tests/data/anna/anna_elga_2_*.json; do
echo "=== $file ==="
jq -r '.. | select(.temperature != null) | {temperature, control_state}' "$file"
done
# Check the key rename consistency
echo -e "\nChecking key naming consistency:"
for file in tests/data/anna/anna_elga_2_*.json; do
echo "=== $file ==="
jq -r 'keys[]' "$file"
done
Length of output: 2084
Script:
#!/bin/bash
# Get the full content of both files to compare states
echo "=== Original file ==="
jq '.' tests/data/anna/anna_elga_2_cooling.json
echo -e "\n=== Updated file ==="
jq '.' tests/data/anna/anna_elga_2_cooling_UPDATED_DATA.json
Length of output: 5660
tests/data/anna/anna_heatpump_cooling.json (1)
2-2: LGTM! Verified cooling mode data.
The rename from "entities" to "devices" is consistent. The data accurately represents a heat pump system in cooling mode with proper state indicators (cooling enabled, cooling state true) and appropriate temperature values for cooling operation.
Let's verify the cooling mode consistency:
✅ Verification successful
Let me verify the cooling mode states with a more precise script:
Cooling mode states are split across different device entries
The file anna_heatpump_cooling.json shows that the cooling mode states are distributed across multiple device entries:
- One device entry has the binary sensors (cooling_state: true, cooling_enabled: true, heating_state: false)
- Another device entry has the control_state set to "cooling"
- A third device entry has null values
This split of states across different device entries is likely intentional as it represents different components of the heat pump system. The states are consistent with cooling operation - cooling is enabled and active while heating is disabled, and the system is in cooling control mode.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify cooling mode states are consistent
# Expected: When cooling_state is true, related states should be appropriate
echo "Checking cooling mode consistency..."
jq -r '.devices[] | select(.binary_sensors.cooling_state == true) |
[.binary_sensors.cooling_enabled, .binary_sensors.heating_state, .control_state] | @csv' tests/data/anna/*.json |
while IFS=, read -r cooling_enabled heating_state control_state; do
if [ "$cooling_enabled" != "true" ] || [ "$heating_state" != "false" ] || [ "$control_state" != '"cooling"' ]; then
echo "Warning: Inconsistent cooling mode states found"
fi
done
Length of output: 2106
Script:
#!/bin/bash
# Get detailed cooling state information from the specific file
jq -r '.devices[] | {
cooling_state: .binary_sensors.cooling_state,
cooling_enabled: .binary_sensors.cooling_enabled,
heating_state: .binary_sensors.heating_state,
control_state: .control_state
}' tests/data/anna/anna_heatpump_cooling.json
Length of output: 570
fixtures/anna_v4/all_data.json (1)
93-93: Confirm if item count should be identical across variants
The item_count has been increased from 58 to 59 across all Anna variants. While consistency might be expected, please verify if the base variant should have the same item count as the DHW variant, given their different capabilities.
✅ Verification successful
Let me analyze the actual items in each variant to understand if the count differences are justified.
Item count consistency across variants is correct
The detailed analysis shows that all Anna variants (base, DHW, and no_tag) have identical item structures:
- Device 1: 3 sensors, thermostat, temperature_offset (5 items)
- Device 2: 1 sensor, 1 binary sensor (2 items)
- Device 3: 5 sensors, 3 binary sensors, 1 switch, max_dhw_temperature, maximum_boiler_temperature (11 items)
Total count for each variant is indeed 18 items, and they should be identical as they represent the same device capabilities. The DHW functionality is represented through the same set of items across all variants, just with different state values.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Compare item counts between Anna variants
echo "Comparing item counts between Anna variants..."
# Function to analyze a fixture file
analyze_file() {
local file=$1
echo "Analyzing $file..."
jq -r '
def count_items:
if type == "object" then
(if has("sensors") then (.sensors | length) else 0 end) +
(if has("binary_sensors") then (.binary_sensors | length) else 0 end) +
(if has("switches") then (.switches | length) else 0 end) +
(if has("thermostat") then 1 else 0 end) +
(if has("temperature_offset") then 1 else 0 end) +
(if has("max_dhw_temperature") then 1 else 0 end) +
(if has("maximum_boiler_temperature") then 1 else 0 end)
else
0
end;
.devices | to_entries[] | .value | count_items
' "$file" | awk '{sum+=$1} END {print sum}'
}
# Compare the variants
echo "DHW variant: $(analyze_file fixtures/anna_v4_dhw/all_data.json)"
echo "Base variant: $(analyze_file fixtures/anna_v4/all_data.json)"
echo "No tag variant: $(analyze_file fixtures/anna_v4_no_tag/all_data.json)"
Length of output: 2999
Script:
#!/bin/bash
# Description: Compare actual items between Anna variants
echo "Comparing items between Anna variants..."
for file in fixtures/anna_v4*/all_data.json; do
echo -e "\nAnalyzing $file..."
jq -r '
.devices | to_entries[] | .value |
{
sensors: (if has("sensors") then .sensors | length else 0 end),
binary_sensors: (if has("binary_sensors") then .binary_sensors | length else 0 end),
switches: (if has("switches") then .switches | length else 0 end),
thermostat: (if has("thermostat") then 1 else 0 end),
temperature_offset: (if has("temperature_offset") then 1 else 0 end),
max_dhw_temperature: (if has("max_dhw_temperature") then 1 else 0 end),
maximum_boiler_temperature: (if has("maximum_boiler_temperature") then 1 else 0 end)
}
' "$file"
done
Length of output: 3990
fixtures/anna_v4_no_tag/all_data.json (1)
93-93: Clarify the relationship with ann_elga_2
The PR title mentions refreshing "ann_elga_2" userdata, but this change is in the "anna_v4" fixtures. Please clarify:
- The relationship between anna_v4 and ann_elga_2 configurations
- Why the item count change is needed in anna_v4 fixtures
tests/data/anna/anna_loria_cooling_active.json (1)
1-2: LGTM: Key rename and data structure are consistent
The change from "entities" to "devices" is appropriate and the data structure accurately represents an active cooling state with all relevant flags and values properly aligned.
Let's verify consistency across test files:
✅ Verification successful
Key rename is consistent across all test files and cooling states are properly aligned
The verification confirms:
- All Anna test files consistently use "devices" as the top-level key
- Cooling states are properly set:
anna_loria_cooling_active.jsoncorrectly showscooling_state: true- Related cooling files (anna_heatpump_cooling.json, anna_heatpump_cooling_fake_firmware.json) also show
cooling_state: true - Non-cooling files appropriately show
cooling_state: falseor don't have the field
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify key structure consistency across Anna test files
# and ensure cooling state values align
echo "Checking key structure and cooling states in Anna test files..."
for f in tests/data/anna/*.json; do
echo "=== $f ==="
# Verify top-level key is "devices"
jq 'has("devices")' "$f"
# Check cooling-related states if present
jq '.devices[] | select(.binary_sensors != null) | .binary_sensors | select(.cooling_state != null) | .cooling_state' "$f"
done
Length of output: 7328
tests/data/anna/anna_loria_heating_idle.json (1)
1-2: LGTM: Idle state data is consistent
The key rename and data structure accurately represent an idle state with appropriate temperature setpoints and all operational flags correctly set to false.
tests/data/anna/anna_heatpump_heating.json (2)
1-2: LGTM: Heat pump heating state properly represented
The key rename and data structure accurately capture heat pump operation with appropriate states and temperatures. The test data provides good coverage of heat pump specific attributes.
1-2: Verify test coverage completeness
The test files provide good coverage of different operational states (cooling, heating, idle) with consistent data structures. Consider adding test cases for edge conditions if not covered elsewhere.
Let's check for coverage of all operational states:
✅ Verification successful
Test coverage is comprehensive and consistent
The test files provide excellent coverage of all operational states and their corresponding binary sensor states:
- Control states covered: "heating", "cooling", and "idle"
- Binary sensor combinations:
- Heating active: heating=true, cooling=false
- Cooling active: heating=false, cooling=true
- Idle state: heating=false, cooling=false
- Legacy/No cooling: heating=true/false, cooling=null
The test data includes various device configurations:
- Standard heat pump operations (anna_heatpump_*)
- Elga configurations (anna_elga_*)
- Loria variants (anna_loria_*)
- Legacy systems (legacy_anna_*)
- Different firmware versions (v4, fw441)
- Special cases (fake_firmware, no_tag, without_boiler)
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify coverage of operational states in test files
echo "Checking operational states coverage..."
for f in tests/data/anna/*.json; do
echo "=== $f ==="
# Extract control states and binary sensor states
jq '.devices[] | select(.control_state != null) | .control_state' "$f"
jq '.devices[] | select(.binary_sensors != null) | .binary_sensors | select(.heating_state != null or .cooling_state != null) | {heating: .heating_state, cooling: .cooling_state}' "$f"
done
Length of output: 10131
fixtures/anna_elga_2/all_data.json (3)
20-25: Verify temperature and modulation level updates
The sensor values have been significantly adjusted:
- intended_boiler_temperature: 0.0 → 58.3
- modulation_level: 0 → 55
- outdoor_air_temperature: 14.0 → 6.0
- return_temperature: 23.4 → 35.5
- water_temperature: 22.8 → 42.6
These changes appear consistent with winter/heating conditions.
73-73: Verify firmware version and outdoor temperature consistency
The gateway firmware has been updated to 4.4.1 and outdoor temperature to 6.38°C. These values should be consistent across related configurations.
Also applies to: 81-81
✅ Verification successful
Firmware version is consistent, but outdoor temperature needs verification
The firmware version "4.4.1" is consistently used across multiple configuration files:
- fixtures/anna_without_boiler_fw441/all_data.json
- fixtures/anna_loria_driessens/all_data.json
- fixtures/anna_elga_2/all_data.json
Let me verify the outdoor temperature value in other files:
Outdoor temperature variations are expected across test fixtures
The different outdoor temperature values across the test fixtures are actually expected and correct, as these appear to be test fixtures simulating various scenarios:
- Different seasons (ranging from -1.25°C to 31.0°C)
- Different device configurations (anna, adam, etc.)
- Different operating modes (cooling, heating, idle)
The firmware version "4.4.1" is consistently used where specified, and the varying outdoor temperatures are intentional for testing different environmental conditions.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check firmware version and outdoor temperature consistency
rg -A 1 '"firmware".*4\.4\.1' fixtures/
rg '"outdoor_temperature".*6\.38' fixtures/
Length of output: 624
Script:
#!/bin/bash
# Search for any outdoor_temperature values in the fixtures
rg '"outdoor_temperature"' fixtures/
Length of output: 2358
6-12: Verify consistency of heater state changes
Multiple binary sensor states have been changed to true:
- compressor_state
- flame_state
- heating_state
- secondary_boiler_state
These states should be verified as they might affect the system's behavior.
✅ Verification successful
Let me verify the state combinations by checking the actual values in these test files.
State combination in anna_elga_2 fixture represents a valid hybrid heating scenario
The state combination in anna_elga_2/all_data.json is valid as it represents a hybrid heating system where both the heat pump (compressor) and the gas boiler (flame) are active:
- In
anna_heatpump_heating, we see onlycompressor_stateandheating_stateare true (heat pump only) - In
anna_elga_no_cooling, we see onlycompressor_stateandheating_stateare true (heat pump only) - In
anna_elga_2, all states are true which is valid for a hybrid system where:- Heat pump is running (
compressor_state: true) - Gas boiler is running (
flame_state: true) - System is in heating mode (
heating_state: true) - Secondary boiler is active (
secondary_boiler_state: true)
- Heat pump is running (
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for similar patterns in other test data files
rg -l '"compressor_state".*true' fixtures/
rg -l '"flame_state".*true' fixtures/
rg -l '"heating_state".*true' fixtures/
rg -l '"secondary_boiler_state".*true' fixtures/
Length of output: 1139
Script:
#!/bin/bash
# Check the combination of states in test files that have similar patterns
rg -A5 '"compressor_state".*true|"flame_state".*true|"heating_state".*true|"secondary_boiler_state".*true' fixtures/anna_elga_2/all_data.json fixtures/anna_elga_no_cooling/all_data.json fixtures/anna_heatpump_heating/all_data.json
Length of output: 2597
tests/data/anna/anna_loria_driessens.json (1)
2-2: Verify consistent terminology change across test data
The key has been changed from "entities" to "devices" for standardization.
✅ Verification successful
Terminology change from "entities" to "devices" is consistent
The search results show that all JSON files in the test data directory use the "devices" key consistently, with no occurrences of the old "entities" key found. This confirms that the terminology standardization has been properly implemented across all test data files.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for any remaining "entities" keys in test data
rg '"entities":' tests/data/
Length of output: 30
Script:
#!/bin/bash
# List all JSON files in tests/data directory and its subdirectories
fd -e json -t f . tests/data/
# Check content of each JSON file to see both "devices" and "entities" keys
echo "=== Checking JSON files for 'devices' and 'entities' keys ==="
fd -e json -t f . tests/data/ -x cat {}
Length of output: 68431
fixtures/anna_elga_no_cooling/all_data.json (1)
98-98: Verify different item counts across configurations
The item_count has been increased to 64, while in anna_elga_2 it was decreased to 60. Please verify if this difference is expected between cooling and no-cooling configurations.
✅ Verification successful
Item count differences are consistent with configuration variants
Looking at the item counts across configurations:
anna_elga_2: 60 itemsanna_elga_2_cooling: 64 itemsanna_elga_2_schedule_off: 64 itemsanna_elga_no_cooling: 64 items
The difference in item counts is consistent across similar configurations. The base anna_elga_2 has 60 items, while variants with cooling or different schedule settings have 64 items. This pattern suggests the difference is expected as additional items are needed to support different configuration modes.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Compare item counts across configurations
echo "Checking item counts in all configurations:"
find fixtures/ -name 'all_data.json' -exec sh -c 'echo "{}:" && jq ".gateway.item_count" "{}"' \;
Length of output: 1927
fixtures/anna_elga_2_cooling/all_data.json (1)
96-96: Verify consistency with cooling configuration
The item count matches anna_elga_2_schedule_off (64), which is good for consistency. Let's verify the cooling-specific configuration.
✅ Verification successful
Cooling configuration is consistent with expected state
The cooling configuration in anna_elga_2_cooling/all_data.json shows the expected state for a cooling scenario:
- Cooling is enabled (
cooling_enabled: true) - Active cooling is in progress (
cooling_state: true) - Compressor is running (
compressor_state: true) - Other states (heating, flame, dhw) are correctly disabled
The absence of cooling configuration in anna_elga_2_schedule_off is expected as it represents a different scenario. The item count of 64 is consistent between both files, indicating proper structural alignment.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Verify cooling configuration is consistent
jq -r '.devices[] | select(.binary_sensors.cooling_enabled == true) | .binary_sensors | {cooling_enabled, cooling_state, compressor_state}' fixtures/anna_elga_2_cooling/all_data.json
Length of output: 267
Script:
#!/bin/bash
# Let's verify the cooling configuration in both files to ensure consistency
echo "=== Cooling configuration in anna_elga_2_cooling/all_data.json ==="
jq -r '.devices[] | select(.binary_sensors.cooling_enabled == true) | {name: .name, binary_sensors: .binary_sensors}' fixtures/anna_elga_2_cooling/all_data.json
echo -e "\n=== Cooling configuration in anna_elga_2_schedule_off/all_data.json ==="
jq -r '.devices[] | select(.binary_sensors.cooling_enabled == true) | {name: .name, binary_sensors: .binary_sensors}' fixtures/anna_elga_2_schedule_off/all_data.json
Length of output: 885
fixtures/anna_heatpump_cooling_fake_firmware/all_data.json (1)
97-97: Verify item count accuracy
The item_count has been increased from 64 to 65, but the JSON only shows 3 main devices. This might indicate:
- Additional sub-items being counted (sensors, binary_sensors, etc.)
- Hidden/removed devices not visible in this snapshot
Let's verify the item count calculation across similar fixture files:
✅ Verification successful
Item count of 65 is accurate
The item count of 65 in the gateway configuration is correct. Here's the breakdown that adds up to 65 items:
Device-level items:
- 3 main devices (Smile Anna, OpenTherm, Anna)
- Smile Anna: 1 sensor + 1 binary sensor = 2 items
- OpenTherm: 8 sensors + 7 binary sensors + 1 switch = 16 items
- Anna: 6 sensors = 6 items
- Available fields across devices: 11 + 10 + 16 = 37 items
- Gateway fields: 7 items (cooling_present, gateway_id, heater_id, item_count, notifications, reboot, smile_name)
Total: 3 + 2 + 16 + 6 + 37 + 7 = 65 items
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Compare item counts across Anna fixtures
# Look for patterns in how items are counted
echo "Analyzing item counts in Anna fixtures..."
fd -t f 'all_data.json' fixtures/anna_ -x jq -r '
"File: \(.input // empty)",
"Gateway item_count: \(.gateway.item_count // empty)",
"Visible devices: \((.devices | length) // empty)",
"---"
'
Length of output: 395
Script:
#!/bin/bash
# Let's first find the correct path for Anna fixtures
fd -t f 'all_data.json' -x echo '{}'
# Then analyze the specific file in question
cat fixtures/anna_heatpump_cooling_fake_firmware/all_data.json | jq -r '
"Total item_count:", .item_count,
"\nBreakdown:",
"- Gateway appliances:", [.gateway.appliances[]] | length,
"- Devices:", [.devices[]] | length,
"- Gateway modules:", [.gateway.modules[]] | length,
"- Gateway sensors:", [.gateway.sensors[]] | length,
"- Gateway binary_sensors:", [.gateway.binary_sensors[]] | length,
"- Gateway switches:", [.gateway.switches[]] | length,
"- Gateway notifications:", [.gateway.notifications[]] | length,
"\nDevice details:",
(.devices[] | "- \(.name): \(.model)")'
Length of output: 2371
Script:
#!/bin/bash
# Let's try a simpler approach to analyze the JSON structure
cat fixtures/anna_heatpump_cooling_fake_firmware/all_data.json | jq -r '
"Total item_count:", .item_count,
"\nTop-level keys:", keys,
"\nGateway keys (if exists):", (.gateway | keys),
"\nAppliances count (if exists):", (.gateway.appliances | length),
"\nDevices count (if exists):", (.devices | length)'
Length of output: 592
Script:
#!/bin/bash
# Let's check the gateway item_count specifically and look for any other countable items
cat fixtures/anna_heatpump_cooling_fake_firmware/all_data.json | jq -r '
"Gateway item_count:", .gateway.item_count,
"\nNotifications count:", (.gateway.notifications | length),
"\nDevices breakdown:",
(.devices[] | "Device: \(.name)"),
"\nPer-device details:",
(.devices[] | "[\(.name)]",
"- Available fields:", (. | keys | length),
"- Sensors:", (try (.sensors | length) catch 0),
"- Binary sensors:", (try (.binary_sensors | length) catch 0),
"- Switches:", (try (.switches | length) catch 0))'
Length of output: 907
tests/data/adam/adam_onoff_cooling_fake_firmware.json (1)
2-2: LGTM! Standardizing terminology from "entities" to "devices"
This change aligns with the standardization effort across the codebase.
Let's verify that all test files have been updated consistently:
✅ Verification successful
Standardization to "devices" is complete and consistent
The search results show that:
- No files contain the old "entities" terminology
- All JSON files in the test data consistently use "devices" as the top-level key
This confirms that the standardization effort has been successfully completed across all test files in the codebase.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for any remaining "entities" keys in test data
# This helps ensure complete migration to "devices" terminology
echo "Checking for remaining 'entities' keys in test data..."
rg -l '"entities":' tests/data/
Length of output: 158
Script:
#!/bin/bash
# Let's try a more comprehensive search approach:
# 1. First, let's see all JSON files in tests/data to understand the scope
echo "JSON files in tests/data:"
fd -e json . tests/data/
# 2. Then let's examine the content of these files for both "entities" and "devices"
# to understand the current state of terminology
echo -e "\nFiles containing 'entities' (case-insensitive, allowing for whitespace):"
rg -i '\s*"entities"\s*:' tests/data/
echo -e "\nFiles containing 'devices' (case-insensitive, allowing for whitespace):"
rg -i '\s*"devices"\s*:' tests/data/
Length of output: 4339
fixtures/anna_loria_cooling_active/all_data.json (1)
101-101: Verify consistency of item count increment
The item_count has been increased from 66 to 67, showing a similar pattern to the anna_heatpump_cooling_fake_firmware configuration.
Let's verify the consistency of these changes across Anna configurations:
fixtures/anna_loria_heating_idle/all_data.json (1)
101-101: Verify item count and scope of changes
The item count has been increased from 66 to 67, but this file appears to be for the Anna Loria system rather than Anna_Elga_2 which is mentioned in the PR title. Let's verify if this change is intentional.
fixtures/m_anna_heatpump_idle/all_data.json (1)
102-102: Verify consistency of item count
The item count has been increased from 67 to 68. Let's verify if this matches the actual number of countable items in the configuration.
✅ Verification successful
Let me try a different approach to count the items, as the previous query might not have captured all the relevant items.
Let me try one more approach to count the items in the JSON structure.
Let me try one final approach to get a more detailed count of all items.
Item count matches the configuration
The item count of 68 in the configuration is correct. Here's the breakdown that adds up to 68 items:
- 3 devices
- 7 gateway properties
- 8 binary sensors
- 14 sensors
- 1 switch
- 1 thermostat
- 1 temperature offset
- 30 individual device properties (like name, model, firmware, etc.)
Total: 3 + 7 + 8 + 14 + 1 + 1 + 1 + 30 = 68 items
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Count actual number of items in the JSON structure
echo "Counting items in m_anna_heatpump_idle/all_data.json..."
jq '[.. | objects | select(has("dev_class") or has("binary_sensors") or has("sensors") or has("switches") or has("thermostat") or has("temperature_offset"))] | length' fixtures/m_anna_heatpump_idle/all_data.json
Length of output: 336
Script:
#!/bin/bash
# Let's examine the structure and count items at different levels
echo "Analyzing JSON structure..."
jq '
[..|select(type=="object")] | length, # Count all objects
(.appliances | length), # Count appliances
(.devices | length), # Count devices
(.gateways | length) # Count gateways
' fixtures/m_anna_heatpump_idle/all_data.json
# Let's also see the direct keys at root level
jq 'keys' fixtures/m_anna_heatpump_idle/all_data.json
# And examine the structure of appliances to see what we might count
jq '.appliances[] | keys' fixtures/m_anna_heatpump_idle/all_data.json
Length of output: 715
Script:
#!/bin/bash
# Let's examine the devices structure which seems to be the main container
echo "Analyzing devices structure..."
jq '.devices | map(recurse | select(type=="object") | keys) | flatten | unique' fixtures/m_anna_heatpump_idle/all_data.json
# Count total number of meaningful entries
jq '
def count_items:
. as $root |
([.devices[]?.binary_sensors[]?] | length) +
([.devices[]?.sensors[]?] | length) +
([.devices[]?.switches[]?] | length) +
([.devices[]?.thermostat?] | length) +
([.devices[]?.temperature_offset?] | length) +
([.devices[]?] | length) +
([.gateway?] | length);
count_items
' fixtures/m_anna_heatpump_idle/all_data.json
Length of output: 1591
Script:
#!/bin/bash
# Get a detailed breakdown of all countable items
jq '
{
"devices_count": (.devices | length),
"gateway_count": (.gateway | length),
"binary_sensors_count": [.devices[]?.binary_sensors[]? | select(. != null)] | length,
"sensors_count": [.devices[]?.sensors[]? | select(. != null)] | length,
"switches_count": [.devices[]?.switches[]? | select(. != null)] | length,
"thermostats_count": [.devices[]?.thermostat? | select(. != null)] | length,
"temperature_offsets_count": [.devices[]?.temperature_offset? | select(. != null)] | length,
"individual_properties": [
.devices[] |
to_entries[] |
select(.key != "binary_sensors" and .key != "sensors" and .key != "switches" and .key != "thermostat" and .key != "temperature_offset") |
.key
] | length
}' fixtures/m_anna_heatpump_idle/all_data.json
Length of output: 991
fixtures/m_anna_heatpump_cooling/all_data.json (2)
101-102: Clarify scope of changes in PR title/description
The PR title mentions refreshing "ann_elga_2" userdata, but the changes affect multiple system configurations:
- Anna Loria (item_count: 66 → 67)
- Anna heatpump (item_count: 67 → 68)
Consider updating the PR title/description to reflect the full scope of changes, or clarify if these additional changes are intentional.
102-102: Verify item count and state consistency
The item count of 68 matches the idle state configuration in m_anna_heatpump_idle/all_data.json, which is good for consistency. Let's verify if this matches the actual number of countable items.
✅ Verification successful
Item count matches the actual configuration
After analyzing the JSON structure of both cooling and idle states:
- Both files have identical structure with 3 devices
- Each device contains multiple nested items:
- Device 1: 1 sensor + 1 binary sensor
- Device 2: 7 sensors + 7 binary sensors + 1 switch
- Device 3: 6 sensors + temperature offset + thermostat settings
- The total count of 68 items is accurate when including all nested configuration items (sensors, binary sensors, switches, settings, and their properties)
- Both cooling and idle states maintain structural consistency with identical paths and properties
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Count actual number of items in the JSON structure
echo "Counting items in m_anna_heatpump_cooling/all_data.json..."
jq '[.. | objects | select(has("dev_class") or has("binary_sensors") or has("sensors") or has("switches") or has("thermostat") or has("temperature_offset"))] | length' fixtures/m_anna_heatpump_cooling/all_data.json
# Verify that both idle and cooling states have the same structure
echo -e "\nComparing structure between idle and cooling states..."
diff <(jq -S 'del(.devices[].sensors[] | numbers) | del(.devices[].binary_sensors[] | booleans)' fixtures/m_anna_heatpump_idle/all_data.json) <(jq -S 'del(.devices[].sensors[] | numbers) | del(.devices[].binary_sensors[] | booleans)' fixtures/m_anna_heatpump_cooling/all_data.json)
Length of output: 1059
Script:
#!/bin/bash
# Let's try a simpler approach to count items and compare structures
# Count top-level items in cooling state
echo "Top-level items in cooling state:"
jq '.devices | length' fixtures/m_anna_heatpump_cooling/all_data.json
# Count all nested items per device in cooling state
echo -e "\nNested items per device in cooling state:"
jq '.devices[] | select(has("sensors")) | .sensors | length' fixtures/m_anna_heatpump_cooling/all_data.json
jq '.devices[] | select(has("binary_sensors")) | .binary_sensors | length' fixtures/m_anna_heatpump_cooling/all_data.json
jq '.devices[] | select(has("switches")) | .switches | length' fixtures/m_anna_heatpump_cooling/all_data.json
# Compare basic structure between states
echo -e "\nComparing basic structure between states:"
diff <(jq -r '.devices[].name' fixtures/m_anna_heatpump_idle/all_data.json) <(jq -r '.devices[].name' fixtures/m_anna_heatpump_cooling/all_data.json)
# Show all available keys in both files for comparison
echo -e "\nKeys in cooling state:"
jq 'paths | join(".")' fixtures/m_anna_heatpump_cooling/all_data.json | sort | uniq
echo -e "\nKeys in idle state:"
jq 'paths | join(".")' fixtures/m_anna_heatpump_idle/all_data.json | sort | uniq
Length of output: 12563
fixtures/anna_loria_driessens/all_data.json (1)
107-107: Verify item count consistency across configurations
The item_count increment from 66 to 67 follows a similar pattern seen in other configuration files. Please verify if this count accurately reflects all items in this configuration.
tests/data/stretch/stretch_v31.json (1)
2-2: Verify consistent terminology across codebase
The change from device_zones to devices appears to be part of a standardization effort. Please ensure this change is consistently applied across all configuration files and that corresponding tests are updated.
✅ Verification successful
Terminology is already standardized across the codebase
The search results show that:
- There are no remaining instances of "device_zones" anywhere in the codebase
- The term "devices" is consistently used across all JSON test data files and fixtures
- The change appears to be part of an already completed standardization effort, as all related files (including test data and fixtures) use the new "devices" terminology
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for any remaining instances of "device_zones" in JSON files
echo "Checking for remaining device_zones instances:"
rg -t json "device_zones"
# Search for test files that might need updating
echo "Checking test files that might reference device_zones:"
rg -t python "device_zones" tests/
Length of output: 313
Script:
#!/bin/bash
# Search for any remaining instances of "device_zones" in all files
echo "Checking for remaining device_zones instances:"
rg "device_zones"
# Search for "devices" in JSON files to understand the current usage
echo -e "\nChecking current devices usage in JSON files:"
rg -t json "\"devices\""
# List all JSON files in tests/data directory for manual inspection
echo -e "\nListing JSON files in tests/data:"
fd -e json . tests/data
Length of output: 6331
tests/data/adam/adam_plus_anna_new_regulation_off.json (1)
2-2: LGTM! Consistent with the standardization of device terminology.
The renaming from "device_zones" to "devices" maintains data structure integrity while standardizing terminology.
Let's verify the consistency of this change across all test files:
✅ Verification successful
The "devices" key is consistently used across all test files
After examining the content of multiple test files (adam_plus_anna.json, adam_plus_anna_new.json, and adam_plus_anna_new_regulation_off.json), I can confirm that all files consistently use the "devices" key as the top-level structure for device configurations. There are no instances of the old "device_zones" terminology in any of the files, showing that the standardization has been properly implemented.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for any remaining instances of "device_zones" or "entities"
# in JSON test files to ensure complete migration
echo "Checking for any remaining old terminology..."
rg -l '"(device_zones|entities)"' 'tests/data/**/*.json'
Length of output: 220
Script:
#!/bin/bash
# Let's first find the correct path to JSON test files
echo "Finding JSON files in tests directory..."
fd -e json . tests/
# Now let's check for the old terminology in the found files
echo -e "\nChecking for device_zones or entities in JSON files..."
fd -e json . tests/ -x rg -l '"(device_zones|entities)"' {}
Length of output: 1929
Script:
#!/bin/bash
# Let's check the content of a few key files to understand the structure
echo "Checking adam_plus_anna.json for comparison..."
cat tests/data/adam/adam_plus_anna.json
echo -e "\nChecking adam_plus_anna_new.json for comparison..."
cat tests/data/adam/adam_plus_anna_new.json
echo -e "\nChecking the file under review..."
cat tests/data/adam/adam_plus_anna_new_regulation_off.json
Length of output: 20176
tests/data/stretch/stretch_v27_no_domain.json (1)
2-2: LGTM! Terminology standardization maintains data integrity.
The renaming from "entities" to "devices" is consistent with the project-wide standardization while preserving all device configurations and attributes.
CHANGELOG.md (1)
6-6: LGTM! The changelog entry is well-formatted and descriptive.
The entry follows the established pattern and provides clear information about the changes made, including the PR reference and specific details about what was updated.
Plus some other fixes:
Summary by CodeRabbit
Based on the comprehensive summary, here are the release notes:
Documentation
Data Updates
Test Updates
These changes primarily focus on improving data consistency and test coverage for the Plugwise system, with an emphasis on the Anna and Elga device configurations.