SecurityPi Part 3

On my previous post I briefly went over the initial setup and configuration of the RaspberryPi, this pretty much got it to a headless server state to where I was able to begin initial testing and development.

x10

 

Since, I had decided I was going to start out with testing with x10 as it was already well established protocol and various devices are available to get started on I figured I would start on getting communication setup.

As I previously mentioned in my Part 1, I was going to use a “CM19A usb x10 RF Transceiver – this is going to be used to get data from the x10 RF Security sensors.”  It can also be used to send data to RF modules…  So,  I started with getting it up and running first.

First, I needed to get the device and drivers up and running. When I first plugged the device in, I noticed it didn’t quite function correctly, so I searched around. I found many options out there some using python directly which sounded enticing, but with the overhead of multiple sensors, I figured the interface needed to be quick (with a raspberrypi resources are limited) and expandable.

I wanted to be able to expand the messaging system to support custom devices, then I ran across Mochad. Seeing how it was written in c, open source and had very good documentation, I decided it would suit me well for what I was looking to accomplish. It also appeared to communicate through tcp port 1099 which would allow me to do some neat additions later on.

So, following the instructions provided, and I started with getting the required libraries:

sudo apt-get install libusb-1.0-0-dev

Downloaded mochad source:

wget -O mochad.tgz http://sourceforge.net/projects/mochad/files/latest/download

then unpack, build, make and install:

tar xzf mochad-...tar.gz
cd mochad-...
./configure
make
sudo make install

At this point, I then did a reboot with the CM19a unplugged and then replugged in after it was up and then I was good to go.

to test it all out, all that was needed to do was run:

sudo nc -l localhost 1099

then test a sensor open and close state, or in my case the DS10A (window sensor) had a test button. In which case broadcast a message like:

12/18 17:40:02 Rx RFSEC Addr: EF:43:80 Func: Contact_normal_min_low_DS10A

which indicates the DATE TIME TX/RX TYPE ADDRESS FUNCTION.
Upon initial tests I noted the range was quite horrible (less than 10ft), but I did locate a very nice guide to improving the range. Which I will need to look at in the future, for now I needed to look into how I wanted to interpret/handle the data, and what I wanted the interface to look like.

Since I was going to be using a web interface and the possibility of custom devices/sensors in the future, I decided I would get a proof of concept setup. So I installed php, sqlite and apache.

sudo apt-get update
sudo apt-get install apache2 php5 sqlite3 libsqlite3-dev php5-sqlite

then add the required line to /etc/php5/conf.d/sqlite.ini with the following command:

sudo echo "extension=sqlite.so" >> /etc/php5/conf.d/sqlite.ini

After a reboot, everything should be up and running.

*Note, as for sqlite, the only reason I went with it over mysql was to reduce overhead and keep the system lite as possible.  I was aware of some of the losses attributed with going with such a database, and I figured if I wanted to change over to mysql in the future it would not be too trivial to make the necessary changes.  The only reason for the database was a means to keep current settings, status’s and a means for the web interface to interact with the backend.

First thing first, I setup a test database..

to begin I ran:

sudo sqlite3 ./security

Then I added some tables:

CREATE TABLE locations (
location_id smallint primary key,
location_name text,
area_id smallint,
location_description text
);
CREATE TABLE sensors (
sensor_id varchar(8) primary key,
sensor_locationid smallint,
sensor_type integer,
sensor_status integer,
sensor_last_update varchar(20)
);
CREATE TABLE sensortypes (
sensor_type integer primary key,
sensor_name varchar(10),
sensor_description text
);
CREATE TABLE status (
sensor_status integer,
status_description varchar(10)
);

Then I added some data to the tables:

insert into locations(location_id, location_name, location_description) values('0', 'unknown', 'unknown or unassigned');
insert into sensortypes(sensor_type, sensor_name, sensor_description) values('0', 'unknown', 'unknown sensor');
insert into sensortypes(sensor_type, sensor_name, sensor_description) values('1', 'DS10A', 'DS10A wireless switch sensor');
insert into sensortypes(sensor_type, sensor_name, sensor_description) values('2', 'MS10A', 'MS10A wireless motion sensor');
insert into status(sensor_status, status_description) values('0', 'normal' );
insert into status(sensor_status, status_description) values('1', 'alert' );
insert into status(sensor_status, status_description) values('2', 'unknown, );

Then using the supplied documentation, I whipped up a test shell script in bash:

x10sqliteadaptor.sh

While not being the most refined script, it seemed to work well as needed for initial testing, only issue I found is it would not quite hold up to the task long term, as bash scripts are not exactly the fastest programs around and this is something that will need to run fairly quickly to keep track of all the sensor data.

So, I decided I could improve it with python in the future.  I know what your thinking.. why python now?   Well, seeing how my python script will only work as an “adaptor” between mochad’s port 1099 and sqlite database, I figure it should work fine. I did play around with running a perl script, but for now I think python will be more than up to the task.

In the meantime, I am going to begin on getting the web interface started as it will provide me with a little better idea as to what I need to incorporate into the “adaptor”.  I think more things will pop up as I work out the interface. So on the next installment, I will begin working on the web interface and backend.

Go Back to Part 2 Setup   OR   Continue to Part 4 Where I Continue Testing, Development and Begin on Web Interface

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.