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.

[kayno]

I've been sending custom packets too, and found similar. I have a branch with some of this that I need to push up once I merge in latest master, which I will try and get up today.

[kayno]

I've found that it responds to the following "command types" or "info types" (whatever we want to call byte 5!):

• 0x02 - settings (we knew this)
• 0x03 - room temp (we knew this)
• 0x04 - not sure what, but it responds
• 0x05 - timers. i'm still determining logic
• 0x06 - i think this includes "operating" status in byte 9, i.e. matches the "operation indicator lamp" on the heatpump, and is 0x00 if the heatpump is "ON" but the room has reached the desired temperature and the heatpump isn't "operating"
• 0x09 - I've noticed it change similar to you, @lekobob, but I am yet to determine what it all means

I have not been able to find powerful, long or isave mode, however I think iSave is really just a saved set of settings so I doubt anything will be in the packets.

I've tried command bytes from 0x00 to 0x1f and only the bytes above responded on my heatpump.

I have a commit here that checks all 6 of the bytes, and actions the "operating" status byte (command 0x06, byte 9). This commit also changes how roomTemperature is handled - I have put it, along with the new "operating" status into a new struct called "heatpumpStatus". This will allow us to add timers and other "status" type info without having to add callbacks for each different status when it changes. I'd like to eventually deprecate the callback for roomTemperature change as it's now covered by the new status changed callback.

I will get timer info sorted next, and prepare a PR.

[SwiCago]

@kayno @lekobob, great progres guys..soon we will know then the mitsu devs lol
In kumo cloud, it also periodically sent 0x09 and 0x05...but i didn't see it send stuff based on that info

[SwiCago]

@kayno, so the timer bytes are only for reading right now? No setters yet?

[kayno]

@SwiCago yes only reading. I am looking at setting now, but not sure where to start! The "command" (5th bytes) packets don't match for settings, i.e. when you read settings it's 0x02, but when you write settings it's 0x01. If that had been the same, then it would be logical to assume you would just set it the same to match between getting and setting.

So the dilemma I see - if I just start randomly setting the command byte and passing in timer data in the bytes where it's read, I might inadvertently set something else, and who knows what. It could have test modes, maintenance modes, all kinds of things that I may not what to activate!!

[lekobob]

@kayno @SwiCago I can probably help with that. The MHK1 can set on/off times. That was next on my list to look at.

[SwiCago]

@kayno yes, that might be the case, however powering off for 15min will clear any lock out settings/modes...i locked myself out of one of my units. Turned the power off, next day all was good again.
@lekobob does mhk1 use cn105 or one of the other ports? Different port may have different protocol, but would still be interesting to see what it sends. Kumo cloud blows, melcloud is the EU version and its app can do much more.
I'll check kumo cloud again tonight and see if it does in fact have a program mode. If it does, i'll do some packet dumps with my oscilloscope

[lekobob]

@SwiCago Yes it uses the cn105 port. From what I have seen so far is sends the same commands and uses the same responses that the library and Kumo cloud uses.

[kayno]

@lekobob I will wait until you capture what the MHK1 sends to set the timers then. Removes any risk of sending a bad packet!! thanks :)

[SwiCago]

@lekobob @kayno I just tried Kumo Cloud app again, it features programs for single zone and multiple zones. However I never saw it send anything to the kumo cloud device. I suspect it is stored on the cloud service and through periodically polling of the server, the device gets the command to set what ever the program was setup for. I did an event to turn on in fan mode, all it did as issue that command withing a few seconds of the set time. The MHK1 does not use internet, but it wouldn't surprise me if it just stores the events setup in its memory and not on the heatpump, like any other conventional thermostat would. But am eager to see what you see.
In all honesty, we don't really need the HeatPump to store events, as we can control them from any automation software.

[SwiCago]

@kayno, I think @lekobob deiscovered another Programming Setter Byte
We send the following when we want to set stuff
fc,41,01,30,10,01,CB,CB (CB == ControlByte)
His, when getting remote temperature setting pushed
fc,41,01,30,10,07,CB,CB
It looks like byte 6 is used for Command Set
we know byte 2 is 41 = set, 42 = get
And bytes 7 and 8 say what byte is being sent for the command set
Byte 6 must be a command set byte.
fc,41,01,30,10,07,01,00,ad,00,00,00,00,00,00,00,00,00,00,00,00,c9
Command set 0x07 byte 1 = set remote temperature, in the sample lekebob provided it was set as 0xad
It is possible other things could be sent via that command set byte, such as timers, powerful, iSee

