MCEUSB IR blasting in Libreelec

  • I have been using Libreelec since is was forked, and before I used Openelec. I have had a serious puzzle in the past to get my MCEUSB IR receiver up and running where I only use ir blasting to control my TV and amplifier. Since Libreelec 8.x I cannot get it working anymore. I've read a lot about Lirc being replaced by ir-support in kernel, but as far as I understand this is only for IR receiving. I have not been able to find a wiki/guide how to set up IR blasting in Libreelec 8.x, only for receiving. can someone point me in the right direction to get this working again?


    My MCEUSB is found:

    Code
    dmesg | grep Infrared
    [ 2.413489] usb 1-1.3: Product: eHome Infrared Transceiver
    [ 5.166912] rc rc0: Media Center Ed. eHome Infrared Remote Transceiver (0471:0815) as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0/rc/rc0
    [ 5.336338] input: Media Center Ed. eHome Infrared Remote Transceiver (0471:0815) as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0/rc/rc0/input0
    [ 5.552379] mceusb 1-1.3:1.0: Registered Philips eHome Infrared Transceiver with mce emulator interface version 1
    Code
    dmesg | grep mceusb
    [ 5.240141] rc rc0: lirc_dev: driver ir-lirc-codec (mceusb) registered at minor = 0
    [ 5.552379] mceusb 1-1.3:1.0: Registered Philips eHome Infrared Transceiver with mce emulator interface version 1
    [ 5.552407] mceusb 1-1.3:1.0: 2 tx ports (0x0 cabled) and 2 rx sensors (0x1 active)
    [ 5.552631] usbcore: registered new interface driver mceusb

    I have a lircd.conf file in /storage/.config, exactly the same file that was working perfectly in Libreelec 7.x. But if I do a irsend -d /run/lirc/lircd-lirc0 SEND_ONCE "RM-U305_func" "ON/OFF" I get the message "do_connect: could not connect to socket", which sounds logical because the port does not exist. In Libreelec 7.x this was the correct port to blast to. I cannot find the correct port in Libreelec 8.x. I have tried every location with something with "lirc" in it, but no luck.


    I hope someone can help me with this! :blush:

  • In LE 8.2 the lircd socket is /run/lirc/lircd.socket - keep in mind that you also have to enable Lirc in LE Settings -> Services and probably have to disable in-kernel decoding if you want to use it. See the wiki page for details infrared_remotes [LibreELEC]


    As an alternative to lircd / ir-send you can also use ir-ctl for "IR blasting". You don't need to run lircd for that and can simply specify the IR protocol and scancode to transmit. eg:


    Code
    ir-ctl -S rc5:0x1234


    so long,


    Hias

  • Hi HiassofT,


    Thnx for your reply.:thumbup:

    Never found ir-ctl. Will give it a try! Which option would you suggest to continue with, lircd/irsend or the ir-ctl? I had a working Lircd based solution, but I get the idea that Lircd is being fased out...


    Can you recommend a source for scancodes to control a Sony Home Theater receiver and a Philips TV?

  • Use whatever suits your needs best.


    We don't have plans to remove lirc - it's still very useful for supporting remotes which aren't handled by the kernel (yet). OTOH if you like to try something new have a look at ir-ctl.


    Sony equipment should use one of the sony protocol variants (12, 15 or 20 bits data) and Philips equipment rc5 (or maybe rc6) - these protocols are supported by the kernel and ir-ctl, so it should work.


    To find out which scancodes you need to transmit it's easiest to check with ir-keytable -t (also specify the protocol, eg -p sony, -p rc5 etc) and press the button of the remote.


    While ir-keytable will automatically decode all bit-length variants of a protocol you have to manually specify the bit-length when blasting. Just try the different sony protocol variant (eg ir-ctl -S sony12:0x11) and check which ones work.


    ir-ctl can also record and send raw signal files, details about this and the other options are in the manpage eg Ubuntu Manpage: ir-ctl - a swiss-knife tool to handle raw IR and to set lirc options


    so long,


    Hias

  • Woow, this is great! Thanks so much for your help! I'm feeling stupid I did not find the correct socket, I have been trying and searching, but no luck. Now I have my Philips TV working again.


    Still have a problem with the Sony receiver. Does not respond to irsend -d /run/lirc/lircd.socket SEND_ONCE "RM-U305_func" "VIDEO". The blasting led flashes, but no response from the receiver. It used to work when I was still at OE 4.x. I remember something with Sony IR that you needed to repeat the signal, maybe you know more about this?

  • I never used irsend before, so not 100% sure what's going wrong.


    irsend seems to support a -#/--count option to send a command multiple times. Maybe this could help?


    Or it could be that lircd doesn't like the sony remote definition in your lircd.conf - OE 4.x came out rather long ago and LE 8.2 is using a much newer version of lirc. You could run "systemctl status lircd" and check if lircd logged any errors or warnings.


    so long,


    Hias

  • Hi, just checked and no errors in the "systemctl status lircd". When I add another (different) Sony remote and try to use it, I do get errors. So I removed it again and went back to the original. Leds on the transmitters flash (so I assume it gets an signal), but still no response from my receiver. I will keep on puzzling and maybe try ir-ctl (only need to find out how to get the codes, since I don't have the original remotes :/).

    If you or anyone else has new suggestions, please let me know. I really like the helpfulness of this forum!! :thumbup: Thnx!!

  • Below my lircd.conf. I just created and added the Sony-RM-U305A, by using irrecord and a mobile phone which has IR remote option. The phone itself works perfect on the receiver, the resulting remote in lircd.conf does not work. The led on the ir blaster flashes, no response from receiver.

  • Thanks for posting the lircd.conf file, it looks OK to me.


    I have it a try with lircd 0.9.0 (as used in OE 4.0) and 0.9.4d and was able to transmit IR signals. I don't have any sony receiver, but checking with another RPi using ir-keytable -t I saw that with both versions identical scancodes (0x100015) were received.


    The signal timing isn't 100% accurate (typical when irrecord is used without templates), here's a cleaned up version:

    With this file signal timing is identical to what my universal remote generates (and what's typical for the sony IR protocol) - verified with my scope hooked up to the IR receiver.


    One thing I noticed in your lircd.conf file is that the RM-U305_func remote has min_repeat set to 3 - so lirc will repeat the signal 3 times when sending. It's not uncommon that devices require the power button on the remote to be pressed for a longer time to wake up.


    So, could you try if it works when you transmit the power button 3-10 times? eg

    Code
    irsend -d /run/lirc/lircd.socket -# 5 SEND_ONCE Sony-RM-U305A KEY_POWER


    so long,


    Hias

  • Hi Hias, thnx for your serious effort to help me!! Really appreciated!

    I tried your tuned remote, but no luck. Led flashes, but no response from receiver. I noticed that with my other remotes (RM-U305_func), when I send the signal twice very quickly after each other, the receiver receiver responses in the correct way. So I thought if I double the min_repeat, it might work in once. Strangely enough, I need to repeat 5 times quickly after each other to get a response. :/ I would expect something different.....

    I also tried the "-# 5", "-# 3" etc. but no luck.

  • How exactly did you repeat sending the signal, did you run irsend multiple times? What was min_repeat set to in the lircd conf when you did that?


    Using min_repeat in lircd and -# with irsend should have the same effect. So it's a bit puzzling what's going on.


    Could you try changing the gap value? Try both lower (eg 30000, 40000) and higher (eg 50000, 60000) values and also use min_repeat 3 or higher (or -# 3 etc). This affects the time between signal repeats, maybe the signals are sent too quickly after each other or too fast.


    so long,


    Hias

  • I'm trying both options in several configurations. I just had success with your tuned remote with "-# 5", I could turn it on and off, but only one time. Now it does not work anymore...

    I tried gap value 30000 and it works again, but after turning on, off and on again I get a

    Code
    busy: repeating
    Error running command: Input/output error

    after a reboot it works again. After several commands the receiver stops responding, although the led flashes the same as when it was working.


    I use this command (I renamed the Keys, hoping LibreElec itself would not respond to the command (see last remark in this post):

    Code
    irsend -d /run/lirc/lircd.socket -# 5 SEND_ONCE "Sony-RM-U305A" "VIDEO"

    It kind of works now, but a bit unstable. If I run from command-line, sometimes the command had been executed, but I need a Ctrl-C to get a prompt back.... So it gets stuck somewhere.


    Code
    Nov 28 23:44:18 GuustHTPC lircd_helper[342]: lircd-0.9.4d[342]: Info: removed client
    Nov 28 23:44:18 GuustHTPC lircd-0.9.4d[342]: Info: removed client
    Nov 28 23:44:18 GuustHTPC lircd_helper[342]: lircd-0.9.4d[342]: Notice: accepted new client on /run/lirc/lircd.socket
    Nov 28 23:44:18 GuustHTPC lircd-0.9.4d[342]: Notice: accepted new client on /run/lirc/lircd.socket
    Nov 28 23:44:18 GuustHTPC lircd_helper[342]: lircd-0.9.4d[342]: Error: error processing command: SEND_ONCE Sony-RM-U305A VIDEO 5
    Nov 28 23:44:18 GuustHTPC lircd_helper[342]: lircd-0.9.4d[342]: Error: busy: repeating
    Nov 28 23:44:18 GuustHTPC lircd-0.9.4d[342]: Error: error processing command: SEND_ONCE Sony-RM-U305A VIDEO 5
    Nov 28 23:44:18 GuustHTPC lircd-0.9.4d[342]: Error: busy: repeating
    Nov 28 23:44:18 GuustHTPC lircd_helper[342]: lircd-0.9.4d[342]: Info: removed client
    Nov 28 23:44:18 GuustHTPC lircd-0.9.4d[342]: Info: removed client


    And I got a new challenge. Sometimes when I send a VolumeUp to the receiver, LibreElec responds, showing the volume icon. Same for power. Must be something simple, but I'm stuck...

  • I got this lockup, too, once during tests. IIRC it happened when I started another irsend on command line immediately after a previous irsend. Not really sure though, I'll try to look into it and see if I can reproduce.


    As for LE seeing the sent signals: have you disabled in-kernel decoding (create an empty /storage/.config/rc-maps.cfg file)? When you run ir-keytable you should see only "lirc" under enabled protocols.


    Maybe lirc is "seeing" it's own transmitted signals, in that case renaming the buttons (so they don't start with KEY_) looks like a good workaround.


    so long,


    Hias

  • I could reproduce the hang, it seems to be caused by the combination of using repeats and invoking irsend quickly after each other. When I waited a bit beween irsend starts (fractions of a second were usually enough) it worked fine.


    This seems to be a lirc bug, and I could reproduce it also in the latest lirc version (0.10.1). I've opened a bug report here:

    LIRC / Tickets / #315 irsend / lircd hang when using repeats


    BTW: ir-ctl also seems to have issues (though different ones) when trying to send repeated signals. I reported that here [BUG] ir-ctl: error sending file with multiple scancodes


    so long,


    Hias

  • I have created an empty rc-maps.cfg, but it's not fixed yet. I noticed that directly after reboot the remote works perfect, without interfering with Libreelec, but when lirc hangs the irsend commands seem to be handled by LibreElec, resulting in showing the volume icon (and acting). Another reboot solves this again.

    By the way, it is pretty difficult to avoid quick repeating commands, when trying to lower the volume for example. This normally involves several repeated commands.


    I might try to experiment with ir-ctl. I read that sony12, sony15 and sony20 are supported, but where can I find the known commands? On this website (Sony Receiver (16, 13, 12, 18, 24, 144, 121, 25.11; 48, 45, 176)) I see a list with device codes and command codes. How can I extract/compose the scancode to be send to switch my receiver to VIDEO for example? Or send discrete PowerOff?

    I see as header above the table Sony:16; 48 (volume, power, inputs) and in the table 34 - Video 1, Aux and 47 - Power Off (discrete). Do you know?

  • Thanks for the info, it could well be that the lirc hanging-bug causes it to somehow see and decode it's own signals.


    If that's the case you could try to disable the lircd-uinput service. This'll prevent the decoded signals to reach kodi, but it also means that controlling kodi via IR remote is no longer possible:

    Code
    systemctl mask lircd-uinput

    To re-enable lircd-uinput use "systemctl unmask lircd-uinput".


    Composing the sony scancodes for irctl is rather simple: the scancode is a 6-digit hex number, the first 2 digits are the device address (00-1f for sony12, 00-ff for sony15), next 2 digits are 00 (IIRC they'd be the 5 highest address bits in sony20) and the last 2 digits are the command (00-7f).


    So the KEY_POWER scancode I used for testing, 0x100015 means device address 0x10 (16 decimal) and command 0x15 (21 decimal).


    Just play around with the last 2 (command) digits, seems the first table on that webpage (sony 16) is the correct one for your receiver.


    BTW: Sean sent me a fix for ir-ctl and it's now also easier to send repeated commands. Which system are you using? If it's RPi2/3 I could upload you a 8.2.1 build with the fix included for testing.


    so long,


    Hias

  • Thanks for the info on ir-ctl. I'm trying with several codes (0x10002F, 0x100015, 0x0C0015), but no luck yet. From the flashing of the led it seems it only sends the code once (short flash, instead of several flashes I have with irsend.

    I would expect by selecting a Sony protocol, the multiple sends are included?


    I would be happy to test a new build, I'm using a RPi2, but I have not yet been able to send at least one successful command trough ir-ctl, I will keep on trying.