Bug(AC): Energy/power sensors incorrect on Air Conditioner 00000Q11 (44204) — no power_analysis_method value produces plausible results

[RobertoHuto]

Verify Issue Submission

• I have read the README documentation , understand how to use midea_ac_lan and enable debug log.
• I have read the device documentation for my device in the README, but the problem still can't fix.
• I have submitted the device type and SN information.
• I have uploaded the full debug log file, rather than just paste a parts of log based on my own judgment.
• I have accurately and clearly described what the current error is and what the expected correct result should be.
• I have searched for my issue in the Issue Tracker and have not found it.

HA core version

2026.7.2

Current integration version

0.6.12

Last known working integration version

0.6.12

Device type and Device SN

Air Conditioner 00000Q11 (44204)

Working mobile app

NetHome Plus

The detail description of bug/problem

The detail description of bug/problem

The energy and power sensors on this device (Air Conditioner 00000Q11 (44204)) report
implausible values under every power_analysis_method I have tried via the customize
config option (1, 2, 3, and 12 — the last one taken from the fix documented in #678 for
a different device type, 00000Q1D):

Method 1 (default, empty customize):

total_energy_consumption fluctuates up and down across days instead of only
increasing (e.g. ~5506 -> 5111 -> 5322 -> 5123 -> 5531 kWh on consecutive days),
which should be impossible for a total_increasing counter.
current_energy_consumption similarly jumps erratically (e.g. 71 -> 2074 -> 6377 -> 79 kWh
on consecutive days).
realtime_power reads 0 W even while the unit is actively running (hvac_mode: cool,
eco_mode: true, fan active).

Method 2:

total_energy_consumption immediately jumped to ~518,374 kWh (~100x too high).
current_energy_consumption jumped to ~4,812 kWh.
realtime_power still 0 W.

Method 3:

total_energy_consumption settled around 7,825 kWh (more plausible order of magnitude).
current_energy_consumption started incrementing by a fixed +100 kWh every ~60 seconds
regardless of actual device activity (188.0 -> 288.0 -> 388.0 -> ... -> 1288.0 kWh over
~12 minutes), which is physically impossible (~6000 kW implied draw).
realtime_power still 0 W.

Method 12 (from the fix in #678, documented there for 00000Q1D PortaSplit):

total_energy_consumption jumped again, this time to 51,840 kWh (~6.6x higher than
under method 3).
current_energy_consumption read 481.28 kWh.
realtime_power still reads 0 W, even while the unit is confirmed actively cooling
(hvac_mode: cool, eco_mode: true, fan_speed active, indoor/outdoor temperature sensors
updating normally).

Across all four methods, realtime_power never once reported a non-zero value despite
the compressor/fan being confirmed active via the climate entity's own state and other
attributes (indoor_temperature, outdoor_temperature actively changing). This suggests the
power/energy decoding for this specific device type (00000Q11, subtype 44204) may not
be correctly handled by any of the currently documented power_analysis_method values,
possibly requiring a new device-specific method similar to how #678 was resolved for the
PortaSplit type.

Expected behavior

total_energy_consumption should only ever increase (monotonic), matching realistic
daily usage
current_energy_consumption should reflect real incremental usage, not a fixed
increment regardless of method
realtime_power should reflect actual instantaneous power draw (non-zero while the
compressor/fan is active)

Additional context

Related issues for other device types with similar symptoms, in case they're useful
context for maintainers:

#609 (Portasplit 3.5kw wrong realtime power)
#678 (Portasplit incorrect power values, fixed via power_analysis_method: 12)
georgezhao2010/midea_ac_lan#114 (older repo, same total_energy_consumption
fluctuation symptom)

A second, identical-generation AC unit in a different room, also on this integration,
shows the same total_energy_consumption fluctuation issue under the default method 1.

The logs

1. DEBUG log MUST be enabled (Please refer to README document), Submit issue without debug log will be directly closed
2. Execute the action to trigger error log（you should description the error action）
3. Upload the debug log file as attachment。
4. Summary: Device SN describes detailed device information. Please clearly describe what the problem and error are. What should the correct expected result be? Finally: How can you prove what you're saying is correct? The debug log file is used to prove the error genuinely exists, and app screenshots or other data are used to prove the correct expected result.
5. Please don't paste the log content! upload it as a attachment file.
6. Please don't paste the log content! upload it as a attachment file.
7. Please don't paste the log content! upload it as a attachment file.
   ...

midea_debug_log_livingroom.log