@cathoderay

I have been looking in detail at the code within various routines, in particular those associated with AC. Unfortunately it is not just a matter of copying over the code, and changing the AC references to C3. There also does not appear to have been a consistent approach carried out in the production of the different routines, which makes it all the more difficult to follow the logic.

Posted by: @derek-m

↑

Maybe try adding Byte23, Byte24 and Byte25 in the same manner as outdoor_temperature.

Back in January, I did something similar, in effect getting the data from these bytes. Here are the notes I made at the time:

data_offset + 16 = 5
data_offset + 15 = 25
data_offset + 14 = 25
data_offset + 22 = 0
data_offset + 23 = 128
24 device stops working
25 device stops working
30 device stops working 

By 'device stops working' I think I meant it failed to load (fatal error). I concluded at that time there was no data beyond data_offset + 23. As the current code assigns the data from data_offset + 22 to outdoor_temperature, and it gets '0', it in effect confirms the above.

Meanwhile there has been a response overnight on github from the second midea_ac_lan, wasilukm:

"Hi, thank you for all the feedback. I don't know the other values you have mentioned. This all was reverse engineering.
I'm not planning to invest more time in this solution as I'm now using direct Modbus communication, which has documentation for all the data/registers. Not to mention it is more reliable."

I think one problem may be that the developer isn't familiar with heat pumps, and so LWT/RWT and flow rate, which were the other values mentioned. It also seems that he has come to pretty much the same conclusion that I was getting to at the end of last week, that it is time to try the modbus approach. which by his account is better documented (I think we can agree with that) and more reliable (I suspect it will be).

I did order the basic hardware at the end of last week, an RS-485 to USB converter, enough shielded twisted pair cable (actually shielded cat 5e ethernet cable) to cover the distance between the wired controller and the mini PC and some 120 ohm resistors that should be sufficient to put together a proof of  concept setup. If that works, then I will put together something more permanent.

@cathoderay

When you carried out the previous test that you mentioned in your previous post, was the additional devices added within the byte array or outside?

Posted by: @derek-m

↑

@cathoderay

When you carried out the previous test that you mentioned in your previous post, was the additional devices added within the byte array or outside?

Not in the def _body(self) code that has return bytearray(), just in the usual places to get the sensors added and message processed. 

I've just been gong through this code from c3/message.py:

from ...core.message import (
    MessageType,
    MessageRequest,
    MessageResponse,
    MessageBody,
	)


class MessageC3Base(MessageRequest):
    def __init__(self, device_protocol_version, message_type, body_type):
        super().__init__(
            device_protocol_version=device_protocol_version,
            device_type=0xC3,
            message_type=message_type,
            body_type=body_type
        )

    @property
    def _body(self):
        raise NotImplementedError


class MessageQuery(MessageC3Base):
    def __init__(self, device_protocol_version):
        super().__init__(
            device_protocol_version=device_protocol_version,
            message_type=MessageType.query,               # this looks up MessageType > query in the imported core/message.py and returns 0x03, MessageType.notify1 would return 0x04 etc  
            body_type=0x01)                                                 # body_type set here

and I can see how the query 'headers' are set up (the above sets up an 03/01 type message) but I am still lost as to how we can determine how to alter this (ie what numbers to use) to get other messages.

@cathoderay

I am fully aware of how the body type is selected.

Would you please carry out the proposed test, as suggested.

Posted by: @derek-m

↑

I am fully aware of how the body type is selected.

I'm sure you are, the above post was just adding more documentation for me and any others - if there are any - who may be following this thread.

Posted by: @derek-m

↑

Would you please carry out the proposed test, as suggested.

I am not sure which test this refers to:

Posted by: @derek-m

↑

Maybe try adding Byte23, Byte24 and Byte25 in the same manner as outdoor_temperature.

I have already in effect done that, see above. Anything above byte 23 breaks the code.

Posted by: @derek-m

↑

A further test would be to remove 'tank_actual_temperature' from the list and see if the data obtained is actually the tank temperature, but under the name outdoor_temperature.

I haven't done this because tank_actual_temperature is part of the live data collection, and I am reluctant to disrupt it.

Posted by: @derek-m

↑

A further test would be to move one of the energy devices to position 23, 24, 25 and 26 in the message body and see if it appears in the type 01 message.

I am not sure what an 'energy device' is or how to set positions in the message body. On the basis of what I think you mean, I have added this to the end of class C3MessageBody(MessageBody) (and commented out outdoor_temperature as it overlaps the bytes used) in c3/message.py:

        self.tank_actual_temperature = body[data_offset + 21]
