You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have two indoor units installed close together and configured to use "Remote Control A" in the first unit and "Remote Control B" in the other unit to avoid interference, as described in the user manual below.
The current codebase has hardcoded the first five bytes 0xF20D03FC01 that only allows to emulate "Remote Control A". After capturing the IR signals of "Remote Control B", it is found that the only variance is on the leading 4 bits of the 3rd byte in the 72-bits command.
Complete Command
3rd byte
4th byte
Remote Control A
0xF20D03FC0180010080
0x03
0xFC
Remote Control B
0xF20D13EC0180010080
0x13
0xEC
While the 4th byte's value is already derived by the checksum function automatically. Please help to enhance the support by enabling to specify remote type in the constructor and expose the field with getter, setter functions. Thank you.
The text was updated successfully, but these errors were encountered:
Version/revision of the library used
v2.8.6/master
Describe the bug
I have two indoor units installed close together and configured to use "Remote Control A" in the first unit and "Remote Control B" in the other unit to avoid interference, as described in the user manual below.
The current codebase has hardcoded the first five bytes
0xF20D03FC01
that only allows to emulate "Remote Control A". After capturing the IR signals of "Remote Control B", it is found that the only variance is on the leading 4 bits of the 3rd byte in the 72-bits command.While the 4th byte's value is already derived by the checksum function automatically. Please help to enhance the support by enabling to specify remote type in the constructor and expose the field with getter, setter functions. Thank you.
The text was updated successfully, but these errors were encountered: