@derek-m - I got distracted an hour ago, missed the time but got it at 1800: 

1757: dropped lower ambient end of weather curve from 58 degrees to 36 degrees, then watched the LWT on the wired controller. Over the following three minutes it dropped from 45 degrees to 40 degrees (and was 39 degrees by 1801).

Checked the HA log byte_14 value at 1800: 36.

1804: I put the weather curve low ambient end back to 58 degrees.

1810: I see a random 04/04 message at 1807 has a byte_14 value of 48.

I think the only reasonable conclusion is that byte_14 is the far less useful set LWT, not the much more useful actual LWT. Grrrr...   

Posted by: @cathoderay

↑

@derek-m - I got distracted an hour ago, missed the time but got it at 1800: 

1757: dropped lower ambient end of weather curve from 58 degrees to 36 degrees, then watched the LWT on the wired controller. Over the following three minutes it dropped from 45 degrees to 40 degrees (and was 39 degrees by 1801).

Checked the HA log byte_14 value at 1800: 36.

1804: I put the weather curve low ambient end back to 58 degrees.

1810: I see a random 04/04 message at 1807 has a byte_14 value of 48.

I think the only reasonable conclusion is that byte_14 is the far less useful set LWT, not the much more useful actual LWT. Grrrr...   

I'm afraid there may be a flaw in the method that you used, which is why I suggested switching to fixed LWT. Changing the lower ambient end of the curve relies upon the outside air temperature, and the slope of the curve, to calculate the required LWT. Is this value displayed anywhere?

The actual LWT will be produced by how the heat pump responds to the change in required LWT.

Using fixed LWT control would have provided a definitive value against which the result could be compared.

Another possible way to test the result, would be to lower your thermostats, and hence cause the heat pump to stop operating. If the produced value is the required LWT, then it should remain reasonably constant, if it is the actual LWT then the value should fall.

@derek-m - I think it was probably OK. I effectively made my weather curve level, with a low ambient end 36 degree LWT, high ambient end 35 degrees, so the set LWT at around 5 degrees ambient would (as an integer) be 36 degrees, which is what the 04/04 byte_14 data showed. I also know it wasn't the actual LWT, which at the relevant time was 40 degrees.

I'm wary of taking the wired controller off weather comp and onto fixed flow temps as the settings are seriously confusing and it is very easy to mess the whole thing up, not a good idea with low temps forecast over the next few days.

@cathoderay

No problem.

@derek-m - I've just done another extensive online search for something, anything that might give us a clue as to how to access other messages beyond the 03/01 and 04/04 type and drawn a blank. I did this because I think we have exhausted to possibilities of data extraction from the current messages, the bytes that we haven't worked out what they are are static, and so aren't going to be what we are looking for. As well as getting other messages, there may also be a possibility of adding a request for extra data in the existing messages.

Here's a sending/received pair:

2023-03-08 17:04:34.821 DEBUG (Heat Pump (LAN)) [custom_components.midea_ac_lan.midea.core.device] [device_id] Sending: {'header': 'aa0bc300000000000003', 'body': '01', 'message type': '03', 'body type': '01'}
2023-03-08 17:04:35.097 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'}

What do the bits in the Sending entry actually do? What if we change the aa0bc3 of the header to aa0ac3? The trouble is, I can't find where the header gets set, a 'search in files' across the whole of the midea_ac_lan code doesn't find it. It's in 'cmd' in core/device.py, but I can't find where 'cmd' is put together:

    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)

@cathoderay

I too have been going through the code and learning the syntax.

The Header is formulated by the following code located within core/message.py, I doubt whether changing it will have the desired affect since it will probably be overwritten by the program.

 @property
    def header(self):
        length = self.HEADER_LENGTH + len(self.body)
        return bytearray([
            # flag
            0xAA,
            # length
            length,
            # device type
            self._device_type,
            # frame checksum
            0x00,  # self._device_type ^ length,
            # unused
            0x00, 0x00,
            # frame ID
            0x00,
            # frame protocol version
            0x00,
            # device protocol version
            self._device_protocol_version,
            # frame type
            self._message_type
        ])

