@derek-m - sounds interesting!

The current/target temperature changes continue to produce '0' (zero), which I guess is 'nothing' rather than the number zero (ie no data not data that happens to be zero).

I did try duplicating the notify1 / 04 message code in C3/message.py and making all the necessary changes I could see were needed to get a notify2 / 05 message, but got nothing, but at least it didn't break the code. I also tried to trace back through the code to see if I had missed anything, but nothing obvious appeared.

@cathoderay

I'm just completing a few file comparisons, after which I should have some suggestions to try.

@cathoderay

I think that I am being polite when I describe some of the midea_ac_lan programming as being 'sloppy', there appear to be a number of typo's that have not been located and corrected, also the same or similar tasks have been achieved using an inconsistent coding approach, which all adds to the confusion of someone trying to interpret the programming.

One of the areas that I have been investigating is the different 'body type's', of which there are quite a number.

I would suggest trying different body type's within the C3 code, to see what type of messages are produced. Below is a list of the body type's so far discovered. This could help to decipher how the body type is constructed to contain the required data.

I assume that the 0x081 is a typo, and should read 0x81.

Posted by: @derek-m

↑

I think that I am being polite when I describe some of the midea_ac_lan programming as being 'sloppy', there appear to be a number of typo's that have not been located and corrected, also the same or similar tasks have been achieved using an inconsistent coding approach, which all adds to the confusion of someone trying to interpret the programming.

I'm very much inclined to agree.

I will try adding different body types. The current added code I mentioned earlier to try to get a 'notify2 / 0x05' result in C3\message.py looks like this:

class C3Notify2MessageBody(MessageBody):
    def __init__(self, body, data_offset=0):
        super().__init__(body)
        self.byte_05_01 = (body[data_offset + 1])
        self.byte_05_02 = (body[data_offset + 2])
        self.byte_05_03 = (body[data_offset + 3])
        self.byte_05_04 = (body[data_offset + 4])
        self.byte_05_05 = (body[data_offset + 5])
        self.byte_05_06 = (body[data_offset + 6])
 
class MessageC3Response(MessageResponse):
    def __init__(self, message):
        super().__init__(message)
        body = message[self.HEADER_LENGTH: -1]
        if (self._message_type in [MessageType.notify1, MessageType.query] and self._body_type == 0x01) or \
                self._message_type == MessageType.notify2:
            self._body = C3MessageBody(body, data_offset=1)
        elif self._message_type == MessageType.notify1 and self._body_type == 0x04:
            self._body = C3Notify1MessageBody(body, data_offset=1)    
        elif self._message_type == MessageType.notify2 and self._body_type == 0x05:
            self._body = C3Notify2MessageBody(body, data_offset=1)    
        self.set_attr()

Added code is all of the C3Notify2MessageBody class and the last elif line. But it doesn't get anything, no message received, no status update. Any thoughts on how I can modify the code to get something?

@cathoderay

I'm still carrying out code comparison to try to understand the structure of the body type, and how it is created and used.

It could be that you don't get any data because there would not appear to be a body type 0x05, I would suggest trying some of the ones that I have listed and see if any data is returned. I believe that the body type sets the physical structure, which is binary, which is integers, of the data section of the message, but not what data is obtained and returned.

Posted by: @derek-m

↑

It could be that you don't get any data because there would not appear to be a body type 0x05

I used 0x05 because I found this in \core\message.py:

class MessageType(IntEnum):
    set = 0x02,
    query = 0x03,
    notify1 = 0x04,
    notify2 = 0x05,
    exception = 0x06,
    querySN = 0x07,
    exception2 = 0x0A,
    querySubtype = 0xA0

but looking more closely, that is about message type, not body type...

I will try some of the other body types in the elif line.

Posted by: @cathoderay

↑

Posted by: @derek-m

↑

It could be that you don't get any data because there would not appear to be a body type 0x05

I used 0x05 because I found this in \core\message.py:

class MessageType(IntEnum):
    set = 0x02,
    query = 0x03,
    notify1 = 0x04,
    notify2 = 0x05,
    exception = 0x06,
    querySN = 0x07,
    exception2 = 0x0A,
    querySubtype = 0xA0

but looking more closely, that is about message type, not body type...

I will try some of the other body types in the elif line.

Did you try other body type's, and if so what were the results?

@derek-m - I'm doing it now, so far done:

Code:
elif self._message_type == MessageType.notify1 and self._body_type == 0x02:
self._body = C3Notify2MessageBody(body, data_offset=1)

Result: nothing

Code:
elif self._message_type == MessageType.notify1 and self._body_type == 0x03:
self._body = C3Notify2MessageBody(body, data_offset=1)

Result: nothing

Code:
elif self._message_type == MessageType.notify1 and self._body_type == 0x08:
self._body = C3Notify2MessageBody(body, data_offset=1)

Result: nothing

Code:
elif self._message_type == MessageType.notify1 and self._body_type == 0x14:
self._body = C3Notify2MessageBody(body, data_offset=1)

Result: nothing

