@derek-m - don't forget that I have already tried something like this, and we have previously discussed it. My code is still at the end of c3/message.py, and it produces nothing (my added code in blue):

 
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)

    
        self.set_attr()

Here you can see I added another message/body type (penultimate lines, which have lost their proper indent), and added a whole new class (C3Notify2MessageBody) to process the messages. I also defined the DeviceAttributes in c3/device.py (all this you can see in the latest c3/device.py and message.py I sent you) and added the relevant C3Attributes in midea_devices.py, all to no avail...  

Edit - I see WP has again adopted its WP knows best policy and screwed up my inline CSS but as it remains clear enough what I meant I'm leaving it as it is. 

I would think the Modbus solution is best. It is probably the approach taken by Freedom for their monitoring system.

I can’t quite see why it would be necessary to add wiring. Surely the UI controller is already connected to the local network and is able to forward messages to the Modbus and receive responses. If it were desired to bypass the controller one could wire to the UI Modbus connection, and I assume Modbus is able to support multiple slave devices. 

Not having studied the Midea_AC thingy I kind of assumed it was sniffing the Lan traffic. Whilst the UI and the Midea Cloud can agree a separate message interface to Modbus with the UI converting these into Modbus format, one would hope that there was a basic read parameters message they use that just gets transferred on to Modbus. 

Phil

Posted by: @filipe

↑

I would think the Modbus solution is best. It is probably the approach taken by Freedom for their monitoring system.

I'm pretty sure both Freedom and Homely use a wired modbus approach, making a physical connection to the H1/H2 connections in the wired controller.

Posted by: @filipe

↑

I can’t quite see why it would be necessary to add wiring. Surely the UI controller is already connected to the local network

The topology/architecture or whatever the correct term is for the connections are far from clear. We have not even established whether midea_ac_lan actively sends queries, or passively listens to traffic (there is evidence it does both, and maybe that is it, it does both). The other thing is that it appears the wired RS-485 modbus side of things and the wifi (which primarily exists to send data to the Midea servers which then ends up in the app) side of things are separate in their implementation, even if they start out from the same data. The wifi data for example is not recognisable as modbus data, it arrives as stings that have to be decoded using reverse engineered Midea routines. It looks as though the modbus data is only available through a physical wired connection, even if the data is subsequently moved from A to B over a wifi connection eg modbus > wires > esp or whatever > wifi. 

As I said a few posts ago, I am also coming round to the idea that we may have reached the limits of what can be got from the wifi interface, and the time may have come to move over to a modbus interface. I am still a little nervous about taking the lid off the wired controller, as in what could possibly go wrong? @derek-m has very generously said he will continue to work on the midea_ac_lan code, to see if it can be made more productive.

I realise now that the UI is the master and the heat pump the slave. It is also a fact that only one instance of the MSmartHome App can be talking to  the Midea Cloud at a time. Unless Midea have implemented Modbus TCP there may be problems adding another master onto the UI Modbus cable. However, if only sending read commands to the slave some inter working may be possible. The cloud may get a bit confused if it picks up replies it did not request. Perhaps it has to deal with the user generating read and write requests though. 

Phil

@cathoderay

Yes, I have seen your added code, but there are two instructions that it does not contain, 'append' and 'extend'. If my understanding is correct, I believe that append is used to add additional tags to the MessageSet and/or MessageQuery code, which I think adds byte size data, whilst extend does a similar role with bit size data.

I'm going to the supermarket shortly, after which I will see what code modifications I can propose.

The fact that changing the refresh timing previously would indicate the the Midea code is 'querying' the controller, as it does when the code is first run, when it sends a broadcast signal to identify any equipment on the LAN.

Posted by: @filipe

↑

I realise now that the UI is the master and the heat pump the slave. It is also a fact that only one instance of the MSmartHome App can be talking to  the Midea Cloud at a time. Unless Midea have implemented Modbus TCP there may be problems adding another master onto the UI Modbus cable. However, if only sending read commands to the slave some inter working may be possible. The cloud may get a bit confused if it picks up replies it did not request. Perhaps it has to deal with the user generating read and write requests though. 

Phil

If UI means the wired controller as I think it does, I think you are right, it is the master (so any and everything else is/are slaves). But I think this is OK, both the Freedom and Homely interfaces work with this set up.

The other important thing is I don't want a wired modbus interface (no TCP) to have anything to do with the Midea wifi/cloud/app setup. Hopefully this will also avoid/bypass all the Midea v3 protocol encryption. Basically, I will just read selected modbus registers as detailed in the various manuals, and collect data that way. In the fullness of time, I might implement my load adjusted weather compensation curve idea, as detailed in past posts, to make it possible to have a night setback followed by an early morning boost. 

