Posts by HiassofT

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

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:

begin remote
  name  Sony-RM-U305A
  bits           12
  flags SPACE_ENC|CONST_LENGTH
  eps            30
  aeps          100
  header       2400   600
  one          1200   600
  zero          600   600
  gap          45000
  toggle_bit_mask 0x0
  frequency    38000
      begin codes
          KEY_VIDEO                0x441
          KEY_POWER                0xA81
          KEY_DVD                  0xBE1
          KEY_VOLUMEUP             0x481
          KEY_VOLUMEDOWN           0xC81
          KEY_MUTE                 0x281
      end codes
end remote

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

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

so long,

Hias

Post your lircd.conf, maybe this'll give some hints.

so long,

Hias

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

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

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:

ir-ctl -S rc5:0x1234

so long,

Hias

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

Please post issues with milhouse builds on the kodi forum LibreELEC Testbuilds for x86_64 (Kodi 18.0)

The last few posts in this thread also describe a workaround you can try: run "ir-ctl -t 100000".

so long,

Hias

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.

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:

Quote

I: Bus=0003 Vendor=25a7 Product=5704 Version=0101

N: Name="2.4G Smart Remote"

P: Phys=usb-3f980000.usb-1.3/input0

S: Sysfs=/devices/platform/soc/http://3f980000.usb/usb1/1-1/1-1.3…01/input/input0

U: Uniq=

H: Handlers=sysrq kbd event0

B: PROP=0

B: EV=10001f

B: KEY=3f 3007f 0 0 0 0 483ffff 17aff32d bf544446 0 0 1 130f93 8b17c007 ffff7bfa d941dfff febeffdf ffefffff ffffffff fffffffe

B: REL=40

B: ABS=1 0

B: MSC=10

Display More

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

evtest /dev/input/event0

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

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

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:

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!

evdev:input:b0003v05A4p9881*
 KEYBOARD_KEY_70028=enter

To activate the config run the following commands:

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

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

Thanks for the feedback and I'm glad it works now!

In 8.0 the Lirc option was mistakingly enabled in a lot of cases without actually doing anything, but in 8.2 this can now cause issues.

So you don't loose anything by disabling it, on the contrary, you restore the state that your remote receiver was meant to be used - handled by the Linux kernel instead of Lirc.

so long,

Hias

Sorry, had a stupid little bug in the rule - missed the "\" at the end of the first line

# 2.4G Smart Remote with keyboard and mouse inputs
ENV{ID_VENDOR_ID}=="25a7",  ENV{ID_MODEL_ID}=="5704", ENV{ID_INPUT_KEYBOARD}=="?*", \
  ENV{eventlircd_enable}="true"

I fixed the file, could you re-download and try again?

so long,

Hias

Could you try downloading this file 98-eventlircd.rules to /storage/.config/udev.rules.d/98-eventlircd.rules and then reboot

wget -O /storage/.config/udev.rules.d/98-eventlircd.rules http://www.horus.com/~hias/tmp/libreelec/24gsmartremote/98-eventlircd.rules

This'll add the following block to the usb section of eventlircd udev rules file so that eventlircd will pick up input from your remote

# 2.4G Smart Remote with keyboard and mouse inputs
ENV{ID_VENDOR_ID}=="25a7",  ENV{ID_MODEL_ID}=="5704", ENV{ID_INPUT_KEYBOARD}=="?*",
  ENV{eventlircd_enable}="true"

Please check if the keyboard part of your remote still works, I fear shift, control, caps etc will then be non-functional.

so long,

Hias

Can your try disabling Lirc in LE Settings (Settings -> Services -> Lirc),, then reboot and check if it works then?

What kind of remote are you using? Did you add or change any files in /storage/.config/ like lircd.conf, udev.rules.d or rc_maps?

so long,

Hias

Did this remote come with a USB dongle?

Please post the output of the following commands:

lsusb
dmesg | paste
cat /proc/bus/input/devices

so long,

Hias

Disable Lirc in LE settings as mentioned in the release notes LibreELEC (Krypton) 8.2.0 RELEASE – LibreELEC

so long,

Hias

Hi Jeroen,

thanks a lot for the feedback! I created a PR with the changes, so the fix should be included in 8.2.1

[LE8.2] macmini IR wakeup-from-suspend fixes by HiassofT · Pull Request #2189 · LibreELEC/LibreELEC.tv · GitHub

so long,

Hias

I did some more digging but I'm still not sure who's to blame for the wakeup issues. Could be kernel 4.11, could be atvclient - no idea.

I think the best solution is to build the hid-appleir driver as a module. Other major linux distributions do this as well, people can still use the remote without atvclient and it's also easy to disable the driver via a simple modprobe blacklist entry.

Could you please do a test with this build: LibreELEC-Generic.x86_64-8.2-devel-20171108132958-r26201-g0285ca7ff1.tar

This build includes the appleir driver as a module, to disable it create a file /storage/.config/modprobe.d/disable-appleir.conf with the following content:

blacklist hid_appleir

I've also enabled wake-from-suspend per default on the appleir USB device so you should no longer need the "echo enabled > /sys/bus/usb/devices/2-1.8.2/power/wakeup" line in autostart.sh.

Could you create the modprobe file and remove the wakeup link from your autostart.sh and test if that setup works?

so long,

Hias

FLIRC doesn't use lirc or in kernel decoding so none of the stuff from the Infrared Remotes wiki page applies here.

But "RPi freezing" could indicate a marginal power supply or too high overclock setting in which case all kinds of strange things can happen. I'd start looking into that first.

so long,

Hias