Me, my life and I
Home Automation
Automated Kitchen Lighting
0114 days
Recently I decided to make some changes to the kitchen. It started off with a strip of warm white LEDs, and I thought “Wouldn’t it be cool if…”. I’ve now lost count of the number of guests asking how it works 
There’s a variety of components at play here. Firstly, there’s a Raspberry Pi, followed up by a simple IRF530 MOSFET, a PNP transistor to pull it low, a PIR sensor, and a strip of LEDs.
Sensing
It’s a a PIR sensor from Seeedstudio that I bought on a whim a while back. It handily runs off of 5v, and returns a 3.3v TTL compatible signal upon detection of movement.
On the Raspberry Pi, I have my own Python app, mqtt-gpio-trigger, running. It continuously monitors pins that are defined in the config file, and in the event of a change of state of any of them it will publish a message to a predefined topic, with the pin number as the final component of the topic, and the message contains the state of the PIN. Simply subscribe to that topic to watch whatever pin on the Raspberry Pi.
Lighting
A strip of warm white LED lights are attached to pin 18 of the Raspberry Pi, via the IRF530 MOSFET. There’s a bog standard NPN transistor to help saturate the gate of the MOSFET, and it’s pin 18 as that’s the only pin on the Raspberry Pi that does hardware PWM. Using any of the other pins subjects you to vagaries of the CPU.
Controlling pin 18 is mqtt-pwm-lights, another one of my scripts. It simply sits and runs, and subscribes to yet another MQTT topic. When it receives a message with a value between 0 and 512, it fades the lights to that value. Due to the NPN transistor it’s inverted, so 512 is off, and 0 is on. A minor annoyance, but the home automation controller handles that.
In the middle
Producing the show is a small script that isn’t public. All it does is listen for MQTT events and reply with canned MQTT messages in return. It’s a stopgap measure until I find a better home automation controller. The main role of the script at the moment is to listen to events from the PIR, start a timer when triggered, and publish a lighting level request. When the timer expires, the lighting level returns to normal (ie, off)
So that’s it. Ambient automated lighting for the kitchen, and worktop lighting, all rolled into one.
OWFS Server on The Raspberry Pi
0192 days
Quick and simple this one is. I have a DS9490R (internally it’s a DS1490F) one-wire bus master attached to my Raspberry Pi. 4 DS18B20 temperature sensors are hanging off the bus, and I’d like to access them from the home automation server.
On the Raspberry Pi, or the server/device that’s hosting the 1-Wire bus:
apt-get install owserver ow-shell
modprobe ds1wm
echo “ds1wm” >> /etc/modules
Edit /etc/owfs.conf such that the following parameters are entered. I’d advise commenting out the rest (at least, the rest of the server: directives)
! server: server = localhost:4304
server: usb = all
server: w1
server: port = 0.0.0.0:4304
Restart the 1-Wire server
/etc/init.d/owserver restart
All being well, the following command should output a listing of all the devices on the bus.
owdir -s localhost:4304 /
On the remote server, simply use the following command to read the data.
owread -s kitchenpi.vpn.glasgownet.com:4304 /28.DDBF1D030000/temperature
MQTT GPIO Monitoring
0213 days
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.
MQTT Republishing Itch
1244 days
So, I had an itch. A variety of data coming in from a variety of sources, all over different protocols and methods, with different names, heirarchies, and paths. For a while I’d been pushing the data into MySQL, but this seemed a bit of a hack, and it still didn’t really cure the problem as it was more of a historical record than an attempt at mapping between the source and the destination, as it were.
I’d been fiddling with MQTT for a while, and had started publishing data over it via my personal broker. And then I read Roberts post over at http://blog.hekkers.net/2012/09/18/mqtt-about-dumb-sensors-topics-and-clean-code/ about republishing it in a logical way.
So simple! So, I wrote a republisher. It’s very simple, and it scratches my itch (and hopefully Roberts too). Data comes in via whatever naming scheme or topic you like, and it gets republished in whatever fashion you want. The map is maintained in map.csv, and items are separated by commas. The MQTT spec doesn’t reserve any characters for the topic name, so I’ve used a comma out of CSV convenience.
The code is over at https://github.com/kylegordon/mqtt-republisher
Making XBMC work on Mint 12, with HDMI Audio Passthrough and LIRC
0I’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.
Recent Comments