Binerry

[binerry]

Introduction to Home Automation with Raspberry Pi and Fhem

Home Automation is a cool subject - Its futurity, energy efficient, everything is everywhere under control and at least its a little bit nerdy/geeky. So concerning sizing, power and pricing the Raspberry Pi is qualified for an house-controller. The additional hard- and software requirements can be achieved by already existing hardware modules and open source software - the setup itself is no rocket science.

At first its good to know which system should be controlled. There are many solutions and products available, starting from some dollars and ending somewhere in a multi-digit sector. Very popluar in germany (in individual households) are the cheaper Intertechno, ELRO and similiar systems or the FS20 / Homematic system. From technical view there aren't much differences (mostly the frequency can be the same [in germany 433/868 MHz] and there are some differences regarding the used protocol) except for the Homematic system. While the cheaper and the FS20 systems are uni-directional, the Homematic system works bi-directional. Of course there are actors and sensors for all types of systems, but Homematic is the only system where you get a feedback or can request a state.

If you have a FS20 switch-actor you "just" can switch it on or off. You won't get a success-response (i.e. "switched on" or "switched off") and furthermore you cannot request a state (i.e. "is it switched on?" or "is it switched off?"). Within an Homematic based system you can request a state of a switch per default and also get a response after an action.

Hardware Prerequisites

For controlling a system via computer there is a appropriate controller needed. For FS20 for example there is a FHZ1300 called controller, for Homematic for example you can use the CCU called controller. Of course, they do what they should do - no question, but they are quite a bit specialized (protocol fixed, which means that FHZ can only control FS20 and CCU can only control Homematic) and expensive (180-250$).

A really perfect alternative are the products of busware: There are a USB-Module (CUL), a USB-Module with Network and OneWire (CUNO) and an UART-Module (CSM) available. All modules are based on an atmel-microcontroller and a CC1101 from Texas Instruments, a low-cost ISM (Industrial, Scientific and Medical) and SRD (Short Range Device) transceiver which operates in 315/433/868/915 MHz bands (definable via firmware). The price-range for the busware-modules is between 30 and 111$. All these modules are not protocol fixed - with the matching firmware and software you can control FS20, EM, FHT, EMS, S300, Homematic and TX2/TX3. (By the way: Busware is actually working on COC, a CC1101-based OneWire-Clock extensions for Raspberry Pi.)

I'm actually using a FS20 system, which actually fits my needs. For controlling this via Raspberry Pi i'm using the UART Module (CSM) from busware which is powered directly via RPi and operates directly via RPi's UART. For testing i'm using a simple wire antenna with a λ/4-length wire antenna (~86,25mm) which is really enough to control devices within a 70-80qm flat.

Software Prerequisites

On software-side i'm using fhem, a GPL'd perl server for house automation. Fhem works perfectly with all modules from busware since the common denominator, the CUL-Firmware (CULFW), is mostly already pre-installed. CULFW is also licensed under GPL and implements some RF protocols on an atmel microcontroller for making them useable by fhem. So from virtual view its the bridge between CC1101 which can send and receive RF-commands, and the computer which is coordinated by fhem.

Preparing Raspberry Pi's UART

