In a full on throw back to the 2nd ever post to this blog, back in February 2010, I’ve recently been updating the system that sends me a video when there is movement in my flat via MMS and email.
I thought I’d try and add audio to the video that gets sent. A quick Google turned up two options, one was to use the sox command and it’s silence option, the second uses the on_event_start triggers in motion as a way to record the audio at the same time as capturing the movement video. I went with the second option and tweaked it a bit to make it pick the right input for my system and to direct encode the audio to MP3 rather than WAV to save space.
The other useful addition was the –process-id-file /var/motion/arecord.pid which writes the process id to a file so I can just use this to stop the recording rather than having to use grep and awk to find the process in the ps output.
on_event_end kill `cat /var/motion/arecord.pid`
Now it’s just a case of combining the video from motion with the audio. I can do this with ffmpeg when I re-encode the video into the 3gp container to make it suitable for sending via a MMS message.
This seams to work but the output file is a little large. The default audio encoding seams to be at 160k bitrate, I wound it down to 32k and the file size got a lot better.
I’d like to try the AMR audio codec but I can’t get ffmpeg to encode with it at the moment, so I’m just going to email the mp3 of the audio along with the high res AVI version of the video and just send the low res 3GP version via MMS.
Back in my very first post I talked about using Bluetooth to detect my presence at home in order to disable the CCTV system and control a few other things.
While this works well it does not scale well to multiple people as the Bluetooth layer 2 ping takes about 5 seconds to time out if the device in not in range. This means that at most 12 different phones can be checked in a minute.
A couple of recent chats with a few people at work (Vaibhavi Joshi & Dale Lane and Bharat Bedi) got me thinking about this again. Modern phones tend to have WIFI as well as Bluetooth and 3G radios these days so I thought that I’d have a look at seeing if this could be used to locate devices.
After bit of a poke around it looked like a package called Kisment should be able to do what I wanted.
Kismet
Kismet is a client server application, the backend server reads from the network card and decodes the packets and the UI which requests data from the server over a socket connection. This also means the backend can be on a different machine, in fact several different drone backends can be consolidated in a single master backend server and all the captured data presented to UI. This means you could distribute a number of drones over site and generate a map as devices move between areas covered by the different backends.
The default client is a ncurses based application that can list all the visible networks and a chart showing the incoming packet rates. It’s great for getting a view of what networks are active which can be very useful when you have to set up a new one and want to see which channels are free.
Rather than use the default client I decided to write my own to drive the backend the way I wanted it and to make exposing the data easier (I’m going to publish detected devices on a MQTT topic). But first I had a bit of a play using the netcat (nc) command. Netcat basically pipes stdin/stdout to and from a given socket, this is useful because the Kisment protocol is just a set of simple text commands. For example the following command will get the kismet backend to return a list of all the clients it has seen to date.
The only tricky bit about the response is that any field that can contain a space is wrapped in characters with a value of 0x01, in this case the manufacture field could contain spaces so we need the following regexp to chop up the responses for each time a client is spotted.
I decided my client in Java (because the MQTT libraries are easy to use) so I chose to use a regular expression to split up the response
By default Kismet cycles round all the available channels to try and get a full picture of all the WIFI traffic in range, but this means it can miss some packets and in turn miss clients that are not generating a lot of traffic. To help get round this I have locked Kismet to just listen on the same channel as my WIFI access point since all my devices are likely to try and connect to it as soon as it comes in range and there is less chance of me missing detecting my phone up front.
cab63dc8-9916-11e0-b51a-0f04751ce201 is the UUID assigned to the wifi card by kismet and the 13 is the channel I run my WIFI access point on. You can find the UUID by running the following command:
Publishing the last seen time on the following topic /WIFIWatch/<mac> allows applications to register to see a specific device and also build up a list of all devices ever seen and when.
It’s not just phones that have WIFI adapters these days, net books, tablets even digital cameras (with things like eyefi) all have , also with multiple kismet nodes it might be possible to track devices as they move around an area.
Next is to look at the signal strength information to see if I can judge a relative distance from the detection adapter.
I left the setup in the last post with a system that would email photos of the burgular off site and then an SMS message. This is a prety good solution but since nearly everybody has a phone capable of receiving picture messages it seamed like the next step is to not just email the photos off site, but to also send them as a picture message so they can be checked for false alarms even when I’m not at my computer.
I went back to searching the net for a package that would supply MMS capability using a cell phone attached to a computer, not a direct connection to a bulk messaging provider. There is project called Mbuni that is a fully functional MMS gateway and relaying service as run by the cell phone providers. Normally this would run on the providers network and or at a company providing paid for content via MMS. Hidden away in the CVS for the latest version there is a add on to one of the components which will allow the sending of MMS messages via a phone.
Kannel
In the last post I had discounted Kannel for sending SMS messages because of the complexity. But Mbuni prereqs it so it was time to have another look at the setup. Mbuni also request a specific level of Kannel (CVS 2008-07-28 download) so because I was planning on using some very new function in Mbuni I decided to build this Kannel version from source to make sure it all matched up.
tar -zxf kannel-snapshot.tar.gz
cd kannel-snapshot
./configure
make
su -c "make install"
Kannel is made up of a number of separate programs that provide different bits of functionality
bearerbox
smsbox
wapbox
In order to be able to send and receive SMS messages we are going to need the frist two on the list. Wapbox is only used if you want to provide a dial up WAPgateway.
Setting up Kannel is not hard, the docs are very good and can be found here and there is a copy of my config files as a guide in the resources section
Mbuni
There is some good documentation for setting up the full MMS gateway version of Mbuni, but because the cell phone plugin is stil only in the development stream there is only a small sample config file and the source code. I have tried to document what I have learned setting it up here.
Since this is a bleeding edge function you will need to build Mbuni from the src in cvs. There are instructions on how to do this on the web site here, but here is a short version
cvs -d:pserver:anonymous@mbuni.cvs.sourceforge.net:/cvsroot/mbuni login
cvs -z3 -d:pserver:anonymous@mbuni.cvs.sourceforge.net:/cvsroot/mbuni co -P
mbuni
cd mbuni
./bootstrap
./configure
make
cd extras/mmsbox-mm1
make
cd ../..
su -c "make install"
The change of directory to the extras/mmsbox-mm1 is to build the extra library needed to work with the phone. If you are running on a machine that has SELINUX enabled you will need to run the following command to allow the library to work
su -c "chcon -t texrel_shlib_t /usr/local/lib/libmmsbox_mm1.so"
Like Kannel, Mbuni is made up of a collection of applications
mmsc
mmsproxy
mmsrelay
mmsbox
To send MMS messages via a phone we only need mmsbox which is what is known as a VAS gateway. So we need to create a Mbuni config file, there is a sample file shipped with the src in the doc/examples directory. Here is my version modified to work with O2 UKs MMS service
group = core
log-file = /var/log/kannel/mmsbox.log
access-log = /var/log/kannel/mmsbox-access.log
log-level = 0
group = mbuni
storage-directory = /usr/local/var/spool/mbuni
max-send-threads = 5
maximum-send-attempts = 50
default-message-expiry = 360000
queue-run-interval = 5
send-attempt-back-off = 300
sendmms-port = 10001
sendsms-url = http://localhost:13013/cgi-bin/sendsms
sendsms-username = tester
sendsms-password = foobar
# Sample conf for MMSBox using a modem (MM1)
group = mmsc
id = modem
type = custom
custom-settings = "smsc-on=lynx -dump 'http://localhost:13000/start-smsc?
password=bar&smsc=w880i';
smsc-off=lynx -dump 'http://localhost:13000/stop-smsc?password=bar&smsc=w880i';
gprs-on=/usr/bin/pon o2;
gprs-pid=cat /var/run/ppp0.pid | head -1;port=13014;
mmsc-url=http://mmsc.mms.o2.co.uk:8002;proxy=193.113.200.195:8080;msisdn=100"
mmsc-library = /usr/local/lib/libmmsbox_mm1.so
group = send-mms-user
username = tester
password = foobar
faked-sender = 100
The interesting bits are the sendsms-url and the custom-settings lines. The sendsms-url points to the bearerbox/smsbox URL from setting up Kannel earlier which Mbuni uses to send the notification about the new mail.
The custom-settings line is a lot more complicated, it is basically a mini config file all of it’s own. The two entries that start with smsc-on and smsc-off are commands that the custom library built earlier uses to stop and start the sms gateway while the MMS message is sent. gprs-on is used to start a PPP session via the phone. This can be either gprs or 3G. The code implies that this command should not return until it’s killed at shutdown, but using /usr/bin/pon on Ubuntu seams to work.
The next few bits depend on which cell phone provider your using. The mmsc-url and proxy are the addresses for the machines on their network you need to use to
send MMS messages. I found the following page has a good list of the settings for UK provider http://www.filesaveas.com/mms.html
SMIL
So now we’ve got the set up working we need some content to send. MMS messages are defined using SMIL markup. The following is the simple SMIL file I am using to send a short video clip and text caption. The first half divides the display in half, with the video in the top half and the text in the lower. The second section contains the details of the links to where Mbuni can find the content to
fill those areas and how long to display them. This is a very simple example, much more complex messages can be assembled with
SMIL.
So far we have been just sending static images, next comes converting the avis created by Motion to mpeg4 in a 3gp container that should be playable on any MMS capable phones. The following ffmpeg command will convert the file to the right format.
Where “-i 07-20090916100019.avi” is the file created by motion, “-s qcif” tells ffmpeg to use an output file that is 176×144 and conforms to a standard that all phones should understand, “-vcodec h263” is the video codec to use. “-y intruder.3gp” tells ffmpeg to overwrite the file if it already exists.
Here is an example of the Motion output.
After transformation:
When viewed on a 2 inch screen the drop in quality is not noticeable and it is still possible to tell if it is somebody you know.
Actually sending the MMS
So now we have actually created the content for the MMS message we need to put it somewhere mbuni can find it. In this case I put the video and text files into the /cam1 directory being server up by http server. The URLs match the entries in the SMIL file created earlier.
Now we need to send the SMIL file to Mbuni along with the phone number to send it to. The following curl command will send the SMIL file and the rest of it.
In this case Mbuni is running on the a machine called x-wing and listening on port 10001 (as set with the sendmms-port in the config above). The frist half is the urlencoded version of the username, password, the senders and recipients numbers and the subject of the message. The second section, after the –data-urlencode loads the SMIL file and encodes it before sending it.
Putting it together
Now we need a to collect all of this up in a scrip to attach to the movie end action of motion. The following script first helps to prevent false alarms by ensuring that any video has at least 15 frames. Assuming that test is satisfied the orginal version of the video is emailed offsite for safe keeping, before converting the it to the 3gp format. It then adds the time and date to the message.txt before sending the SMIL to Mbuni.
#!/bin/sh
FRAME_COUNT=`/home/hardillb/bin/frameCounter $1`
if [ $FRAME_COUNT -gt 14 ]; then
uuenview -a -m foobar@xxxxxx.xxx $1 <<EOF
Subject: Movement detected video $2 $3
EOF
/home/hardillb/bin/sendMessage SMS/Outbound "TO: +447703xxxxxx MESSAGE: possible intruder"
ffmpeg -i $1 -s qcif -vcodec h263 -y /var/www/html/cam1/intruder.3gp
echo "$2 $3" > /var/www/html/cam1/message.txt
curl --data "username=tester&password=foobar&to=07703xxxxxx&subject=Possible+Intruder&from=07543xxxxxx"
--data-urlencode "smil@/var/www/html/cam1/intruder.smil" http://x-wing.loc:10001
fi
The frameCounter was a script I had run up earlier for a different project, made sense to reuse it here.
So that’s about it, I have a motion activated CCTV system that will log off site and send alerts to me anywhere in the world with enough detail to decided if it’s a false alarm
So this is a project I’ve been picking away at for some time now, adding new bits along the way. I was looking for a way to keep an eye on my flat while spending a lot of time on the road with work.
While hunting around online I found a reference to a small application called Motion which will monitor a web cam and can trigger alerts when the image changes. Along with the alerts it can capture the images or video of what has changed and has filters to detect the gradual changes as it gets light or dark during the day.
My motion config file is in the Resources section at the end.
Originally I had to build Motion from src, but it was recently added to the extras rpm repository I use with Fedora 11. Once installed it’s relatively easy to configure, initially I just had to update the config file (/etc/motion/motion.conf) point it at my web cam (/dev/video0) and a directory to save the images in.
Motion has a number of useful features, once running you can update all of the settings via web interface and it will also stream the video from the camera on a different port which is good for testing. There is also a REST style interface which can be used to turn the motion detection on and off, more on that later.
After that I set up Motion to email the images to a spare gmail account to ensure there was a off site copy of the images just in case the computer with the camera was stolen. The following script was attached to the “on_picture_save” event as follows:
Where %f is the path to the image and %H:%M%S %d-%m-%Y is a time and date stamp.
#!/bin/sh
uuenview -a -m foobar@xxxxxx.xxx $1 << EOF
Subject: Possible Intruder $2 $3
EOF
This sends a mail with the time and date in the subject and the image in the body.
So that was not a bad solution, I normally run Thunderbird or have the gmail manager plugin for Firefox running so I get updates about new emails relatively quickly. But then I ended up at a customer who would not let me hook my laptop up to internet while in the office so I started to look for a different notification mechanism to add on as well.
Gnokii
The next perfect solution seamed to be SMS messages. I had a spare mobile phone and pay-as-you-go sim cards are free. So back to searching the net for some software to send SMS messages. I found 2 different Linux packages that would do this. The first is called Gnokii which is part of a package that started out as a way to back up and interact with Nokia phones. Gnokki’s smsd works from two simple mysql tables, one for inbound and one for outbound messages. It polls the outbox table at a configuable interval (I’ve set mine to 5 seconds) and sends any unprocessed messages.
The second SMS package for Linux is called Kannel. Kannel is a lot more than just a program to send SMS messages, it is also a full WAP stack. It is very powerful but requires 2 processes and webserver to be able to send and receive messages.
So to start with I chose Gnokii as the set up was a lot simpler. You basically just need to get a serial connection to your phone, this can be either via a USB cable or you can set up a connection via Bluetooth using the rfcomm command.
I am using a Sony w880i as my phone and it comes with a USB cable which doubles as a charger which makes things easier. When I plugged it into my box it showed up as 2 Serial ports (/dev/ttyACM0 and /dev/ttyACM1) they both seam to behave the same.
I added a new script to the “on_movie_end” Motion trigger
There is a sample Gnokii config file in the Resources section
Anybody Home?
So that is a good start, we’ve got a system that will detect motion and raise the alarm. But at the moment it’s turned on all the time, which is no good. This is where Motion REST style control API comes in. If I had a way to automatically tell when I’m at home I can turn off the motion detection. I discovered a blog post by another guy at Hursley called Gareth Jones
Who seamed to have already solved this problem. Gareth had put together some Python that scans for Bluetooth devices with in range of the computer and sends alerts as devices arrive or leave. Since most people carry a Bluetooth device arround with them all the time in the shape of a mobile phone this seamed like a good idea.
At the time I was looking at this bit I didn’t have time to go digging in Python, so I hacked up a quick shell script verion that would just track one phone and then use the Motion REST API to pause the detection when ever I’m at home and turn it on again when I leave.
The detection is done using the l2ping command from the Bluez package and giving it the Bluetooth mac address of the phone I want to track.
#!/bin/sh
MAC=00:AA:BB:CC:DD:EE
while true; do
if [[ `sudo l2ping -c 1 $MAC 2> /dev/null | grep -c "44 bytes from"` == "1" ]]
then
echo "home"
if [[ `cat /home/user/home` != "YES" ]]
then
echo YES > /home/user/home
fi
lwp-request -C user:password http://127.0.0.1:8080/0/detection/pause > /dev/null
sleep 90
else
echo "away"
if [[ `cat /home/user/home` != "NO" ]]
then
echo NO > /home/user/home
fi
lwp-request -C user:password http://127.0.0.1:8080/0/detection/start > /dev/null
sleep 15
fi
done
MAC is the bluetooth address of my phone, you can discover this by running the following command “hcitool scan” which will produce a list of all the bluetooth devices your machine can currently see and their names.
So this is where I left the solution for quite a while because I couldn’t find a project that would allow me to send MMS messages from Linux without having an arrangement with a cell phone
network.
