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
Wednesday, January 30, 2013
Watchdog timer for Raspberry Pi
Just a quick note: I set up the watchdog timer facility on the Raspberry Pi this evening following the directions at http://raspberrypi.stackexchange.com/questions/1401/how-do-i-hard-reset-a-raspberry-pi pretty much verbatim. Here's an excerpt from the blog, signature at end:
The daemon monitors the state of various things defined in the file /etc/watchdog.conf, including the existence of several files, successful pings, etc. and stops signaling the watchdog timer if they don't exist, which resets the Raspberry Pi.
You can use the BCM2708's hardware watchdog.
To use it begin by loading the module:
sudo modprobe bcm2708_wdog
Then edit the /etc/modules file:
sudo nano /etc/modules
and add the following line:
bcm2708_wdog
Next you will need to setup the watchdog daemon.
Install and confiigure it to start on bootup:
sudo apt-get install watchdog chkconfig
chkconfig watchdog on
sudo /etc/init.d/watchdog start
Next configure watchdog:
sudo nano /etc/watchdog.conf
# Uncomment the line watchdog-device = /dev/watchdog
The watchdog daemon will send /dev/watchdog a heartbeat every 10 seconds. If /dev/watchdog does not receive this signal it will restart your Raspberry Pi.
answered Aug 2 '12 at 4:34
 |
The daemon monitors the state of various things defined in the file /etc/watchdog.conf, including the existence of several files, successful pings, etc. and stops signaling the watchdog timer if they don't exist, which resets the Raspberry Pi.
Thursday, January 24, 2013
New Raspbian “wheezy” installed on 8 GB SanDisk SDHC card
I obtained an 8 GB SD card and downloaded and installed using windows 7 a later drop of wheezy (2012-12-16-wheezy-raspbian.zip) on it using Win32DiskImager.
After booting I had to download and install avahi-daemon ('sudo apt-get install avahi-daemon') as before, but unlike with the previous version first I had update using 'apt-get update' due to some daemon libraries being missing.
Remote logins to the pi account were blocked due to a host key problem in the Pi. Here's the error message:
john@john-ThinkPad-T42:~$ ssh pi@raspberrypi.local
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
d4:21:93:57:3e:18:79:9f:d3:f4:99:00:9a:c1:fe:59.
Please contact your system administrator.
Add correct host key in /home/john/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/john/.ssh/known_hosts:12
remove with: ssh-keygen -f "/home/john/.ssh/known_hosts" -R raspberrypi.local
ECDSA host key for raspberrypi.local has changed and you have requested strict checking.
Host key verification failed.
john@john-ThinkPad-T42:~$ ^C
The new version has no root account, so privileged operations require sudo, which the 'pi' user has the ability to use.
I used raspi-config to change the keyboard to the 104 key pc style and expand the disk partition to the full 8 GB available on the SD card.
The new version also shows the full 512 MB of ram, unlike the previous version.
After booting I had to download and install avahi-daemon ('sudo apt-get install avahi-daemon') as before, but unlike with the previous version first I had update using 'apt-get update' due to some daemon libraries being missing.
Remote logins to the pi account were blocked due to a host key problem in the Pi. Here's the error message:
john@john-ThinkPad-T42:~$ ssh pi@raspberrypi.local
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
d4:21:93:57:3e:18:79:9f:d3:f4:99:00:9a:c1:fe:59.
Please contact your system administrator.
Add correct host key in /home/john/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/john/.ssh/known_hosts:12
remove with: ssh-keygen -f "/home/john/.ssh/known_hosts" -R raspberrypi.local
ECDSA host key for raspberrypi.local has changed and you have requested strict checking.
Host key verification failed.
john@john-ThinkPad-T42:~$ ^C
The new version has no root account, so privileged operations require sudo, which the 'pi' user has the ability to use.
I used raspi-config to change the keyboard to the 104 key pc style and expand the disk partition to the full 8 GB available on the SD card.
The new version also shows the full 512 MB of ram, unlike the previous version.
Subscribe to:
Posts (Atom)