Posted by: @derek-m

↑

As a test you could try changing the body_type 0x01 some other value. This would need to be done within the code shown below.

I changed it to 0x04, being a type we know exists, and got this back:

2023-03-16 17:09:12.516 DEBUG (Heat Pump (LAN)) [custom_components.midea_ac_lan.midea.core.device] [device_id] Sending: {'header': 'aa0bc300000000000003', 'body': '04', 'message type': '03', 'body type': '04'}
2023-03-16 17:09:12.824 DEBUG (Heat Pump (LAN)) [custom_components.midea_ac_lan.midea.devices.c3.device] [device_id] Received: {'header': 'aa12c300000000000003', 'body': '0400000000000000', 'message type': '03', 'body type': '04'}
2023-03-16 17:09:12.825 DEBUG (Heat Pump (LAN)) [custom_components.midea_ac_lan.midea.core.device] [device_id] Unidentified protocol

They are not trying to make it easy, are they. The 'Received' entry may be interesting: the header now has 'aa12c3' rather than 'aa23c3' and the message itself is short and and all but empty/null.

The 'Unidentified protocol' log entry comes from line 258 in core/device.py after a long series of 'if' statements that perform some complex (at least to my eyes) tests. 

Posted by: @derek-m

↑

What happens if you add byte_17 to byte_25?

I can't, including bytes 23 and above crashes the code and/or gives the out of range error. 

@cathoderay

It would appear from your 0x04 test, that the first byte within the message body indicates the body type, then either the body length is limited to 9 bytes, or it gave up because it found no suitable data. What is a little strange is that the message length recorded within the header states that the full message should be 18 bytes, but the produced header is 10 and the body is 9, which totaled 19 when I went to school.

If you have the time you may wish to try different body type's from the table below. That would at least indicate any differences, and may even produce some data.

I have been searching through the various files to locate all the different body type's, which are detailed below. It would appear that as new appliances, with different models, have been added to the list, new body type's have been included within the software. I presume there may be a list somewhere which details the structure of each body type, but as yet I have not discovered its location.

_body_type								
midea/core/message.py		0x00						
midea/devices/a1/message.py		0xB0	0xB1	0xB5	0xA0			
midea/devices/ac/message.py		0xA0	0xA1	0xB0	0xB1	0xB5	0xC0	0xC1
midea/devices/b0/message.py		0x01	0x04					
midea/devices/b6/message.py		0x11	0x22	0x31	0x32	0x41	0x0A	0xA1
midea/devices/c3/message.py		0x01						
midea/devices/ca/message.py		0x00	0x02	0x01				
midea/devices/cc/message.py		0x01	0xC3					
midea/devices/ce/message.py		0x01	0x02					
midea/devices/cf/message.py		0x01						
midea/devices/da/message.py		0x04						
midea/devices/db/message.py		0x04						
midea/devices/dc/message.py		0x04						
midea/devices/e1/message.py		<= 7	== 0					
midea/devices/e2/message.py		0x01	0x02	0x04	0x14			
midea/devices/e3/message.py		0x01	0x02	0x04	0x14	0x00		
midea/devices/ed/message.py		0x01	0x03	0x04	0x05	0x06	0x07	
midea/devices/fc/message.py		0xB0	0xB1	0xA0	0xC8			
midea/devices/fd/message.py		0xB0	0xB1	0xA0	0xC8			

@derek-m - HA has just corrupted its database again. For most of the last hour, the HA sqlite add-on has produced a string of 404 pages. I'm getting to the point where I want my life back: HA is by far the worst software I can remember ever having the misfortune to use. Written by arrogant idiots for, well arrogant idiots. 

I have now received what I think I need in the way of bits and pieces to connect to the wired controller using modbus over a wired connection. The thing is, all I ever wanted to do was get some data, and HA is now getting in the way of getting data. At it's simplest, all in want to do is get data into a spreadsheet so I can manipulate it and produce simple graphs.

