Energy Sensors across all 3 format modes reports excess consumption (Midea AC Split)

[srleach]

Midea Model(s): MA-12NZD0-XI, MA-12NZD0-XO

Across default, Alternate A and Alternate B, energy utilisation on the above device, all reported sensor values pertaining to energy are off by several orders of magnitude.

Based on observation of upstream metering, I would expect the consumption of the device to be anywhere from 400-1000 watt hours, or 0.4 - 1.0 kWh.

Power Mode	Reported Units	Total Energy Sensor	Current Energy Sensor	Power Sensor	Observed Consumption (not accurate)
Default	kWh	4,276.14 kWh	1,154.0 kWh	0.0 W	~400 - 600 (W)
Alternate A	kWh	435,559.8 kWh	47,872 kWh	0.0 W	~400 - 600 (W)
Alternate B	kWh	43,555.98 kWh	5,442.56 kWh	0.0 W	~400 - 600 (W)

Across all three modes, I am observing a variance in the reported values versus what I'd expect to see. The closest would be Alternate B - but I believe there are still two issues present here:

• Units against sensor log as kWh vs. Watt hours.
• Along with the incorrect units, I believe the value is still reporting an order of magnitude higher than I would expect

The above is to say that based on the above measurements (each taken at a marginally different time hence the apparent change in consumption rates), I believe the true value I should've seen is 544.256 Watt Hours, or 0.544256 kWh.

I also believe the same variance can be applied to the Total Energy sensor, I'm unsure of the epoch of this value's calculation, but I believe 435 kWh over the lifetime of this device to date is much more believable than almost 44,000 kWh - at my current unit price this would sum to £11,000 which is probably more than all of my electricity use combined over that same period.

Excerpt from debug log included below, including the BCD encoded energy response payload.

If I can provide anything more to assist, please let me know.

2025-05-08 09:04:32.923 DEBUG (MainThread) [msmart.device.AC.device] State response payload from device 145135534884926: c00122657f7f0000000000564a06000100000000000000ff
2025-05-08 09:04:32.923 DEBUG (MainThread) [msmart.device.AC.device] Energy response payload from device 145135534884926: c12101440042730e2f000000000a4e000000000000
2025-05-08 09:04:32.923 DEBUG (MainThread) [msmart.device.AC.device] Humidity response payload from device 145135534884926: c12101450042730e2f000000000a4e0400bb750001

[srleach]

Scanning the code, I think this could be resolved (if confirmed) with an extension of your change in #282 where the energy_scale is defined.

midea-ac-py/custom_components/midea_ac/sensor.py

Line 36 in 34c3267

energy_scale = .1

Here we branch based on the config being ALTERNATE_B - I think to minimise variance to units etc we could introduce an ALTERNATE_C to the EnergyFormat enum in custom_components/midea_ac/const.py along with the requisite plumbing to pull this through to the config section, and subsequently modify the energy_scale variable in sensor.py

if config_entry.options.get(CONF_ENERGY_FORMAT) == EnergyFormat.ALTERNATE_B:
        energy_scale = .1
if config_entry.options.get(CONF_ENERGY_FORMAT) == EnergyFormat.ALTERNATE_C:
        energy_scale = .001

Alternatively, I'm unsure whether actually modifying the units to Wh would allow for a better default precision to be stored by recorder.

[srleach]

Captured some data on this today, and i'm thinking the solution isn't as simple as a scaling value.

I've made a minimum reproducible example (https://gist.github.com/srleach/49ce87cb61c41b86523cba93ece379e6) of grabbing the data using msmart-ng lib, and observed the data whilst manipulating the setpoint on the device and observing consumption measured upstream (I can't be totally accurate with this, since the upstream measurement includes a number of other devices so at best this should be considered a close instantaneous estimate)

Meter data:

Self-reported consumption:

