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]

@lekobob @SwiCago clearly i need to get my eyes tested! Sorry @lekobob, nice test!!

@SwiCago can you create two wiki pages on this repo please: "Related information" and "Supported models". That was we can add all the doco we have found that is related/helpful/etc to the first, and the models that have been submitted in #13 to the second. If you gave me access to edit them, I'd be happy to add what the stuff I have stumbled across and help maintain them...

[SwiCago]

@kayno I believe you got an evite to collaborate and the initial wiki is made

[kayno]

@SwiCago I did get the evite and I accepted - thanks!

[SwiCago]

We should create a wiki table with the byte layout of the settings and various return data sets. I am not very good with wiki, but when I get a chance I will update. Already updated supported devices and updated readme to link it

[kayno]

i can sort out the markup for tables. would be good to come up with some standard names for "packet type", "control byte", "command type", etc

[SwiCago]

@kayno look at the wiki, I made a table to start us off...See if this makes sense

[kayno]

I did the same here: https://github.com/SwiCago/HeatPump/wiki/Mitsubishi-protocol

[kayno]

I used markup, you used HTML. I find markup tends to be easier - see what you think.

[SwiCago]

LOL, leave your page, makes sense to document it separately...but see if you can add a header line like I did, below your 0-21 Yeah wiki markup is easier...I am not too familiar with it

[SwiCago]

A header like I have will make it easier to describe each Byte and what they do

[kayno]

I've tried going the other way (vertical) too. I think this page will be one that evolves into something great over the next few days, once we get all of the known packets in there, and work out the best layout along the way!

[SwiCago]

@kayno, what do you think about this naming Start, Set/Read, Hardcoded, Hardcoded, Hardcoded, Command, Control1, Control2, Data101, Data102, Data104, Data108, Data110, Data120, Data140, Data180, Data201, Data202, Data204, Data208, Data210, ChkSum

START = FC Set = 41 / Read = 42 Command = 01,07 for setting Command = 02, 03, 04, 05, 06, 09 Reading Control1,2 = DataXYY where X=control1 or 2, Y = the byte in ^2 representation ChkSum = FC - Sum of bytes

[lekobob]

@SwiCago @kayno Maybe we should start using this https://github.com/integrations/slack

[SwiCago]

@lekobob , not sure we are that big a team, that "issues" can't be used for chatting and throwing ideas out for now...

[SwiCago]

@kayno...byte 21 = chksum, not data

[kayno]

@lekobob Slack would be great to shift all of these conversations out of issues, great idea!

[SwiCago]

@kayno @lekobob, how do we setup up slack then?

[schotime]

Could just use gitter too. Easy with GitHub.

On 8 Mar 2017 1:20 PM, "SwiCago" notifications@github.com wrote:

@kayno https://github.com/kayno @lekobob https://github.com/lekobob, how do we setup up slake then?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/SwiCago/HeatPump/issues/39#issuecomment-284925920, or mute the thread https://github.com/notifications/unsubscribe-auth/AAMYqx_UCToLYes57NZNEsRC8cJ_83k2ks5rjhBdgaJpZM4MS7MZ .

[SwiCago]

@kayno, looked at your wiki. Isn't 41 set and response to set 61 and 42 read and response to read 62 ???

[kayno]

@SwiCago @schotime gitter might be better for me actually, but don't mind either way. @lekobob, do you have a preference?

@SwiCago feel free to switch around any typos you see too, I am trying to keep up :)

[SwiCago]

@lekobob @kayno @schotime I'm going to call it a night...the woman just got home, so need to spend time with her... Cheers mates

[lekobob]

@kayno Gitter looks like it is a little easier to understand. Thats fine with me.

[kayno]

@schotime @SwiCago @lekobob I've hooked up gitter for us to try out

[kayno]

gitter test comment

[SwiCago]

@lekobob did you ever get a chance to see what your MKH1 sends when setting timers?

[lekobob]

@SwiCago I did. The mhk1 uses an internal time and then sends the power off command. It does not send a timer set command.

[SwiCago]

@lekobob figures...probably better the external unit says what time to go into what mode, then the unit itself LOL

[lekobob]

I think I found one more bit of information the indoor unit returns. In the 0x06 return packet, byte 8 seems to be compressor frequency. It returns a value when any of my three units are operating. If you convert it to decimal it is between 0 and 58. Since we have been around 117deg F in Vegas this week I have seen my unit operate at full blast with 58 returned in that value. Right now I only have an esp8266 on one of my indoor units, can anyone confirm that all indoor units on the same outdoor unit return the same value in that byte?

