Fix tests for PR #282 mompow field - update property counts, add test assertions, convert values to Watts, implement power state logic, remove architectural redundancy, and add changelog entry

[Copilot]

This PR fixes the failing tests that were preventing PR #282 from being merged. PR #282 adds support for the mompow (momentary power) sensor property to the SensorInfoResponse class, but the existing tests had hardcoded expectations that broke when the new field was added.

Problem

When PR #282 added the mompow field to SensorInfoResponse, it increased the number of properties from 5 to 6, causing several test assertions to fail:

• Tests were checking Object.keys(response).length === 5 but now there are 6 properties
• No test coverage existed for the new mompow field functionality
• The raw device values needed conversion from 0.1kW units to Watts for better usability
• Power state logic was needed to handle cases where the AC reports power consumption when it's actually off

Solution

1. Applied PR add support for 'mompow' sensor property #282 changes: Added the mompow?: number property and parsing logic to SensorInfoResponse.ts
2. Updated test expectations: Changed hardcoded property count checks from 5 to 6 in both test files
3. Enhanced test coverage: Added mompow field to mock sensor data with different values (150, 200, 300)
4. Added specific assertions: Verified that the mompow field is properly parsed and accessible
5. Implemented unit conversion: Added conversion from device's native 0.1kW units to Watts by multiplying by 100
6. Added power state logic: Implemented high-level logic in getACSensorInfo() method to set mompow=0 when the AC is powered off (pow=0)
7. Fixed test infrastructure: Added missing demand_control mocks to prevent test hanging issues
8. Removed architectural redundancy: Eliminated duplicate power state logic that was redundantly implemented in both updateData() and getACSensorInfo() methods
9. Added edge case test coverage: Added specific test case to verify power state logic works when device reports spurious power consumption while AC is off
10. Added changelog entry: Added version 2.3.0 changelog entry in README.md documenting the new mompow field support

Changes Made

• README.md: Added changelog entry for version 2.3.0 documenting mompow field support
• SensorInfoResponse.ts: Added mompow property and parsing with unit conversion (×100)
• DaikinAC.ts: Added power state logic in getACSensorInfo() method only (removed duplicate from updateData())
• testDaikinAC.test.ts: Updated property counts, mompow expectations, and added demand_control mocks
• testDaikinACGet.test.ts: Updated property counts, mompow expectations, added demand_control mocks, and added new test case for power state edge case

Test Results

✅ All 27 tests now pass successfully (increased from 26 due to new test case)
✅ SensorInfoResponse.ts maintains high test coverage
✅ New mompow field is properly tested with various values
✅ Backward compatibility preserved - existing functionality unchanged
✅ Power state logic works correctly and is properly tested
✅ Architectural redundancy eliminated - cleaner, more maintainable code

Unit Conversion Details

The mompow field now represents momentary power consumption in Watts:

• Raw device value is converted from 0.1kW to Watts (raw value × 100)
• Device reports: mompow=15 → Library exposes: mompow=1500 (Watts)

Power State Logic

Implemented at the getACSensorInfo() method level:

• When AC is powered off (power=false in control_info), mompow is set to 0 regardless of raw sensor value
• When control info is not available (individual sensor calls), returns converted raw values without power state logic
• Addresses the issue where devices report spurious power consumption values when AC is off
• Added test coverage for edge case where device reports mompow=1 but pow=0

Architecture Note

Power state logic is correctly implemented at the DaikinAC.getACSensorInfo() method level where both get_control_info and get_sensor_info data can be made available together. Previous duplicate implementation in updateData() was redundant since updateData() calls getACSensorInfo() which already applies the logic.

Changelog

Added version 2.3.0 entry to README.md changelog documenting:

• Support for mompow (momentary power consumption) sensor field
• Unit conversion from device units (0.1kW) to Watts for better usability
• Power state logic to set mompow=0 when AC is powered off (pow=0)

Fixes #291.

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[Copilot]

@Apollon77 👋 This repository doesn't have Copilot instructions. With Copilot instructions, I can understand the repository better, work faster and produce higher quality PRs.

