Add more IR remote codes about feature-requests

[OttoWinter]

I don't it will ever be possible to make something generic enough to encapsulate all protocols - so I will close this issue. All feature requests for specific protocols should go into separate feature requests per protocol so that contributors can coordinate efforts better.

[escoand]

Physically, every code consists of base frequency with header, data (one and zero) and eventually footer with each high and low lengths.
The data could be splitted in address and command with each a defined length.

This sounds simple to configure. So the code needs to be implemented only once. Currently the classes are all slightly different but do at the end the same thing.

[OttoWinter]

Yes for encoding it's mostly that simple. However when it comes to decoding it can quickly get more complicated. For example with sony codes only 12 bit, 15 bit or 20 bit codes are valid.

Anyway, I think it would be possible to create a generic IR code class, but I don't really have a problem with the existing solution of having one class per manufacturer. It's a bit more difficult to maintain, but ultimately it saves me from creating a monstrous class that attempts to support every single IR code there is.

[yawor]

@OttoWinter I'd add another aspect to this issue. Naming of the supported IR codes (LG, Samsung, Sony etc) is far from good. There's no guarantee at all that a single brand is always going to use the same IR protocol. For example I have LG TV and Soundbar and the TV uses NEC1, but the Soundbar uses NECx2. In esphomelib, NEC2/NECx2 is implemented as samsung.
I think esphomelib should use protocol names instead of equipment brands. So samsung should probably be renamed to nec2, nec should be renamed to nec1. Sony doesn't need renaming as it's actually Sony's own protocol and is referred to as such (usually as sony8, sony12, sony15, sony20 depending on the frame length). Panasonic is also ok, as it's the same situation as with sony, but without variants. I don't recognise the protocol defined in the lg.cpp - seems similar to NEC1, but it's off a little.

@escoand it's not that easy. All IR protocols implemented right now in esphomelib (nec1, nec2, sony, panasonic) use a burst/gap timing encoding. This is quite simple to decode as you say, as the rising and falling edges are always within a single bit. But there are also phase-shift encoding schemes, where the order of high/low signal define 0 and 1 (for example high/low -> 0, low/high -> 1). For example this means that if you have two bits 00, then the signal is going to look high/low/high/low, but if you have bits 01 then the signal would look like high/low2/high (low2 means keep the signal low twice long as normal) so you don't have a rising or falling edge between bits. It's of course still possible to decode but it's a bit harder than a simple gap protocol.
There are also protocols where multiple bits are encoded in a single burst/gap pair, which has multiple possible timings (for example 00 -> 600us/600us, 01 -> 600us/800us, 10 -> 600us/1000us and 11 -> 600us/1200us). An extreme example of such protocol is the XMP, which encodes 4 bits in a single pair with 16 different gap times (from 760us up to 2800us with 136us increments).

[yawor]

As a reference for different IR signals and protocols, I can recommend IrScrutinizer program. It's written in Java so it can be run on any desktop system. You can use Generate tab in the program to generate an IR signal for any IR protocol added in the program (and there's a lot). With proper hardware it can also send and receive IR signals. It can be used to analyse and decode signals.

[escoand]

OK, you seem to have much more experience with all that. My knowledge was just some googling and try and catch.
I also tried to reverse engineer my Logitech remote but this seems to be some of your described phase-shift protocols.
Good would be a existing collection which could be used here.

[yawor]

@escoand download the program I've recommended. It's open source and is being developed by a member of hifi-remote (jp1) community. There's a really big collection of IR protocols included in the program. You just select one from the dropdown, enter some values and you can generate a signal for provided parameters.
If you mean Logitech Harmony remote, then the protocol it uses depends on the devices configured on the remote. But there's also a logitech proprietary protocol, but it's not phase-shift, but a simple gap timing.

[OttoWinter]

The names of the IR protocols are based on https://github.com/markszabo/IRremoteESP8266/ and personally I don't really mind these protocol names not being 100% correct. Most users who have previously used IR using another firmware probably did so directly or indirectly through the IRremote library. So if you already have the IR codes for the other frameworks you can use them here too.

Also, when "dumping" these remote codes using the remote receiver component, you get the name of the protocol too. So when the user presses the remote on an LG soundbar, they get a message saying "samsung code=bla ..." - and the user probably doesn't really care whether it says lg or samsung as long as it works :)

The other aspect to this is that renaming the protocol would be a breaking change, and I don't like breaking changes unless they're absolutely necessary. And even if the lg, ... protocol names are a bit off, they're far more memorable than the nec1, nec2, ...

I mean I don't really care that much. Maybe if I would re-do this implementation I would change it, but personally I don't really see a big reason why to change it now. Yes it's technically incorrect but as long as it works ¯_(ツ)_/¯

