KUMO Cloud DUMP

[SwiCago]

Here is what KUMO CLOUD sends for each mode FC,42,01,30,10,02,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,7B =>INFO FC,42,01,30,10,03,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,7A =>INFO_TEMP FC,42,01,30,10,04,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,79 => ??? FC,42,01,30,10,09,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,74 => ??? TP=Type,pw=power,md=mode,fs=fanSpeed,vv=vane,tF=temp FC,42,01,30,10,- -,TP,00,pw,md,00,fs,vv,00,00,00,00,00,00,tF,00,CHK FC,41,01,30,10,01,07,00,01,02,00,00,00,00,00,00,00,00,00,A8,00,CB => DRY FC,41,01,30,10,01,03,00,01,07,00,00,00,00,00,00,00,00,00,80,00,F2 => FAN FC,41,01,30,10,01,07,00,01,01,00,00,00,00,00,00,00,00,00,A8,00,CC => HEAT FC,41,01,30,10,01,07,00,01,03,00,00,00,00,00,00,00,00,00,A8,00,CA =>COOL FC,41,01,30,10,01,05,00,00,00,00,00,00,00,00,00,00,00,00,A8,00,D0 => OFF FC,41,01,30,10,01,08,00,00,00,00,01,00,00,00,00,00,00,00,80,00,F4 =>FANQuiet FC,41,01,30,10,01,08,00,00,00,00,02,00,00,00,00,00,00,00,80,00,F3 =>FAN1 FC,41,01,30,10,01,08,00,00,00,00,03,00,00,00,00,00,00,00,80,00,F2 =>FAN2 FC,41,01,30,10,01,08,00,00,00,00,05,00,00,00,00,00,00,00,80,00,F0 =>FAN3 FC,41,01,30,10,01,08,00,00,00,00,06,00,00,00,00,00,00,00,80,00,EF =>FAN4 FC,41,01,30,10,01,08,00,00,00,00,00,00,00,00,00,00,00,00,80,00,F5 =>FANAuto FC,41,01,30,10,01,10,00,00,00,00,00,00,00,00,00,00,00,00,80,00,ED => VANEAuto FC,41,01,30,10,01,10,00,00,00,00,00,01,00,00,00,00,00,00,80,00,EC => VANE1 FC,41,01,30,10,01,10,00,00,00,00,00,02,00,00,00,00,00,00,80,00,EB => VANE2 FC,41,01,30,10,01,10,00,00,00,00,00,03,00,00,00,00,00,00,80,00,EB => VANE3 FC,41,01,30,10,01,10,00,00,00,00,00,04,00,00,00,00,00,00,80,00,E9 => VANE4 FC,41,01,30,10,01,10,00,00,00,00,00,05,00,00,00,00,00,00,80,00,E8 => VANE5 FC,41,01,30,10,01,10,00,00,00,00,00,07,00,00,00,00,00,00,80,00,E6 => VANE_Swing

TP=Type,pw=power,md=mode,fs=fanSpeed,vv=vane,tF=temp FC,42,01,30,10,- -,TP,00,pw,md,00,fs,vv,00,00,00,00,00,00,tF,00,CHK INFO : FC,42,01,30,10,02,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,7B INFO : FC,42,01,30,10,03,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,7A ???? : FC,42,01,30,10,04,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,79 ???? : FC,42,01,30,10,09,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,74

DRY : FC,41,01,30,10,01,07,00,01,02,00,00,00,00,00,00,00,00,00,A8,00,CB DRY ON FC,41,01,30,10,01,0C,00,00,00,00,01,00,00,00,00,00,00,00,BE,00,B2 DRY, FAN_Q,88° FC,41,01,30,10,01,0C,00,00,00,00,02,00,00,00,00,00,00,00,BE,00,B1 DRY, FAN_1,88° FC,41,01,30,10,01,14,00,00,00,00,00,00,00,00,00,00,00,00,BE,00,AB DARY,VANEA,88° FC,41,01,30,10,01,14,00,00,00,00,00,01,00,00,00,00,00,00,BE,00,AA COOL, VANE1,88°

