2014-10-14, 18:05
Maybe this has already been done, but I've never noticed it.....
I've been using a universal remote, a Flirc and an IR extender to control my XBMC (which sits one floor below my living room TV). However, it seems to be a fairly common problem that the Flirc doesn't work very well with many IR extenders, so my control has been somewhat unreliable even after playing with many of the Flirc settings. I think IR extenders in general just suck.
Not sure if this will help anyone else, but last night I played around with a raspi and an old MCE USB-based IR receiver and I got it so the raspi is now a "repeater" which receives an IR signal in my living room and then sends out a JSON request to XBMC with the corresponding command. So far it seems perfectly reliable, much more so than the IR extender.
For anyone interested (maybe not many of you!), here are the basics:
My raspi is running raspbian, and I installed lirc with a simple sudo apt-get install lirc. My USB receiver is a MCE USB-based receiver, and for testing I used an old MCE remote control.
I configured lirc to use the MCE USB receiver by editing hardware.conf (to use /dev/lirc0) and copying the mceusb lircd.conf file from the pre-packed config settings directory (I believe it's /usr/share/lirc/remotes/mceusb/). I started lircd and used irw to test that the commands are being received by lirc.
To configure the action of sending a JSON request each time an IR command is received, I'm using irexec. In the .lircrc file (used by irexec), I have entries like this for each button-JSON mapping:
begin
button = KEY_UP
prog = irexec
config = curl --data-binary '{ "jsonrpc": "2.0", "method": "Input.Up", "id": "mybash"}' -H 'content-type: application/json;' http://192.168.1.140:8080/jsonrpc
end
These get a little more complicated for requests that require a playerID, but this is generally the flow. In this example it basically means that each time the KEY_UP button is detected, it sends a curl request to my XBMC with a JSON payload that tells it to go "up", and so there will be one entry like this for each remote control button.
I configured irexec to run in daemon mode on startup, and so far everything seems to work great. I would say that it's about as responsive as my old setup, which is "good" but not "great". Mine is currently running on wifi, so I may experiment with ethernet to see if it improves response time at all. However more importantly is the fact that it's very reliable.
For now I will continue to use Flirc for certain commands, because I have it configured to do things that are not easily available through JSON. The Flirc is a really great device, but it just hasn't been working very well with the IR extender.
Hope this helps someone.
I've been using a universal remote, a Flirc and an IR extender to control my XBMC (which sits one floor below my living room TV). However, it seems to be a fairly common problem that the Flirc doesn't work very well with many IR extenders, so my control has been somewhat unreliable even after playing with many of the Flirc settings. I think IR extenders in general just suck.
Not sure if this will help anyone else, but last night I played around with a raspi and an old MCE USB-based IR receiver and I got it so the raspi is now a "repeater" which receives an IR signal in my living room and then sends out a JSON request to XBMC with the corresponding command. So far it seems perfectly reliable, much more so than the IR extender.
For anyone interested (maybe not many of you!), here are the basics:
My raspi is running raspbian, and I installed lirc with a simple sudo apt-get install lirc. My USB receiver is a MCE USB-based receiver, and for testing I used an old MCE remote control.
I configured lirc to use the MCE USB receiver by editing hardware.conf (to use /dev/lirc0) and copying the mceusb lircd.conf file from the pre-packed config settings directory (I believe it's /usr/share/lirc/remotes/mceusb/). I started lircd and used irw to test that the commands are being received by lirc.
To configure the action of sending a JSON request each time an IR command is received, I'm using irexec. In the .lircrc file (used by irexec), I have entries like this for each button-JSON mapping:
begin
button = KEY_UP
prog = irexec
config = curl --data-binary '{ "jsonrpc": "2.0", "method": "Input.Up", "id": "mybash"}' -H 'content-type: application/json;' http://192.168.1.140:8080/jsonrpc
end
These get a little more complicated for requests that require a playerID, but this is generally the flow. In this example it basically means that each time the KEY_UP button is detected, it sends a curl request to my XBMC with a JSON payload that tells it to go "up", and so there will be one entry like this for each remote control button.
I configured irexec to run in daemon mode on startup, and so far everything seems to work great. I would say that it's about as responsive as my old setup, which is "good" but not "great". Mine is currently running on wifi, so I may experiment with ethernet to see if it improves response time at all. However more importantly is the fact that it's very reliable.
For now I will continue to use Flirc for certain commands, because I have it configured to do things that are not easily available through JSON. The Flirc is a really great device, but it just hasn't been working very well with the IR extender.
Hope this helps someone.