Notes on setting up OpenELEC on a Raspberry Pi

First, before you go out an buy a Raspberry Pi for this purpose, keep in mind that it does not have any type of digital audio output (such as a TOSLINK connector), other than the HDMI output – see discussion here. This may or may not be an issue in your installation, but you should be aware of that going into the project.

While you could use NOOBS to set up OpenELEC, you may not get the latest version. You are better off using these installation instructions and downloading the latest build.

OpenELEC is very fast but much of the file system is read only, and even if you SSH in as root you cannot edit many of the configuration files as you could on a normal Linux system. Sometimes there are ways around that. For example, Samba by default is controlled by the file /etc/samba/smb.conf. But you can’t edit that file. However, if you navigate to the /storage/.config directory you will find a file called samba.conf.sample. If you copy or rename that file to samba.conf in the same directory, then that becomes the file that controls Samba, and you can edit that file. For example, you can change the share name by editing the line server string = OpenELEC and changing OpenELEC to something else, and then find the line netbios name = %h and change the %h to the same thing you used as the value for the server string.

Also if you don’t want your Raspberry Pi acting as a Master Browser for your local network, you can comment out the following lines in samba.conf, as shown here:

# domain master = yes
# local master = yes
# preferred master = yes

When you are in XBMC you may notice that the CPU usage seems high. This is apparently because of two things. First, the act of measuring the usage in XBMC and drawing the usage bar on the GUI actually consumes significant CPU power. You can confirm this by using SSH and then the top command to view actual actual usage. When you are on screens that are completely static, with nothing being continually redrawn, the CPU usage will be lower. But also, if you go into XBMC’s settings (System | Appearance | Skins) and turn off the RSS feed, your CPU usage will drop considerably. Note that actually playing video content actually causes CPU usage to decrease since the work of drawing the screen is transferred to the GPU. On the other hand, leaving the XBMC GUI parked on certain pages may cause CPU usage to increase – for example, we found that if we went to a page that displayed large size thumbnails and fanart, the CPU usage shot up considerably.

To get a PVR plugin to work, you must first enable Live TV. Only then will you be given the option to pick a PVR frontend, But note that even if you set it up properly, you might get audio only and no video. As best I can determine, the reason is that neither the Raspberry Pi nor OpenELEC contains a license to play MPEG2 video. The Raspberry Pi folks will be happy to sell you a license, but we didn’t bite so have no idea if it works or not, and we have read where others have had mixed results. Keep in mind that MythTV, and probably other PVR backends, have the ability to transcode recorded programs to another format that does not require a license, so if all you want to do is watch previously recorded content and not actual live TV, you could just set up the backend to transcode everything to a format that the Raspberry Pi will play after it is recorded.

OpenELEC and the Raspberry Pi will output 1080p, however it appears that on some TV’s you need to go into XBMC’s setting and explicitly specify playback at 1080p, otherwise it will default to 720p. This happened for us on one TV set but not on another.

One question remains, some older TV’s need a “CVT reduced blank” signal before they will offer a Dot-by-Dot mode that has no overscan issues. In normal systems you can change this by using specific software, or in Linux, a specific ModeLine in the xorg.conf file. But it appears that OpenELEC has no support for this. This might make OpenELEC a poor choice for those users. Fortunately, you can also try other distributions for the Pi, such as Raspbmc, XBian, or GeeXboX.

Some people are gluttons for Pi: Mounting multiple Raspberry Pi devices

Some fans of the Raspberry Pi just can’t get enough, it seems, and have devised various ways to mount multiple Pis. In fact, when this idea occurred to us, we thought we had the perfect name for such a device – the Pi Rack – until we found out that name was taken by hydroponic growing systems that are sometimes used to grow medical marijuana, and other types of plants. So, guess that idea was only half-baked.

(We’ll pause a moment while you groan at that bad pun, realizing it works two ways. You know, baked pi(e), and baked from… do we really need to spell it out?)

Anyway, we came across this clever way to mount multiple Raspberry Pis, using a block of plywood and the audio and video jacks as mounts:

DSC04761