#        self.outdoor_temperature = body[data_offset + 22]  # Add
        self.total_energy_consumption = (
            (body[data_offset + 22] << 32) +
            (body[data_offset + 23] << 16) +
            (body[data_offset + 24] << 8) +
            (body[data_offset + 25]))
           
class C3Notify1MessageBody(MessageBody):

This time, the inclusion of bytes above 23 didn't break the code totally ie it loads, but what I get in the log entry is:

2023-03-13 13:07:40.422 ERROR (Heat Pump (LAN)) [custom_components.midea_ac_lan.midea.core.device] [device_id] Unknown error IndexError('index out of range')
2023-03-13 13:07:40.827 DEBUG (Heat Pump (LAN)) [custom_components.midea_ac_lan.midea.core.device] [device_id] Status update: {'available': False}

and then it gives up the ghost, endless handshaking followed by the above:

Connected
Handshaking
Authentication success
Sending: {'header': 'aa0bc300000000000003', 'body': '01', 'message type': '03', etc etc

Unknown error IndexError('index out of range')
Status update: {'available': False}

repeated over and over.

I suspect "IndexError('index out of range')" may be because bytes above 23 don't exist, so we get a typical index out of range error.

@cathoderay

The objective was to see if the message body could be extended to incorporate new data. If I am interpreting the result correctly, this was achieved. The errors being generated could be because additional code has not be added in other routines. Please provide a text copy of the relevant files, so that I can see what you have done. I am rather busy at the moment so I will have a look later. Could you also provide a copy of the message body string after each test.

Posted by: @derek-m

↑

The objective was to see if the message body could be extended to incorporate new data. If I am interpreting the result correctly, this was achieved.

Not really, what you see above is what you get, no message body or string at all. I've seen this before. The code can either fail to load at all, there is usually just a line or two in the log saying fatal error, or it will load and do handshaking and then fail. This is what is happening this time, and it gets stuck in an endless handshaking fail handshaking fail loop. My reading is the 'index out of range' error is the clue, I've seen this when an array is supposed to have x members, when in fact it has x + n members, and the error happens when a loop acting on the array tries to operate on a member that is out of the expected range.

The only code change I made is the one I posted above, adding the energy entity with the higher byte numbers (and commenting out outdoor_temperature because of the byte overlap). I can send the whole lot again, but I for one find tracking version changes a nightmare, so I try to keep the number of files as small as possible. 

No problem at all with the time scale, we all have other things to do!

Posted by: @cathoderay

↑

Posted by: @derek-m

↑

The objective was to see if the message body could be extended to incorporate new data. If I am interpreting the result correctly, this was achieved.

Not really, what you see above is what you get, no message body or string at all. I've seen this before. The code can either fail to load at all, there is usually just a line or two in the log saying fatal error, or it will load and do handshaking and then fail. This is what is happening this time, and it gets stuck in an endless handshaking fail handshaking fail loop. My reading is the 'index out of range' error is the clue, I've seen this when an array is supposed to have x members, when in fact it has x + n members, and the error happens when a loop acting on the array tries to operate on a member that is out of the expected range.

The only code change I made is the one I posted above, adding the energy entity with the higher byte numbers (and commenting out outdoor_temperature because of the byte overlap). I can send the whole lot again, but I for one find tracking version changes a nightmare, so I try to keep the number of files as small as possible. 

No problem at all with the time scale, we all have other things to do!

I would suggest that you remove recent added code until you once more obtain a message, and then let me know what code has been removed, from where. Also post a copy of the message.

Posted by: @derek-m

↑

I would suggest that you remove recent added code until you once more obtain a message, and then let me know what code has been removed, from where.

I removed the code causing the error straight away, and the remaining code now functions normally as it did before. The code added and then removed is exactly as shown above in my 1:17pm post: added # at the start of the self.outdoor_temperature line and then added the five total_energy lines immediately below. Removal reversed those changes.

Posted by: @cathoderay

↑

Posted by: @derek-m

↑

I would suggest that you remove recent added code until you once more obtain a message, and then let me know what code has been removed, from where.

I removed the code causing the error straight away, and the remaining code now functions normally as it did before. The code added and then removed is exactly as shown above in my 1:17pm post: added # at the start of the self.outdoor_temperature line and then added the five total_energy lines immediately below. Removal reversed those changes.

Can you now post a copy of the message.

@cathoderay

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