[yawor]

@OttoWinter that's fair enough. I've been thinking about adding some form of aliases to keep compatibility with the old names, but it's probably not worth doing that. At least not when there are a lot of other issues and features to be taken care of.

[yawor]

One more thing regarding receiving IR signals. I've just connected a TSOP38348, with following configuration:

remote_receiver:
  pin:
    number: 33
    inverted: true
    mode: INPUT_PULLUP
  dump: all

I have a NEC1 remote from a cheap IR controlled RGBW LED driver. If I press and hold the button, I get this in the logs:

[21:34:52][D][remote.lg:100]: Received LG: data=0x00FF1AE5, nbits=32
[21:34:52][D][remote.nec:105]: Received NEC: address=0x00FF, command=0x1AE5
[21:34:52][D][remote.raw:051]: Received Raw: 9344, -4491, 636, -494, 616, -541, 621, -537, 637, -492, 618, -540, 612, -545, 639, -491, 619, -538, 614, -1656, 617, -1680, 592, -1678, 616, -1654, 619, -1678, 584, -1686, 618, -1652, 621, -1676, 586, -543, 620, -536, 616, -541, 590, 
[21:34:52][D][remote.raw:064]:   -1679, 615, -1655, 618, -538, 614, -1656, 617, -540, 612, -1658, 615, -1682, 590, -1680, 614, -543, 588, -541, 622, -1676, 586, -543, 620, -1678, 584, -32510
[21:34:52][D][remote.raw:064]: Received Raw: 9378, -2185, 616, -32510
[21:34:52][D][remote.raw:064]: Received Raw: 9381, -2183, 618, -32510
[21:34:52][D][remote.raw:064]: Received Raw: 9372, -2188, 613, -32510
[21:34:52][D][remote.raw:064]: Received Raw: 9359, -2186, 615, -32510
[21:34:52][D][remote.raw:064]: Received Raw: 9352, -2192, 620, -32510

It is correctly recognised as both LG and NEC (as it's basically the same thing). I understand that I always get dump of raw data, which is ok. But I wonder how hard it would be to implement proper button hold detection. NEC1 protocol doesn't do full frame repeat, but sends only a so called Ditto frame, which is always the same (like above for NEC1 and "[phone] +564 -564 [phone]" for NECx1 - compatible with samsung in esphomelib).
The button hold detection is needed if someone would for example like to smoothly increase/decrease light brightness.

[josh929800]

I am using the IRMQTTServer from the same repository. The thing I like about this server is whatever you feed into it. The code will decode it and you can then re-transmit that same code. E.G. I could feed it a remote code from remote central in pronto format. It would send the code out and receive it and tell me what the IR code is. The catch is you have to prefix your code with a number that represents the type of code. https://github.com/markszabo/IRremoteESP8266/tree/master/examples/IRMQTTServer

[jay-wilkinson]

@josh929800 Thanks for that link. It appears to be a short term solution to a problem I have.
@OttoWinter I'd like to suggest and vote for the Pronto protocol.
Technical info: http://www.remotecentral.com/features/irdisp2.htm
Codes Database: http://files.remotecentral.com/library/3-1/index.html
The reason I need this is I'm trying to control an RCA 5.1 Receiver. RCA doesn't use the same modulation frequency as almost every other device on the planet. They used a carrier frequency of 56kHz. And of course any IR LED will work fine but the IR receiver has to be made for 56kHz. Without the correct receiver, I can't capture the codes in RAW format. The codes exist in Pronto and I've played with them using IRremoteESP8266 and they do work. Implementing this protocol would create a bridge to a lot of very old (10 - 20+ years) devices.
RCA IR info: https://www.sbprojects.net/knowledge/ir/rca.php

[aenertia]

Upstream IRemoteESP8266 now has full support for ESP32 - including things like Daikin etc from there should now be relatively trivial.

[OttoWinter]

@aenertia Yes, but that has never been the problem - ESPHome has support for ESP8266/ESP32 already and a pretty good API for sending/receiving codes. The individual protocols just need to be implemented.

[Ariskayler]

Yeah. That would be so nice!

[JoshuaSG]

Would it be difficult to implement the GlobalCache protocol? It's a nice universal code format that is easily searchable. It is implemented for the ESP8266 here on IRremoteESP8266 https://github.com/crankyoldgit/IRremoteESP8266/blob/master/src/ir_GlobalCache.cpp

[subzero79]

Is it possible to add LG2 to the available protocols. It was already in IRremoteESP8266 as you can see

https://github.com/crankyoldgit/IRremoteESP8266/blob/master/src/ir_LG.cpp