Posted by: @derek-m

↑

Any progress?

I was tied up with other things for most of today, so nothing to report yet.

Posted by: @derek-m

↑

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'.

I still think the logging library (or whatever it is called) is a generic core python component that is used whenever logging is wanted. In the preamble to cpython/Lib/logging/__init__.py it says "Logging package for Python.". The midea_ac_lan code then uses the library to write to the HA log (which is where I see the messages) after setting the logging level to 'debug'. Note the DEBUG in the log entry; if I didn't have logging set to debug, the log entry would not appear. 

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'}

There is no option to set timing (of messages and/or logging) in HA. I can now, thanks to you pointing it out, see a timing function in core\device.py:

                    if now - previous_refresh >= 30:
                        self.refresh_status()
                        previous_refresh = now

ie after 30s (I assume it is seconds) it runs refresh_status. There's also the heatbeat code, but to my (medical) mind I thought that is more about keeping something alive than timing!

Posted by: @derek-m

↑

Did the 'body type' tests obtain any data?

No, still nothing (as in nothing).

Posted by: @derek-m

↑

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.

I think this is certainly worth trying, it would also go some way towards tracking down what sets the timing. I might also trying changing the 30 in the above code to say 120 and see what happens.

Posted by: @derek-m

↑

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.

I did try something similar earlier, but using writing to a file, as print has nowhere to show up (remember HA is running on a so-called headless device, including no monitor), but couldn't get it to work for any useful data. Yes, != is 'not equal'. 

@derek-m - a result! Changing 60 (it was 60 not 30) to 180 in the code below from core\device.py changes the logged entry frequency from once a minute to once every three minutes:

    def run(self):
        while self._is_run:
            while self._socket is None:
                if self.connect(refresh_status=True) is False:
                    if not self._is_run:
                        return
                    self.close_socket()
                    time.sleep(5)
            timeout_counter = 0
            start = time.time()
            previous_refresh = start
            previous_heartbeat = start
            while True:
                try:
                    now = time.time()
                    if now - previous_refresh >= 180:    # was 60
                        self.refresh_status()
                        previous_refresh = now
                    if now - previous_heartbeat >= 10:
                        self.send_heartbeat()
                        previous_heartbeat = now
                    msg = self._socket.recv(512)
                    msg_len = len(msg)
                    if msg_len == 0:
                        raise socket.error("Connection closed by peer")
                    result = self.parse_message(msg)
                    if result == ParseMessageResult.ERROR:
                        _LOGGER.debug(f"[{self._device_id}] Message 'ERROR' received")
                        self.close_socket()
                        break
                    elif result == ParseMessageResult.SUCCESS:
                        timeout_counter = 0
                except socket.timeout:
                    timeout_counter = timeout_counter + 1
                    if timeout_counter >= 12:
                        _LOGGER.debug(f"[{self._device_id}] Heartbeat timed out")
                        self.close_socket()
                        break
                except socket.error as e:
                    _LOGGER.debug(f"[{self._device_id}] Socket error {repr(e)}")
                    self.close_socket()
                    break
                except Exception as e:
                    _LOGGER.debug(f"[{self._device_id}] Unknown error {repr(e)}")
                    self.close_socket()
                    break

which means we now know where the 03/01 message frequency is set. Perhaps by working backwards and forwards from that code we can put to together the rest of the story. But still no clues about the 04/04 message timing that I can see.

@derek-m - this might be interesting. It is the debug log entries immediately after a HA restart:

2023-03-04 19:41:49.545 DEBUG (Heat Pump Wi-Fi Controller) [custom_components.midea_ac_lan.midea.core.device] [device_id] Connected
2023-03-04 19:41:49.545 DEBUG (Heat Pump Wi-Fi Controller) [custom_components.midea_ac_lan.midea.core.device] [device_id] Handshaking
2023-03-04 19:41:49.614 DEBUG (Heat Pump Wi-Fi Controller) [custom_components.midea_ac_lan.midea.core.device] [device_id] Authentication success
2023-03-04 19:41:49.614 DEBUG (Heat Pump Wi-Fi Controller) [custom_components.midea_ac_lan.midea.core.device] [device_id] Sending: {'header': 'aa1dc3000000000000a0', 'body': '00000000000000000000000000000000000000', 'message type': 'a0', 'body type': '00'}
2023-03-04 19:41:49.884 DEBUG (Heat Pump Wi-Fi Controller) [custom_components.midea_ac_lan.midea.core.device] [device_id] Received: {'header': 'aa2ac3000000000000a0', 'body': '00c3000000000000000000000000000000000000000000000000000000000000', 'message type': 'a0', 'body type': '00'}
2023-03-04 19:41:49.885 DEBUG (Heat Pump Wi-Fi Controller) [custom_components.midea_ac_lan.midea.core.device] [device_id] Subtype: 0. Device protocol version: 0
2023-03-04 19:41:49.885 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'}
2023-03-04 19:41:50.130 DEBUG (Heat Pump Wi-Fi Controller) [custom_components.midea_ac_lan.midea.devices.c3.device] [device_id] Received: {'header': 'aa23c300000000000003', 'body': '010975910303281e323041231905371919053c223c142f0080', 'message type': '03', 'body type': '01'}
2023-03-04 19:41:50.131 DEBUG (Heat Pump Wi-Fi Controller) [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, 'current_temperature': 0, 'zone1_water_temp_mode': True, 'zone2_water_temp_mode': False, 'zone1_room_temp_mode': False, 'zone2_room_temp_mode': False}
2023-03-04 19:41:50.133 DEBUG (Heat Pump Wi-Fi Controller) [custom_components.midea_ac_lan.midea.core.device] [device_id] Status update: {'available': True}