FAN : FC,41,01,30,10,01,03,00,01,07,00,00,00,00,00,00,00,00,00,80,00,F2 FAN ON FC,41,01,30,10,01,08,00,00,00,00,01,00,00,00,00,00,00,00,80,00,F4 FAN, FAN_Q,NO_temp_setting FC,41,01,30,10,01,08,00,00,00,00,02,00,00,00,00,00,00,00,80,00,F3 FAN, FAN_1,NO_temp_setting FC,41,01,30,10,01,10,00,00,00,00,00,00,00,00,00,00,00,00,80,00,ED FAN, VANEA,NO_temp_setting FC,41,01,30,10,01,10,00,00,00,00,00,01,00,00,00,00,00,00,80,00,EC FAN, VANE1,NO_temp_setting

HEAT : FC,41,01,30,10,01,07,00,01,01,00,00,00,00,00,00,00,00,00,A8,00,CC HEAT ON : FC,41,01,30,10,01,0C,00,00,00,00,01,00,00,00,00,00,00,00,94,00,DC HEAT,FAN_Q,50° FC,41,01,30,10,01,0C,00,00,00,00,01,00,00,00,00,00,00,00,BE,00,B2 HEAT,FAN_Q,88° FC,41,01,30,10,01,14,00,00,00,00,00,00,00,00,00,00,00,00,94,00,D5 HEAT,VANEA,50° FC,41,01,30,10,01,14,00,00,00,00,00,01,00,00,00,00,00,00,94,00,D4 HEAT,VANE1,50

COOL : FC,41,01,30,10,01,07,00,01,03,00,00,00,00,00,00,00,00,00,A8,00,CA COOL ON FC,41,01,30,10,01,0C,00,00,00,00,01,00,00,00,00,00,00,00,A0,00,D0 COOL, FAN_Q,61° FC,41,01,30,10,01,0C,00,00,00,00,02,00,00,00,00,00,00,00,A0,00,CF COOL, FAN 1,61° FC,41,01,30,10,01,0C,00,00,00,00,01,00,00,00,00,00,00,00,BE,00,B2 COOL, FAN_Q,88° FC,41,01,30,10,01,0C,00,00,00,00,02,00,00,00,00,00,00,00,BE,00,B1 COOL, FAN_1,88° FC,41,01,30,10,01,14,00,00,00,00,00,00,00,00,00,00,00,00,BE,00,AB COOL, VANEA,88° FC,41,01,30,10,01,14,00,00,00,00,00,01,00,00,00,00,00,00,BE,00,AA COOL, VANE1,88°

Looks like temp can always be sent, with any setting. It looks like there is a magic byte that says what the payload could contain. The above seems pretty easy to replicate and I am sure I could recode a branch of the library to do the above...just not tonight LOL

So, from the above, magic bytes are as follows 0x0c FAN speed change and TEMP for modes DRY,COOL,HEAT

[kayno]

@SwiCago i am trying to get my head around this. is each block the result of you pressing different fan/vane settings for each mode?

[SwiCago]