The remote temperate is very helpful for the ducted units, as their internal sensors are not room temperature and pretty much useless. In winter, mine can read 10C as it is pretty cold in the attic, but room is much warmer. Now in theory we could support remote temperature sensors and MQTT could relay it to the HP

[SwiCago]

@lekobob, you could test your 0x05 theory by removing the comms wire from indoor to outdoor unit. It should throw 6840,6841,6844 or 6845

[lekobob]

@SwiCago When I have some time I was planning on doing that.
@kayno I am afraid @SwiCago is right. When I set an off time in the MHK1 it waits until the set time and sends the off command.

On another note, I watched the 0x06 type return packet and found that byte 8 seems to return either the coil temperature or the difference between return air and output air. I see if fluctuate up when the power output is higher and down when the power goes down.

[kayno]

@lekobob can you post the initial connect packet that the MHK1 sends please?

[SwiCago]

@lekobob, when the mhk1 sends the 0x07 + temperature, how do you get the hp to use internal temp again?
You mentioned info temp packet returns all 0x00, does it revert to hp temp sensors if removed? I wonder if it is just a matter of setting 0x07 + temp as 0x00 to get it to go back to internal sensors. Or just a time out of not receiving external temp sens data.
I like being able to use remote temp to control setpoints, but knowing running temp of ducted units in certain conditions can be helpful too.

[lekobob]

@SwiCago The MHK1 has a setting to change the sense location back to the indoor unit. When I change that setting the MHK1 sends:
fc,41,01,30,10,07,00,00,80,00,00,00,00,00,00,00,00,00,00,00,00,f7
every second instead of the one with the temp.
It mentions in the manual that if the MHK1 looses connection that the indoor unit will start sensing from its internal sensor automatically.
The indoor unit always send its return air temperature in the 0x03 packet even if it is getting an external temp in the 0x07 packet.

[lekobob]

@kayno
here is the initial connect exchange:
fc,5a,01,30,02,ca,01,a8
fc,7a,01,30,01,00,54
fc,5b,01,30,01,c9,aa
fc,7b,01,30,10,c9,03,00,20,00,14,07,75,0c,05,a0,be,94,be,a0,be,a9

[SwiCago]

@lekobob @kayno
I just tested the 0x07 remote temperature packets.
I discovered a few new things. If I set the temperature it is returned back via info 0x03 as lekebob discovered, however it is returned back as prior temp reading and current temp reading. Not sensor 1 and sensor 2 like we thought. I send the packet again and the prior becomes like the current. I send 0x00 and it reverts to internal sensors, where prior is what I sent manually and current is hp temp sensor, eventually both are the same again. So if we want current temp, we should be looking at second byte, not first
Actual room temp before sending remote temp
First 90 is prior reading and second 90 is current reading
fc 62 01 30 10 03 00 00 00 00 01 90 90 fe 00 00 00 00 00 00 00 3b

Sent
fc 41 01 30 10 07 01 00 ae 00 00 00 00 00 00 00 00 00 00 00 00 c8
Received
fc 62 01 30 10 03 00 00 00 00 01 90 ae fe 00 00 00 00 00 00 00 1d
Sent
fc 41 01 30 10 07 01 00 ae 00 00 00 00 00 00 00 00 00 00 00 00 c8
Received
fc 62 01 30 10 03 00 00 0d 00 01 ae ae fe 00 00 00 00 00 00 00 f2
Sent
fc 41 01 30 10 07 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 76
Received
fc 62 01 30 10 03 00 00 0d 00 01 ae 90 fe 00 00 00 00 00 00 00 10
And shortly there after
fc 62 01 30 10 03 00 00 00 00 01 90 90 fe 00 00 00 00 00 00 00 3b

So if I send a remote temp of 0x00, it reverts to what the HP reads, first temp byte is prior reading and second is current reading. And as lekebob mentions, it will revert back to internal sensors after a period of timeout.
Edit: it must be a pretty long time out, to revert on own. I disconnected the ESP for a few minutes and when I connected it, it was still returning what I sent it as current room temp. But again, with 0x00 sent it will automatically revert to internal temp ASAP
EDIT2: setting 0x00 does not make it revert to internal temp sensors, but rather spits out the lowest temp it could read 8°C = 0x90
So I guess that means, the only way to get it to revert back at the moment is to disconnect from HP for a certain time or power cycle

