Remote controlled Home Automation using Sinatra, Ruby and the LightwaveRF Wifi box

In the last post I created a Ruby Gem to communicate with the LightwaveRF Wifi Link Box. The next step was getting that gem into a web server so that I could send commands to the LightwaveRF box over HTTP. The eventual aim was to get this deployed on a RaspberryPi so that it could act as an always-on webserver to control any of the devices in the house.

The obvious choice for a lightweight and simple webserver in Ruby is Sinatra. The following code was all it took to get things started:

class App < Sinatra::Base
  def initialize
    super
    @lightwave = LightwaveRF.new
  end

  get "/" do
    body "Usage: turn items on or off: /[on|off]/:room/:device to dim /dim/:room/:device/:level. Level should be between 0 and 100."
  end

  get "/:room/:device/:action/?:level?" do |room, device, action, level|
    return [422, "Level required for dim"] if action == "dim" && !level
    case action
    when /on/i
      @lightwave.turn_on(room, device)
    when /off/i
      @lightwave.turn_off(room, device)
    when /dim/i
      puts level
      @lightwave.dim(room, device, level.to_i)
    else
      return [422, "Unknown action #{action}"]
    end
    body "Room #{room} Device #{device} #{action}#{" to #{level}%" if level}."
  end
end

The code starts off by creating an instance of the LightwaveRF gem. Then you can just call the root page on the server to see the interface. Then you can use the following to turn on room 1, device 2.


http://localhost:9292/on/1/2

or to Dim room 2, device 3 to 50% you could use:


http://localhost:9292/dim/2/3/50

Don't forget you'll need to register the device first by calling LightwaveRF.new.register from the computer that's running the webserver.

If you're not familiar with Ruby the following should help you get setup in the terminal assuming that you have ruby installed:

git clone git@github.com:scsmith/lightwaverf-sinatra.git
cd lightwaverf-sinatra
bundle install --path ./vendor/bundle
bundle exec ruby -e "require 'lightwave_rf'; LightwaveRF.new.register; puts 'Done'"
bundle exec rackup -p 9292

This will register the device and start the server running on port 9292 (the default for sinatra). You can then call http://localhost:9292/ like above to start using the server.

Home automation with Ruby using the LightwaveRF Wifi Link box

