Posted by: @derek-m

↑

Can you now post a copy of the message.

They are exactly the same as before, with minor value changes for variables that change eg tank_actual_temperature:

2023-03-13 18:47:52.638 DEBUG (Heat Pump (LAN)) [custom_components.midea_ac_lan.midea.devices.c3.device] [device_id] Received: {'header': 'aa23c300000000000003', 'body': '010975910303281e323041231905371919053c223c142e0080', 'message type': '03', 'body type': '01'}

2023-03-13 18:47:52.639 DEBUG (Heat Pump (LAN)) [custom_components.midea_ac_lan.midea.core.device] [device_id] Status update: {'zone1_power': True, 'zone2_power': False, 'dhw_power': False, 'disinfect': False, 'fast_dhw': False, 'zone_temp_type': [True, True], 'mode': 3, 'mode_auto': 3, 'zone_target_temp': [40, 30], 'dhw_target_temp': 50, 'room_target_temp': 24.0, 'zone_heating_temp_max': [65, 55], 'zone_heating_temp_min': [35, 25], 'zone_cooling_temp_max': [25, 25], 'zone_cooling_temp_min': [5, 5], 'room_temp_max': 30.0, 'room_temp_min': 17.0, 'dhw_temp_max': 60, 'dhw_temp_min': 20, 'tank_actual_temperature': 46, 'outdoor_temperature': 0, 'zone1_water_temp_mode': True, 'zone2_water_temp_mode': False, 'zone1_room_temp_mode': False, 'zone2_room_temp_mode': False}

Posted by: @derek-m

↑

Can you provide a text copy of midea/core/message.py

Done by PM.

@cathoderay

This code in midea/core/message.py is interesting. It seems to specify the byte array size. I wonder if increasing it to * 20 or * 25 would increase the message length?

Found at line 129.

@property
    def _body(self):
        return bytearray([0x00] * 18)

Posted by: @derek-m

↑

@property def _body(self): return bytearray([0x00] * 18)

Rant starts!

This really is a brilliant example of how irritating python is, and proof of the claim that it is easy to learn is bullshit.

By all normal rules 0 * 18 = 0. Full stop.

Make it hex and it is still zero: 0x00 * 18 = 0. Full stop.

