search

crankyoldgit / IRremoteESP8266

Infrared remote library for ESP8266/ESP32: send and receive infrared signals with multiple protocols. Based on: https://github.com/shirriff/Arduino-IRremote/
GNU Lesser General Public License v2.1
2.84k stars 810 forks source link

DECODE_HASH should get its own protocol type #2057

Closed uwekaditz closed 5 months ago

uwekaditz commented 5 months ago

In our project letscontrolit/ESPEasy we use the latest IRremoteESP8266 lib v2.8.6. We found that it would be useful if the DECODE_HASH function gets its own protocol type and not just UNKNOWN see #4907

NiKiZe commented 5 months ago

Which part of an UNKNOWN message are you using? The only data you could be using is the raw timings, never the hash code.

To know if a message is actually the same you will need to know and decode the protocol. Changing Unknown to decode_hash would lead to a full set of issues, including even more people thinking that the result of such message is usable, and then complain when the same button on their remote does no longer give the same code as they once recorded.

crankyoldgit commented 5 months ago

@uwekaditz Can you please explain/elborate/justify why you need DECODE_HASH as a protocol? It's almost the opposite of a protocol. DECODE_HASH's result that is stuffed in the response because people expect/want one when no protocol is found. You can't send a hash. There is no way to convert a hash back into anything that is a semblance of the original message. Heck, it doesn't even do a good job of what it is intended to do of saying "hey, this IR message for a protocol I don't understand has a fingerprint of 32bit integer. If you get the same integer again, it might be the same message again. But it might not".

It already has a protocol number associated with it of sorts. i.e. UNKNOWN, which is exactly what it is.

DECODE_HASH is a nice hack which was inherited from the very beginning from the origin IRremote arduino library.

uwekaditz commented 5 months ago

@uwekaditz Can you please explain/elborate/justify why you need DECODE_HASH as a protocol? It's almost the opposite of a protocol. DECODE_HASH's result that is stuffed in the response because people expect/want one when no protocol is found. You can't send a hash. There is no way to convert a hash back into anything that is a semblance of the original message. Heck, it doesn't even do a good job of what it is intended to do of saying "hey, this IR message for a protocol I don't understand has a fingerprint of 32bit integer. If you get the same integer again, it might be the same message again. But it might not".

It already has a protocol number associated with it of sorts. i.e. UNKNOWN, which is exactly what it is.

DECODE_HASH is a nice hack which was inherited from the very beginning from the origin IRremote arduino library.

In my ESP8266 application I want to get a unique code from the IR control to switch an output of the ESP8266. Within the application only DECODE_NEC and DECODE_HASH are enabled. The IR control I use is a noname Chinese IR for a christmas illumination. If DECODE_HASH wouldn't be enabled the result of IRrecv::decode() would be FALSE, otherwise it returns TRUE, the hash of the received bits and decode type UNKNOWN. In my application decode type UNKNOWN is also used for discarding an already captured, decoded and saved code. Therefore, I thought that it would be a good idea to give the hash decoded code another type as UNKNOWN, but if UNKNOWN is fixed for you I can change my application to use another marker to discard a saved code. I'm sorry that I've bothered you with this issue.

uwekaditz commented 5 months ago

@uwekaditz Can you please explain/elborate/justify why you need DECODE_HASH as a protocol? It's almost the opposite of a protocol. DECODE_HASH's result that is stuffed in the response because people expect/want one when no protocol is found. You can't send a hash. There is no way to convert a hash back into anything that is a semblance of the original message. Heck, it doesn't even do a good job of what it is intended to do of saying "hey, this IR message for a protocol I don't understand has a fingerprint of 32bit integer. If you get the same integer again, it might be the same message again. But it might not".

It already has a protocol number associated with it of sorts. i.e. UNKNOWN, which is exactly what it is.

DECODE_HASH is a nice hack which was inherited from the very beginning from the origin IRremote arduino library.

Thanks for the explanations. I've always used the hashed code. Over more than one year I still get the same hash from the cheap noname Chinese IR. Even a second IR remote of the same type gives me the same hash if I press the same buttons.

crankyoldgit commented 5 months ago

Have you tried the full complement of protocols to decode the unknown protocol? e.g. https://github.com/crankyoldgit/IRremoteESP8266/tree/master/examples/IRrecvDumpV3

You never know, the protocol might already be known.

NiKiZe commented 5 months ago

The only way to get a valid "code" from a remote is by deciding the protocol. The hash for unknown should simply never be used.

uwekaditz commented 5 months ago

Have you tried the full complement of protocols to decode the unknown protocol? e.g. https://github.com/crankyoldgit/IRremoteESP8266/tree/master/examples/IRrecvDumpV3

You never know, the protocol might already be known.

I tested the full complement of decodes as you suggested. The result of the noname Chines IR remote is as follows:

Timestamp : 000129.343<\n>Library : v2.8.6 Protocol : UNKNOWN<\n>Code : 0x4A61DF53 (10 Bits)<\n>uint16_t rawData[19] = {8926, 3986, 562, 494, 538, 494, 542, 490, 546, 490, 544, 488, 540, 496, 1072, 1044, 1072, 1040, 542}; // UNKNOWN 4A61DF53

uwekaditz commented 5 months ago

I found the bug in my application: The decode types UNKNOWN and UNUSED were mixed up and thats why I wanted to have the above mentioned workaround. Thank for your help.

uwekaditz commented 5 months ago

I found the bug in my application. Thank for your help.