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]

@kayno i think you have misunderstood. I have a 6 zone (split) setup. 4 wall units and two in attic ducted units. 1 outdoor compressor. All the units have their own temperature sensors, but ducted units wil be obviously off due to what ever temperature the attic has. Using a external (not exterior) temperature sensor, allows the unit to know what the actual room temperature is. Also a high wall unit may not be accurate either, depending on how tall the room is. The difference could be as much as 2 degrees from floor to ceiling. Using an external sensor would place the temperature sensor closer to where people would actually be and not where the unit is Or as @schotime mentions, the area where the heat pump had to be installed may not be ideal and is cooled or heated fast, thus keeping the other areas of the given area from reaching the wanted temperature. Placing the remote sensor in the larger area makes most sense...windows can also be a factor. A unit above windows could be also inaccurate. Now that this new setting has been discovererd I will no longer have to turn my attic units on/off via remote sensor, but rather can let the unit decide what is best based on transmitted remote temperature sensor.

Note:since the ducted units have no remote or controller on their own, mitsubishi sells expensive accessories for them. The MKH1 is a 250$ accessory. The kumo cloud is 180$, but has no external temp sensor of its own, meaning the ducted unit would use it's inaccurate sensors. They have a offset setting i the app, but that wont be accurate either, it is just a bandaid fix

[lekobob]

@SwiCago Because the manual mentions that if the MHK1 ever looses signal it will revert to the internal temp, I assume if you stop sending external temp packets it will automatically revert to internal temp. Mine just starts sending the packet with 80 in it when I change the setting in the MHK1 to use internal temp. Notice though that byte 6 (or control byte) is 00 so it is saying "I am setting nothing".

I made a screen cap of what the stream between the MHK1 and the heat pump looks like. https://youtu.be/cRFqmeP7KaQ The only other packet I have seen is a Setting Set packet when I change a setting like Mode or the setpoint temp.

[SwiCago]

@lekobob, i tried that. I let it not send for 20min, it still sent back the last sent temp. It only went back when i removed the esp8266! I know this because the first few temp pakets were from hp, but shortly after it started reporting back the last sent temp of external. Power cycle or the special packet i sent made it revert.

I think the revert is just temporary unless power loss or special packet sent.

[lekobob]

@SwiCago when I have a chance I will pull the batteries from the thermostat and see if the receiver sends anything new to the unit.

[lekobob]

@SwiCago If I just pull the batteries from the thermostat the receiver sends that same 80 packet to the unit. fc,41,01,30,10,07,00,00,80,00,00,00,00,00,00,00,00,00,00,00,00,f7

[lekobob]

@SwiCago I am thinking about using multiple sensors in a room (all esp8266-01 in a little wall wart package) and averaging them to send back to the unit.

[SwiCago]

@lekebob, when i get a chance tonight, i'll see if sending 0x80 0°C reverts and stays reverted... I think it is temporary, until it gets real data again. I wouldnt want the library to have to keep sending 0x80, i rather it sends a signle once to revert. And yes multiple esp-01 with humidity temp sensor is the best way to go. Small and indescreet sensors, instead of huge ugly thermostats

[SwiCago]

Off subject @lekobob, I saw in supported units you mention North America. Where are you in exactly? I'm in Chicago. Would be funny if you were close by.

@lekobob Just tried sending fc 41 01 30 10 07 01 00 80 00 00 00 00 00 00 00 00 00 00 00 00 f6 and this is the response fc 62 01 30 10 03 00 00 0f 00 01 b2 80 fe 00 00 00 00 00 00 00 1a sent it again and the response is fc 62 01 30 10 03 00 00 00 00 01 80 80 fe 00 00 00 00 00 00 00 5b

Then tried the packet you said it sent, which doesn't seem to be setting any control byte value, just 0°C temp, I was surprised that this is a valid value for reset fc 41 01 30 10 07 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00 f7 Then for shits and giggles I also tried sending the same without any values and to my surprise it works as well, so why does mitsu send 80 when it bares no meaning. fc 41 01 30 10 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 77 The following also works, as I have mentioned above fc 41 01 30 10 07 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 75 and fc 41 01 30 10 07 02 00 00 01 00 00 00 00 00 00 00 00 00 00 00 74

