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?