MQTT GPIO Monitoring

My little Raspberry Pi seems to be growing arms and legs.

The other day I hooked up a simple PIR to it. I can’t remember where I got it, but it runs off 5v, consumes a low enough amount of milliAmps to be directly connected to the Raspberry Pi 5v supply, and outputs a TTL compatible 3.3v signal. Bonus!

I wanted to be able to signal to my MQTT broker when motion was detected, so it was time to start monitoring the GPIO pins. I wrote up this short app using the framework I’d made for MQTT-Republisher earlier. MQTT-GPIO-Trigger will accept a list of GPIO pins that you wish to watch, and will cycle through them all and fire off MQTT messages on any state change.

It uses the standard Linux sysfs interface to read the pin states, and if it detects the WiringPi library on the system it will use Gordons gpio command to export the pins to the system.

apt-key from behind a firewall

At work we’re pretty heavily firewalled. This means that outbound requests on funny ports are often firewalled off, and systems that rely on such ports will time out.

One such system that is commonly used yet inaccessible is the GPG SKS port 11371. And many many Linux things use GPG!

What got me looking was the common command to import a key, in this case for Spotify.

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 94558F59

It will time out and fail to import the key, subsequently causing your apt-get operations to fail. A quick update to the command cures it. You *have* to specify hkp:// and :80

sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 94558F59

Success! You can also apply the same changes to your default keyservers in ~/.gnupg/gpg.conf

Epson SX235W on Linux

Recently my parents purchased an Epson Stylus SX235W for use with their Linux laptops. It’s a combined inkjet printer and flatbed scanner with wireless network support, all for a decent price.

My dad uses Ubuntu Lucid, my own choice back when Lucid was current, and it was also conveniently on Long Term Support (which it still is) – this shouldn’t be too bad.

Printing
Out the box, CUPS does not support the SX235W printer. This was easily resolvable by heading to Epsons website and following through the various procedures to get Linux support. The download center at http://download.ebz.epson.net/dsc/search/01/search/searchModule seems blissfully unaware of the SX235W printer that they gleefully sell, but it does know it under the model SX235. Select that option, and grab the version of epson-inkjet-printer-201108w that’s applicable for your architecture.

Once you install the package, the standard ‘Add Printer’ tools in Ubuntu will be able to find the printer on the network. A word of warning though – be patient. It will take up to a minute for the printer to be discovered on the network. Once found, you can add the printer, let it search for and find the driver, and then you’ll be off and running.

Scanning
Scanning was a slightly different matter. This is supported through the use of the iscan package, along with the iscan-network-nt plugin. The key here is that unlike the printer driver which uses DNS-SD to find the printer, SANE has to be configured to look at the correct network address of the scanner before it will allow anything to be done. My parents router is a nice little TP-Link TP-WR841N running OpenWRT, so a quick delve into /etc/config/dhcp to give the printer a static lease had the printer on a readily discoverable IP address within a couple of minutes.

Once the printer was on a dedicated IP address, installation of the iscan and SANE packages followed. For SANE, just ‘apt-get install sane-utils’. For iscan head back to the Epson Driver Download Center mentioned above, and download both the “core package&data package” and the “network plugin package” package for your architecture. Bear in mind that as Lucid uses libltdl7, you’ll need to grab the version suitable for libtdl7 or later. Make sure you download and install the iscan-data package first, before trying to install the core package. Once those two are installed, the network plugin package can be installed.

Remember previously where we set the printer/scanner up with a static DHCP lease? This is where it comes in important. Edit /etc/sane.d/epkowa.conf and down in the network section put in ‘net 192.168.1.50’, and substitute the correct IP address.

All sorted. Execute ‘iscan’ at the command line or “Image Scan! for Linux” from the Ubuntu menu, and it should detect your scanner and offer to scan. Job done 🙂

Making XBMC work on Mint 12, with HDMI Audio Passthrough and LIRC

I’ve got a Dell Optiplex 755 hooked up to my Yamaha amp and surround system, and it was about time XBMC was installed on it. It uses a low profile Nvidia GeForce 8400GS for VDPAU acceleration and HDMI audio. These are some rough notes I took whilst setting it up.

Follow this guide to install XBMC on Mint 12

adduser --system --home /var/lib/htpc/ htpc
vipw, change htpc shell to /bin/bash
apt-get install build-essential vim xbmc xbmc-standalone ubuntu-restricted-extras mint-meta-gnome-dvd mint-meta-codecs

