Other Packets

[lekobob]

I have been doing some experimenting with my heat pump. I found if you send a request packet (0x42) with a 0x09 in byte 5 (0xfc is 0) you get a packet with a few info bytes. Here is what I found so far.

Examples: fc 62 01 30 10 09 00 00 00 01 01 00 00 00 00 00 00 00 00 00 00 52 fc 62 01 30 10 09 00 00 00 03 02 00 00 00 00 00 00 00 00 00 00 4f fc 62 01 30 10 09 00 00 08 00 00 00 00 00 00 00 00 00 00 00 00 4c fc 62 01 30 10 09 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 52

Byte 8: 0x04 is preheating 0x08 is standby or waiting, In a multi head system if others are already heating and one wants to cool it goes to this mode.

Byte 9: Heating or cooling stage.
0x01 to 0x04, in heating 0x01 is lowest power 0x05 is highest output

Byte 10: Only in "Auto" mode is shows what the unit is doing 0x01 is cool 0x02 is heat

In the examples above #1 is Auto mode calling for low cooling

2 is Auto mode calling for 3rd stage heating

3 is Waiting (other units in cool while calling for heat)

4 is Heating mode at stage 2. Looks the same for cooling mode at stage 2

I also purchased a MHK1 thermostat for one of my units to figure out how it works. Because you can set it up to sense temperature at the thermostat, it sends an "external room temp" packet.

It looks like this: fc,41,01,30,10,07,01,00,ad,00,00,00,00,00,00,00,00,00,00,00,00,c9

Byte 8 is the room temp in the normal hi resolution formula ((n -128)/2)= deg c

the unit responds with: fc,61,01,30,10,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,5e

For the most part the thermostat send the same commands for power, fan, vane and such. It never uses "Auto" mode, it figures out the temp difference and sets the unit in cool or heat accordingly, and sends a setpoint for each.

Lastly, there is a byte 5 0x04 info packet that can be requested, I think it is a error information packet. For me it always responds with 0x80 in byte 9. Based on this 0x80 is "normal operation" . I have no way to test this, so it is only speculation. My thermostat requests that packet constantly.

[unixko]

My use case for automode is in building management system. I have 14 heat pumps in a building. Each room user can adjust mode and temp by IR. I use Home Assistant just to monitor heat pump status, not take full control. At evening I can turn all of them off from central.

left: COOL mode | right: AUTO mode with cooling status. Status changes to idle when operating=false.

I prefer HP to return mode AUTO in state topic as usual and to return automode as an extra json attribute along with roomTemperature and operating in info topic.

[SwiCago]

@unixko that is a good suggestion to place it in info topic

[SwiCago]

@luiscgalo I just recently discover that the kumo cloud app now supports installer settings. This includes offsets and fan off/on on temp reached. I will hopefully get a rig setup again to packet dump it with my scope in a few weeks. I have a few things I need to finish around the house, to keep the wife happy. LOL

[luiscgalo]

@SwiCago I hope that everything goes fine with you. I'm sending this message just to say that I'm still interested on the installer settings exchanged via CN105 connector. If you have already some sniffing of the messages exchanged, please let us know... :)

[SwiCago]

@luiscgalo thanks for the continued interest. I have been pretty busy with home renovations, so have not yet setup a new rig to dump those packets. I do plan to do it, just need to build the rig again, connect my scope and start dumping packets...and need time

[SwiCago]

So I ordered a 36" extension cable, so I can build a new packet sniffer for between official kumo cloud device and HP unit. We'll see if I can figure out the installer settings packets.

[iclems]

FYI in some recent documentation I read "Energy monitoring The new MSZ-AP supports energy consumption monitoring via MELCloud remote control system. This function is also available in Multisplit R32 configuration."

[SwiCago]

@iclems , when I get rolling again with packet dumps, I'll see if I can find that too, but that already might be apart of the packets that tell you compressor frequency and such. In any case, for me personally I do not care about energy stats. If I need to heat or cool, what difference does it make if I know how much was consumed? For high rises it could make sense, to find out which tenant is over using the system more than others, but there are other ways to do that too.

[iclems]

Makes sense. I guess for me it’s about learning the true cost of using it versus not for average temperatures, and also of different modes (auto vs manually turning it on / off)

Le sam. 18 janv. 2020 à 15:39, SwiCago notifications@github.com a écrit :