I'm going to sleep on it, but at the moment I think the time has come to get rid of HA, total and absolute annihilation, and find a way get the data over modbus and log it into a csv/spreadsheet file, or even some form of simple database, because such data can always be exported as csv files.     

@derek-m - having slept on it, I think the prudent course of action is to concentrate my energies on getting a wired modbus connection set up, and finding a way to log the data that doesn't involve Home Assistant. Despite our determined best efforts, and your expert knowledge, we still haven't really made much progress, in fact the only thing we have achieved is identifying byte_09 as being likely to be the ambient outdoor temperature. The other two key factors in my decision are:

(1) HA's instability. Software that routinely corrupts its own data is not worthy of the label software. Nor does it help that it is appallingly badly documented, and appears, as you put it so well, to have been written by sadists. The 'community forum' is a joke, membership being made up of 80% of masochists who enjoy the pain of trying to make dud software work, and the 20% of sadists, who enjoy flogging the masochists.

(2) perhaps most persuasive of all is wasilukum's recent comment (he was the one who added the total energy sensors to the midea_ac_lan code):

"I'm not planning to invest more time in this solution [ie midea_ac_lan] as I'm now using direct Modbus communication, which has documentation for all the data/registers. Not to mention it is more reliable."

If someone who knew enough about the inner workings of midea_ac_lan decided to ditch it in favour of modbus, which as he puts it, 'has documentation for all the data/registers'  and 'is more reliable', then surely that tells us something. 

I now have a RS-485 to USB adaptor, some shielded twisted pair cable and the probably necessary 120 ohm resistors that should allow me to establish a wired connection to the wired controller. I then need to find some preferably open source software that can read the modbus registers and log the data to a suitable, ideally csv, format. I have already come across some possible candidates. Alternatively, it may be so straightforward that I can write my own code to do it. At a very basic level, I can manage python, as long as the HA sadists stay away. 

As I have said before, I don't think we have wasted our time up till now on trying to get midea_ac_lan to work. It looked as if it had potential, and there was only one way to find out whether it actually did have potential, and that was by trying to hammer it into shape. We have since discovered it doesn't have that potential, at least in any form that we can use. To carry on hammering it now is in effect flogging a dead horse. There is also the previously mentioned incidental benefit that we have given our little grey cells a good work out, and that can only be a good thing. 

You'll only need one 120R resistor @cathoderay  - at the far end of the RS485 line. 🤔 

I've been assembling a range of Modbus devices over the past few months.
They are to monitor and control storage battery systems, so not identical to the task you're embarking on.

However, I'd be very surprised if you were satisfied with any existing software suite.
If you can manage Python, then I'll bet you end up writing your own code!

Modbus devices do indeed have lots of documentation concerning their registers.
But there's precious little agreement about a standard approach!

One other hint as you start experimenting...
... it's useful to be able to set an attached device back to a known configuration when you've pranged it by writing decimal instead of hex (or vice-versa).
Create a table of Modbus commands for each device which you can send out to put it back into a known configuration.
That eventually evolves into an Initialisation Sequence for when the software starts.

@transparent - thanks very much for the tips, all understood. Just one question:

Posted by: @transparent

↑

at the far end of the RS485 line

Is that the computer/RS-485 to USB adaptor end, or the wired controller end? I think I have read somewhere that (some of?) these adaptors already have a 120 ohm resistor in them, suggesting the end left needing one is the wired controller end. 

It's usually the case that the USB adaptor end 'offers' the 120R impedance by default.

You therefore need to place that matching resistor at the other end of the RS485 wire.

At the moment you're only considering a connection to one device.
But once you've got Modbus running, you can of course add scores more sensors and controllers in a single (parallel) string.
Each device uses the same A and B connections, but only the final one requires a 120R resistor.

Also, by all means connect the earth at the computer end if you wish, so that your cable is screened.
But RS485 doesn't stipulate that it's necessary.
The A & B wires are floating and your adaptor is reading the differential voltage.
You don't want to connect the screen of the cable needlessly, only to end up creating an earth-loop. Aagh!

@transparent - thanks again, points noted. Two new questions (sorry!):

