GREE protocol is not quite right for YX1F remote

[stonemull]

I was attempting to send a command emulating the YX1F remote to enable the timer and have not yet managed it. Used IRrecvDumpV3 to analyse. This is just a heads up that the GREE protocol decoder does not match the older devices, I will spend some time and attempt to report more as I go.

When turning on the timer in either on or off mode, 2 packets are sent. There is 39.7mS between packets so kTimeout was dropped to 35 or it appears as kelvinator protocol when timer button used.

So looking at the protocol decoder I think the GREE byte3 "unknown1" which is always 0x5 becomes 0x6 for the second packet. I would suggest the 4 bit unknown1 should perhaps be replaced with

uint8_t packetNum      :2;  // value=0b01 on first packet, 0b10 on second packet
uint8_t unknown1        :2;  // value=0b01

Byte 4 SwingV is part of timer off setting.

Byte 5 WiFi is toggled between packets, this is an old air con and has no wifi, the unnamed bit 7 of Byte 5 also toggles with timer operations and also part of "unknown2".

So air con is being used set to 22C dry. Power on decode is ..

Protocol : GREE Code : 0x1A066050002000C1 (64 Bits) Mesg Desc.: Model: 1 (YAW1F), Power: On, Mode: 2 (Dry), Temp: 22C, Fan: 1 (Low), Turbo: Off, Econo: Off, IFeel: Off, WiFi: Off, XFan: Off, Light: On, Sleep: Off, Swing(V) Mode: Manual, Swing(V): 0 (Last), Swing(H): 0 (Off), Timer: Off, Display Temp: 0 (Off)

Pressing timer button set to 30 minutes to enable the "Off" timer sends 2 packets. Code : 0x1A966050002000C1 (64 Bits) Code : 0x1A96606000E00181 (64 Bits)

When unit power is off (on the remote) then pressing the timer button to enable the "On" timer to 30 minutes sends 2 packets. Code : 0x1296605000200041 (64 Bits) Code : 0x129660601E000032 (64 Bits)

turning off the "Off" timer. Only sends 1 packet. Code : 0x1A066050002000C1 (64 Bits)

turning off the "On" timer. Only sends 1 packet Code : 0x1206205000200041 (64 Bits)

more later..

[crankyoldgit]

Have you tried controlling the device using the KELVINATOR protocol?

[crankyoldgit]

Ping

[stonemull]

Sorry been busy, just wired up the TSOP again and had a look with the standard IRRecvDumpV3 and using the kelvinator protocol is more incomplete than the GREE and has similar inconsistency's. I much prefer using the 2 packet Gree method as that is obviously what the GREE (and kelvinator as well) remote is really doing anyway.

Here is a decode of the kelvinator protocol of a timer button press (24C Dry, swing on, timer set 1 HR, setting T-OFF to on) There is no mention of timer settings here. So its not really useful currently without a lot more struct filling in, then the byte 5-6 pad bytes need to be filled in with copies of byte 0,1 and 2 etc.

