New Raspberry Pi Home Monitor Approach

I have lax in working with the Raspi lately (but the beaglebone monitor has been working flawlessly for a month now in Maryland) so I started experimenting with configuring the Raspi differently than beaglebone to do the monitoring job.

With beaglebone I wrote one large Tcl program that ran almost as a daemon (it was actually started at boot time via cron @reboot and kept running) that did everything from data gathering (temperature, A/C power status, etc.) to sending SMS messages. When the modem acted up as mentioned in previous posts, the beaglebone watchdog timer would cause the system to reboot. Part of the reboot process involved resetting the modem by power cycling the USB +5V line to circumvent certain problems specific to this modem.

The central concept of the new approach is to implement home monitoring functions in a more "Unix-like" way by using multiple small programs (commands) run in combination as processes to get larger jobs done. Additionally, I am shifting to the use of cron to provide time-dependent behavior on the minute-day-week-month time scale instead of building a single large program that runs continually as a daemon. The programs can be written in multiple different languages, but I plan to use multi-platform scripting languages like Tcl, javascript, shell script, perl, python wherever possible.

The most critical component in the monitor is the GSM modem used for all communications with the outside world, since I want it to be useful in remote locations where internet is unavailable but cell coverage is. So this component and its software have to be very reliable.

All interfacing with the GSM modem is done through a fairly small Tcl program I wrote (currently called gsm.)  gsm is invoked with arguments for reading and sending SMS (text) messages, and obtaining and controlling the state of the modem. Confining the modem interface to this one program designed to do one thing well makes it small so I can analyse and thoroughly test it, making it more reliable. In the home monitor gsm is run when needed, such as when an SMS is to be sent, and it opens, operates, then closes the modem each time cleanly. Having only one program run the modem makes it possible to rewrite it in different languages and refine and test it separately from the rest of the system.

With this approach a simple home monitoring system can be as simple as a cron job that periodically runs a shell script which, via different helper programs like gsm, gathers household data, tests it for various conditions and sends SMS messages when appropriate using gsm.

For example here is a script called periodically by cron to tweet house status. I've commented out sections that actually gather data and handle incoming text messages for testing purposes. In addition I've embedded calls to gsm in the handledata.tcl program in the form of running gsm as a process:


#!/bin/bash

# Name
#     monitor-cron.sh - Shell script version of home monitor - experimental
# 
# Usage
#     Run as cron job
#
# Idea is to use multiple dedicated programs in series,
# using gsm Tcl program to perform all GSM modem functions,
# like sending and receiving SMS text messages. Series programs
# communicate via files.

cd /home/pi/gsm-monitor/CommandLine

# Get data to report on and put in data.txt
#./getdata.tcl >data.txt

# Handle house data

# ./handledata <data.txt

# Get all new SMS messgaes from modem and put in messages.txt
./gsm listall >messages.txt

# Also catenate to database
cat messages.txt >>mdatabase.txt

# Erase read messages from modem
./gsm eraseread

# Process received messages
#./handlesms.tcl <messages.txt

# Now, tweet something...

./gsm tweet "House monitor reporting on `date`" >>monitor.output.txt



Here's the crontab to run it every 1/2 hour on the 22nd and 23rd of February (I wanted to have it only run a couple of days this month):



# Edit this file to introduce tasks to be run by cron.
#
# Each task to run has to be defined through a single line
# indicating with different fields when the task will be run
# and what command to run for the task
#
# To define the time you can provide concrete values for
# minute (m), hour (h), day of month (dom), month (mon),
# and day of week (dow) or use '*' in these fields (for 'any').
#
# Notice that tasks will be started based on the cron's system
# daemon's notion of time and timezones.
#
# Output of the crontab jobs (including errors) is sent through
# email to the user the crontab file belongs to (unless redirected).
#
# For example, you can run a backup of all your user accounts
# at 5 a.m every week with:
# 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/
#
# For more information see the manual pages of crontab(5) and cron(8)
#
# Run the monitor to report (null data at this time) every 30 minutes
# just today (Feb 23, 2013) and tomorrow costing $0.02 per hour
# at $0.01 per text message with my AT&T 1000 SMS for $10 pckage:
#

# m  h  dom   mon dow   command

*/30 *  23,24 2   *     ./monitor-cron.sh