Add support for multiple models of Apple remote + long press

[zas]

No description provided.

[zas]

@dspverden I noticed something in

freeDSP-aurora/SOURCES/WEBAPP/ESP32/aurora/hwconfig.h

Lines 41 to 44 in 7bbd8f7

	#define APPLE_REMOTE_CENTER_UP 0x77E12047
	#define APPLE_REMOTE_MENU 0x77E14047
	#define APPLE_REMOTE_PLAY_DOWN 0x77E17A47
	#define APPLE_REMOTE_PLAY_UP 0x77E12047

0x77E12047 seems to be emitted when CENTER or PLAY are released (UP), so the codes are incorrect, but since they weren't used, no problem.
Other buttons don't send a different code when releasing, so not sure it is worth bothering.

My remote has codes looking like 77E1xx36, the master source has codes in the form of 77E1xx47, and f35adc3 has codes in the form of 77E1xx55.
#73 gives another set of codes that have the following patten 77E1xxF7

The code here should work with all.

[zas]

@dspverden I improved the thing a bit so it speeds up when maintaining a long press on volume remote buttons, and tried to debounce very short presses, so it's possible to fine tune volume level. On short presses, it goes with 0.5db as it was before, but when maintaining buttons it speeds up to 1db then 2db.
Tell me what you think once you tested it.

[zas]

I'm not yet happy with this code. I'll update the PR once I have something good enough.

[zas]

I reworked the code, it is much simpler now, and should work as expected.

[exislow]

Great job. Just tested it. Works like charm. Even the logic regarding short long presses and longer long presses. Love it.

[dspverden]

To make things a bit more complicated, I had a bunch of Apple remotes here, they all showed different patterns. But it can be narrowed down to a scheme. In hex code the second byte identifies the key while byte 4 & 3 are always 0x77E1xxxx. That means masking byte 2 by 0x0000FF00 will give the key code. Here I found two variants for each key, e.g. Play button is either 0x00007A00 or 0x0000FA00.
See my last commit on develop. There I already implemented that. Perhaps you want to adapt long press solution to it?

[zas]

@dspverden did you test my code with those remotes ? The 0x00007A00 or 0x0000FA00 should be handled by 0x00007F00 mask

EDIT:

I'm pretty sure this code was working with the variant you added in 00f0012

I wonder if you actually tested this code, and if it wasn't working, why.
Check
https://github.com/brackendawson/Appleceiver/blob/357a0a16013d9e35f1119530399aba55b7030bab/Appleceiver.ino#L43-L55:

//Apple remote definitions
//Address
#define A1156_ADDRESS   0x77E1  
/*Button codes
 I've seen many remotes have various codes,
 this is the best decode I have. The address
 is fixed, the message may be as so:
 #define A1156_BUT_PLUS  0x   5    0    9    D
                           0101 0000 1001 1101
                           ||      | |       |
 varies, battery flat?-----+|      | |       |
 fixed?, the button---------+------+ |       |
 varies, serial number?--------------+-------+ */

The first bit on the left varies ("battery flat?"), hence the mask 0x00007F00.

[zas]

@dspverden you didn't answer to my comment above, I need to know what wasn't working with the models you own, before reworking this PR.

[dspverden]

Please have a look at the one of the latest commits from develop. There you can see, it seems to be bit 7 (most left) of the the second byte. As you described it above.