Infrared + Keyes IR input 838B

Having issues with your DietPi installation or found a bug? Post it here.
Post Reply
Posts: 10
Joined: Thu May 02, 2019 9:03 pm

Infrared + Keyes IR input 838B

Post by jhorv »


I would like to use my TV (Samsung) remote with Kodi. Apparently the remote is CEC compatible and the adapter actually loads in Kodi but my remote doesn't work. So I bought a VS1838 IR receiver module and I also have a Keyes IR input 838B (also known as HX1838B) which came with another generic remote. I tested them out on my ESP8266 running Tasmota and they both work flawlessly. On my Raspberry Pi Zero W however I can't get them to work.

From what I know LIRC appears to be on its way out and gpio-ir is taking its place. In fact a LIRC installation is not even required because the devinput driver is supposed to be already set with GPIO 18 being the default. From what I read elsewhere, this scheme should work "out of the box" if being used only for IR input, but it doesn't.

I added the following to /DietPi/config.txt:
Supposedly this should be enough. After booting when I check with dmesg I get the following:
root@DietPi:~# [ 10.438978] Registered IR keymap rc-rc6-mce
root@DietPi:~# [ 10.469685] IR RC6 protocol handler initialized
root@DietPi:~# [ 10.503879] rc rc0: gpio_ir_recv as /devices/platform/ir-receiver@12/rc/rc0
root@DietPi:~# [ 10.504308] input: gpio_ir_recv as /devices/platform/ir-receiver@12/rc/rc0/in put0
root@DietPi:~# [ 10.504761] rc rc0: lirc_dev: driver gpio_ir_recv registered at minor = 0, raw IR receiver, no transmitter
There is a LED on the HX1838B which flashes whenever a signal is received. However when I boot my RPi0w the LED is constantly on, meaning the pin is high even though I specified in the config.txt file that it should be low. It goes without saying that when I press a button on the remote nothing happens.

So it appears the IR driver is loaded but it can't communicate with the GPIO because something has grabbed it, that is why it is high. I disabled the CEC adapter in Kodi thinking that this might be the conflict but the problem persists.

From what I know, among the limitations of using the gpio-ir only method is that there must be exactly one capture device supported by the kernel and that the remote used must also be supported by the kernel. Maybe this is the problem?

Post Reply