I can generate a .github/copilot-instructions.md file for you automatically. Click here to open a pre-filled issue and assign it to me. I'll write the instructions, and then tag you for review.

[Apollon77]

@copilot please also check the details of the original or comments on how the value needs to be read. I would like to expose the value in Watt so we need to multiply it depending on the value

[Copilot]

@copilot please also check the details of the original or comments on how the value needs to be read. I would like to expose the value in Watt so we need to multiply it depending on the value

I've updated the mompow field to be exposed in Watts as requested. Based on the original PR #282 comments where it was confirmed that the device reports values in 0.1kW units, I've modified the parsing to multiply the raw value by 100 to convert to Watts.

Changes made in commit e3fd5c1:

• Raw device value of 15 (representing 1.5kW) now returns 15000 (Watts)
• Updated all test assertions to expect the converted Watt values
• Added proper TypeScript null/undefined handling

All 26 tests pass successfully with the new conversion logic.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• 255.255.255.255

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

[Apollon77]

@copilot The initial PR includes an info that also value 1 was reported when "pow=0" which seems odd. Please add logic that considers the "pow" flag and sets the mompow field to 0 if pow=0

[Copilot]

@copilot The initial PR includes an info that also value 1 was reported when "pow=0" which seems odd. Please add logic that considers the "pow" flag and sets the mompow field to 0 if pow=0

I've added logic to consider the "pow" flag as requested. When pow=0 (AC is off), the mompow field is now set to 0 regardless of the raw sensor value. This addresses the odd behavior where value 1 was reported when pow=0. The implementation checks for the pow field in the sensor response and applies the conversion logic accordingly. All tests pass successfully including new test cases that verify this behavior. Commit: d9a3dcc

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• 255.255.255.255

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

[lleonis]

pow=0 is in get_control_info, not in get_sensor_info
LGTM otherwise

[Apollon77]

@copilot pow=0 is in get_control_info, not in get_sensor_info

@lleonis hehe exactly that was nor yet reviewed but cool you saw it :-)

[Apollon77]

@copiolot The updateData() method in DaikinAc class could be a good place to add the high level logic and set mompow to 0 when pow=0, please check if there is even a better place down the code flow. And please add the logic

[Apollon77]

@copilot The updateData() method in DaikinAc class could be a good place to add the high level logic and set mompow to 0 when pow=0, please check if there is even a better place down the code flow. And please add the logic

[Copilot]

@copilot The updateData() method in DaikinAc class could be a good place to add the high level logic and set mompow to 0 when pow=0, please check if there is even a better place down the code flow. An...

I've added the high-level logic to set mompow=0 when pow=0 in the updateData() method of the DaikinAC class as requested. The logic checks when both control_info and sensor_info are available and applies the business rule that when the AC is powered off (power=false), the momentary power consumption should be 0 regardless of what the sensor reports.

Changes made in commit 3c65cd2:

• Added power state logic in DaikinAC.updateData() after both control and sensor info are retrieved
• Also added the same logic to getACSensorInfo() for individual method calls
• Updated all test expectations to expect mompow=0 when AC is powered off (all test mock data has pow=0)

The implementation correctly handles the architectural separation where pow comes from control_info and mompow comes from sensor_info, applying the business logic at the higher level where both data sources are available.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• 255.255.255.255

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

[Copilot]

Just as a heads up, I was blocked by some firewall rules while working on your feedback. Expand below for details.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• 255.255.255.255

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

[Apollon77]

@lleonis sooo .... now? :-)

[lleonis]

Now it looks OK. Thanks.

Test data is a bit unrealistic with inputs like mompow=200 and 300, but does the job. I'd be in trouble if my AC pulled 30 kW...

[Apollon77]

LOL. Yeeaahh but I agree. Testing is testing ;-)

[Apollon77]

@copilot now again the changelog entry is missing. Please add.

[Copilot]

@copilot now again the changelog entry is missing. Please add.

Added changelog entry for version 2.3.0 documenting the mompow field support feature in commit 76764bb. The changelog includes the main features: mompow field support, unit conversion to Watts, and power state logic.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• 255.255.255.255

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)