Download and extract lirc-0.9.0.tar.bz2 from www.lirc.org
As I’m using a DangerousPrototypes USB IRToy, all I’m interested in is the IRMan driver

sudo apt-get install libirman-dev
./configure --prefix=/usr/ --with-driver=irman
make install

Copy the SysV startup script from a Debian package into /etc/init.d/, use update-rc.d lirc defaults to put it in all the right runlevel directories

Used my existing Hauppauge A415 remote control definition file, and put it in /etc/lirc/

Edited /etc/lirc/hardware.conf to include the following…

REMOTE_MODULES=”lirc_dev mceusb”
REMOTE_DRIVER=”irman”
REMOTE_DEVICE=”/dev/ttyACM0″
REMOTE_SOCKET=””
REMOTE_LIRCD_CONF=”mceusb/lircd.conf.mceusb”
REMOTE_LIRCD_ARGS=””
LOAD_MODULES=”true”
START_LIRCD=”true”

Edited /etc/lirc/lircd.conf to include the following at the end…

include “/etc/lirc/A415-HPG-KG.conf”

Ensure the lirc_dev module is loaded at boot, with echo lirc_dev >> /etc/modules

Start lirc with /etc/init.d/lirc start, and fire up irw. Press some keys on the remote to make sure it works.

Edit /etc/lightdm/lightdm.conf, ensure autologin-user=htpc, and user-session=XBMC

Reboot and bask in XBMC glory

I restored most of my XBMC settings from backups, but the audio settings were of a particular concern. This is what I use to get HDMI passthrough over a NVidia GeForce 8400GS card…

Audio Output : HDMI
Speaker Configuration : 5.1
Audio Output Device : Custom
Custom Audio Device : plughw:0,7
Passthrough output device : Custom
Custom Passthrough device : plughw:0,7

I knew the audio devices courtesy of the output from aplay -l, and some random testing with mplayer got me the results. To test it with mplayer, I just ran mplayer -fs -afm hwac3,hwdts -ao alsa:device=hw=0.7 against the name of a movie I knew had an AC3 soundtrack. Within a couple of seconds the amp was reporting a full AC3 bitstream, and surround sound was filling the living room.

Making OpenDAB, FEC and the Psion Wavefinder work on x64

I’ve had a Psion Wavefinder for a while now, and it’s never really worked that well due to the rather bad combination of poorly written amateur radio related software, out of date build environments (see the previous argument), and the fact that most amateur radio enthusiasts seem to use Windows (see the first argument again)

OpenDAB has been around for a while, and it certainly seems promising. However, although it’s not an absolute requirement, the use of DAB+ is preferable, and that subsequently requires Phil Karns FEC library.

Now Phil Karn might be a genius, but he doesn’t reply to emails, and nor does he keep his build environment or OS up to date. FEC 3.0.1 is now over 4 years, doesn’t compile with modern GCC versions, and requires some massaging to make work.

Firstly, GCC no longer allows labels at the end of compound statements. This screws up dotprod.c

Next, well, I dunno what’s going on. ld chucks its guts up at the end of the build on x64 (how long has x64 been around for now?), and suggests using -fPIC. So, makefile.in was tweaked to include -fPIC in CFLAGS

I believe -m32 will do the job too, so that it’s built for x86, but hey, this works. If anyone wishes to elaborate on the pros and cons of Position Independent Code vs x86 on x64 then comment away.

In addition to this, OpenDAB supplied a patch to be applied to fec.h, as described in their documentation.

Anyway, to make life easier I created a patch. This includes the OpenDAB patch, my own patch, and a patch found at http://mmbtools.crc.ca/component/option,com_fireboard/Itemid,55/func,view/catid,7/id,178/

Just untar the standard fec-3.0.1 package, cd into it, and patch it as below. A handy one liner is also evident on this example.

bagpuss@mine:~/src/WaveFinder/fec $ wget –quiet http://ka9q.net/code/fec/fec-3.0.1.tar.bz2 ; wget –quiet http://lodge.glasgownet.com/bitsnbobs/kg_fec-3.0.1.patch ; tar -xjf fec-3.0.1.tar.bz2 ; cd fec-3.0.1/ ; patch < ../kg_fec-3.0.1.patch patching file configure patching file cpu_mode_port.c patching file dotprod.c patching file fec.h patching file makefile.in bagpuss@mine:~/src/WaveFinder/fec/fec-3.0.1 $

Once patched, ./configure && make && make install should have FEC up and running, and ready for OpenDAB. I have it working here on my trusty x64 Ubuntu 11.04 (actually it’s Mint 11) desktop.