(a) the cable is a FTP Cat 5e cable, with four twisted sheathed pairs, one bare copper wire (fine as hair!) and the foil overall sheath under the PVC sheath. I was planning to use one of the twisted pairs four the A-H2 and B-H1 connections, ie two cables from the same pair, but it looks as though the twisted pairs might then be twisted themselves inside the sheath, meaning it might also work using both cables in a pair for one connection, and both cables from another pair for the second connection. Any thoughts?

(b) I was going to use one of the other twisted pairs for the earth connection, rather than the ultra fine bare copper wire, making connections at both ends, I think I read somewhere it works better with that earth setup. The foil sheath I was going to cut back and not connect it to anything. Have I got the right idea?

I had the floor boards up this afternoon, and now have the cable running (as yet unconnected at either end, obviously) from the wired controller in the airing cupboard to my study where my PC is, all neatly stowed away out of sight. I've left enough slack very loosely coiled in the underfloor space to be able to take the cable down through the ceiling to the kitchen below, where the external meter supplying the heat pump is conveniently to hand (unfortunately it doesn't have a RS-485 interface, so I will have to use a pulse counter on the LED, 1000 pulses = 1 kWh). It is also a sensible place to have a temperature sensor in the kitchen, near centre of house and out of any direct sunlight at any time of day.

PS I've double checked, the connections are the counter-intuitive A to 2 and B to 1. The same page in the Midea manual also shows the terminal to connect the earth wire to. What could possibly go weong? 

Oh great - more hardware questions. 😀 

FTP is well beyond the cable spec you're after. But it'll do ok.
Let's remember that RS485 gets deployed in refineries and chemical processing plants stretching over a kilometer!

There are several device manufacturers who choose RJ45 sockets for RS485 ports. But there's no agreed standard to support that.
So you just have to take care to connect the A and B pins which are identified in the user manual.

Here, for example, is the diagram issued by Growatt for its SPF-series of inverters:

So both of their two RJ45 sockets have RS485 on pins 1 & 2.
They then spread confusion amongst their customers by producing a diagram to show which end is Pin-1, but forget to identify whether you're looking at the end of the plug or into the socket! 🤔 

You'll notice that Growatt do not offer an earth connection.
That's commonly the case.

The important point is that the A & B wires must be a single twisted pair.

There are two reasons why you might want an earth on your cable

• to provide better emf shielding as an anti-interference measure, by using the foil-screen
• to supply an earth reference to a device which is otherwise 'floating', such as a battery-operated sensor in an anti-static environment

The former only requires the foil screen to be connected to earth at a single point, which is usually the PC. It's not a current-carrying conductor.
But if the USB adapter you've chosen is not itself tied to earth, well then there's nothing to gain from that anyway!

The latter case is implemented by using a third conductor in the cable, other than the twisted pair used for A & B.
But it doesn't matter which conductor it is.

It's not the case that RS485 'works better' with an earth connection.

Connecting an earth when you don't require one can create other anomalies, especially if the PC and a device it connects to both have a mains earth connection, but are a volt or two apart.
That can easily occur in an industrial environment which has different power circuits across long distances.

Not only would the RS485 cable now be carrying current as the two power circuits attempt to balance themselves,
but the earth path can also carry spikes and surges back to the electronics of the PC doing the monitoring.

If I were in your position, I'd omit the earth connection at the far end of the cable,
and I'd leave myself the option to connect the drain-wire of the foil screen to earth at the computer end.

@cathoderay

I agree with your decision to ditch Midea_ac_lan and HA.

I have just discovered why the Python programming language is such fun. Watch the following video. 🙄 

If you want to place a few temperature or voltage sensors around your heat-pump, you could consider using an analogue acquisition module with a Modbus RS485 output.

There are a number of these for sale with several different input ranges.

Here's a module design which I've just imported from China and has seven analogue input ports available.

@transparent Please share your results with the above device.  I am getting significant noise from my 10k thermistors.  I think these [thermistors on a long cable] are designed for much higher voltages than the 1v I am sending down them