@iclems https://github.com/iclems , when I get rolling again with packet dumps, I'll see if I can find that too, but that already might be apart of the packets that tell you compressor frequency and such. In any case, for me personally I do not care about energy stats. If I need to heat or cool, what difference does it make if I know how much was consumed? For high rises it could make sense, to find out which tenant is over using the system more than others, but there are other ways to do that too.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/SwiCago/HeatPump/issues/39?email_source=notifications&email_token=AAIROMRRRAQVXID7NNOIZCTQ6MIA5A5CNFSM4DCLWMM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJJZUXI#issuecomment-575904349, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIROMSC3SESI67BT4WE57LQ6MIA5ANCNFSM4DCLWMMQ .

-- Clément

[plambrechtsen]

@iclems , when I get rolling again with packet dumps, I'll see if I can find that too, but that already might be apart of the packets that tell you compressor frequency and such. In any case, for me personally I do not care about energy stats. If I need to heat or cool, what difference does it make if I know how much was consumed? For high rises it could make sense, to find out which tenant is over using the system more than others, but there are other ways to do that too.

I think what would be useful is if the protocol was fully documented then others who may want to write code could use it. I know personally I have used your code as a reference when writing my own code. I'm currently writing code that take the official controller and proxies it via proxypy and into home assistant and off to the official melview server. Having a central wiki where protocol decodes are documented is extremely useful. Even if you had a commented out section saying //offset [xx] energy usage with base of x * value /2.. or similar is extremely useful for other projects.

[AceAutomation]

Greetings all from France ! I've a PEAD-M125JA. I did some test on serial CN105 port (I added a RS485 converter with RS485 to USB over Ethernet module), I can manage the port from my PC. I'm in this case "Other Packets" case. If I send 0x00 0xFC 0x5A 0x01 0x30 0x02 0xca 0x01 0xa8, I receive FC 7A 01 30 01 00 54 I tried the Mitsubishi2MQTT project with a LOLIN Wemos Wifi. But it doesn't work. I read a lot of things... But I still found something good. I am looking for MQTT for this unit. If anybody can help me to find the right solution... if it exists. Thanks

[girlpunk]

Hi Folks, First of all thanks for all your hard work getting this up and running. I've got some parts on order so going to try and set this up on some ceiling units next week. Just got to find where that pesky connector is first.

It looks like there's another github repo at m000c400/Mitsubishi-CN105-Protocol-Decode that's had a fair bit of work in decoding some of the packet types, including some of the ones this issue was originally raised for. Might be worth a look to see if it has anything useful that could be added to the library?

[akamali]

So I ordered a 36" extension cable, so I can build a new packet sniffer for between official kumo cloud device and HP unit. We'll see if I can figure out the installer settings packets.

Hi @SwiCago / @luiscgalo, have you had any progress with controlling the function settings through CN105?

[SwiCago]

Special Function packets that have been decoded are as follows mosquitto_pub -t 'heatpump/set' -m '{"custom":"42 01 30 10 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00"}' {"customPacket":"42 01 30 10 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 "} {"packetSent":"fc 42 01 30 10 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 5d "} {"packetRecv":"fc 62 01 30 10 20 04 08 0c 10 14 18 3c 40 44 48 4c 50 54 58 00 99 "} 04 F1 = Unit automatically restarts after poweroutag (0:?,1:OFF,2:ON,3:NA) 08 F2 = ? 0c F3 = Ventilation Air (0:?,1:NA,2:IDU does not intake outdoor air,3:IDU does intake outdoor air) 10 F4 = Power Voltage (0:?,1:OFF,2:ON,3:NA) 14 F5 = Auto energy-savings operation(0:?,1:ON,2:OFF,3:NA) 18 F6 = ? 3c F15= Indoor Unit Coil Frost Prevention Temperature (0:?,1:2°C,2:3°C,3:NA) 40 F16= ? 44 F17=Defrost Control (0:?,1:STANDARD,2:HIGH,3:NA) 48 F18= ? 4c F19= ? 50 F20= ? 54 F21= ? 58 F22= ? 00 EOT