@kayno, yes These blocks are where I turn unit on and to each mode, then off FC,41,01,30,10,01,07,00,01,02,00,00,00,00,00,00,00,00,00,A8,00,CB => DRY FC,41,01,30,10,01,03,00,01,07,00,00,00,00,00,00,00,00,00,80,00,F2 => FAN FC,41,01,30,10,01,07,00,01,01,00,00,00,00,00,00,00,00,00,A8,00,CC => HEAT FC,41,01,30,10,01,07,00,01,03,00,00,00,00,00,00,00,00,00,A8,00,CA =>COOL FC,41,01,30,10,01,05,00,00,00,00,00,00,00,00,00,00,00,00,A8,00,D0 => OFF These blocks are where I changed a FAN speed, and went to low/high temp in some cases, in corresponding mode i was in FC,41,01,30,10,01,0C,00,00,00,00,01,00,00,00,00,00,00,00,BE,00,B2 DRY, FAN_Q,88° FC,41,01,30,10,01,0C,00,00,00,00,02,00,00,00,00,00,00,00,BE,00,B1 DRY, FAN_1,88° FC,41,01,30,10,01,08,00,00,00,00,01,00,00,00,00,00,00,00,80,00,F4 FAN, FAN_Q,NO_temp_setting FC,41,01,30,10,01,08,00,00,00,00,02,00,00,00,00,00,00,00,80,00,F3 FAN, FAN_1,NO_temp_setting FC,41,01,30,10,01,0C,00,00,00,00,01,00,00,00,00,00,00,00,94,00,DC HEAT,FAN_Q,50° FC,41,01,30,10,01,0C,00,00,00,00,01,00,00,00,00,00,00,00,BE,00,B2 HEAT,FAN_Q,88° FC,41,01,30,10,01,0C,00,00,00,00,01,00,00,00,00,00,00,00,BE,00,B2 COOL, FAN_Q,88° FC,41,01,30,10,01,0C,00,00,00,00,02,00,00,00,00,00,00,00,BE,00,B1 COOL, FAN_1,88° These blocks are where I changed a VANE setting, and went to low/high temp in some cases in corresponding mode i was in FC,41,01,30,10,01,14,00,00,00,00,00,00,00,00,00,00,00,00,BE,00,AB DARY,VANEA,88° FC,41,01,30,10,01,14,00,00,00,00,00,01,00,00,00,00,00,00,BE,00,AA COOL, VANE1,88° FC,41,01,30,10,01,10,00,00,00,00,00,00,00,00,00,00,00,00,80,00,ED FAN, VANEA,NO_temp_setting FC,41,01,30,10,01,10,00,00,00,00,00,01,00,00,00,00,00,00,80,00,EC FAN, VANE1,NO_temp_setting FC,41,01,30,10,01,14,00,00,00,00,00,00,00,00,00,00,00,00,94,00,D5 HEAT,VANEA,50° FC,41,01,30,10,01,14,00,00,00,00,00,01,00,00,00,00,00,00,94,00,D4 HEAT,VANE1,50 FC,41,01,30,10,01,14,00,00,00,00,00,00,00,00,00,00,00,00,BE,00,AB COOL, VANEA,88° FC,41,01,30,10,01,14,00,00,00,00,00,01,00,00,00,00,00,00,BE,00,AA COOL, VANE1,88°

The KUMO Cloud device never sends more than 2 settings at once..Usually only fan or vane and temp OR mode and temp. There was never a send all settings at once

[SwiCago]

@kayno, @uronito @schotime I think I see where we made our mistake. While porting Hadley's pi code, I missed the control packet. The above 07,03,12,10,0C are control packets. It is the sum of all items you want to change. I am going to add that now. I just re-reviewed Hadley's pi code, can't believe I missed that

[kayno]

@SwiCago just so I am clear on this, this is it a control byte (in the 7th position of the packet) within the packet that is sent by update()??

so this byte in bold:

01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 FC | 41 | 01 | 30 | 10 | 01 | 07 | 00 | 01 | 02 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | A8 | 00 | CB

we've had this hardcoded to 0x9f - hopefully getting this right will sort wideVane?

[SwiCago]

Yes, it was hardcoded...about to commit a branch for testing

[SwiCago]

@kayno @uronito @schotime , please try https://github.com/SwiCago/HeatPump/tree/control_packets and let me know how that goes. May need some debugging

[kayno]

I will try tonight. Given we were sending 0x9f, the sum of const byte CONTROL_PACKET[6] = {0x01, 0x02, 0x04, 0x08, 0x10, 0x80}; (indicating that we are changing all settings, right?), it shouldn't make much difference - like at first glance I do not expect this to fix wideVane... are you thinking similar?

[SwiCago]

and BTW, I still get a more accurate temperature packet at byte 17 on return packets and I believe we should be sending temperature to byte 20 for more accurate temperature setting. But lets see if this works better first.

[kayno]

more accurate temperature as in down to 0.5 increments as mentioned in another issue by someone else?

[SwiCago]

@kayno, I do not think it will fix it, but it is more closely to KUMO Cloud, which is official. And like I mentioned before temp should be set on 20th byte and read from 17th byte. We can do conversion to °C from library Anyhow, I putzed enough for today. I am beat. It was my day off LOL and tomorrow I get to do more of the same at work.

[kayno]

I have been testing the control_packets branch.

So everything still seems to work (except for wide vane) however I have noticed that the control byte is never smaller than 0x80. If i do just a temp change, it's 0x84 (TEMP control value is 0x04) which is telling me it's always adding the 0x80 for widevane. Which means the code always thinks wide vane has changed...

Here is what the packet to change just temperature from 16C to 31C looks like:

You can see that the TMP byte changed between the two packets, the CTL (CONTROL) byte is 0x84. Should only be 0x04.

More digging to do...

[kayno]