[SwiCago]

@lekobob i am making new adapters with cases for all my units, when I am done I'll check debug output and verifynif what you described is what I see on my units

[SwiCago]

@lekobob I would like to revisit this error packet real quick again We know that the below is No errors, normal operation fc 62 01 30 10 04 00 00 00 80 00 00 00 00 00 00 00 00 00 00 00 d9 You once posted, 6840 E6/E8 fault code fc 62 01 30 10 04 00 00 01 68 40 46 00 00 00 00 00 00 00 00 00 6a I wonder if byte 8(starting from 0) is the number of codes stored or the number of times it has been thrown or just an indicator that an error has occurred(based on the PDF, I believe it is the last one) byte 9 and 10 represent the error code thrown byte 11 may represent which HP it is in ascii? 46 = F or 6th unit. How many units do you have?

@lekobob @kayno So we know the following 0x02 - settings 0x03 - room temp 0x04 - error codes 0x05 - timers. Kayno "i'm still determining logic" 0x06 - per Kayno "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 - Stage info see below

lekebob 0x09 stage info "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"

Would be great if we can complete the library and maybe start on some code clean for efficiency and ease of reading. What do you guys think. I see the wiki never got far :(

[lekobob]

@SwiCago I am assuming byte 8 is to indicate that an error is thrown. Don't have much way of testing that any farther. I have 3 units. I think the one I tested was unit B. I bet byte 11 is some kind of sub code that Mitsubishi can use to troubleshoot deeper, they just have never shared that list with the outside world.

Couple things to add to the list:

0x06 byte 8 I am 90% positive it is compressor frequency. 0x09 byte 9 is fan speed. It steps up and down as the unit has to do more work when the fan is in auto and indicates the set speed when a speed is selected.

I have also made some changes on my own branch to wait for the ack (61 or 62) from the unit before sending the next packet. In that process I broke some things so I never bothered creating a PR for it. I created a branch on my repo here: https://github.com/lekobob/HeatPump/tree/ackwait-test

[plambrechtsen]

I've been pointed here by Al so I purchase a 558e legacy wifi adapter and have been sniffing the traffic. It base64 encodes a blob of data and then has a large XML document. I think I have figured out what the outdoor temperature is and it's in group 03 byte 06 When the outdoor fan isn't running you get a 01 in fc62013010 030000090001a6a6fe0000000000000006

As per the XML in the payload it phones home to Mitsubishi every minute on the api.melview.net end point

03012018/11/28 19:01:24fc62013010030000090001a6a6fe0000000000000006

When the fan is running I see the outdoor temp on the app on my phone as 12 Degrees

fc620130100300000800 98 a5a4fe0000000000000073 98 = (152 - 128) / 2 = 12C and fc620130100300000700 9a a2a2fe0000000000000077 9a = (154 - 128) / 2 = 13C

Even though it's divide by two I never see the .5 degrees, so there hasn't been a 99 or 9b, only 98 and 9a. Got up to 27 yesterday outside so it went to b6.

My heat pump is a recent model high-wall Ecocore "GL" series so who knows if the older model outdoor units have the temperature sensor or not. But I will keep on investigating the XML payload responses and control messages.

[plambrechtsen]

The other interesting thing is the "PROFILECODE" sections in the XML payload. I think it's the serial number / hardware info on the heatpump as the values are static. There is a C9 and CD. values

C93a30300010c9..... CDfc7b013010cd... Not sure if anyone has looked into those values to see if there is anything interesting or not. As it may indicate the serial number? Tail end of it from the group C9 is "a0bea0bea0be" for me, then CD starts with "a0bea0bea0be" so I would assume "be" is a separator and a0 is just empty value?

[SwiCago]

Hi Peter @plambrechtsen , great to see you here. As per email, that is a neat discovery. I will recheck mine with them running. I never run them in the winter, only use them to pull room temperature for my hydronic heat. I will confirm if the value differs from 0x01 after running for a while. Not sure if outdoor temp is of any use for anyone, when it only reports while running. But still a neat discovery.

[SwiCago]

@plambrechtsen , had a chance to run the HPs and watch debug packets. My units always shows 01 for that packet, in which you say is exterior temperature. Maybe it is only supported by specific models. Maybe some others can try their HPs and see. In anycase, it is useless if it is not reported at all times(as in only while running).

[luiscgalo]

Hi all, Following SwiCago's suggestion, it is better to move the topic I introduced yesterday on Issue 126 to this thread.

I'm already using the CN105 protocol with success on PEAD-M140JA ducted units.

However, I was wondering the possibility of changing the named "Function Settings" or "Installer Settings" that are stored on internal memory of AC indoor unit.

The "Function Settings" are advanced technical parameters that can be changed to fine tune operation of the AC unit. As example, it is possible to change the behaviour of indoor fan when setpoint temperature is reached (for cooling and heating modes), selection of temperature sensor in use, lock functionalities of wired controllers, static pressure selection for ducted systems (performance of indoor fan), power loss auto recovery, etc.

Usually, those settings are managed within service menu of an wired controller such as PAR-31MAA (which I have in my system and it is presents something similar to the picture below)

However, according to specifications, it seems to be possible to change those settings also on the MHK1 controller that is connected via CN105 port (serial interface).

The following link shows brief instructions about how to change indoor fan behaviour via "Function Settings" on the MHK1 controller: https://www.greenbuildingadvisor.com/question/mitsubishi-minisplit-secret-advanced-settings

The following PDF file (Mitsubishi's Installation Manual) lists the available settings in "Installer setup tables" at page 6. remote-controller-function-settings.pdf

Please note that, like I said before, the referred settings are stored on the AC unit itself (not on the remote controller!) It means that serial communication in CN105 must be exchanged between MHK1 and the AC unit.

There is also the following warning stating that reading/writing "Function Settings" takes several seconds. This happens because of the serial data communication which is slow.

In PAR-31MAA controller that I have (I know that it is using another interface, not the CN105) I see exactly the same behaviour. It takes about half a minute to load or store modifications of "Function Settings". It also displays text messages on the display stating: "Loading settings from AC unit" / "Transmitting settings to AC unit..."

Based on this, I'm interested in understanding which data is exchanged on the CN105 serial bus when "Function Settings" are read/written.

The problem is that I don't have an MHK1 controller in my hand to experiment this... Does anyone tried to change "Function Settings" via MHK1 controller? For who has an MHK1, there is any chance of capturing some packets exchanged on the serial interface when "Function Settings" are read/written so we can analyse them?

Thanks in advance for your help. ;)

[SwiCago]

@lekobob you have/had a mhk1, maybe you can chime in?

[luiscgalo]

Hi again everybody. Probably all members in this topic are quite busy...

Anyway, if anyone with an MHK1 controller has a chance of recording packets exchanged in CN105 when reading/writing "Function Settings" I will appreciate that.

Thanks again in advance for your help...

[SwiCago]

@luiscgalo , the only person I know that has a mhk1 is @lekobob and it seems he is no longer active. You best bet is to get your own mhk1 and try to dump the packets. Then when you have figured them out, sell the mhk1 to recover the cost.

[plambrechtsen]

If you had two CN105 I have seen with the MAC-558IF-E I get all the commands that were executed by the heatpump using the infrared remote. Otherwise I can try reconfiguring my home heatpump as the PEAD-M140JA and see what the official app + wifi controller sends to the heatpump.

[SwiCago]

@plambrechtsen the packets he is after, do not exist via IR or via official wifi device and app. I have already dumped everything that the official device can give us. In theory the things he is after could be simulated software side, such as reduce fan speed once temperature is reached or make virtual setpoints. Such as if someone wants 24C for heat, shutoff at 25 or 26 and turn one at 23 or even 22. That in thoery does not need to be programmed into the HP, it can be done via software. But other things such as static pressure cannot be simulated. Hence why he is after those packets. He believes the mhk1 controller can do this and that is why someone with one needs to confirm or he needs to pony up and buy one.

[luiscgalo]

Hi all, Thanks for your comments.

Indeed there are some features that cannot set via IR commands such as setting the static pressure (indoor fan performance), locking of wired controller functions or ventilation air setting (these are just 3 examples).

The problem if that the MHK1 is an expensive device and is not sold in Europe (I'm from Portugal). If I purchase that expensive device I'm sure that I will have to pay the controller itself plus huge importation taxes... That's why I'm kindly ask for someone that already has an MHK1 controller to capture serial packets exchanged.

[kelchm]

@luiscgalo, I have MHK1s for my system and will plan on doing the packet capture for the installer setup in the coming weeks.

Is there anything specific you'd like me to capture other than what toggling setup function 108 (which control the external static pressure setting for air handlers)?

[luiscgalo]

Hello @kelchm , Thanks in advance for your help by capturing the communication exchanged with MHK1 controller. It will very nice to understand how to read/write advanced settings from/to the indoor units.

Since I don't have access to an MHK1 controller, I have the following questions:

1. Can the "Function Settings" been changed (read or written) when the indoor unit is in operation? I'm asking this because, with the PAR-31MAA controller, those settings can only be acessed when the indoor unit is turned OFF (with electric power but not in operation).

2. What is the sequence of the commands exchanged in the CN105 bus to read "Function Settings" from the indoor unit? (maybe you can paste here the raw TX/RX packets captures from the serial lines)

3. What is the sequence of the commands exchanged in the CN105 bus to write "Function Settings" to the indoor unit? (maybe you can paste here the raw TX/RX packets captures from the serial lines)

4. Is the MHK1 sending multiple individual commands, one per "Function Setting" to retrieve the overall status of the indoor unit? (multiple requests or a single request from the MHK1?)

5. How are the "Function Settings" values encoded on the CN105 serial packets?

6. Regarding the interesting "Function Settings" to be "sniffed", I propose the following ones to start with:

   • 101 -> Unit automatically restarts after power outage
   • 125 -> Thermal Off Fan (Heat Mode)
   • 127 -> Thermal Off Fan (Cool Mode) I'm assuming that the serial data format exchanged on the CN105 bus should be quite similar, no matter which "Function Setting" we are trying to read or write (probably there is a specific byte where the "Function Setting" code is encoded and the remaining bytes have the same meaning...)

I think that by clarifying the topics above we have everything needed to be able to read and write "Function Settings" on Mitsubishi Electric CN105 compatible units :)

Thanks again for offering your help to understand this functionality. If you need any help from my side, please let me know.

[kelchm]

@luiscgalo

Thanks again for offering your help to understand this functionality. If you need any help from my side, please let me know.

One area I could use some guidance on is how to actually go about doing the serial capture. I have a Siglent SDS1104X-E oscilloscope which is capable of doing serial decoding. Is this my best bet, or is there another approach I should be looking into?

[luiscgalo]

Sure, your oscilloscope seems to be more than enough to capture the serial packets.

My suggestion is that you establish the standard electrical connection between the indoor unit and your MHK1 controller via CN105 connector, intercepting the communication lines of the bus.

You only need to intercept 3 wires in order to capture the data exchanged (see image below which presents the pinout of CN105 connector within indoor ac unit):

• Pin 2 -> Ground connection
• Pin 4 -> TX (data sent from indoor unit to MHK1)
• Pin 5 -> RX (data traveling from MHK1 to indoor unit)

You could use two oscilloscope channels, one for TX other for RX, in order to simultaneously capture commands and responses between devices.

Regarding serial decoding settings, it should be a standard 5V TTL UART running at 2400 bps with even parity. Let me know if you need further guidance on this...

[SwiCago]

@kelchm, good luck. If you do happen to actually have clean packet capture, do post each one here for analysis and maybe I will be able to add them to the library. We do have some prior captures that we have no idea what they are, so maybe your captures in combo with mkh1 will resolve those. Best going forward is to do one setting at a time multiple times in a row and catch what is sent and received. Note these. You can then later review the packets and see the ones that are all the same for a set and that will help weed out from statndard packets, such as current temp....then go on to next set, etc. Dump to pc or usb of you can, it will make it easier. Cheers

[unixko]

@SwiCago if you are going to enhance library could you please also add 0x09 byte 10?

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

It helps report status when integration with HA. Thank you.

[dzungpv]

@SwiCago so we can add hvac action support like: cooling or heating with data reading from Byte 10, or use HA Heat/Cool mode mention here https://github.com/SwiCago/HeatPump/issues/138#issuecomment-533201557

[SwiCago]

@dzungpv don't really know who would ever use mode AUTO, in an automation scenario. The whole point of automation is having the automation decide what is the best mode and setting to use, based on variables unknown to the HP. Setting it in auto, then there is no point in using automation, might as well set it to auto and set temperature to your desired setting and just let HP do its thing. But I will think about it, if more people show more interest in it. My question would be, should HP return mode of what is being reported by auto or send back mode AUTO and have autoMode as an extra json attribute?