[SwiCago]

@kayno @lekobob, not sure of the best way to incorporate sending Remote Temperature to the HeatPump, as it would require byte 6 to be changed from 0x01 to 0x07...And as lekebob said it returns the change on info Temp 0x03, which does not necessarily mean remote temp sensor. Also, since this is not a wanted setting, it should not be part of that struct.
I would like to add this feature, but don't quite see a good way to do it. Any suggestions?

[SwiCago]

@kayno @lekobob, I made a first version of setting remote Temperature via the MQTT sketch.
Set remote temp sensor value
mosquitto_pub -h localhost -p 1883 -t 'heatpump/set' -m '{"remoteTemp":21}'
revert back to HeatPump temp sensors (EDIT, this does not revert, just sets to 0x90)
mosquitto_pub -h localhost -p 1883 -t 'heatpump/set' -m '{"remoteTemp":0}'
This is my test branch only, as again I am not sure if this is the best way to have this in the library. It was more of a "it works " concept.

EDIT: setting value to 0x00, does not make it revert. It defaults to 8°C = 0x90, so far only a power cycle or loss of connection makes it revert. NOt sure if there is a magic byte to make it read internal sensors again. I guess in theory it wouldn't expect that, as when something sends temp data, it expects it to always send temp data. So a timeout of sorts or power cycle would make it revert.

https://github.com/SwiCago/HeatPump/tree/testing

[SwiCago]

@lekobob @kayno Got it, if I send
fc 41 01 30 10 07 02 00 00 01 00 00 00 00 00 00 00 00 00 00 00 74
it reverts

So to set remote temp, you send
fc 41 01 30 10 07 01 00 TT 00 00 00 00 00 00 00 00 00 00 00 00 76
and to revert both values asap
fc 41 01 30 10 07 02 00 00 01 00 00 00 00 00 00 00 00 00 00 00 74
and to revert one value and let it update on its own
fc 41 01 30 10 07 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 75

I am updating my test branch
Edit: Updated test branch

[schotime]

What is this remote temp about?

[SwiCago]

@schotime it lets you use a remote temperature, instead of HeatPump internal sensor
If you have a ducted unit, the temp could be off by 10°C or more if in attic during summer heat.
Using a remote temp sensor tells the heat pump what the room temp is, so it can decided if it should cool or not on its own.

[schotime]

I see. That's pretty cool.

[SwiCago]

@lekobob figured out how to turn it on, and I just figured out how to turn it back off again.
Could be useful when you want to use a remote temp sensor and then it's battery goes out or it stops sending updates. This can allow for the controller to revert back to internal sensors without power cycle or removing of controller.
Edit: 0x01, resets both prior and current asap with HP current temp. 0x00 reverts to HP setting current and then later prior. Revised test branch to do 0x00 model. Interesting that it has different variations though

[kayno]

@lekobob thanks for the connect packets. I had a theory that maybe 0x07 would appear in there, but not to be. Interesting that it sends two different short connect packets, and that it also gets a short 0x7a reply (I am assuming that the 4 packets are sent, received, sent, received?)

[SwiCago]

@lekobob i didnt see your edit where you mention 0x80 being sent to use internal sensor. I saw you mention it was sent every second. What happens if it stops sending 0x80, does it stay reverted to internal sensors? I'll have to try that out as well and send 0x80 just once and see if it stays reverted. If not, I know the signal i found reverts it. 0x80 is 0°C, which would be an invalid value...maybè it does that on purpose, so internal sensors are used, until it sends a valid value??? In any case very interesting stuff we are discovering here

[kayno]

given my unit is (what we call here) a "split system" (outdoor compressor unit, indoor wall mounted head unit) I haven't given much thought to using an external source for room temperature. However with just a little thought, I am surprised that the ducted units would actually use the temperature of wherever the compressor unit is installed (e.g. an attic) to moderate their operation! Surely they would ALWAYS use a sensor that was in a room being heated/cooled? What am I overlooking here!?

[schotime]

Sometimes where that sensor is placed can be cooled quicker than other parts of the house so you may want to set the temp to somewhere else.

[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 <#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.