I have worked out why it always summed in the 0x80 for wideVane, even if you didn't change it - it's the same bug that was hurting us earlier - if(!wantedSettings)! We need to avoid using the ! operator for the heatpumpSettings until I make it work!

So I have added the firstRun bool flag in instead, and now see the 0x04 in the CTL byte when I change only temperature:

[kayno]

Actually scratch my last comment. The moment you change wide vane (which still has no affect) wideVane is out of sync with the heatpump and you start to get the 0x80 being summed back in to the CTL byte. My mistake. Again.

Either way, I think the CTL byte is working fine.

Just still can't control wide vane. I find it troubling that for power, mode, fan and vane - byte values and positions are the same when the heatpump reports them and when you want to change them. But for wide vane - if you send the same byte in the same position that the heatpump sends this setting on, but to change it, it won't update. Why would it be different?

[SwiCago]

@kayno, you have the same hp as Hadley, right? On my HP the 19th, per above chart is my temp byte. Maybe some heat pumps only could do 1 degree C increments and when mitsu decided to go to US market, they changed it so they could do 1 degree increments in F. I will toninght try to run through the entire F range, but i beleieve anything inbetwen the min and the max I already reported should work. Then we can see if it works on your HP as well. If not, then we need to add a choice or auto detect based on that initital connect return response. I also, would still like to try and send it IR packets over the serial and see if that works too

[schotime]

Mine only does 1 degree increments.

[SwiCago]

Hi @schotime , thanks for that information. I am thinking of adding a detection on return packets, if temp is defined in another byte on return, then it must be set in byte 19. I believe I'll be able to determine that on first call. Working on a library that should work for both types.

[kayno]

@SwiCago my heatpump is a different model to Hadley's, but it only does 1 degree Celsius increments (at least on the remote - would be interesting to see if it accepted 0.5C increments on cn105, as it reports the temp on both bytes...).

[schotime]

If i send 0.5 degrees through hass it seems to round down.

[kayno]

@schotime as in HASS rounds down and sends an integer over MQTT to the heatpump, or the heatpump accepts a 0.5 increment but reports back a rounded down temp?

I suspect it's the latter, which makes sense as the heatpumpSettings struct has int temperature, and when you push a float into that it will most likely round it down. And even if we made it a float, the 0.5 increments would need to be added to the TEMP/TEMP_MAP constants and we'd need to send the value in the byte 19, not the one it's sending in now! If that works, that is :)

[SwiCago]

@kayno at the moment it does not do 19th byte for temp send. I am working on that now. I know on my unit the temperature is return in byte 16 and byte 10. I plan to look at byte 16 on settingsInfo and if it is set on firstRun, then use byte 19 to send else use byte 10

[kayno]

@SwiCago no problems. I knew it was only setting on the 10th byte, but like your unit, mine also returns it on both the 10th and 16th. Interesting that it needs to be set on 19 - another case of a mismatch (like wide vane appears to be)?

Tonight I am going to unleash the sendCustomPacket() method to see if I can brute force the wide vane. I am doing this with the hope that if I blow up the unit trying, you will all pitch in what you can to help me replace it!! :D

[SwiCago]

@kayno, I modified your MQTT sample to do custom packet. Would you like me to commit it to my control_packets branch?

[kayno]

yes please! i can then fetch and test when I get home.

i think I need to order another huzzah so I can have one disconnected from the heatpump ready to program whilst I test the last round of code on another that's connected to the heatpump. Would make the process of code -> diconnect -> upload -> reconnect -> test -> repeat quicker!! :)

[SwiCago]

@kayno, just posted it...review it...I did not test the conversion from String to HEX bytes

[kayno]

excellent, thanks. did you test sending a known packet to see if it worked? that will be my first test...

[SwiCago]

@kayno, no not yet...I was going to get to that next LOL. Busy doing the new temp that will work for both old style and new

[SwiCago]

@kayno, even though I setup the struct for temp to be a float, I am currently only setting and getting int. I even set it to float in the MQTT...but the good news is that it is accepting the new temp packet and returning it correctly and also reporting roomTemp correctly

[SwiCago]

@kayno, with IR, I can set 0.5 increments and the MQTT receives them correctly. So it is just a matter of figuring out why my set is not sending in increments of 0.5 .. but it is working YAY

[kayno]

@SwiCago - nice, so you are trying to set temp on byte 19, and read it back of 16, in increments of 0.5?

