Posts by HiassofT

  • MCEUSB IR blasting in Libreelec

    Here's the link to the testbuild:

    LibreELEC-RPi2.arm-8.2-devel-20171130133422-r26229-ga24418465c.tar

    ir-ctl doesn't to any automatic repeat handling, it just transmits each scancode once.

    With the new version you can specify the delay (gap) between signal transmits on the command line. It should be about 25000.

    To send out 3 repeats with 25ms inbetween do this:

    Code
    ir-ctl -g 25000 -S sony12:0x100015 -S sony12:0x100015 -S sony12:0x100015

    You can also store scancodes in a file, like this:

    Code
    LibreELEC:~ # cat sony-power.irctl
scancode sony12:0x100015
scancode sony12:0x100015
scancode sony12:0x100015


    and transmit that with ir-ctl

    Code
    ir-ctl -g 25000 -s sony-power.irctl

    As an alternative you can specify the delay between scancodes in the file

    Code
    scancode sony12:0x100015
space 25000
scancode sony12:0x100015
space 25000
scancode sony12:0x100015

    In that case the -g option of ir-ctl is not needed

    One thing to keep in mind is that when sending a file all of it will be transmitted in a single call - and you can run into the limit of the lirc device. When using -s or -S multiple times each of the scancodes / files are transmitted in separate calls, so you don't run into the limits that easily.

    so long,

    Hias

  • MCEUSB IR blasting in Libreelec

    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

  • MCEUSB IR blasting in Libreelec

    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

  • MCEUSB IR blasting in Libreelec

    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

  • MCEUSB IR blasting in Libreelec

    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

  • LE Auto-Update to 8.2.1 ?

    You may need to enable the "wait for network online" option in LE Settings -> Network.

    If the network configuration (DHCP etc) takes too long the LE update and addon update checks running on Kodi startup can run into network errors because the net isn't up - if this is happening it should be logged in kodi.log.

    so long,

    Hias

  • MCEUSB IR blasting in Libreelec

    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

  • MCEUSB IR blasting in Libreelec

    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

  • MCEUSB IR blasting in Libreelec

    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

  • MCEUSB IR blasting in Libreelec

    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

  • Wolfson/Cirrus Logic audio card is now supported in official LibreELEC builds

    I recommend that you upgrade to the latest LibreELEC release (currently 8.2.0.1 for RPi), other than that you don't need to install any software/addons - Kodi works fine as a music player.

    Also have a look at the Yatse app for Android, it allows you to browse through your music library and start/stop/queue songs from your Android tablet or phone without having to turn on the TV. This is what I'm using here and it works really great.

    so long,

    Hias

  • [RPi3] OK Button doesn't work on H1 Remote

    OK, let's try something different. We can remap the OK key with a hwdb file.

    First install the system tools addon (from LibreELEC repository -> Programs) as we'll need the evtest program. Also remove the udev conf file from the previous test.

    Reboot with only the wireless remote connected, then ssh in and stop kodi.

    Code
    systemctl stop kodi

    Now lookup the remote in /proc/bus/input/devices. According to the infos in post 3 there should be 2 entries, one for the keyboard / remote part and one for the mouse - we're interested in the former. Look at the name entries (Name="2.4G Smart Remote") and the handler (Handlers=sysrq kbd eventX) to locate it - ignore the one with the mouse handler.

    We need the event device number (eventX) and sysfs path from that block:


    Now run evtest on the event device (substitute event0 with the event device number from above)

    Code
    evtest /dev/input/event0

    Press the OK button, you should get something like this:

    Code
    Event: time 1510571041.251851, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70028
Event: time 1510571041.251851, type 1 (EV_KEY), code 352 (KEY_OK), value 1
Event: time 1510571041.251851, -------------- SYN_REPORT ------------
Event: time 1510571041.291835, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70028
Event: time 1510571041.291835, type 1 (EV_KEY), code 352 (KEY_OK), value 0
Event: time 1510571041.291835, -------------- SYN_REPORT ------------

    We are interested in the scancode of the button, that's the value in the EV_MSC line. In the output above that would be 70028. The EV_KEY line tells us which key code the button/key is mapped to - in above example it's KEY_OK (which kodi can't handle), we want to remap that to KEY_ENTER (which kodi supports).

    Now stop evtest with ctrl-c.

    Next thing we need is the modalias of the input device. We can get that with udevadm using the sysfs path from above. Run the following command, replace the long /devices/platform/... path with the one you got from /proc/bus/input/devices

    Code
    udevadm test /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0/0003:25A7:5704.0001/input/input0 2>&1 | grep ^MODALIAS

    This should print a line like this:

    Code
    MODALIAS=input:b0003v05A4p9881e0110-e0,1,4,11,14,k77,7D,7E,7F,160,ram4,l0,1,2,sfw

    The important info from that line is the "input:bXXXXvYYYYpZZZZ" part. In your case that would probably be "input:b0003v25A7p5704" (b0003 is USB bus, followed by v and uppercase USB vendor id, followed by p and uppercase USB product id) - we can ignore the stuff after that (eXXXX is the version info from USB).

    Now with this info we can create a /storage/.config/hwdb.d/70-local-keyboard.hwdb file with the following content. Replace the "input:..." and the scancode in KEYBOARD_KEY_XXXXX with your values. Don't forget the "*" at the end of the evdev:input:... line!

    Code
    evdev:input:b0003v05A4p9881*
 KEYBOARD_KEY_70028=enter

    To activate the config run the following commands:

    Code
    udevadm hwdb --update
udevadm trigger -s input

    Then run evtest again, press the OK button and verify that you now see KEY_ENTER in the EV_KEY lines

    Code
    evtest /dev/input/event0
...
Event: time 1510573065.623580, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70028
Event: time 1510573065.623580, type 1 (EV_KEY), code 28 (KEY_ENTER), value 1
Event: time 1510573065.623580, -------------- SYN_REPORT ------------
Event: time 1510573065.663566, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70028
Event: time 1510573065.663566, type 1 (EV_KEY), code 28 (KEY_ENTER), value 0
Event: time 1510573065.663566, -------------- SYN_REPORT ------------

    If it doesn't work please post the evtest output and the contents of your hwdb file.

    so long,

    Hias