I have just realised that the above header produces the return information,as detailed below.

'header': 'aa23c300000000000003',

aa - is the fixed flag.

23 - is the length in hexadecimal of both the Header (10 bytes), combined with the Body (25 bytes), giving a total of 35 bytes.

c3 - is the Device Type (Heat Pump).

03 - is the Message Type (Query) as detailed below, again in core/message.py

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

As far as I am aware cmd is a python instruction. In the code you have cmd.serialize(), with serialize being formulated as detailed below.

 def serialize(self):
        stream = self.header + self.body
        stream.append(MessageBase.checksum(stream[1:]))
        return stream

It would appear that this specifies the data stream, to consist of the Header + Body + Checksum.

I will post more information shortly.

@derek-m - you have certainly cracked the header. But there is still in my mind the question of how does it know that self._device_type is c3 (a heat pump) and that self._message_type is 03 (a query)? Something somewhere must set these variables to these values. I am also baffled by the various incarnations of very similar looking variables eg device.type and _device_type. The underscore prefixes are something I haven't really come across before.

Posted by: @derek-m

↑

As far as I am aware cmd is a python instruction. In the code you have cmd.serialize(), with serialize being formulated as detailed below.

I'm sure cmd is a variable, at one point I used debug logging to get it printed in the log and it was a string that if memory serves was the same as that which comes after 'Sending' in the above log extract. I'm also pretty sure cmd.serialize() is variable.method() type statement, or in plainer English noun.verb() as in take the noun and do the verb on it: take the cmd variable and serialise it. The () at the end of serialize() indicates it is a function, which is then defined as a function at

 def serialize(self):
        stream = self.header + self.body
        stream.append(MessageBase.checksum(stream[1:]))
        return stream

The function is serialize, which takes the parameter self (which is probably a sort of self reference) and then the serialize function does as you say:

sets stream to be self.header plus (concatenate to) self.body

appends a checksum to stream (this is the noun.verb() form again, as in car.paint(red) ie paint the car red) 

finally, return stream to whatever called serialize().

@cathoderay

I suspect that midea_ac_lan sends a query to the device using core/discover.py, which searches for devices. I can only assume that the device indicates it is device_type C3 in the returned message.

I think the following code instructs core/device.py to use a query.

 def send_message(self, data):
        if self._protocol == 3:
            self.send_message_V3(data, msg_type=MSGTYPE_ENCRYPTED_REQUEST)
        else:
            self.send_message_V2(data)

Posted by: @derek-m

↑

I suspect that midea_ac_lan sends a query to the device using core/discover.py, which searches for devices. I can only assume that the device indicates it is device_type C3 in the returned message.

I think you are right, and it happens after a HA restart as part of a handshaking routine:

2023-03-07 13:13:54.187 DEBUG (Heat Pump (LAN)) [custom_components.midea_ac_lan.midea.core.device] [device_id] Connected
2023-03-07 13:13:54.187 DEBUG (Heat Pump (LAN)) [custom_components.midea_ac_lan.midea.core.device] [device_id] Handshaking
2023-03-07 13:13:54.239 DEBUG (Heat Pump (LAN)) [custom_components.midea_ac_lan.midea.core.device] [device_id] Authentication success
2023-03-07 13:13:54.239 DEBUG (Heat Pump (LAN)) [custom_components.midea_ac_lan.midea.core.device] [device_id] Sending: {'header': 'aa1dc3000000000000a0', 'body': '00000000000000000000000000000000000000', 'message type': 'a0', 'body type': '00'}
2023-03-07 13:13:54.473 DEBUG (Heat Pump (LAN)) [custom_components.midea_ac_lan.midea.core.device] [device_id] Received: {'header': 'aa2ac3000000000000a0', 'body': '00c3000000000000000000000000000000000000000000000000000000000000', 'message type': 'a0', 'body type': '00'}