After connecting RPi and CSM you need to free your UART-port at first. (If you're using something else like FHZ, CCU, CUL or CUN you can skip this step) Per default all currently available images for RPi are using the UART-port for linux serial console - so before you can use it, you need to disable it and remove all references to getty on UART-port /dev/ttyAMA0. So at first you need to edit /boot/cmdline.txt and /etc/inittab and remove all references to /dev/ttyAMA0:

sudo nano /boot/cmdline.txt # remove all references (struck through) dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait sudo nano /etc/inittab # comment out getty-references #Spawn a getty on Raspberry Pi serial line #T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100 sudo reboot

After that you need to reboot your RPi and after its up again you can make a short test on /dev/ttyAMA0 with minicom (please note that the baudrate is 38,4k):

sudo apt-get install minicom minicom -b 38400 -o -D /dev/ttyAMA0 # send command "V" (get version) to receive a response like: # "V 1.44 CSM868" # send something like "D" (not known) to receive info-response: # "? ( is unknown) Use one of m B C F A G M R T V W X e f l t x)"

Software Installation

If everything is correct, you receive some lines out of the CC1101 register and so you know that your connection is working good. Now you can proceed with installing fhem. Download the latest version from the fhem website - for a debian-based system you can use the provided package. But before you need to fulfill the dependencies: perl and the serialport-perl module. A detailed installation-howto can be found on the website, the wiki can be found here.

sudo apt-get install perl libdevice-serialport-perl wget http://fhem.de/fhem-5.2.deb dpkg -i fhem-5.2.deb

After the installation is finished, you can visit the fhem-gui per navigating to http://[RPi-IP]:8083/fhem in your browser. You will find a clean and minimal gui - note the command-input on top of the page - so as next step you need to make CSM (or FHZ, CUL, ...) known by fhem. The fhem-command should be something like "define <name> <device-type> <device> <ID>". In my case it is "define CSM1 CUL /dev/ttyAMA0@38400 1234" (CUL, CUNO and CSM are always device-type CUL [CULFW], the device depends on your used module, for CUL it will be /dev/ttyACM0 for example).

Please note that you need to specify the baudrate with the device. You can type the command into the command-input and press enter at first. Its important to press enter at first and not save - Click save only after first submit via enter for saving the command into fhem.cfg.

After that you can click on "Unsorted" in the navigation for checking your device - if adding was successfull it will be listed there. If you want, you can perform some further checks/connectivity-tests with "get <name> version" or "get <name> ccconf". In my case:

get CSM1 version - CSM1 version => V 1.44 CSM868 get CSM1 ccconf - CSM1 ccconf => freq:868.300MHz bWidth:325KHz rAmpl:42dB sens:4dB

Adding Remote Device

So now you can go on with adding a remote device - for example a remote power socket. In my case its a FS20 device. The command for adding an actor is "define <actor_name> <system_type> <house_address> <actor_address>". You can also add the switch to a room with the attr-command "attr <actor_name> room <room_name>". You can find the full commands in the command-reference. For this sample i've defined 11223344 as house-code.

define test_switch FS20 05af 00 attr test_switch model FS20ST attr test_switch room FS20 define FileLog_FS20 FileLog /var/log/fhem/FS20_05af00-%Y.log test_switch attr FileLog_FS20  logtype text attr FileLog_FS20 room FS20

Hint: If you don't know the house-code/house-address or the actor-address you can simply press the switch-dedicated key of your remote control. You will find a log-entry with the code in your log-file. For example: "FS20 Unknown device 05af (11223344), Button 00 (1111) Code 15 (dimupdown), please define it".

If you have added your device and specified a room, you will find the room in the left navigation of fhem. If you haven't specified a room, you will find your device under "Unsorted". Now you can control your device directly via browser by clicking on "on" or "off".

P.S.: Im also working on a shield with a buffered DS1307 real-time clock, a DS1621 thermometer, a DS2483 one-wire controller and a CSM module with some signaling possibilities via piezo-buffer and leds. I2C and One-Wire should be also lead through extern and the whole shield should fits together with Raspberry Pi in one case. The beta-shield will be produced via Fritzing Fab on September 03, 2012 and it will be released as open-source (CC-BY-SA).

[binerry]

Raspberry Pi Caller and Answering Machine

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:

sudo apt-get install subversion svn checkout http://svn.pjsip.org/repos/pjproject/trunk

sudo apt-get install build-essential automake autoconf libtool libasound2-dev libpulse-dev libssl-dev libsamplerate0-dev libcommoncpp2-dev libccrtp-dev libzrtpcpp-dev libdbus-1-dev libdbus-c++-dev libyaml-dev libpcre3-dev libgsm1-dev libspeex-dev libspeexdsp-dev libcelt-dev

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.

[binerry]

Raspberry Pi Watchdog Timer

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.

[binerry]

Raspberry Pi with I2C-Arduino-Slave

Since Raspberry Pi has only about 8 GPIO's (or up to 17 if you reconfigure UART, SPI and I2C as GPIO) or for some other reasons, it may be helpful to combine Raspberry Pi with another μC or PIC (or even a ready-to-use μC-/PIC-Board like Arduino, Netduino or Pinguino) e.g. to get more I/O's or just to seperate two different application areas. Such a combination is surely easy to setup via serial or usb - but at least if serial/usb is already in use or if you are thinking about using more than one further μC or PIC its getting a bit clumsy. Much more flexible and cleaner will be a solution via I2C - in this case you can easily address up to 128 slaves.

So why not combine Raspberry Pi with for example Arduino? Certainly a connection via serial of both devices sounds much easier but really is not. An i2c-slave configuration on Arduino is realized within a few minutes via Arduino's Wire-Library. You just need to define an address for the slave and two callback-methods for sending and receiving data. Thats all:

void setup() {   // define slave address (0x2A = 42)   #define SLAVE_ADDRESS 0x2A   // initialize i2c as slave   Wire.begin(SLAVE_ADDRESS);      // define callbacks for i2c communication   Wire.onReceive(receiveData);   Wire.onRequest(sendData); } // callback for received data void receiveData(int byteCount) {     [...] } // callback for sending data void sendData() {     [...] }

The connection of Raspberry Pi with Arduino is a small tricky proposition since its running at 5V and also all logic levels are 5V, too. The RPi however is running at 3V3 and only accepts 3V3 logic levels. (Once again: Remember that a higher voltage may destroy your RPi.) So in this case you need a bidirectional level-shifter/bridge which shifts/translates and isolates the intercommunication via i2c between both devices. You will find some more informations about this in a previous blog post (I2C-Level-Shifter / I2C-Bridge).

If you have connected both devices like above you can check if your RaspberryPi detects your Arduino-slave via i2cdetect. (Remember that Raspberry Pi needs an actual firmware with an i2c enabled and supported kernel). Ensure that you have loaded the i2c-dev-module before.

sudo modprobe i2c-dev sudo i2cdetect -y -a 0

If everything works fine it will find a device on address 0x2A and you can proceed with testing it. For this scenario i've written some lines of c-code. For accessing I2C within c you need to include the i2c-dev- and i2c-header-files. Creating a connection and requesting data is quite easy and straight forward:

#include <linux/i2c-dev.h> #include <linux/i2c.h> int deviceHandle; char buffer[7]; int main (void) {   // initialize buffer   buffer[0] = 0x00;     // open device on /dev/i2c-0   deviceHandle = open("/dev/i2c-0", O_RDWR);     // connect to arduino as i2c slave   int deviceI2CAddress = 0x2A;  // (0x2A = 42)   ioctl(deviceHandle, I2C_SLAVE, deviceI2CAddress);     // begin transmission and request acknowledgement   write(deviceHandle, buffer, 1);     // close connection and return   close(deviceHandle);   return 0; }

I've connected some leds and a relay to Arduino for testing the basic operation over i2c. As you can see in the top image i've used my own prototyping clone of Arduino consisting of an ATmega328P with Arduino Bootloader and 5V + 3V3 voltage regulators. Its also running at 16MHz and operating at 5V and its fully compatible with the Arduino IDE - so this scenario will run on every Arduino (e.g. Uno, Leonardo, Mega or Nano).

You can download my Arduino and Raspberry Pi sample code from my github-repository or as zip-package. Just load it within Arduino IDE, build and upload it. On Raspberry Pi build i2c-arduino.c (cc -o i2c-arduino i2c-arduino.c) and run it (sudo ./i2c-arduino). The code is licensed under GPL and is distributed without any warranty. Feel free to test and play with it.

[binerry]

I2C-Level-Shifter / I2C-Bridge

For some scenarios you need to enable communication over two or more different voltage levels. For example, if you want to use an ATmega168/328 or Arduino running @ 16MHz/5V as an i2c-slave with a RaspberryPi running @ 3V3 you need to shift/translate/isolate intercommunication levels between both devices. (Remember that RaspberryPi only runs 3V3 logic levels and a higher voltage may destroy the board.)

A solution for this scenario is an i2c-level-shifter or i2c-bridge. Such parts are available as ready-to-use IC's, eg.: Philips AN97055 or Philips PCA9515. Sadly they aren't available as DIP/DIL for an easier protoyping-usage, but since they just consists of some MOSFETs you can realize the circut by yourself.

I've created and tested a simple circuit as shown below. You can also download it as a fritzing-prototype from my github-repository. For creating the circuit i've used 4x BS170 N-Channel MOSFETs and 4x 10kΩ pull-up resistors. You need just about 5 minutes and 1-2€ to finish the circuit.

(Note: Before you start using it ensure that your circuit is fine and check the voltages on SDA/SCL lines with a voltmeter!)

[binerry]

Raspberry Pi and I2C

I2C (Inter-Integrated Circuit) (see wikipedia), also known as two-wire interface (TWI), is a very handy bus protocol. It enables communication of multiple devices over just two wires: SCL (clock line) and SDA (data line).

Generally the RPi supports I2C over GPIO assumed that the kernel supports it and a driver is loaded. For this requirement i use the kernel of Chris Boot which is based on a 3.2 kernel, supports SPI and I2C out of the box and has some more features and advantages in comparison to the official RPi 3.1 kernel.

For a handy test i've found some DS1307 RTC devices from Maxim in my little stock, so why don't try a bit around with it? I've connected it to my RPi as shown below:

The device is running at 5V, but logic levels are running at just 2V2 - so you don't need to worry since RPi can just handle a maximum of 3V3 at logic levels and a 5V logic input may destroy the board. Furthermore you need to ensure that DS1307 and RPi shares common ground. You also need to know, that there is no need for external pull-up resitors at SCL and SDA lines since the RPi has integrated pull-up resistors (1,8kΩ) on both pins.

For running it directly i've loaded the device-driver with modprobe and checked the circuit (if the device gets found via i2cdetect):

sudo modprobe i2c-dev sudo i2cdetect -y -a 0

After some minor adjusments it worked and i2cdetect found a device on address 0x68 - This is the usual device address of DS1307. No i've loaded the kernel-module for the DS1307 RTC and created the device:

sudo bash modprobe rtc-ds1307 echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-0/new_device

(Hint: It's required to run at least the last command as root or via sudo bash, otherwise the device cannot be created.)

Now the actual hardware time can be resolved via hwclock. If you're using the RTC for the first time or the backup battery was disconnected you have to correct the time settings. For this i've first updated the local system time via ntpdate and written this time to the RTC via systohc-param of hwclock:

hwclock -r sudo ntpdate-debian [or] ntpdate -u ntp.ubuntu.com sudo hwclock --systohc

So now, local system time and hardware clock time are synced.

Since I2C is very interesting and some devices are really usefull for using it within own applications i've created a short test snippet for getting the hardware clock within a c-application. For accessing I2C within c you need to include the i2c-dev- and i2c-header-files. Creating a connection and requesting data is quite easy and straight forward. You can found my test-snippet in my github-repository. Feel free to test and play with it.

cc -o rtc_ds1307_rpi rtc_ds1307_rpi.c ./rtc_ds1307_rpi

[binerry]

Raspberry Pi Fritzing Part

For doing some prototyping stuff it maybe really helpfull to use Raspberry Pi within' Fritzing*. Since i haven't found a part of the board until today i've spent some time and created the svg-files for building the appropriate part of the board, model b.

You can get it from my github-repository or download it directly here.

Please note that since there are some DNC-pins (Do Not Connect) on the GPIO-Header (what really means: Do Not Connect!) i haven't enabled them in Fritzing. Maybe some pins are reserved for future purposes, but actually they aren't needed and accordingly not supported/enabled in this fritzing part.

This part is licensed under GPL - feel free to redistribute it and/or modify it under the terms of the GPL.

* Fritzing is an open-source initiative of the University of Applied Sciences Potsdam to support designers, artists, researchers and hobbyists to work creatively with interactive electronics. For more informations and downloads visit http://fritzing.org

[binerry]

PCD8544 Library for Raspberry Pi

(Nokia 3310/5110 Display)

For some Arduino/ATmega328p/µC-based projects i've used a PCD8544-based Nokia 3310/5110 Display. The main advantages of this display are the low price and the simplicity of driving it. So since i've got my first Raspberry Pi and discovered the GPIO-functionality i wanted to drive this display with my RPi.

After a few tests i've decided to port the library of the meshphone-project by Le Dang Dung based on the Arduino-library written by Limor Fried, Adafruit Industries. This driver uses 5 GPIOs on target board with a bit-bang SPI implementation (hence, may not be as fast, but seems fast enough...).

To be honest, it was not much effort and required not many changes until the library works on Raspberry Pi. It makes use of WiringPI-library of Gordon Henderson - so the WiringPI-library is required to be installed. By the way - Gordon has created a nice overview of the RPi GPIO pin mapping.

Since the PCD8544-chip and the GPIO pins of Raspberry Pi are designed to run at 3V3 and both have 3V communication levels there is no logic level shifter (e.g. 4050 like with Arduino) required.

Important Note: Please check the pin assignment of your LCD before you connect it - Nokia 3310 and Nokia 5110 pin assignments can vary, also different breakout-boards can have different pin assignments!

Based on the origin library this version is also licensed under GPL. Feel free to check it out at github or download it directly:

https://github.com/downloads/binerry/RaspberryPi/Raspberry.Pi_PCD8544.Library.zip

There are also three samples available: basic functions (pcd8544_test.c), animation (pcd8544_test2.c) and a basic system monitor (pcd8544_rpi.c).

Since gcc is installed on Raspberry Pi images (tested debian6-squeeze-2012-04-19 and debian7-wheezy-2012-06-18_beta) you can easily build them via

cc -o pcd8544_test pcd8544_test.c ../PCD8544.c  -L/usr/local/lib -lwiringPi cc -o pcd8544_test2 pcd8544_test2.c ../PCD8544.c  -L/usr/local/lib -lwiringPi cc -o pcd8544_rpi pcd8544_rpi.c ../PCD8544.c  -L/usr/local/lib -lwiringPi

and run them via

sudo ./pcd8544_test sudo ./pcd8544_test2 sudo ./pcd8544_rpi