Protocol : KELVINATOR Code : 0x5A886150112000015A88616000C00391 (128 Bits) Mesg Desc.: Power: On, Mode: 2 (Dry), Temp: 24C, Fan: 0 (Auto), Turbo: Off, Quiet: Off, XFan: Off, Ion: On, Light: On, Swing(H): On, Swing(V): On uint16_t rawData[279] = {9062, 4442, 698, 508, 698, 1608, 700, 508, 698, 1610, 698, 1608, 698, 508, 698, 1608, 698, 506, 700, 506, 698, 506, 700, 506, 700, 1608, 700, 506, 700, 506, 698, 508, 698, 1608, 698, 1608, 698, 506, 700, 508, 696, 506, 700, 456, 750, 1610, 698, 1606, 698, 506, 700, 506, 700, 506, 700, 506, 700, 506, 698, 1610, 698, 506, 700, 1608, 698, 506, 700, 506, 700, 1608, 698, 506, 698, 19938, 698, 1608, 698, 506, 700, 508, 698, 506, 700, 1610, 698, 506, 700, 506, 698, 426, 780, 506, 700, 506, 698, 506, 698, 506, 700, 506, 700, 1608, 698, 508, 698, 506, 698, 508, 698, 506, 700, 506, 698, 506, 700, 506, 700, 504, 700, 506, 698, 506, 700, 1606, 700, 508, 698, 506, 698, 508, 698, 506, 698, 506, 698, 506, 700, 508, 698, 39950, 9036, 4440, 698, 506, 698, 1608, 700, 506, 700, 1608, 698, 1608, 700, 506, 698, 1608, 698, 506, 698, 506, 700, 506, 698, 508, 698, 1608, 700, 504, 700, 506, 698, 508, 698, 1536, 770, 1608, 698, 508, 698, 508, 698, 506, 702, 506, 698, 1608, 698, 1608, 700, 504, 700, 508, 700, 506, 698, 508, 700, 490, 714, 506, 700, 1608, 698, 1608, 700, 506, 698, 506, 698, 1608, 698, 508, 698, 19942, 698, 506, 700, 506, 698, 506, 700, 506, 698, 508, 700, 506, 700, 508, 698, 506, 700, 506, 698, 506, 698, 506, 700, 506, 700, 506, 700, 506, 700, 1608, 700, 1608, 700, 1608, 698, 1608, 700, 506, 698, 508, 698, 508, 698, 508, 696, 506, 700, 506, 700, 1608, 700, 504, 700, 506, 698, 506, 700, 1608, 700, 506, 700, 506, 700, 1608, 698}; // KELVINATOR uint8_t state[16] = {0x5A, 0x88, 0x61, 0x50, 0x11, 0x20, 0x00, 0x01, 0x5A, 0x88, 0x61, 0x60, 0x00, 0xC0, 0x03, 0x91};

By comparison I changed the packet timeout to 35mS and decodes as 2 Gree packets is much more fleshed out.

`Timestamp : 000030.601 Library : v_IRREMOTEESP8266_VERSION_MAJOR._IRREMOTEESP8266_VERSION_MINOR._IRREMOTEESP8266_VERSION_PATCH

Protocol : GREE Code : 0x5A88615011200001 (64 Bits) Mesg Desc.: Model: 1 (YAW1F), Power: On, Mode: 2 (Dry), Temp: 24C, Fan: 1 (Low), Turbo: Off, Econo: Off, IFeel: Off, WiFi: Off, XFan: Off, Light: On, Sleep: Off, Swing(V) Mode: Auto, Swing(V): 1 (Auto), Swing(H): 1 (Auto), Timer: 01:00, Display Temp: 0 (Off) uint16_t rawData[139] = {9064, 4414, 728, 480, 726, 1578, 730, 476, 728, 1578, 754, 1554, 728, 478, 726, 1578, 730, 476, 728, 478, 728, 476, 726, 480, 728, 1576, 754, 454, 726, 478, 726, 480, 726, 1580, 728, 1578, 730, 478, 732, 476, 726, 476, 778, 428, 734, 1568, 728, 1578, 812, 384, 736, 370, 836, 478, 808, 400, 724, 454, 778, 1552, 752, 452, 728, 1580, 728, 476, 728, 480, 728, 1576, 730, 480, 724, 19908, 728, 1578, 730, 478, 726, 478, 728, 478, 728, 1578, 726, 482, 726, 476, 726, 480, 726, 478, 754, 454, 724, 478, 728, 478, 728, 480, 724, 1580, 728, 478, 726, 480, 726, 478, 728, 476, 730, 478, 752, 456, 724, 480, 728, 468, 760, 454, 726, 482, 726, 1578, 726, 478, 728, 480, 752, 454, 778, 430, 748, 454, 724, 480, 728, 478, 728}; // GREE uint8_t state[8] = {0x5A, 0x88, 0x61, 0x50, 0x11, 0x20, 0x00, 0x01};

Timestamp : 000030.777 Library : v_IRREMOTEESP8266_VERSION_MAJOR._IRREMOTEESP8266_VERSION_MINOR._IRREMOTEESP8266_VERSION_PATCH

Protocol : GREE Code : 0x5A88616000C00391 (64 Bits) Mesg Desc.: Model: 1 (YAW1F), Power: On, Mode: 2 (Dry), Temp: 24C, Fan: 1 (Low), Turbo: Off, Econo: Off, IFeel: Off, WiFi: On, XFan: Off, Light: On, Sleep: Off, Swing(V) Mode: Auto, Swing(V): 0 (Last), Swing(H): 0 (Off), Timer: 01:00, Display Temp: 0 (Off) uint16_t rawData[139] = {9066, 4412, 728, 482, 724, 1580, 728, 478, 728, 1578, 732, 1578, 726, 478, 726, 1580, 736, 468, 728, 480, 724, 480, 726, 480, 726, 1580, 728, 480, 724, 484, 722, 478, 726, 1580, 726, 1582, 766, 444, 720, 482, 724, 482, 748, 458, 724, 1580, 726, 1580, 730, 476, 728, 480, 724, 482, 750, 454, 724, 480, 726, 480, 730, 1576, 728, 1580, 726, 480, 726, 482, 726, 1580, 750, 456, 722, 19914, 726, 480, 724, 480, 726, 480, 724, 482, 750, 456, 724, 480, 724, 484, 722, 482, 724, 480, 722, 484, 726, 480, 724, 484, 722, 480, 726, 482, 722, 1582, 728, 1582, 724, 1582, 726, 1580, 728, 482, 722, 482, 722, 482, 724, 482, 724, 482, 724, 482, 724, 1582, 724, 484, 724, 482, 722, 482, 724, 1582, 726, 480, 722, 484, 724, 1582, 728}; // GREE uint8_t state[8] = {0x5A, 0x88, 0x61, 0x60, 0x00, 0xC0, 0x03, 0x91}; `