@derek-m - the need to add append and extend instructions makes sense. I also agree that changing the timing did in effect confirm on the face of it that the midea_ac_lan code does query the wired controller, as does the presence of a 'Sending' log entry immediately before every received 03/01 message log entry. I await any code proposals you may have with interest. 

@cathoderay

I have just found this code which looks quite interesting. The way that I interpret this code, is that extra switches and/or sensors can be added to an original list. This would appear to be done when the code is first run.

midea_ac_lan/custom_components/midea_ac_lan/__init__.py

async def async_setup(hass: HomeAssistant, hass_config: dict):
    hass.data.setdefault(DOMAIN, {})
    attributes = []
    for device_entities in MIDEA_DEVICES.values():
        for attribute_name, attribute in device_entities.get("entities").items():
            if attribute.get("type") in EXTRA_SWITCH and attribute_name.value not in attributes:
                attributes.append(attribute_name.value)

Following the code flow takes one to:-

midea_ac_lan/custom_components/midea_ac_lan/sensor.py 

async def async_setup_entry(hass, config_entry, async_add_entities):
    device_id = config_entry.data.get(CONF_DEVICE_ID)
    device = hass.data[DOMAIN][DEVICES].get(device_id)
    extra_sensors = config_entry.options.get(
        CONF_SENSORS, []
    )
    sensors = []
    for entity_key, config in MIDEA_DEVICES[device.device_type]["entities"].items():
        if config["type"] == "sensor" and entity_key in extra_sensors:
            sensor = MideaSensor(device, entity_key)
            sensors.append(sensor)
    async_add_entities(sensors)

@derek-m - that's very interesting, and armed with it, I had another look in HA and it turns out the extra sensors are visible in Midea AC LAN > configure:

I hadn't spotted them before (was looking in the logs, not in configuration options). As you can see I have enabled them - now it is a question of waiting to see if they produce any data!

This is produced by the code in the c3/message.py and message.py files you already have plus this in midea_devices.py:

            C3Attributes.byte_05_01: {
                "type": "sensor",
                "name": "Byte 05_01",
                "device_class": SensorDeviceClass.TEMPERATURE,
                "unit": TEMP_CELSIUS,
                "state_class": SensorStateClass.MEASUREMENT
            },
            C3Attributes.byte_05_02: {
                "type": "sensor",
                "name": "Byte 05_02",
                "device_class": SensorDeviceClass.TEMPERATURE,
                "unit": TEMP_CELSIUS,
                "state_class": SensorStateClass.MEASUREMENT
            },

repeated up to byte_05_06. I've just used temp settings as a proxy way of dealing with anything that turns up.

@derek-m - I've also added this to the right place at the end of c3/message.py so we test for multiple body types in one pass:

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

@cathoderay

That is also interesting. Can you supply a list of all the sensor names that are located in the list.

I have just spent a few hours tracing through the code to find all occurrences of 'indoor' and 'outdoor' with the following results. They will not be shown in the C3 files because I am searching the original code.

The objective is to see what additional code may be required in C3, to get the 'Outdoor Temperature' to appear in the type 01 message as well as the type 04.

When you added the additional sensors Byte 05 etc., did you also include them in 'climate.py' and 'midea_devices.py'?

'Indoor Temperature' occurs in files:-

climate.py
midea_devices.py
midea/devices/ac/device.py
midea/devices/ac/message.py
midea/devices/cc/device.py
midea/devices/cc/message.py

Whilst 'Outdoor Temperature occurs in files:-

climate.py
midea_devices.py
midea/devices/ac/device.py
midea/devices/ac/message.py

Posted by: @cathoderay

↑

@derek-m - I've also added this to the right place at the end of c3/message.py so we test for multiple body types in one pass:

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

Please post any results that you obtain, or let me know if nothing is forthcoming.

Posted by: @derek-m

↑

The objective is to see what additional code may be required in C3, to get the 'Outdoor Temperature' to appear in the type 01 message as well as the type 04.

I think that is a very useful objective. We're pretty sure it is in the 04/04 message, if we can then make it appear in the 03/01 message, then we have established we can add out own sensors.

Posted by: @derek-m

↑

When you added the additional sensors Byte 05 etc., did you also include them in 'climate.py' and 'midea_devices.py'?

Only in midea_devices.py (in the C3 section) (see above post timed 6:54pm). I don't think climate.py has ever needed/had any modifications to date, also no obvious thing to add to it (all the more so as I am treating any data retrieved as if it was a temp measurement even if it isn't, just to get it processed).

Nothing forthcoming yet, I'll let it run overnight.