Now point me to a clear reference that explains what enclosing something in [] does in python (I couldn't find one). After reading round the usual python crap (why use English when you can obfuscate? - eg never say a number in the range 0 to 255, instead use 'an unsigned int that satisfies 0b1111_1111>=x>=0'), I think enclosing something in [] tells python is it is a list. If so, we now have:

a list of one zero ( ie 0) * 18 which is still zero. Except in the the Alice through the Looking Glass world of python. 

Somehow I am supposed to intuit that [0x00] * 18 does not mean what it says, instead it is an obfuscated way of saying [0x00] repeated 18 times...

If indeed that is what it means. Who knows? 

Rant over!

@derek-m - I will start by just increasing the unsigned int that satisfies 0b1111_1111>=x>=0 (aka 18) to a higher unsigned int that satisfies 0b1111_1111>=x>=0 (aka 20 and then 25) and see what happens to the received messages. 

@derek-m - decided to go straight to 25 ('return bytearray([0x00] * 25)'), no change in message length (or content):

Message immediately before change:

'010975910303281e323041231905371919053c223c14290080'

Message immediately after change:

'010975910303281e323041231905371919053c223c14290080'  

Posted by: @cathoderay

↑

Posted by: @derek-m

↑

@property def _body(self): return bytearray([0x00] * 18)

Rant starts!

This really is a brilliant example of how irritating python is, and proof of the claim that it is easy to learn is bullshit.

By all normal rules 0 * 18 = 0. Full stop.

Make it hex and it is still zero: 0x00 * 18 = 0. Full stop.

Now point me to a clear reference that explains what enclosing something in [] does in python (I couldn't find one). After reading round the usual python crap (why use English when you can obfuscate? - eg never say a number in the range 0 to 255, instead use 'an unsigned int that satisfies 0b1111_1111>=x>=0'), I think enclosing something in [] tells python is it is a list. If so, we now have:

a list of one zero ( ie 0) * 18 which is still zero. Except in the the Alice through the Looking Glass world of python. 

Somehow I am supposed to intuit that [0x00] * 18 does not mean what it says, instead it is an obfuscated way of saying [0x00] repeated 18 times...

If indeed that is what it means. Who knows? 

Rant over!

@derek-m - I will start by just increasing the unsigned int that satisfies 0b1111_1111>=x>=0 (aka 18) to a higher unsigned int that satisfies 0b1111_1111>=x>=0 (aka 20 and then 25) and see what happens to the received messages. 

I fully agree that Python appears to have been developed and documented by a group of sadists.

What gave ma the clue was the code below, though its use does not appear to have been consistent across the different devices.

I interpret this as a byte array, 19 bytes long, initially containing the specified data. Someone correct me if I am wrong.

 @property
    def _body(self):
        return bytearray([
            0x81, 0x00, 0xFF, 0x03,
            0xFF, 0x00, 0x02,
            0x00, 0x00, 0x00, 0x00,
            0x00, 0x00, 0x00, 0x00,
            0x00, 0x00, 0x00, 0x00
        ])

Posted by: @derek-m

↑

Someone correct me if I am wrong.

I am sure you are right, but that begs the question of why '*18' in the other code above. Perhaps it is something to do with our old friend zero based counting. Items 0 to 18 = 19 items. But if I have 12 eggs in my shopping basket, I still have 12 eggs even if I number them 0 to 11. My 12th egg is number eleven. What could be clearer that that? Or that my first egg is now number 0, and zero usually means nothing. Perhaps I have a baker's dozen? But no, that's 13. Why make things simple when you can make them complicated! 

Posted by: @cathoderay

↑

Posted by: @derek-m

↑

Someone correct me if I am wrong.

I am sure you are right, but that begs the question of why '*18' in the other code above. Perhaps it is something to do with our old friend zero based counting. Items 0 to 18 = 19 items. But if I have 12 eggs in my shopping basket, I still have 12 eggs even if I number them 0 to 11. My 12th egg is number eleven. What could be clearer that that? Or that my first egg is now number 0, and zero usually means nothing. Perhaps I have a baker's dozen? But no, that's 13. Why make things simple when you can make them complicated! 

The byte array in my example was actually from the code for AC. In the C3 code they actually use the following, which I interpret as meaning a byte array of unspecified length. As usual it is as clear as mud.

   @property
    def _body(self):
        return bytearray([])

My point was that the byte arrays used for different appliances can differ, in both length, and I also believe structure. A number of bytes appear to contain bitwise data, with the remaining ones appearing to contain both integers of various length (1, 2 or 4 bytes), and floating point numbers, which appear to be transmitted as integers.

From a message requesting and deciphering point of view, we appear to know the structure for the present type 01 message, but not how to add extra data to the request, such that it will be returned in a format that can be deciphered. Is it the requesting part that is failing to add the required data to the message, or is it the deciphering part which is failing to recognise the data correctly. Alternatively it could be that the byte array is not big enough to accommodate all the required data.

I will send some possible test through shortly.

@cathoderay

Whilst compiling information for the next test, I spotted an omission that I feel may be important.

Try adding 'outdoor_temperature' to the following in midea/devices/C3/device.py.

def set_attribute(self, attr, value):
        if attr in [
            DeviceAttributes.zone1_power,
            DeviceAttributes.zone2_power,
            DeviceAttributes.dhw_power,
            DeviceAttributes.zone1_curve,
            DeviceAttributes.zone2_curve,
            DeviceAttributes.disinfect,
            DeviceAttributes.fast_dhw,
            DeviceAttributes.dhw_target_temp,
	    DeviceAttributes.outdoor_temperature

        ]:

Posted by: @derek-m

↑

Try adding 'outdoor_temperature' to the following in midea/devices/C3/device.py.

Well spotted, I missed that. Done, and HA restarted, but unfortunately still get 'outdoor_temperature': 0:

2023-03-14 18:49:17.061 DEBUG (Heat Pump (LAN)) [custom_components.midea_ac_lan.midea.devices.c3.device] [device_id] Received: {'header': 'aa23c300000000000003', 'body': '010975910303281e323041231905371919053c223c142f0080', 'message type': '03', 'body type': '01'}

2023-03-14 18:49:17.062 DEBUG (Heat Pump (LAN)) [custom_components.midea_ac_lan.midea.core.device] [device_id] Status update: {'zone1_power': True, 'zone2_power': False, 'dhw_power': False, 'disinfect': False, 'fast_dhw': False, 'zone_temp_type': [True, True], 'mode': 3, 'mode_auto': 3, 'zone_target_temp': [40, 30], 'dhw_target_temp': 50, 'room_target_temp': 24.0, 'zone_heating_temp_max': [65, 55], 'zone_heating_temp_min': [35, 25], 'zone_cooling_temp_max': [25, 25], 'zone_cooling_temp_min': [5, 5], 'room_temp_max': 30.0, 'room_temp_min': 17.0, 'dhw_temp_max': 60, 'dhw_temp_min': 20, 'tank_actual_temperature': 47, 'outdoor_temperature': 0, 'zone1_water_temp_mode': True, 'zone2_water_temp_mode': False, 'zone1_room_temp_mode': False, 'zone2_room_temp_mode': False}

@cathoderay

So, I suppose the next test would be to change all the occurrences of 'outdoor_temperature' to 'byte_22', in all the relevant C3 files, including midea_devices.py.

The objective being to be able to change the attributes for byte_22 from temperature measurement, to others attributes, which may then obtain data.

@cathoderay

A further test would be to change all occurrences of 'tank_actual_temperature' to 'byte_21' to see if it still produces data for 'tank_actual_temperature'.

@derek-m - thanks, will give the bytes 22 and 21 tests a try tomorrow.

On a general note, I think it might be worth continuing this in a new thread, as the thread title has become increasingly inaccurate. Maybe 'Connecting to a Midea Heat Pump from a PC'?