I notice there is no place currently in the GREE structure to indicate which timer, on or off is being set. The power bit in byte 0 changes obviously but I think there are further changes than that deeper into the packet.

2 packets from setting off timer to 1.5 hours

0x5A98615011200001 0x5A98616000A00571

2 packets from setting the "on" timer to 1.5 hours

0x5298615011200081 0x529861605A0000A2

first packet is unchanged apart from bit 0:3 (power bit) and the checksum. second packet though has big changes, bytes 4,5,6 change from --

00000000 -> 01011010 10100000 -> 00000000 00000101 -> 00000000

I'll look further later.

[Limb]

I'm working on implementing the YX1F8F remote, and while I have basic functionality working (On/Off, Temperature, implemented Econo mode), I am having trouble with the timer functionality. Without modifications, the timer function will activate (the "Timer" LED on the unit is lit) but the unit does not actually turn off as it is supposed to. Also, when setting the timer using the remote, the LCD on the unit will switch the display to show the current timer setting (i.e "0.5"), but this does not happen when sending the command via IRremote. I supposed this is something to do with the additional packets I log the remote sending, whereas IRremote only sends one.

Some of the things I've noticed are similar to what stonemull has noticed, with some differences. I have dumped out the IR commands to a google sheet.

First major difference is the presence of a third packet, consisting of all 0's except for unknown1 being set to 0b0101.

uint8_t packetNum :2; // value=0b01 on first packet, 0b10 on second packet uint8_t unknown1 :2; // value=0b01

I've noticed the inverse. first packet is 0b10, second is 0b01.

Byte 4 SwingV is part of timer off setting. SwingV remains 0b0000 on this remote.

Byte 5 WiFi is toggled between packets, this is an old air con and has no wifi, the unnamed bit 7 of Byte 5 also toggles with timer operations and also part of "unknown2".

This unit also does not have wifi. The wifi bit is set to 1 on the second packet for timer values of 0.5 and 1.0, but remains 0 for a timer of 1.5. I see the bit changing for unknown2 as well. I'm confused by "bit 7 of byte 5" as that is marked as SwingH, but regardless I see no bit change there.

Do any other remotes implement a multi-packet structure? I'm not sure how we should go about implementing the multi-packet commands since the current code would have to be re-written with state machine logic or some other approach.