mosquitto_pub -t 'heatpump/set' -m '{"custom":"42 01 30 10 22 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00"}' {"packetSent":"fc 42 01 30 10 22 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 5b "} {"packetRecv":"fc 62 01 30 10 22 1c 20 24 28 2c 30 34 38 5c 60 64 68 6c 70 00 87 "} 1c F7 = Change Filter Duration (0:?,1:100hr,2:2500hr,3:NA) 20 F8 = Auto Fan speed setting (0:?,1:Quiet,2:Standard,3:High Ceiling) 24 F9 = No. of Air Outlets (0:?,1:4-directions,2:3-directions,3:2-directions) 28 F10= High Performance Filter Installed(0:?,1:NO,2:YES,3:NA) 2c F11= Airflow Direction Settings(0:?,1:No Vanes,2:Vane #1 setting,3:Vane #2 setting) 30 F12= ? 34 F13= ? 38 F14= ? 5c F23= Airflow Oscillate Mode (0:?,1:NA,2:Supported,3:NA) 60 F24= Heating Mode Temperature Offset(0:?,1:ON,2:OFF,3:NA) 64 F25= Thermal Off Fan Operation (Heat Mode)(0:?,1:ExtraLow,2:Stop,3:Selectable) 68 F26= ? 6c F27= Thermal Off Fan Operation (Cool Mode)(0:?,1:Selectable,2:Stop,3:NA) 70 F28= Display System Error (0:?,1:ON,2:OFF,3:NA) 00 EOT

I pulled these while the Unit was off. So in my case all have value Zero. I will when I have time again, see what they are when the unit is on. Thanks to @goosfand:matrix.org for Finding out what mkh1 sends in order to get these numbers

To set. you would send (excludes FC and chksum byte) 41 01 30 10 1F (first set of 14) 61 01 30 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 5E (responds to confirm accepted) 41 01 30 10 21 (Second set of 14) 61 01 30 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 5E (responds to confirm accepted)

So say you wanted to just change function 27 to STOP then you would send all of the same packets back, but have byte representing F27 set Example based on my OFF state(Don't send as I am still figuring it out) 41 01 30 10 21 1c 20 24 28 2c 30 34 38 5c 60 64 68 6e 70 00 As you can see what was previously 6c is now 6e 41 01 30 10 21 1c 20 24 28 2c 30 34 38 5c 60 64 68 6c 70 00 (no change) 41 01 30 10 21 1c 20 24 28 2c 30 34 38 5c 60 64 68 6e 70 00 (F27 changed to STOP)

Still a work in prog and need to confirm a few things first, but it looks promising

[akamali]

Thanks @SwiCago. Regarding functions 11 and 23, on air handles with back up heat strips they control how the strips function (refer to https://www.mitsubishitechinfo.ca/sites/default/files/SH_PVA-A12_42AA7_201812.pdf page 21), I've already tested this on my air handler:

11=1, 23=1: No backup strip present 11=2, 23=1: Strips are activated under low temperature conditions when heatpump cannot keep up (see page 21 for details) 11=2, 23=2: Strips are activated under low temperature and during defrost and error conditions

I also tested my air handler with packet 09/standby, this is what I'm seeing (this disagrees with the first post here). In all cases below my thermostat was set to heating mode. I'd have to wait until summer to test these when the unit is in cooling mode :-)

fc 62 01 30 10 09 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 (CHECKSUM): System is off

fc 62 01 30 10 09 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 (CHECKSUM): Standby/Stage 1, I can see the outdoor unit is not running.

fc 62 01 30 10 09 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 (CHECKSUM): Stage 2, outdoor unit is running

fc 62 01 30 10 09 00 00 00 03 00 00 00 00 00 00 00 00 00 00 00 (CHECKSUM): Stage 3, outdoor unit is running

fc 62 01 30 10 09 00 00 00 04 00 00 00 00 00 00 00 00 00 00 00 (CHECKSUM): Stage 4, outdoor unit is running, I noticed back up strips also came on after some time, back up strips need more testing

fc 62 01 30 10 09 00 00 04 01(/2/3/4) 00 00 00 00 00 00 00 00 00 00 00 (CHECKSUM): Preheating with all stages, I only see this after defrost or when first the unit comes on. I assume it's a warm up stage.

fc 62 01 30 10 09 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 (CHECKSUM): Defrost. What I see is from any heating stage the unit first goes to a compressor frequency of 0, then stage changes to defrost for 2-10 minutes or so, then to warm up and then to whatever heating stage that it was set to previously.

See sample capture:

2022-02-12T00:33:30.803: CompressorFrequency: 26
2022-02-12T00:33:36.276: CompressorFrequency: 28
2022-02-12T00:44:47.979: CompressorFrequency: 30
2022-02-12T00:44:53.493: CompressorFrequency: 8 
2022-02-12T00:44:58.979: CompressorFrequency: 4 (I'm guessing this went to 0 and back, reversing the direction)
2022-02-12T00:45:15.988: CompressorFrequency: 28
2022-02-12T00:45:23.724: StandBy: Defrost raw: 0 ArraySeq(9, 0, 0, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0)
2022-02-12T00:45:27.556: CompressorFrequency: 30
2022-02-12T00:45:33.047: CompressorFrequency: 32
2022-02-12T00:45:44.587: CompressorFrequency: 28
2022-02-12T00:46:41.207: CompressorFrequency: 37
2022-02-12T00:46:47.272: CompressorFrequency: 25
2022-02-12T00:46:52.771: CompressorFrequency: 5
2022-02-12T00:46:58.252: CompressorFrequency: 0 (reversing the direction again? back to heating)
2022-02-12T00:48:57.563: CompressorFrequency: 4
2022-02-12T00:49:03.611: CompressorFrequency: 14
2022-02-12T00:49:09.096: CompressorFrequency: 20
2022-02-12T00:49:14.588: CompressorFrequency: 34
2022-02-12T00:49:20.682: CompressorFrequency: 39
2022-02-12T00:49:37.243: StandBy: Stage1 raw: 1 ArraySeq(9, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0)
2022-02-12T00:49:37.713: CompressorFrequency: 43
2022-02-12T00:49:46.785: StandBy: Warmup raw: 1 ArraySeq(9, 0, 0, 4, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0)
2022-02-12T00:50:11.739: CompressorFrequency: 37
2022-02-12T00:50:21.919: StandBy: Warmup raw: 2 ArraySeq(9, 0, 0, 4, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0)
2022-02-12T00:50:22.719: CompressorFrequency: 39
2022-02-12T00:51:13.848: CompressorFrequency: 40
2022-02-12T00:51:19.912: CompressorFrequency: 41
2022-02-12T00:51:25.392: CompressorFrequency: 43
2022-02-12T00:52:30.789: StandBy: Stage2 raw: 2 ArraySeq(9, 0, 0, 0, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0)
2022-02-12T00:54:10.498: CompressorFrequency: 47
2022-02-12T00:57:29.702: CompressorFrequency: 48

[akamali]

Also, for what it is worth this document https://www.mitsubishitechinfo.ca/sites/default/files/IM_PVA_A12_42AA7_PA79D213H09.pdf lists the function codes for PVA air handlers, page 22:

01/101: Power failure auto restart 02/?: Indoor temperature detecting (indoor unit, indoor unit's controller, remote controller) 03/103: LOSSNAY connectivity 04/104: Power Voltage 07/107: Filter sign 08/108: External static pressure 10/110: External static pressure 16/116: Humidifier control 13/113: Humidifier present 11/111: Heater present 23/123: Heater during defrost and error 25/125: Fan speed when heating is off 27/127: Fan speed when cooling is off

[luiscgalo]

Hi everyone,

Very nice information provided regarding function settings change via CN105 link!

To be honest I was not able to move forward with investigation due to lack of time and because I don't have a controller such MHK1 that is able to change those settings via CN105 so that I can capture the exchanged packets.

However, based on your captured data I will try to make some experiments soon...

We keep in touch.

[SwiCago]

So my initial tests show that Attic units accept commands that mhk1 would send, but high-wall units ignore them and return values of 0 for all functions. Fan shut off for cooling would have been nice on high-walls, since the only way to turn off the fan is by turning of the unit.

[kelchm]

So my initial tests show that Attic units accept commands that mhk1 would send, but high-wall units ignore them and return values of 0 for all functions. Fan shut off for cooling would have been nice on high-walls, since the only way to turn off the fan is by turning of the unit.

There are actually jumpers on the main board for the wall units that can be cut to turn the fan off automatically when the setpoint is reached. See application note 3048 on my link drive.

[BunpGhost]

Hi Folks, First of all thanks for all your hard work getting this up and running. I've got some parts on order so going to try and set this up on some ceiling units next week. Just got to find where that pesky connector is first.

It looks like there's another github repo at m000c400/Mitsubishi-CN105-Protocol-Decode that's had a fair bit of work in decoding some of the packet types, including some of the ones this issue was originally raised for. Might be worth a look to see if it has anything useful that could be added to the library?

Hi @SwiCago, just recently joined in. Read the whole thread. I'm very interested in the Energy management part. Did you get a chance to test if the Power (Kw) or Consumed Energy are possible to obtain? I know that personally you do not care for the energy stats and in a way you are right but for me it would be great to match against solar energy production and try to be more efficient. Thanks in advance.

[matthandel]

Hey all, first of all thanks so much for creating this library. I've been using it with my Mitsubishi split systems for many months now without issue. For the record, the model numbers of those units are MSZ-AP50VGD and MSZ-AP71VGD. If you want to add them to the supported models list, they work perfectly with this library.

A few days ago I got a Mitsubishi 4-zone ducted AC system installed in the attic. This is quite different to the regular split systems, but uses the same connector as the CN105 that's present in the split systems. I was glad to find that the HeatPump library is mostly compatible with this system too, but lacks the ability to control the individual zones. After some experimenting I was able to find the right commands to control the zones so I thought I'd share the info here.

The unit in question is a PAC-ZC40L-E Zone Controller. It's basically a standalone circuit board in a box which acts as a front end, sending commands to a separate heat pump unit (a PEAD-M71JAAD unit) to control fan and compressor functions, and it has individual cables connected to actuators in the ducts to open and close individual zones. The unit I have is a 4 zone unit, but there are near-identical units that can control up to 8 zones.

Obviously with a ducted system there are no vane or swing settings, but the on/off, mode selection, fan speed and temperature controls of the HeatPump library all work straight out of the box.

The command type to open and close individual zone ducts is 0x15. Here is working code that prepares the packet correctly to control individual zone actuators:

  // Note: zoneNumber is zero-based for this code
  byte packet[PACKET_LEN] = {};
  prepareSetPacket(packet, PACKET_LEN);
  packet[5] = 0x15;
  packet[6] = 1 << zoneNumber;
  packet[8 + zoneNumber] = zoneActive ? 1 : 0;
  packet[21] = checkSum(packet, 21);

Reading back the zones is very similar, the packet type is 0x15. To get regular updates for the active zones I just appended the value 0x15 to the end of the INFOMODE array, then added another case statement in the readPacket method:

  case 0x15: {
    for (int i = 0; i < 8; i++) {
      zoneState[i] = data[i+3];
    }
    break;
  }

For my use case I've basically just added 2 new methods to the HeatPump class: getZoneState and setZoneState. I'm using this library to integrate with ESPHome, which in turn integrates with Home Assistant. I also modified that library to expose the getZoneState and setZoneState methods, then I use a template switch with a custom lambda snippet in the ESPHome YAML file to create toggles for each of the zones.

ESPHome YAML excerpt:

switch:
  - platform: template
    name: AC Vent Master Bedroom
    lambda: return id(climate_upstairs_ac).getZoneState(1);
    turn_on_action:
    - lambda: id(climate_upstairs_ac).setZoneState(1, true);
    turn_off_action:
    - lambda: id(climate_upstairs_ac).setZoneState(1, false);

The end result in Home Assistant looks like this:

Not sure how many people this will help as searching online turned up nothing, but since my trial and error ended up working out well I thought I'd share this here. I might submit a PR if there's any interest. This at least can serve as a record of command type 0x15 which is currently listed as unknown in the Mitsubishi-CN105-Protocol-Decode repo.

[fastbike]

Interesting work. I do not have a multiroom unit, but appreciate the work that you've put into extending this library for others to use :)

[SwiCago]

@matthandel , I know you posted the zone vent code a while back. Do you you think you can add the code to the library via a PULL and I can review it and merge it. It might be a help for others with an attic unit that uses Zoned vents.

[disruptivepatternmaterial]

Just sharing that I hooked up a kumo adapter (that was on a small AP I made just for this) and I have a Saleae logic analyzer that I put on the gnd, tx, rx and parsed the sentences. You can see my raw info here https://github.com/echavet/MitsubishiCN105ESPHome/wiki/Dictionary-of-Messages-on-CN105-Serial working on organizing it and making sense of it. Much like the work done here there the main commands (byte 5) are similar to what others have found, but the extra settings I am seeing are different.

[KazWolfe]

In the interest of keeping everything combined (and since I think we're doing work in multiple places), I do want to raise that Sammy1am's GitHub repo also has an active wiki of information and packet captures.

The Gitter (and Sammy's Discord) also contain some extra information sources as well as some more esoteric data sources that may be of value for future projects.