The [custom_components.midea_ac_lan...] part tells us which file made the entry. The 'Sending' entries come from \core\device.py, and the content (and received response) varies, suggesting to me the message does set what gets returned (which makes sense). I think the first 'Sending' is a start up one off about the device (response is 00c3000... ie it is a heat pump) and the second sending asks for what will become the status update. But still no sign of anything to do with the 04/04 messages. 

@cathoderay

I think that the 04 timing is being initiated by the Midea server, requesting data for the App.

@derek-m - I discovered this morning that at 2135 yesterday evening, when I was nowhere near anything to do with HA and my desktop PC was off, midea_ac_lan decided to fail, and everything became unavailable. The log is useless, all it says is 'Connection error' which I already know to be the case since everything is unavailable. HA itself seems to be running normally.

I have cleaned up (removed the changes/additions) the code in core\device.py and restarted HA. all to no avail.

The command line utility midea-discover, not part of midea_ac_lan, used for getting details about the heat pump, can 'see' the heat pump, or rather its SSID, and gets the correct unit model and ID, but fails to get other essential details.

Something is badly broken, and I have no idea what it is. I can't help wondering though if Midea have messed with the protocol again, in keeping with their policy of making sure foreign devils live in interesting times.     

Posted by: @cathoderay

↑

@derek-m - I discovered this morning that at 2135 yesterday evening, when I was nowhere near anything to do with HA and my desktop PC was off, midea_ac_lan decided to fail, and everything became unavailable. The log is useless, all it says is 'Connection error' which I already know to be the case since everything is unavailable. HA itself seems to be running normally.

I have cleaned up (removed the changes/additions) the code in core\device.py and restarted HA. all to no avail.

The command line utility midea-discover, not part of midea_ac_lan, used for getting details about the heat pump, can 'see' the heat pump, or rather its SSID, and gets the correct unit model and ID, but fails to get other essential details.

Something is badly broken, and I have no idea what it is. I can't help wondering though if Midea have messed with the protocol again, in keeping with their policy of making sure foreign devils live in interesting times.     

Your middle name isn't Johah by any chance? 🙄 

I can remember the days when one would load software from a disc, and it worked, without the need for an internet connection so that the software could have all the mistakes corrected later.

Did you set the logging frequency back to 60 seconds?

Would it be possible to create your own program that just utilises the relevant files from Github?

Are you planning to continue with your objective?

@cathoderay

I forgot to mention that the software into which I have been delving, which I access via the link that you provided on page 2 of this post, actually contains a refresh time set at 30 seconds, not 60 seconds as you find in your version. So there are obviously differences between the version available.

@cathoderay

Have you considered using Visual Basic to read the Modbus Registers within the Midea Controller? By reading the actual registers it should be possible to obtain the precise data that you require. I used VB with Excel, but it may be possible to write the data to HA.

I used Visual Basic a number of years ago to help write the software for some Emergency Shutdown Systems, and I found it quite useful, and easier to understand than Python.

Just dropping in here as I'm keeping track. You can get chatgpt to write code for you. Might help some of your heavy lifting. 

Posted by: @batalto

↑

Just dropping in here as I'm keeping track. You can get chatgpt to write code for you. Might help some of your heavy lifting. 

It is not so much writing the code with Midea_ac_lan, as trying to find out how to decipher the data being collected, most of which has now been accomplished, but also trying to discover if it is possible to obtain further data, assuming it is available.

@cathoderay

You may find this YouTube video of interest.

Posted by: @derek-m

↑

Did you set the logging frequency back to 60 seconds?

Would it be possible to create your own program that just utilises the relevant files from Github?

Are you planning to continue with your objective?

Been busy again today with other things, apologies for delayed replies.

Yes I did set the frequency back to 60 seconds (not 30, not sure where that came from). There definitely are two versions, the original georgezhao2010 and the modified version.

I have considered creating my own program, but am up against the problem of not really knowing what I am trying to get, plus of course facing a steep learning code, as I will probably be coding above my pay grade. I too have done a small amount (a very small amount) of VB coding, and I certainly wouldn't rule it out at this stage.

At the moment, I still think everything is local, and it is all happening over wifi on my lan - I still can't any point in the code at which midea_ac_lan uses the Midea servers, they are only involved at initial setup, using the separate midea_discover CLI program. I agree it is possible midea_ac_lan eavesdrops on wired controller/server traffic, but it is still doing that locally. I haven't made any wired connections to the H1/H2 RS-485 modbus connections in the wired controller, that has sort of become a Plan B, in the event Plan A (using midea_ac_lan over wifi) fails. I may be approaching a time where I have to say that has now happened. I find this evening I can't even connect to HA. It is as they say a case of the lights are on (on the mini PC), but nobody's home... This on the face of it appears to be HA's second major failure in the space of only a few weeks. The hardware is new, and I SMART checked the SSD after the last major HA failure (database corruption) and it passed 100%, I don't think a hardware fault is the likely explanation. I will try a full reboot of the mini PC tomorrow morning.  

I am certainly going to carry on for now, but in the Beginners Guide thread I said straight up in the first post "I'm setting a time limit: if I haven't got a working monitoring system by 1st April 2023 (choice of 1st April is deliberate), then the effort becomes history." One has to be sensible about these things. Perhaps I need to order the stuff needed for a H1/H2 RS-485 modbus connection this coming week.

@batalto - have you seen anything odd on your Msmarthome app? I haven't on mine, but I'm wondering if there was a covert over the air upgrade that made significant changes.