How do people figure out all the AC remote codes for the lesser used buttons?

I've been through this exact rabbit hole with an old split system, and the answer is that most air con remotes don't send single commands at all. They send the whole state of the unit every time you press anything. So when you hit fan speed, the remote transmits power, temp, mode, swing and fan all baked into one long burst, just with the fan bits changed. That's why your fan button does something weird, you're probably sending a partial or default state and the unit interprets it strangely. And swing doing nothing usally means your library's swing code was written for a different model and the checksum or bit layout doesn't match yours.

The way to actually work it out is to capture what your real remote sends. If your library is IRremoteESP8266 or anything compatible, load up the example sketch called IRrecvDumpV2 or V3 on your board, point the original remote at the receiver, and press each button. It'll print the raw timings plus a decoded guess. Save the output for every button and every setting combo you care about. Then press power with fan on low, then fan on high, and diff the two dumps. The bytes that changed are your fan field. Same trick for swing, temp, timer, everything.

Once you can see which bytes move for which setting, you've got two options. Check if the library has a class for a related model from the same brand, becasue manufacturers reuse protocol layouts across years, and sometimes you just need to shift which byte holds what. Or skip the library's model code entirely and build the frame yourself, copy the captured bytes, modify only your target bits, fix the checksum if there is one, and send it with the raw send function.

One gotcha, some units send two bursts back to back with a gap, and some flip certain bits between repeats. Capture the full sequence, not just the first packet, or the unit will ignore you. For an older wall unit the captures are honestly more reliable than any library anyway. Took me an evening of pressing buttons and comparing hex dumps to map out a remote the libraries had never heard of.

That idea about capturing the timings for every button press makes sense. I had a similar time with an older device, trying to decode its signals, and the timing variations were trickier than I expected. Once you have all the captured byte data from that dump, how complex is it to acutally structure the sending code? I'm mostly worried about getting the checksum calculation correct when I try to build the frame myself.

I think focusing on the checksum first is the right approach because once you've got the byte map, the calculation is just a math problem. When I was mapping out an older remote years ago, I found that the timing information was inconsistent in the library examples. I ended up using a logic analyzer to actually see the clock pulses, which helped me determine if the manufacturer was using a simple parity bit or a more complex CRC. Without that precise timing data, the checksum is basicly guesswork. It’s frustrating when the library is incomplete.

The dumping method works, sure, but the success of mapping those bytes relies heavily on the physical setup. You can't get clean raw timing data if you're running everything on noisy power or using some cheap IR receiver. I always tell guys to get a stable power rail and a decent sensor. If the signal is muddy, your timing comparisons are just going to be guesswork, no matter how good the code is. You need that raw capture to be perfect before you even worry about the checksum logic.

Mapping the byte shifts is defintely the heavy lifting. Once you have your capture logs, you have to build a custom frame generator that handles the data structure. I once mapped a cheap set-top box remote, and the timing consistency had to be within 1.2 microseconds across the entire sequence for the unit to actually accept the signal. Most people just focus on the byte values and miss that precise timing detail. You need that tight tolerance or the unit will reject the whole burst.