The last two entries are a reguest and a reply, the latter saying it is a c3 unit. The only variation to your assessment is that the actions appears to come from .core.device (ie /core/device.py).

Meanwhile, I have been taking a step back, and wondering why we are not getting anywhere with either finding other types of messages beyond the 03/01 and 04/04 messages or finding a way to add extra data requests to existing messages. Looked at from a distance, one possible answer is that there is no such data or message type, ie we have already discovered all there is to discover. I'm inclined to think this is the case because:

(a) the whole point of the wifi interface is to send data to the Midea cloud so it can be used by the Msmarthome (cr)app

(b) it makes sense to send only that data which you need, ie what appears on the app

(c) the data made available in the app amounts to

energy consumed and produced, divided into heating and DHW use

ambient temp, set DHW temp and set LWT temp (and I am sure actual DHW temp is there just can't find it)

(d) and this is pretty much what we have found in the messages: DHW in the 03/01 messages and the rest is the 04/04 messages. The energy in/out by x period is derived from total now minus total x period ago, the only thing that is not clear is how it determines whether it is DHW or heating use, though there is a way it could do this, by using the binary status messages (zone ie heating power true/false and DHW power true false) ie it allocates the energy in and out depending on which is on at the time

(e) and finally there are only a few (three?) static unchanging bytes in the 04/04 message we have't yet accounted for. All of the 03/01 message is accounted for, and the rest of the 04/04 message is accounted for. 

My inclination is that we (especially you) have given this a very decent amount of honourable time and energy, and can say we have done our best, and have to conclude that we have effectively found all there is to find on the Midea wifi connection. Let me know what you think. 

I'm going to order the RS-485 to USB adaptor and psyche myself up to connect it to the H1/H2 connections on the wired controller. Initial setup will be RS-485 to USB adaptor plugged into mini PC and then a long wire (RS-485 can cover long distances) from the adaptor to the wired controller. I will then see if I can get Midea modbus data to appear on the mini PC or maybe even desktop initially.   

@cathoderay

I carry out day trading on the stock market, so often have lots of free time when nothing exciting is happening, so you don't have to concern yourself about wasting my time. I would also like to understand how the software works and what can be achieved.

I have a number of further avenues to explore, I have seen code where additional variables have been added, and I also found reference to a list of accepted variables within HA, though I did not explore it further at the time, and am now searching for the reference.

In a little while I will post a recap of what I think has been discovered, so that we can compare notes.

@derek-m - that sounds like a good plan. It would be great if we can get more data, as wifi is after all the simplest connection that needs no extra hardware as long as you have wifi which I do. I also agree about the intellectual challenge of getting to understand how something works, and I think, as we have said before, it is worth it, if only to stave off the day when everyone we meet turns out to be Dr Alzheimer.

When you are ready, post your recap and we can review it.  

Posted by: @cathoderay

↑

@derek-m - that sounds like a good plan. It would be great if we can get more data, as wifi is after all the simplest connection that needs no extra hardware as long as you have wifi which I do. I also agree about the intellectual challenge of getting to understand how something works, and I think, as we have said before, it is worth it, if only to stave off the day when everyone we meet turns out to be Dr Alzheimer.

When you are ready, post your recap and we can review it.  

In the _init_.py there is the following code which imports data from HA. I have a feeling that HA contains a list of the sensors etc. from which data can be obtained from the various devices, and I believe that I have seen code that checks this list before requesting the data. Could you have a look through the HA files to see if there is such a list, and if so, then send a copy.

I am still of the opinion that data is extracted from a device by requesting it by name, which needs to be in the specified list. When you used Byte1 etc. I believe that you were just naming a variable into which the data was deposited, after it had been extracted.