For more photos, and details on construction and the components used, see this article and the comments underneath:
Simple Pi Rack (raspberrypi.org)

(2020 Edit:) If you happen to stumble across this old article, note there have been several newer ways to mount multiple Pi’s developed since it was written. Some are homemade and some commercial. Some require a 3D printer, such as this one:

3D Printed Raspberry Pi Server Serves Up Fourteen Slices of Pi (Tom’s Hardware)

Useful SSH How-Tos

These are from an interesting site called Make Tech Easier, listed in order from oldest to newest:

Link: MythTV: Use All Buttons of Your Remote Control – Without LIRC

It can be really frustrating to get a remote control to work properly under Linux with LIRC and programs like MythTV, mplayer or XMBC. This article shows how to avoid using LIRC altogether: Treat the remote like any other keyboard, then change the keyboard mapping to use the application’s key shortcuts. Because we do this before the keypresses reach X11, it avoids the dreaded problem of keys with codes >255 not working.

Full article here:
Link: MythTV: Use All Buttons of Your Remote Control – Without LIRC (Richard Atterer)

Link: Sikuli (Automation Tool Using Images) 1.0.0 Released

Sikuli is a tool available for Linux, Windows and Mac OS X which automates tasks using images: you take a screenshot of what you want to click, right click, hover, drag and drop and so on and Sikuli performs those actions automatically, when you need it, either by using the GUI or running it via command line.

It can be useful for running repetitive tasks automatically, running some actions remotely via the command line and so on.

Article continues here:
Sikuli (Automation Tool Using Images) 1.0.0 Released (WebUpd8)

Do-it-yourselfers: Raspberry Pi with Asterisk installed to act as a door entry system

This is for those that are really into building their own hardware, in addition to being familiar with Asterisk. From Reddit’s Asterisk section comes this post:

I’m working on using a Raspberry Pi with Asterisk installed on it to act as a door entry system integrated with my home phone system (also running Asterisk). The operation I would like is this:

    Doorbell pushed.
    Raspberry Pi detects push and its asterisk originates a call from the local console channel to some predefined extension on the main asterisk server, which routes to the appropriate house extensions.
    Person at door hears either ringing or music, whatever.
    Call is eventually answered.
    Caller talks to owner and owner decides to let caller in.
    ????
    Asterisk in Raspberry Pi activates a local GPIO pin to open the door strike.

I believe I’ve got all of the above described parts working, or at least workable. The “????” line — I haven’t.

The post continues to explain the thinking that has bee put into solving this problem. Then others chime in, and finally a solution is found that involves some lines added to Asterisk’s features.conf file, and a small program in C. We’re not into hardware hacking but this solution seems like it would be a lot less expensive, and probably more fun to build than some, than an equivalent commercial unit.

How it used to be done: How to use Google Voice for free outgoing calls on an Asterisk/FreePBX system (the no-XMPP way)

 

Important
This article contains text excerpted from a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Certain edits, including those in the green boxes below, were made on or after December 1, 2013.

EDIT (May 23, 2018): This post is seriously outdated. For more recent information, see How to use Google Voice with FreePBX and Asterisk without using XMPP or buying new hardware. You may also wish to visit this thread at DSLReports for additional information.

It appears that some people are getting upset because Google is dropping the use of its XMPP protocol with Google Hangouts, and there is much speculation that they might drop XMPP support altogether, which could break the method used by PBX software (such as Asterisk, FreeSWITCH, or Yate) and even some hardware to connect to Google Voice.

We would just like to remind everyone that back in the ancient days of Google Voice, Asterisk users had another way to initiate Google Voice calls that did not involve the use of XMPP. While we do not suggest attempting to use this method today, unless absolutely nothing else works, we are reposting a portion of the original instructions here. Again, please note that this method is being reposted as a matter of historical interest only (see this article for more recent recommendations). It is just intended to show that it used to be possible to connect outgoing calls using Google Voice, but without using XMPP.