I let each one run for an hour, in case they are hourly messages, like the 0x04 ones.

I think we need to try and find out what triggers the messages being sent. 

Posted by: @derek-m

↑

I think that the hourly message is being initiated by the Midea controller or the Midea server. The 1 minute messages are being requested, I suspect by HA, via the Python code, within the 'logging' function within the Python code itself. If you open core/message.py then highlight and click on logging, a dropdown box appears. Then click on 'python/cpython:lib/logging/_init_.py', which takes you to some code that provides the logging function.

I think @editor has done a clean up job, as some of the posts have disappeared, but at least we have a functioning thread again. Oh, the joys of WordPress. The above quote is actually from an email notification. 

I think the logging functions are just core python code that provides a way to write to logs, There is no reason to suppose the logging code knows about midea_ac_lan or how Midea sends or makes available its heat pump data.

I don't think the Midea server is involved in any of this. It is used just once when setting up midea_ac_lan, to get the key and token, using another command line program, but after that it is not involved. I suppose it may however be that it does initiate a request, and midea_ac_lan eavesdrops on the response.

In one of the posts that has disappeared, I mentioned two possible clues about how messages might be initiated:

(1) timing - something somewhere must set the timing. The 03/01 messages are roughly every minute, the 04/04 messages are on the hour, and then, rather curiously, at occasional and apparently random times during the hour. I haven't as yet, however, managed to find any midea_ac_lan code that looks like it provides a timer, which is why it is I suppose possible they are initiated by the Midea server. However:

(2) the 03/01 messages, but not the 04/04 messages, get logged as three events, the first one of which is 'Sending' (then 'Received@ then 'Status update'). If we take 'Sending' as having its normal meaning, then something is being sent. But from where? The code that logs 'Sending' is in core\device.py:

    def build_send(self, cmd):
        data = cmd.serialize()
        _LOGGER.debug(f"[{self._device_id}] Sending: {cmd}")
        msg = PacketBuilder(self._device_id, data).finalize()
        self.send_message(msg)

and a corresponding log entry looks like this:

2023-03-04 08:03:12.871 DEBUG (Heat Pump Wi-Fi Controller) [custom_components.midea_ac_lan.midea.core.device] [device_id] Sending: {'header': 'aa0bc300000000000003', 'body': '01', 'message type': '03', 'body type': '01'}

The build_send function is called a few lines later in core\device.py:

    def refresh_status(self, wait_response=False):
        cmds = self.build_query()
        error_count = 0
        for cmd in cmds:
            if cmd.__class__.__name__ not in self._unsupported_protocol:
                self.build_send(cmd)
                if wait_response:
                    try:
                        while True:
                            msg = self._socket.recv(512)
                            if len(msg) == 0:
                                raise socket.error
                            result = self.parse_message(msg)
                            if result == ParseMessageResult.SUCCESS:
                                break
                            elif result == ParseMessageResult.PADDING:
                                continue
                            else:
                                raise ResponseException
                    except socket.timeout:
                        error_count += 1
                        self._unsupported_protocol.append(cmd.__class__.__name__)
                        _LOGGER.debug(f"[{self._device_id}] Does not supports "
                                      f"the protocol {cmd.__class__.__name__}, ignored")
                    except ResponseException:
                        error_count += 1
            else:
                error_count += 1
        if error_count == len(cmds):
            raise RefreshFailed

The variable cmd comes from cmds ('for cmd in cmds') and cmds comes from cmds = self.build_query() but it is a dead end:

    def build_query(self):
        raise NotImplementedError

It's insane! WTF is a 'NotImplementedError'??? It sounds like negative gravity to me. That said, I think core\device.py may hold the key to understanding the insanity.

@cathoderay

I fully agree with your sentiments concerning the quality of programming, which is also poorly commented and documented. Making modifications and/or additions should involve changes in one routine, not four or five.

The way that I interpret the code is that 'C3 messages' imports several classes from 'core messages', which in turn imports 'logging' from 'cpython:Lib'. I therefore believe that 'Midea_ac_lan' uses 'logging' to supply the data to 'HA'. Within the 'logging' code there is the ability to set timing functions. Do you have to, or can you, set logging frequency within 'HA'? There is also some timing being performed within 'core/devices.py'.

Did the 'body type' tests obtain any data?

To speed up the testing process I wonder if swapping 'notify1' and 'notify2' within 'MessageC3Response(MessageResponse)', would change from a 1 hour to 1 minute logging frequency for the data of interest.

A further test to try would be to change the 'DeviceAttributes' of the added test variables, from 0 or none, to 100 for the first, 101 for the second, and so on and so forth. This would possibly prove that data is being logged by the code, but not being obtained from the Midea controller.

@cathoderay

Any progress?

@cathoderay

Is it possible to add code to print or display messages when the program runs?

Something like:-

If msg != msg1

     Print msg

     msg1 = msg

I think that != is Python syntax for 'not equal'.

The above code should be added at line 282 in 'core/device.py'. It may then be possible to see how the message is constructed.