Embedded Systems Course

              Final Project

Smart House Emulator using Tmote-Sky

Developers: Tal Shapira & Max Gurtovoy

Course lecturer: Prof. Sivan Toledo

Winter semester 2012-2013



The goal of the project is to build a smart house – a computerized system for long distance control over a house.

The house's electric equipment is operated by Tmote-Sky MCUs. Each LED on the MCU emulates turning on/off an electric device.

The system's user/manager uses an Android application in order to control the system.


System Architecture

The architecture is demonstrated in the diagram below. The server (which has a static IP address) communicates with both the

Android application and the master Tmote-Sky node (the red circle in the illustration below) using the TCP/IP protocol. The master

Tmote-Sky node communicates with all other nodes with our RIME-based protocol that is explained later.





> There is no NIC in the Tmote-Sky MCU.

Solution: the master node has to be connected over SLIP (Serial Line Internet Protocol) to a router that will forward packets to/from

the Android application.

> Absence of static IP address on the Android appliance and on the Tmote-Sky MCU.

Solution: connect as two clients (Android & master sky node) to a server with a static IP address. In this way we can deploy the

 Tmote-Sky network anywhere we want.

> Signal strength limitations of the IEEE 802.15.4 Chipcon Wireless Transceiver.

Solution: use multi-hop communication primitives. The multi-hop primitives do not specify how packets are routed through the network.

Instead, as a packet is sent across the network, the application or upper layer protocol is invoked at every node to choose the next-hop

neighbor. This makes it possible to implement arbitrary routing protocols on top of the multi-hop primitives.

> Make the Tmote-Sky nodes communicate (between the master and the designated node) in a reliable way, using low power


Solution: each command to the system is performed using a 3-step transaction as explained later.

> Build the Android application view in a dynamic way according to the number of nodes in the Tmote-Sky network.

Solution: extend the BaseAdapter abstract class. The BaseAdapter class implements the Adapter interface. The Adapter object acts as a

bridge between an AdapterView (view whose children are determined by an adapter) and the data for that view (data that is determined




System Flow

1. Server with static IP address listens for TCP connections from the master node client (i.e Contiki client) and from the Android application

(i.e. Android client).

2. Contiki client connects to the server.

3. Android client connects to the server.

4. Server waits for messages from the Android client to forward to the Contiki client.

5. Android client queries for the number of nodes in the system in order to build the application view.

6. Server forwards the query to the Contiki client (master node) and waits for an answer.

7. Contiki client (mater node) sends the answer to the server.

8. Server sends the answer to the Android client and waits for commands from it.

9. Android client builds application view and waits for user input (clicks on the relevant buttons).

10. User clicks a button to cause a change of state at some node in the network.

11. Android client sends the relevant command to the server and waits for ack.

12. Server receives the command, forwards it to the Contiki client and waits for ack.

13. Contiki client receives the command and sends it to the relevant node in the network.

14. Relevant node receives the command and performs the needed action. Then it sends an ack to the Contiki client.

15. Contiki client receives an ack from the node in the network, and then sends a “stop flooding” message to the network, and an ack to the


16. Server receives the ack and forwards it to the Android client.

17. Android client receives the ack and becomes available for user commands again (back to step #10).


Android Client Flow



















Contiki Client (Master Node) Flow























Multi-Hop Protocol Explanation and Demonstration (Using Cooja Emulator)

To implement the system communication we relied on Contiki Trickle (RIME-based single source flooding) and changed it for our needs.

Each command received by the master node from the server is followed by a 3-step transaction.

In each step a message is flooded in the system. Each message contains (from left to right in the diagram below):

2 cells of source Id (master node), 2 cells of destination device node id, 1 cell of operation id (e.g. “4” in the diagram, meaning

“turn the blue LED on”), and 1 cell of message status. At first the master node sends a command with status 0, and when the

designated node receives the command it performs it and changes the status to 1 (ack message). When the master node receives the ack

it floods a "close" message in the system. Each node forwards this message a predefined number of times and then stops all forwarding,

it "sleeps" until a new command arrives.














Each small circle with a number (in the diagram below) represents a node in the network.

The green circle represents the transmission range of the node transceiver.

Step 1 – master node (node #1) sends the command “green LED on” to node #2.

Initial state: Green LED on Node #2 is off.

Node #1 floods the message in the network.

Node #5 receives the message and floods it too.

Node #6 receives the message from Node #5 and floods it too.

Node #4 receives the message from Node #6 and floods it too.



Step 2 – node #2 receives the message

Node #2 receives a message “green LED on” from Node #4.

Node #2 performs the command.

Node #2 floods an ack message to node #1.

Node #4 receives an ack from node #2 and floods it in the network.

Node #6 receives an ack from node #4 and floods it too.

Node #5 receives an ack from node #6 and floods it too.




















Step 3 – Node #1 receives the ack and sends a “CLOSE” message to the network

The “CLOSE” message tells the nodes to stop flooding the current message and move to the “resting” state.

Node #1 receives an ack from node #5 and sends a “CLOSE” message to the network.



The network nodes move to the “resting” state

The “CLOSE” message is flooded in the network and all nodes close the session for this command by saying:

“BYE BYE. I’m closed”.






















Android Application (for Platform 4.0.3 and Above)

As we mentioned earlier, the Android application connects as a client to a server with a static IP address. The first message

after the connection is a query to the master node in the Contiki network for the number of nodes in it. After receiving the

answer the application builds the main user interface:



Now the user can press on a button to perform the desired action. After pressing a button the application sends the relevant

command to the relevant node (through the server and the Contiki client) and waits for ACK:



 Future Possibilities

> Connect the network nodes to real house equipment to enable the user to control real home devices.

> Add a NIC to the master Contiki node in order to get rid of the server that is the bottle neck in the current configuration.

> Develop an iOS application to control the Contiki network.




Contiki OS - http://contiki.sourceforge.net/docs/2.6/index.html

Get started with contiki - http://www.contiki-os.org/start.html

Contiki uIP TCP/IP stack - http://senstools.gforge.inria.fr/doku.php?id=os:contiki

Linux network configuration - http://www.yolinux.com/TUTORIALS/LinuxTutorialNetworking.html

Android training - http://developer.android.com/training/index.html

Tmote-sky datasheet - http://www.eecs.harvard.edu/~konrad/projects/shimmer/references/tmote-sky-datasheet.pdf