pi@raspberrypi ~ $ sqlite3
SQLite version 3.7.13 2012-06-11 02:05:22
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite>
Sunday, February 24, 2013
Database for Home Monitor: sqlite3 on Raspberry Pi
Thinking a database would be preferable to simple files for storing monitor-specific data, I installed it using sudo apt-get install sqlite3. I'm now trying the command line shell:
pi@raspberrypi ~ $ sqlite3
SQLite version 3.7.13 2012-06-11 02:05:22
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite>
pi@raspberrypi ~ $ sqlite3
SQLite version 3.7.13 2012-06-11 02:05:22
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite>
Logitech USB Video Camera on Raspberry Pi
Yesterday I connected my Logitech, Inc. Webcam C210 USB camera to my Raspi, and after installing fswebcam (sudo apt-get install fswebcam) the camera was fully operational and would record pictures as required:
To make it more useful in home monitoring, I installed motion, which runs the camera unattended, noticing motion in the picture and taking different user-configurable actions, like recording frames and running user-specified scripts, when it does.
Although I can't send pictures as text messages (yet, you need a data plan which I don't have) with my GSM modem, I can send events I've set the motion program up to notice, so it might be useful.
To make it more useful in home monitoring, I installed motion, which runs the camera unattended, noticing motion in the picture and taking different user-configurable actions, like recording frames and running user-specified scripts, when it does.
Although I can't send pictures as text messages (yet, you need a data plan which I don't have) with my GSM modem, I can send events I've set the motion program up to notice, so it might be useful.
Adding tcllib to Raspberry Pi
Eventually I hope to change over to Javascript using nodejs, but until then I need to run my existing software, written in Tcl and for this I had to install tcllib1.14. Tcl/Tk was already installed in my drop of raspian. Tcllib is a library of very handy packages written in pure Tcl.
I downloaded the library from http://sourceforge.net/projects/tcllib/files/tcllib/1.14/
I moved it to the Pi using sftp (WinSCP) from my Windows 7 computer. The Pi has an sftp daemon running by default.
I also moved the latest drop of my software to the Pi from Dropbox/Beaglebone-monitor/BeagleboneBackup.
I gunzipped and tar'ed it, and from the tarred directory did a ./configure and make install.
Make takes a while as it generates lots of man files. (In fact its still going as I write this.)
To be continued....
I downloaded the library from http://sourceforge.net/projects/tcllib/files/tcllib/1.14/
I moved it to the Pi using sftp (WinSCP) from my Windows 7 computer. The Pi has an sftp daemon running by default.
I also moved the latest drop of my software to the Pi from Dropbox/Beaglebone-monitor/BeagleboneBackup.
I gunzipped and tar'ed it, and from the tarred directory did a ./configure and make install.
Make takes a while as it generates lots of man files. (In fact its still going as I write this.)
To be continued....
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
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
Saturday, February 2, 2013
Nokia CS 12 GSM Modem Quick Notes
To test the Raspberry Pi as a text (SMS) message device for home monitoring I bought a used Nokia CS-12 USB GSM modem and a gophone SIM card via Amazon.
I set up the SIM card account using AT&T's web pages, setting up an account and buying a 1000 SMS message package for $10.
A quick test using 'screen' ('screen /dev/ttyACM0') to connect to the modem as a serial device was successful (a few 'AT' commands worked as expected.)
Download program:
$ sudo apt-get install usb-modeswitch
Add lines to usb rules file: /lib/udev/rules.d/40-usb_modeswitch.rules:
# Nokia CS-12 zouck 2/1/2013
ATTRS{idVendor}=="0421", ATTRS{idProduct}=="0618", RUN+="usb_modeswitch '%b/%k'"
Add file named 0421:0618 to /usr/share/usb_modeswitch. This can be a copy of the file 0421:0610 with 0610 changed to 0618. The same mode change string seems to work fine:
File 0421:0618:
# Nokia CS-12
DefaultVendor= 0x0421
DefaultProduct= 0x0618
TargetVendor= 0x0421
# Changed this from 0618 due to debug output indicating resulting target product
# is 0619.
TargetProduct= 0x0619
MessageContent="5553424312345678000000000000061b000000020000000000000000000000"
Turn on debugging by setting config file line in /etc/usb_modeswitch.conf:
...
# Enable logging (results in a extensive report file in /var/log, named
# "usb_modeswitch_<interface-name>" and probably others
EnableLogging=1
...
Log will be in file:
/var/log/usb_modeswitch_1-1.3.3:1.0
The log says the modeswitch may have failed, but it seemed to create the right /dev/ttyACM0 and 1 files and they seemed to work.
I used minicom from the command line on the Raspberry Pi to communicate AT commands to the modem:
$ minicom /dev/ttyACM0
Welcome to minicom 2.6.1
OPTIONS: I18n
Compiled on Apr 28 2012, 19:24:31.
Port /dev/ttyACM0
Press CTRL-A Z for help on special keys
at
OK
I set up the SIM card account using AT&T's web pages, setting up an account and buying a 1000 SMS message package for $10.
Windows 7
To use it in Windows 7 I ran the install program on the USB modem. It appeared as a serial device (com21) when plugged in, and communication could be had via putty. Some stuff id different from the Option Icon modem, mainly there is no way I could find to get the ICCID number from the SIM card using 'AT' commands.Ubuntu
On Ubuntu the modem did not get handled by usb_modeswitch so no /dev/tty* entries were created for use in communicating with it. After some hours of frustration I downloaded the new version (1.2.5) of the program and did a make install, which failed because usb.h was missing. So I did an 'sudo apt-get install libusb-dev' to get a new library and that fixed the install. After the install, plugging in the modem resulted in devices /dev/ttyACM0 and /dev/ttyACM1.A quick test using 'screen' ('screen /dev/ttyACM0') to connect to the modem as a serial device was successful (a few 'AT' commands worked as expected.)
Raspberry Pi
Download program:
$ sudo apt-get install usb-modeswitch
Add lines to usb rules file: /lib/udev/rules.d/40-usb_modeswitch.rules:
# Nokia CS-12 zouck 2/1/2013
ATTRS{idVendor}=="0421", ATTRS{idProduct}=="0618", RUN+="usb_modeswitch '%b/%k'"
Add file named 0421:0618 to /usr/share/usb_modeswitch. This can be a copy of the file 0421:0610 with 0610 changed to 0618. The same mode change string seems to work fine:
File 0421:0618:
# Nokia CS-12
DefaultVendor= 0x0421
DefaultProduct= 0x0618
TargetVendor= 0x0421
# Changed this from 0618 due to debug output indicating resulting target product
# is 0619.
TargetProduct= 0x0619
MessageContent="5553424312345678000000000000061b000000020000000000000000000000"
Turn on debugging by setting config file line in /etc/usb_modeswitch.conf:
...
# Enable logging (results in a extensive report file in /var/log, named
# "usb_modeswitch_<interface-name>" and probably others
EnableLogging=1
...
/var/log/usb_modeswitch_1-1.3.3:1.0
The log says the modeswitch may have failed, but it seemed to create the right /dev/ttyACM0 and 1 files and they seemed to work.
I used minicom from the command line on the Raspberry Pi to communicate AT commands to the modem:
$ minicom /dev/ttyACM0
Welcome to minicom 2.6.1
OPTIONS: I18n
Compiled on Apr 28 2012, 19:24:31.
Port /dev/ttyACM0
Press CTRL-A Z for help on special keys
at
OK
Subscribe to:
Posts (Atom)