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
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).

Blog comments powered by Disqus