For some purposes i thought it would be very nice to enable some telecommunication abilities on raspberry pi. For example if something does not work as it should (e.g. average load too high, temperature/humidity too high) raspberry pi can call you. Or if you just want to control something quickly via phone (e.g. starting a process, reboot or open the door) - raspberry pi can answer your calls and made it for you. Of course you can make it via SMS or web-interface, too - but for example a call often gets more attention than a sms.
So at first i've searched for a tts-tool. Very popluar are festival and eSpeak. For using synthesized speech later its important to cache speech as wav-files - such an option is alread included in both tools (espeak -w / text2wave). I've compared both tools on raspberry pi - the synthesized speech sounds similar, but espeak seems to be a bit faster with generating wav-files and is more adjustable. But at least which tool is choosen is a question of taste. Both tools are available via apt:
sudo apt-get install espeak espeak-data
sudo apt-get install festival
For making calls i've decided to use a sip/voip based system. I've found at least two possible tools which are controllable via command line: Linphone (linphonec/linphonecsh) and PJSIP. After a few tests i've sorted out linphone because its way to difficult to include into own applications/scripts in comparison to PJSIP. PJSIP delivers not only a command line interface - it provides a powerfull library/api (PJSUA) for using within own sip-based projects - so it was predestinated for my proposition.
For start using PJSIP/PJSUA you need to download and compile it by yourself - its not installable via apt but this is not really a problem:
cd trunk
./configure && make dep && make clean && make && make install
After finishing compilation (you can have a coffee or two meanwhile) you can test a bit around with pjsystest or pjsua which are available in /pjsip-apps/bin. With the actual raspbian-os i've discovered some sound-problems with making normal calls to another phone (echo/jitter) which seems to be alsa/pulse-based.
For my proposition i've created two tools: sipcall and sipserv. With sipcall you can easily make an automated call to a specified number with a text to speech. Its easy usable via bash-script for example to check a system or sensor state and place a call if a critical threshold is reached. Sipserv however acts more like a service - you can make a call to it and query informations or execute commands via phone (your sip-provider needs to support inbound dtmf - i'm using sipgate, which works fine). You can download them from my github-repository. For compiling both tools you need the pkg-config-package:
sudo apt-get install pkg-config
make
I've also created a simple bash-script for checking actual load and placing a call if load is too high. For sipserv there is a sample configuration and a bash-script for starting/stopping the service available. All files are well documented to understand how it works - general infos are also available in the readme-file.
Both tools work so far but currently they are in alpha state and more "proof of concept" than final. Feel free to play a bit around, test or extend them. Please let me know if you have improvements, especially for the current sound problems.
Since i'm familiar with using a watchdog timer in some microcontroller-projects, i've been thinking about watchdog-support for Raspberry Pi. Generally a watchdog timer is nothing else than a timer-register which can be realized on hardware- and/or software-side. It's main purpose is to trigger a system reset or other corrective action if something doesn't works anymore as it should be. In detail the timer-register needs to get resetted in a functional workflow before its filled up and triggers the reset or special action.
This means that the functional system must trigger a heartbeat to the watchdog ("feeding the dog") within a hard (hardware, not changeable) or soft (software, self-definable) time period. An absence of some heartbeats results in reaching the time limit and triggering the reset/action.
Luckily the BCM2835 SoC has a hardware-based watchdog timer on board - but sadly there are no further informations about it in the actual datasheet. If i'm right informed this watchdog timeout register has 20 bits and counts down every 16µs (source: Raspberry PI BB), so the the hardware timer limit is something around 16 seconds (16*2^20µs) which seems to be right according to bcm2708_wdog module source.
The actual firmware includes the driver-module bcm2708_wdog (or if you compiled your kernel by yourself ensure that you have enabled BCM2835 watchdog support [CONFIG_WATCHDOG=y, CONFIG_BCM2708_WDT=m|y]). Just load it and add it if necessary to your modules-configuration for loading it at startup:
sudo modprobe bcm2708_wdog
sudo nano /etc/modules (add line "bcm2708_wdog")
This will create the device /dev/watchdog. The watchdog is automatically started once the device is opened. Once the watchdog is started, it needs to get feeded with heartbeats - this is done by writing anything but the character "V" to the device (see watchdog api). "V" is a magic character which will disable the watchdog - so it's important to know that just closing the device without writing the magic char to it won't stops the watchdog, quite the contrary will happen and the timer limit will be reached and the reset gets triggered.
If you want to use the watchdog within an own application scenario its recommended to use ioctl-api. For feeding the watchdog you can insert WDIOC_KEEPALIVE via ioctl. You can get or set the soft timer limit
via WDIOC_GETTIMEOUT and WDIOC_SETTIMEOUT, but remember that its hard limited to 16s, so if you set a soft-timeout larger than this limit it will be just setted to 15s. Also remember to disable the watchdog by writing a "V" for a straight program exit.
I have written a small test-snippet for demonstrating the use of the watchdog timer within an own application. You can find it in my github-repository - Just build it and play with it - It supports a clean and a failure exit for testing purposes:
cc -o wdt_test wdt_test.c (or just:) make
sudo ./wdt_test (for a clean exit)
sudo ./wdt_test -t (for a failure exit)
If you don't want to control the watchdog by your own, of course you can use a ready-to-use watchdog-daemon, which provides some more features than just feeding the dog with heartbeats every 10 or 15s. It can also run several tests to check the system healthfulness like monitoring memory and load, checking ping-results, measuring temperature or performing user-defined commands to do arbitrary tests and trigger reboot when they fail.
sudo bash
apt-get install watchdog chkconfig
chkconfig watchdog on
/etc/init.d/watchdog start
nano /etc/watchdog.conf
(enable line "watchdog-device = /dev/watchdog")
So now its time to test if everything works as it should be. Ensure that there aren't any critical processes running and try to cause a kernel panic for example. This can be tried with deactivating any swap space and a nasty forkbomb (: (){ :|:& };:), but more reliable will be a fake kernel-module.
If everything is set up correctly the system will reboot a few seconds later. So from now your system is protected by the watchdog.