This method was used by those using Asterisk and FreePBX that wanted to enable free Google Voice outgoing calls. It was assumed that you already had a Google Voice number and has it coming into your system via an Inbound Route (that is, you had it forwarded to a DID that came into your system, that was then handled by an Inbound Route).

Before you began the process, you had to make sure that your Google Voice account was set up correctly.  In your Google Voice account, under the Settings link, Calls tab, you had to make sure the following four options on that page were set up as follows:

Call Screening: Off
Caller ID (in): Display caller’s number (very important!)
Do Not Disturb: Make sure this is unchecked!
Call Options: Make sure this is unchecked!

You also needed to install some Python additions and the pygooglevoice program, assuming you had not done so previously.  Under CentOS you’d do the following from a command prompt:

cd /root
yum -y install python-setuptools
easy_install simplejson
 

Important
If (and only if) you receive a series of error messages while attempting to install simplejson, it may be because your system is running an older version of Python, such as version 2.4 (if some of the error lines contain the string “python2.4”, this is almost certainly the problem). In that case, you can try this (note that the first line might be split into two lines on your display, but should be entered as a single line):

wget http://pypi.python.org/packages/source/s/simplejson/simplejson-2.0.9.tar.gz#md5=af5e67a39ca3408563411d357e6d5e47
tar xzvf simplejson-2.0.9.tar.gz
cd simplejson-2.0.9
sudo python setup.py install

You’d then download the latest version of pygooglevoice and install it, using a line similar to this (this is all one line):

wget http://code.google.com/p/pygooglevoice/downloads/detail?name=pygooglevoice-0.5.tar.gz

Then you’d extract and install pygooglevoice:

tar zxvf pygooglevoice-0.5
cd pygooglevoice-0.5
python setup.py install

There was also a patch that needed to be installed (again this is all one line):

sed -i 's|https://www.google.com/accounts/ServiceLoginAuth?service=grandcentral|https://accounts.google.com/ServiceLogin?service=grandcentral\&continue=https://www.google.com/voice|' /usr/lib/python2.4/site-packages/googlevoice/settings.py

The above was found in this thread in the PBX in a Flash forum, which explains why the patch was needed.