I updated my test branch to mimic what MHK1 does instead. Passing the 80 packet once is enough to revert, so no need to do it repeatedly

[lekobob]

@SwiCago I am in Las Vegas. You should say hi if you ever com this way. I hear it is a fun place to visit.

[SwiCago]

@lekobob LOL I was out there 2 xmas' ago..My brother lives in North LasVegas I used to live in So.Cal so I am familiar with Vegas ;)

Anyhow, I updated my test branch, can you see if it works for you too. And then I'll merge into master. @kayno, I didn't do anything in constants for this. Want you to review this and get your suggestions.

[SwiCago]

@lekobob do you know of a wall wart project box that would be a good fit? I have not found any online yet. Still looking.

[lekobob]

@SwiCago https://www.itead.cc/smart-home/smart-socket.html might me be a good place to start.

[SwiCago]

@lekobob, so you are planning to gut/reuse an existing wall wart device. Hmmm maybe use one that has esp8266 built in and just add temp sensor

[lekobob]

@SwiCago Found this https://www.polycase.com/gs-2415 and https://www.itead.cc/sonoff-sc.html too.

[SwiCago]

@lekobob that first looks usable, but not when outlets are not high enough from the ground. The second "sonoff" one may work, but they are using the ESP8266 with a ATMEGA. I found the source code page for the ATMEGA and it is using AT commands, so it looks like the ESP is only used as WIFI dongle and all sensors are connected to ATMEGA. The ATMEGA code is a .ino file, so it could be modified and there is instructions on how to re-flash with custom code. Also uses DHT11 and not DHT22 and a bunch of other sensors I wouldn't need making the packaging bulky. A small disc would have looked better. But then again, seems to have a hacker following and some peeps already did MQTT and OTA for it and replaced dht11 with dht22 Update: the sonoff is out of stock...

[SwiCago]

@lekobob, here is an idea for a sleek hidden box. A faux candle. Modify the base to fit ESP8266 and DHT22. The battery compartment could easily house electronics. Some larger ones have enough space w/o modifying battery compartment. Some dremmel trimming in back, so DHT22 can breath and a little trimming for micro USB port(for power)... Looks like a lot of space in them https://www.youtube.com/watch?v=XM1c9Ny3X8E

[lekobob]

@SwiCago @kayno I disconnected the s3 (communication) wire on one of my units today, it took probably 5 min of trying to operate this way but finally shut down and blinked the light. The 0x04 packet returned: fc,62,01,30,10,04,00,00,01,68,40,46,00,00,00,00,00,00,00,00,00,6a Based on this That is a indoor/outdoor reception error. I think we can safely say it is an error packet. Just don't know what byte 11 is exactly.

[kayno]

@lekobob nice test! Would be good to create a .h file (I think that would be best way, but open to ideas) with all of the error code mappings in there, so that the library can report them if they ever happen. Then you could setup the likes of home-assistant.io to send a notification to your phone if they were to ever occur.

Also, nice find on that manual for the IntesisBox - could be quite useful!

edit: fixed salutation, sorry lekobob!

[SwiCago]

@lekobob, great job. @kayno, yes we should have a .h with all possible codes, based on the file lekebob linked. Kayno, I have looked at the document many times over, there is not much else in it that we don't already know and it also does not say which bytes or command sets are responsible for items listed. I just says how long each item is. 1bit, 1 byte, 2 bytes etc

[SwiCago]

@lekobob maybe the 11 byte is the page number in the repair manual ;) -JK

[SwiCago]

here is another pdf file that lists more codes and also cross references between unit types https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=4&ved=0ahUKEwjcp67r2MXSAhVK1oMKHdycA0MQFggtMAM&url=http%3A%2F%2Fwww.orionair.co.uk%2FPDF%2FMitsubishi_elec_Fault_codes.pdf&usg=AFQjCNG8xKAyIxPFq_L2sVmPHfekNd_FqQ&sig2=fSGukVvWYQJ-fpD48qRQ0g&cad=rja

Example: 6840 translates to E6/E8 fault code, which is either E6 Indoor/outdoor communication error, mainly caused by outdoor unit being powered up before indoor unit. Drain pump being wired into S1 and S2 causes interference or E8 Comms failure indoor to outdoor (S2/S3) - check pumps wired in, check indoor isolator and re-power in the correct sequence i.e. indoor then outdoor