[2025-05-09 19:27:53 PS:False,IT:19.2,TT:16.0] Estimated usage 1996.8
... Omitted useless data ...
[2025-05-09 19:29:28 PS:True,IT:20.0,TT:16.0] Estimated usage 1996.8
[2025-05-09 19:29:34 PS:True,IT:20.0,TT:16.0] Estimated usage 8550.4
[2025-05-09 19:29:39 PS:True,IT:20.0,TT:16.0] Estimated usage 8550.4
[2025-05-09 19:29:44 PS:True,IT:20.0,TT:16.0] Estimated usage 8550.4
[2025-05-09 19:29:50 PS:True,IT:20.0,TT:16.0] Estimated usage 8550.4
[2025-05-09 19:29:55 PS:True,IT:20.2,TT:16.0] Estimated usage 8550.4
[2025-05-09 19:30:00 PS:True,IT:20.2,TT:16.0] Estimated usage 8550.4
[2025-05-09 19:30:06 PS:True,IT:20.2,TT:16.0] Estimated usage 8550.4
[2025-05-09 19:30:11 PS:True,IT:20.2,TT:16.0] Estimated usage 8550.4
[2025-05-09 19:30:16 PS:True,IT:20.2,TT:16.0] Estimated usage 8550.4
[2025-05-09 19:30:22 PS:True,IT:20.2,TT:16.0] Estimated usage 8550.4
[2025-05-09 19:30:27 PS:True,IT:20.2,TT:16.0] Estimated usage 8550.4
[2025-05-09 19:30:32 PS:True,IT:20.2,TT:16.0] Estimated usage 15104.0
[2025-05-09 19:30:37 PS:True,IT:20.2,TT:16.0] Estimated usage 15104.0
[2025-05-09 19:30:43 PS:True,IT:20.2,TT:16.0] Estimated usage 15104.0
[2025-05-09 19:30:48 PS:True,IT:20.2,TT:16.0] Estimated usage 15104.0
[2025-05-09 19:30:53 PS:True,IT:20.1,TT:16.0] Estimated usage 15104.0
[2025-05-09 19:30:59 PS:True,IT:20.0,TT:16.0] Estimated usage 15104.0
[2025-05-09 19:31:04 PS:True,IT:20.0,TT:16.0] Estimated usage 15104.0
[2025-05-09 19:31:09 PS:True,IT:20.0,TT:16.0] Estimated usage 15104.0
[2025-05-09 19:31:15 PS:True,IT:20.0,TT:16.0] Estimated usage 15104.0
[2025-05-09 19:31:20 PS:True,IT:20.0,TT:16.0] Estimated usage 15104.0
[2025-05-09 19:31:25 PS:True,IT:19.9,TT:16.0] Estimated usage 15104.0
[2025-05-09 19:31:31 PS:True,IT:19.8,TT:16.0] Estimated usage 15104.0
[2025-05-09 19:31:36 PS:True,IT:19.7,TT:16.0] Estimated usage 21657.6
[2025-05-09 19:31:41 PS:True,IT:19.7,TT:16.0] Estimated usage 21657.6
[2025-05-09 19:31:47 PS:True,IT:19.6,TT:16.0] Estimated usage 21657.6
[2025-05-09 19:31:52 PS:True,IT:19.5,TT:16.0] Estimated usage 21657.6
[2025-05-09 19:31:57 PS:True,IT:19.4,TT:16.0] Estimated usage 21657.6
[2025-05-09 19:32:03 PS:False,IT:19.4,TT:16.0] Estimated usage 21657.6
[2025-05-09 19:32:08 PS:False,IT:19.3,TT:16.0] Estimated usage 21657.6
[2025-05-09 19:32:13 PS:False,IT:19.2,TT:16.0] Estimated usage 21657.6
[2025-05-09 19:32:18 PS:False,IT:19.2,TT:16.0] Estimated usage 21657.6
[2025-05-09 19:32:24 PS:False,IT:19.1,TT:16.0] Estimated usage 1996.8
[2025-05-09 19:32:29 PS:False,IT:19.0,TT:16.0] Estimated usage 1996.8
[2025-05-09 19:32:34 PS:False,IT:19.0,TT:16.0] Estimated usage 1996.8
[2025-05-09 19:32:40 PS:False,IT:19.0,TT:16.0] Estimated usage 1996.8