Then you’d open /etc/asterisk/extensions_custom.conf in a text editor and add two new contexts (assuming you were using Asterisk 1.6 or later):

 
[custom-gv-trunk-username
exten => _X.,1,System(gvoice -e username@gmail.com -p userpassword call ${EXTEN} gvregphonenum code &)
exten => _X.,n,Set(DB(gv_dialout_username/channel)=${CHANNEL})
exten => _X.,n,Wait(20)
exten => _X.,n,Noop(Never received callback from Google Voice on channel ${DB_DELETE(gv_dialout_username/channel)} – exiting)
exten => h,1,GotoIf($[“${CHANNEL(state)}” = “Ring”]?:bridged)
exten => h,n,Noop(Hangup on channel ${DB_DELETE(gv_dialout_username/channel)})
exten => h,n,System(gvoice -e username@gmail.com -p userpassword cancel &)
exten => h,n,Hangup()
exten => h,n(bridged),Noop(The channel has been bridged successfully)

Replacing username with the name of the user associated with the Google Voice account (the name before @gmail.com in the associated Gmail account), userpassword with the password of the Google Voice account, gvregphonenumber with the registered phone number in Google Voice that you want to forward calls to (this had to be a number that came into your Asterisk/FreePBX box, and that you had already registered it as a destination in Google Voice, NOT your Google Voice number.  And sometimes you had to use just ten digits, other times you had to add the “1” at the start of the number, and that could vary from account to account so you just had to try and see which worked), and code with a single digit that was one of the following:  1-Home, 2-Mobile, or 3-Work (you’d just use the single digit, not the word, and when you registered the destination phone number with Google Voice you had to tell them if the number was a Home, Work, or Mobile, so the code would correspond to what you’d put there. Some people found that they could omit the code and it would still work, but that wasn’t always true).

In the System() calls it was important not to omit the space and ampersand just before the final parenthesis — this allowed the dial plan to move ahead rather than imposing extra and unnecessary delays on the caller.

One strange thing about this context was that the Noop line was NOT optional – things just didn’t work as expected if it was left out or commented out.
 

Important
On one Asterisk 1.8 system, the following changes were necessary:

  1. The first instance of System(gvoice -e … had to be changed to System(sudo gvoice -e … (adding sudo before gvoice)
  2. In the file /etc/sudoers the following line had to be added: asterisk ALL = NOPASSWD: /usr/bin/gvoice
  3. The hangup portion of the context (everything below the first Noop statement) did not work as intended, and actually cancelled the Google Voice callback!. So it was changed to simply:

exten => h,1,Hangup

As you will see, the line that cancels an abandoned call was added to the second context. The first two changes were necessary because without them, Asterisk could not successfully execute the gvoice program, despite the fact that permissions were set to make it readable and executable by everyone.

The second context that had to be added in /etc/asterisk/extensions_custom.conf was this one:

 
[custom-gv-inbound-username
exten => s,1,NoCDR()
exten => s,n,Bridge(${DB_DELETE(gv_dialout_username/channel)})
 

Important
On one Asterisk 1.8 system it was found necessary to change the above context to read as follows:

 
[custom-gv-inbound-username
exten => s,1,NoCDR()
exten => s,n,GotoIf($[${ISNULL(${DB(gv_dialout_username/channel)})}]?ext-did-0002,gvregphonenum,1)
exten => s,n,Bridge(${DB_DELETE(gv_dialout_username/channel)})
exten => s,n,System(sudo gvoice -e username@gmail.com -p userpassword cancel &)
exten => s,n,Hangup()

The purpose of the line that begins with exten => s,n,GotoIf… is to correctly route the incoming call in case you initiated a callback from the Google Voice web page. The string gvregphonenum is replaced by the registered phone number in Google Voice that you are forwarding calls to, which should also be the same as the DID in your Inbound Route for Google Voice calls – this is NOT your Google Voice number! This line is optional, and note that it sends calls to the context ext-did-0002 in extensions_additional.conf, which could possibly be different in differently-configured versions or future versions of FreePBX. If it doesn’t work for you, you can leave the entire line out, but you won’t be able to initiate callbacks from your Google Voice page.

The purpose of the line that begins with exten => s,n,System… is to cancel the call in case the caller has hung up before the callback from Google Voice is received. If the call is not cancelled, weird stuff happens! You can omit the “sudo” if you did not find it necessary to add it above.

Again replacing all instances of username and userpassword with the name and password of the user associated with the Google Voice account. After saving those changes you would then go into the FreePBX GUI, go to the Tools menu, Custom Destinations module, and create a new Custom Destination. In the Custom Destination: text box you’d enter this string:

custom-gv-inbound-username,s,1

In the Description: field, you could use a meaningful description such as Google Voice Bridge username and then click on “Submit Changes.” After saving that you’d go into Trunk settings and create a new CUSTOM trunk with these settings:

Maximum Channels: set to 1
Dial Rules: Use what you like, it’s suggested that you at least add 1+NXXNXXXXXX but if your area allows seven digit dialing, you may also want to add one like 1areacode+NXXXXXX where areacode is replaced with your local three digit area code.
Custom Dial String: Set to Local/$OUTNUM$@custom-gv-trunk-username — once again, replace username with the name of the user associated with the Google Voice account.

Once you had created and saved this trunk, it could be used as a trunk selection for any USA/Canada Outbound Route.

One assumption was that you had already set up Google Voice to send incoming calls to your Asterisk system via a DID that did not change the incoming Caller ID number. Normally this would be accomplished by getting a DID from some provider (either a free one or one you paid for — it didn’t matter as long as they would pass incoming Caller ID number correctly). Once that was working, you’d create a second inbound route for that same DID, without changing the original in any way — this would be a new Incoming Route, which would be set it up as follows:

Description: Anything meaningful, such as Username Google Voice”.

DID Number: Same as on your other Inbound Route that handles your Google Voice traffic.

Caller ID number: This had to be be your Google Voice number (the one associated with your Google Voice account), but depending on how your DID provider sent Caller ID, you might have to specify it as either a ten or eleven digit Caller ID, or even +1 followed by ten digits.  Whatever format your DID provider used, you had to match their format, which sometimes meant watching the Asterisk CLI during a test call to see what format they used. If it didn’t match what they sent, it wouldn’t work.

Destination: the Custom Destination created above (e.g. Custom Destinations: Google Voice Bridge username).

No other settings of the Inbound Route were changed and in particular, you were advised not to set a CID Lookup Source because it would cause an unwanted delay in connection time and was totally useless in this route, and there’s no reason to do so since this route is only triggered when a single Caller ID comes in).

Once you had submitted these changes, you should have been able to add your Google Voice custom trunk as a trunk selection for one or more of your USA/Canada Outbound Routes.

If it didn’t work it was generally one of three things. Either the Custom Trunk hadn’t been specified as a destination in the appropriate Outbound Route, or the incoming Caller ID of the Google Voice call didn’t exactly match what you set up in the Inbound Route you created, or you got something wrong in extensions_custom.conf such as the username or password (or you missed a place where you were supposed to change one of those items).

For test purposes, you could go to a Linux command prompt (not a CLI prompt in Asterisk!) and try entering a gvoice command directly, using this format (note this is all one line):

gvoice -e username@gmail.com -p userpassword call numbertocall gvregphonenum code

All of those values are as explained earlier, except for numbertocall, which had to be a USA or Canada phone number in 11 digit format.  Yes, the number to call had to be in 11 digit format (with the leading “1”) whereas the gvregphonenum might (or might not) need to be TEN digits (no leading “1”) – go figure.  If it worked from the command line then you needed to double check your values in extensions_custom.conf.  If it did not work from the command line, then either there was something wrong with your pygooglevoice installation, or with Python on your system (you had to have at least Python version 2.4 or higher), or you could have been using incorrect values (EDIT: Or, on some systems, it might be necessary to execute the gvoice command using sudo from within Asterisk, as described above).  And, some people got confused over the fact that that the “gvregphonenum” value was NOT supposed to be their Google Voice number, but instead the number to which Google Voice forwarded their calls, and it had to be a number that had been previously registered as a destination with Google Voice.

That’s the basics of how it was done. Note this is not intended to be a guide as to how to set this up now, since many things have changed since then. Just because this method worked back then does not mean it will still work today, and it’s definitely slower in the setup of calls than more recent methods. However, it is worth noting that at no point was the XMPP protocol used. It’s also worth mentioning that there are other programs that can interact with Google Voice besides PyGoogleVoice (see for example Google-Voice-PHP-API, google-voice-java, SharpGoogleVoice, voice.js, etc.) that may or may not be more suitable for use in this type of application.

Link: Asterisk – Voicemail with Speech Recognition using Google API

This is probably a somewhat advanced level project, but for those who might enjoy a challenge, all the steps are laid out for you.

In a previous article I published a solution to convert Asterisk voicemail attachments from WAV to MP3 on the fly. This is done by catching the mails sent by Asterisk just before they are passed to sendmail.

I recently got the idea from Daniel Dainty to add Voice Recognition feature at the same time as mp3 encoding.

After testing different voice recognition engines, I realized that the Google Speech Recognition API is by far superior to any other solution available under Linux (Sphinx, …).

This article will explain an approach to add voice recognition to Asterisk voicemail using the services of Google Speech Recognition API.

Full article here:
Asterisk – Voicemail with Speech Recognition using Google API (Bernaerts family site)

Link and Video: Drastically Speed up your Linux System with Preload (and other speed-ups)

Preload is an “adaptive readahead daemon” that runs in the background of your system, and observes what programs you use most often, caching them in order to speed up application load time. By using Preload, you can put unused RAM to good work, and improve the overall performance of your desktop system.

Most Linux users should install Preload using their distribution’s Software Center or repository, and simply installing the program will be all that is needed.  But this article explains much more about Preload, including various configuration options:

Drastically Speed up your Linux System with Preload (TechThrob)

Preload is also featured in this video:
View on YouTube