I think you will need to duplicate lookupByteMapIndex, and override it for float...

[kayno]

and possibly lookupByteMapValue() too... There must be a better way to do those lookups... perhaps check how jarrod's library does it...

[SwiCago]

@kayno yes, that is exactly what I am doing setting on 19, reading from 16. But I am not using map. I am using a simple calculation to verify the value is in a specific range

[kayno]

@SwiCago thanks for byte confirmation. that only leaves 13, 14, 17, 18, and 20 for me to try and bruteforce the widevane on :)

18 is my bet!

[SwiCago]

@kayno, I am able to set 0.5 increment in some cases...I wan to push the MQTT and the cpp and h file to that same branch. do you mind pulling it and playing with it. I added auto detect to decide which temp byte to send/receive on. Seems to be working for the most part,

[SwiCago]

@kayno just committed to control_packets ... please putz around with it..I am beat and can't see straight no more. But it looks promising. Hey and If I have not said it already enough, thanks for working together with me on this. I just wish jarrod would have also joined us, instead of making another variant. Extra eyes and ideas are what make open source so great

[SwiCago]

@kayno, does git always have a few minutes of delay till it is sync'd? Anyhow I see it there now online

[kayno]

@SwiCago not sure on the git delay, but I wouldn't be surprised given how much code they have.

happy to test the temp stuff to, so all good that it's in this branch. I like the approach to branching you are taking, as I am still not up-to-speed or ready to try the auto update branch you have, so glad it's separate and out of the way (but not lost!)

I really like jarrod's code, but whilst the structure is really nice, I haven't seen things like the callbacks that we worked on here (and jarrod had input on). I am not sure why he decided to go down the path he took, but I'd like to see some of his stuff in here and some of the stuff here in his! Each to their own I guess, and jarrod is free to do as he pleases. on the plus side, we can incorporate the good parts of his code into here :)

Same goes to you as well - thanks for all your work and accepting all of our suggestions and pull requests! I've enjoyed collaborating a lot! I do wonder if I will ever pull the cover off my heatpump again and tuck the ESP inside, or if I will just leave it hanging outside of the unit so i can re-program and tinker and tweak the code whenever I like!

[kayno]

@SwiCago was just reviewing your commit. Interesting that when you are sending the temperature in the 19th byte, you still sum in 0x04 into the control byte. As this is a bitmap, that corresponds to the 10th byte where we were previously setting the temp packet. The heatpump must look in 19 first, and take that if it's set, perhaps? The bitmap value for 19 is 2048 (0x0800), so it wouldn't fit in one byte anyway. but perhaps that's what byte 7 is for, as we always leave it set to 0x00.... I'm just thinking out aloud!

[SwiCago]

@kayno, yes it is still 0x04, i saw this in the kumo cloud dumps. It seems to like it anyhow lol. It probably does something similar, check byte x 0x00, then read other byte

[kayno]

@SwiCago yeah, if it's working, must assume to read other byte if 19 is not set. I checked your dumps above and the 7th byte is always 0x00, so doesn't look like anything is going on there...

[SwiCago]

@kayno LOL, yeah i wonder if the cover will ever go back onto my hp as well lol. My house is totally upside down from renovations, so the wife doesnt seem to care about a cable dangling lol. I know someone on esp8266.net came up with a way to do over the air updates, maybe we should look at that. I like the esp01 as it fits easily in the dead space next to the master board, just outside the RF shield.

[kayno]

@SwiCago i get asked by visitors - "what's that hanging out of your air conditioner!?"

And yes - OTA would be great!

[SwiCago]

@kayno, would be neat of someone with pac-wf010-e and melcloud could chime in. That app supports wideVane http://www.melcloud.com

[schotime]

Don't think my model even supports it.

[kayno]

@schotime - doesn't support the pac-wf010-e? or something else?

[schotime]

@kayno widevane.

[kayno]

@schotime ah ok.

[kayno]

@SwiCago - I have cracked wide vane! will doco the byte combo now, but I wanted to share already :)

[SwiCago]

@kayno, just fixed custom byte sender. seems for some reason i was sending 20 chars as 20 bytes, that was wrong. 40 hex chars = 20bytes

[SwiCago]

@kayno, wideVane...forking awesome. Probably something stupid simple too

[schotime]

Great work gents!!!!