In this log, PS (Power State), IT (Internal Temp), TT (Target Temp) and self reported energy.

I powered the unit on around 19:28 as you'll see from the point where the meter data starts to increase. By about 19:29:30, peak energy use was observed externally at roughly 600 watts. A little napkin calculation here - removing the static 1996.8 that appears to be reported at all times (this could well be actual standby usage on the device, unit dependent) - we're left with a value of 6550 (thereabouts) which seems to correspond to the observed usage just after 19:30 in the graph (i.e 650 watts).

From here is where it loses me. The AC system then appears to increment it's usage in steps and I can't correlate this to any increase in consumption, which leads me to think there's something I'm missing. Perhaps it's a tally of energy used since it was enabled - something like "energy this activation" but then I can't reconcile the figures to anything sensible with only a few minutes of data.

I'd be interested in your thoughts on this - happy to provide any further info as required.

[mill1000]

Thanks for all the information. Good analysis.

I'm not sure what the epoch of the current and total energy sensors are. I haven't found any specific documentation or references on the sensor values.

[srleach]

Thanks for checking in on this @mill1000 - my assessment here is that Total Energy Sensor for Alternate B is reading correctly, ish - with some variance in units and scale.

I've just run the unit for an hour, and I see the "Total Energy" sensor increase from 43,594.38 kWh to 43,602.06 kWh, a value of 7.68 kWh.

My house's smart meter during that period went from 10.923kWh to 12.255kWh - Excluding other consumers of power as far as I can, I can see that the AC unit applied a continuous load to my baseline (0.614kW) of (1.334kW-0.614kW) of ~0.72kW for the test period of an hour (i.e 0.72kWh).

Allowing for some margin of error in my observation over that period, these numbers match albeit with a misaligned scale.

TL;DR - My thoughts (at least on the Total Energy Sensor):

#282 Introduced a multiplier of .1 for ENERGY_SCALE_B where I think it should instead not scale, but change the units to Wh

custom_components/midea_ac/sensor.py

# Configure energy format
unit_of_energy = UnitOfEnergy.KILO_WATT_HOUR

if config_entry.options.get(CONF_ENERGY_FORMAT) == EnergyFormat.ALTERNATE_B:
    unit_of_energy =  UnitOfEnergy.WATT_HOUR
...
...
# Energy sensors
# Removed explicit setting of energy_scale, and updating to compute unit_of_energy
MideaEnergySensor(coordinator,
                  "total_energy_usage",
                  SensorDeviceClass.ENERGY,
                  unit_of_energy
                  "total_energy_usage",
                  state_class=SensorStateClass.TOTAL),

I'm still currently at a loss for the "current" sensor as per the above.

Stubbed suggestion here for easier use if you're happy: #346 - since I've not contributed to this repository before I'd appreciate if you could verify the change before any merge, though assuming you'd have done so anyway!

[mill1000]

Are you sure that the Default setting in Watts wouldn't be a better match that Alternate B in Watts?

Based on your sample payload,

Default (BCD)
Total energy 4273.14
Current energy 1054.0

Alt A. (Binary)
Total energy 435483.0
Current energy 67532.8

Alt B. (Binary div 10)
Total energy div10 43548.3,
Current energy div10 6753.28

[srleach]

Reasonably sure - I've tested all three of the existing approaches, and ALTERNATE_B was the closest, albeit out by orders of magnitude as solved by changing the units to watts.

It's really hard to say with confidence, as my measurements upstream are also skewed with other data, but my closest estimate is that ALTERNATE_C should match the behaviour of ALTERNATE_B, except reporting in watts - at least for the total field.

That does raise an interesting point around whether current energy reported in watts under the default behaviour shows anything close to reality though. I'll do some further observations there when I get a minute.