I recently got to play with the LightwaveRF Wifi Link box (http://www.lightwaverf.com/). They’re becoming fairly common in the UK with companies like screwfix selling them. You can get a range of devices to pair with the box including lights, plug sockets and even PIR sensors. We plugged things in, got a lightbulb paired up and had a play. It’s pretty cool however the next step was writing our own software to control it. Who doesn’t want to control their house using Ruby?

Unfortunately the LightwaveRF Wifi Link doesn’t come with an API or any obvious way to communicate with it outside the tools that the company provide. I was just about ready to get out wireshark and try to figure out the protocol it was using to communicate however, fortunately someone had already done this.

It turned out talking to the box is pretty simple over UDP. First you have to initialise the conversation and pair the device you want to use to communicate with the Wifi box. You can do that with the following:

socket = UDPSocket.new
socket.setsockopt(Socket::SOL_SOCKET, Socket::SO_BROADCAST, true)
socket.send("533,!R1D1F0|", 0, "255.255.255.255", 9760)
socket.close

Once you've done this commands are sent in the following format:

"001,!R1D2F1"

Prefix: 001
Room: 1
Device: 2
Function Code: F1

The prefix is a random number between 001 and 099 Function code F0 means turn off, F1 means turn on and to Dim a device you can send FdPXX where XX is a number between 1 and 32, with FdP32 meaning full brightness. So the following code would dim Room 2, Device 3 to 50% brightness:

socket = UDPSocket.new
socket.setsockopt(Socket::SOL_SOCKET, Socket::SO_BROADCAST, true)
socket.send("001,!R2D3FdP16|", 0, "255.255.255.255", 9760)
socket.close

To make this easier I've published the LightwaveRF Ruby Gem to let you interact with the device from Ruby in a much easier way.

lightwave = LightwaveRF.new

# Initial Registration (Only needs doing once per device)
lightwave.register

# Turn the light on in room 1, device number 1
lightwave.turn_on(1, 1)

# Dim the lights in room 2, device number 3 after turning them on
lightwave.turn_on(2, 3)
lightwave.dim(2, 3, 50)

# Turn off the lights
lightwave.turn_off(1, 1)
lightwave.turn_off(2, 3)

For more details or if you find any other features to add checkout the project on Github. The next step was to add this gem to a small Sinatra webserver, which I'll post soon.

Converting a github issue into a pull request

Converting a github issue into a pull request

Recently someone submitted an issue for one of my open source github repositories (https://github.com/scsmith/language_list). Language list imports a pretty huge list of lanauges as it loads and this was taking a bit of time. There was quite a bit of discussion on the issue, with a fair few branches. Eventaully we were happy with the changes in one of the branches and wanted to bring them into master.

There were two options here, the first is to create a new pull request and just reference the existing issue (you can do this by typing # and using the autocomplete). However I also managed to find this stackoverflow question and answer giving a more preferable option. You can convert an existing issue into a pull request itself. You need to use the github api though but this is pretty easy using curl:

curl --user "your_username:your_password" --request POST --data '{"issue": "4", "head": "username:reponame", "base": "master"}' https://api.github.com/repos/username/reponame/pulls

In this head is the repo you want to bring in and base is the subject of the pull that you want to merge to.

There's also a site that can do this for you http://issue2pr.herokuapp.com/ but you will have to give full access to your private repos. Personally I find the curl approach pretty simple and really liked this option. Remember to head over to the stackoverflow question and upvote the answer if you use it!

Installing Rails 3.2 on ArchLinux Raspberry Pi

Before I was playing with Debian on the Raspberry Pi I was messing with ArchLinux and managed to get Rails 3.2 running on the Pi. I’m posting this up as a quick guide for anyone else that might want it.

The first step is to log into the command prompt either directly or via ssh. I’m not going to add a different user at this point just set things up for the root user but you might want to consider doing this differently for anything but a toy project.

Next we need to install the dependancies. Arch uses a dependancy manager called pacman. Let’s start by updating pacman itself to make sure it’s up to date.

pacman -S pacman

We then need to install the rest of the dependancies:

pacman -S ruby # ruby itself.
pacman -S base-devel # make etc for compiling gems
pacman -S libxml2 # used by gems like nokogiri for xml
pacman -S libxslt # used by gems like nokogiri
pacman -S sqlite # sqlite database
pacman -S nodejs # Rails 3.2 needs a javascript runtime. Node is one of the options.

I wanted to run solr for search so I also installed openJDK6 but I suspect most projects won't need this.

pacman -S openjdk6

With the dependancies installed we should now have ruby 1.9 installed. We can just check this using the version flag on ruby.

ruby -v

Now we just need to install bundler:

gem install bundler

With bundler installed we'll need to copy the code over to the device (or generate a new rails app by installing the rails gem and running the generator). You could easily do this yourself using scp or a similar tool but I used capistrano here with the following recipe:

set :application, "manifest"
set :repository,  "."
set :deploy_via, :copy
set :scm, :git

set :user, "root"
set :password, "root"
set :use_sudo, false

role :web, "192.168.1.190"
role :app, "192.168.1.190"

Rather than checking out the git repo remotely I'm just asking capistrano to copy my local project which uses git and providing it the Raspberry Pi's username, password and IP address.

Once the code is deployed simply run bundler to install the gems.

bundle install

Once the gems are installed go ahead and migrate up the database:

rake db:schema:load

and Start Rails!

script/rails server -p 80

You should now be able to access your rails app over the network!. There's nothing groundbreaking in here but I thought I'd document this in case it helps anyone.

Logging into a Rasberry Pi using Public/Private Keys

In a previous post we covered enabling sshd on the Raspberry Pi. Now that we’ve got SSH setup I’ll cover how to log in using a public/private key-pair rather than using password authentication. This is particularly useful if you’re going to put the Pi on the public internet. It’s also pretty handy if you can’t be bothered to type your password each time you ssh into the device.

The first step is to ensure that you have a public private key-pair installed on your local machine. Most developers will already have this but in linux or mac you can normally generate a new pair using:

ssh-keygen -t rsa -C "your_email@youremail.com"

I won't cover creating these in any detail as there are plenty of guides available. Github's guides cover this as a side effect of setting up git here and an issues helper here.

Next up we need to copy our keys over to the Rasberry Pi. I'm going to use the following script:

cat ~/.ssh/id_rsa.pub | ssh pi@192.168.1.190 "mkdir .ssh;cat >> .ssh/authorized_keys"

This assumes that your private key is stored in ~/.ssh/id_rsa.pub and that the ip address of the server is 192.168.1.190. You can change these for your own values. If all goes well you should be prompted for the password for the last time.

Now we should be able to log in using:

ssh pi@192.168.1.190

This time we shouldn't be asked for a password it should use the key instead!

Disallowing password login. To disallow password login we need to edit the ssh config found in /etc/ssh/sshd_config. Do do this we can ssh into the Pi. Once at the prompt we can enter the following:

sudo vi /etc/ssh/sshd_config
scroll down to the section that says #PasswordAuthentication yes
With the cursor over the # press x
Then scroll the console to the end and press i
Then press backspace to delete the word yes and replace it to no
Then press the escape key, press : and then w, then press : and then q.

We now need to restart sshd. The easiest way to do this is to type sudo /etc/init.d/ssh restart alternatively you can just reboot using sudo reboot.

Enabling SSH on Debian Raspberry Pi

Debian is the default recommended image for the Raspberry Pi. If you’re using the Raspberry Pi as a server you’ll most likely want to be able to manage it remotely over the network using a local computer and SSH. However, by default SSH isn’t enabled on the Pi. We’ll walk through the basics of getting SSH enabled and logging into the Raspberry Pi over SSH.

The first thing we need to do is log into the Pi normally by plugging in a monitor and keyboard. It also makes sense to plug in the network cable at this point. Once the board boots you get the login screen where the default username is pi and password raspberry.

If you want to change this password you can just type:

passwd

Now we're going to enable SSH at boot. Luckily there's a script that enables SSH for us provided so we just need to use the following command to move it to the right location:

sudo mv /boot/boot_enable_ssh.rc /boot/boot.rc

Once we've done this rebooting the Raspberry Pi will show something like:

Starting OpenBSD Secure Shell server: sshd

You should now be able to log in via SSH and the same username and password. To find the ip address we need to type:

ip addr

Here we want to look for the ip address on eth0 for example if the output is

1: lo: mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
2: eth0: mtu 1488 qdisc pfifo_fast state UP qlen 1000
    link/ether b8:27:eb:49:32:63 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.190/24 brd 192.168.1.255 scope global eth0

then our ip address is listed after inet as 192.168.1.190. You could even use ip addr | grep -e 'inet .* eth0' to find just this line.

With this ip address you can now log in using the following credentials:

host: 192.168.1.190 (or whatever your IP was)
username: pi
password: raspberry (or whatever you changed it to)

On a unix based system this will most probably be:

ssh pi@192.168.1.190

From here you can manage the Pi fully over SSH. It's also possible to remove the password altogether and use a public/private keypair to log in. This is especially recommended if the Pi is going to be publicly available on the internet. In the next post we'll cover removing the password and just using the keypair.

Controlling access to Routes and Rack apps in Rails 3 with Devise and Warden

Devise is a great authentication solution for use within your Rails apps. We’ve used it in a number of projects and have always been happy with the flexibility but never realised quite how great it was until very recently.

Recently we wanted to make use of an A/B testing solution and one of the options was Split. Like a number of projects nowadays (Resque included) Split comes with an embedded server that allows you to control it via the web interface.

You can mount that rack app using:

mount Split::Dashboard, :at => 'split'

The problem is this leaves split open for anyone to see and your AB testing is open for anyone to play with. The split guide recommends that you can use a standard rack approach to protect your split testing.

Split::Dashboard.use Rack::Auth::Basic do |username, password|
  username == 'admin' && password == 'p4s5w0rd'
end

We were already using Devise though and I'm sure this is only there to prove as an example by the authors. What we really wanted to do was use Devise to protect our mounted app. It turns out that this isn't that difficult. Firstly you can authenticate any route using devise using the authenticated command like the following:

authenticated(:user) do
  resources :post
end

This ensures that the following route, specified with the block, is only availible to people who have authenticated. Using authenticate you can also bounce people to the login page if they're not authenticated:

authenticate(:user) do
  resources :post
end

This is awesome and ensures that only registered users can access the routes. You can of course replace :user with any of your scopes, such as :admin, in order to ensure that only specific scopes have access to the route. However, we wanted a bit more control. What if you want to only allow any users that had the boolean `allowed_to_ab_test?` method?

As soon as you realise that:

mount Split::Dashboard, :at => 'split'

is actually just a short hand for

match "/split" => Split::Dashboard, :anchor => false

You can use any normal constraint. Since warden makes use of the request object you can pull out any details you like from warden including the user model by using a lambda for the constraint. This provides massive flexibility for controlling your routes:

match "/split" => Split::Dashboard, :anchor => false, :constraints => lambda { |request|
  request.env['warden'].authenticated? # are we authenticated?
  request.env['warden'].authenticate! # authenticate if not already
  # or even check any other condition
  request.env['warden'].user.allowed_to_ab_test?
}

With that example we can take a really fine grained control of our routes and only allow access to certain routes for certain people without having to specify different scopes for the users.

Nothing here's groundbreaking but it took us a little time to figure it out. The combination of Devise and Warden gives a huge amount of power and flexibility allowing you to protect both your normal routes or your embedded apps. We thought we'd share this in case it was useful to others. It's certainly opened our eyes to just how great Devise and Warden are!

Follow

Get every new post delivered to your Inbox.

Join 362 other followers