Overview
Automation is the key to make life easier. In this project, we have implemented a simple Internet of Things (IoT) system to automate lighting and curtains based on triggers from the environment. The automation system can turn on or off the lights and adjust the brightness if needed. The system can also lower or open curtains. As the trigger to initiate actions, different sensors such as luminosity could be used, but in this project, the main trigger is network traffic.

Hardware
Philips Hue bridge + 3x lights
Intel Edison + Intel Edison Kit for Arduino
28BYJ-48 5V DC 4-Phase 5-Wire + ULN2003 Stepper Motor Driver Board
Dell D630 laptop with Netwjork W522U USB WLAN dongle
Easton Carbon One 660 arrow

Wiring the Curtains

The stepper motor board was wired to the following pins on the Arduino kit:
IN1 -> 3
IN2 -> 5
IN3 -> 6
IN4 -> 9
GND -> Digital GND
+ -> 5V

Software
The following software and libraries were used in the project
Mraa: Low Level Skeleton Library for Communication on GNU/Linux platforms [3]
phue: A Python library for Philips Hue [4]
Scapy: the python-based interactive packet manipulation program library [6]
Dnsmasq [1]
Hostapd [2]
Google Protobuf [5]

Description of the Prototype
As the full prototype includes a lot of moving pieces, brief descriptions of each piece is given here.

Access Point
The central part of the system is a Dell D630 laptop. The laptop acts as an wireless access point and router for the entire system. The laptop is running Ubuntu 14.04 LTS, dnsmasq [1] and iptables. The AP is created using a Netwjork W522U USB WLAN dongle, which supports master mode, and hostapd [2]. The Philips Hue Bridge is plugged into the AP using a generic USB Ethernet dongle. The Edison uses its onboard WLAN NIC to connect to the AP.

IoT Hub
The IoT Hub is a small central server, which listens commands from different monitoring elements. These elements can be for example sensors (with relevant software) monitoring luminosity or network monitors. In the end, it does not matter what kind of trigger or combination of triggers are used, something needs to gather the signals and translate them to relevant actions.

The IoT Hub listens for commands through a protocol created with Google Protobuf.[5] In general, the signals are notifications from events. In IoT environment, signal could be luminosity change, or in a bit more general environment, a network event such as stream to specific address or a DHCP request.

In the end, the hub takes inputs and then translates them to relevant outputs to different IoT devices, in this case, the curtains and the lights.

Intel Edison and Curtains

The stepper motor is wired to the arduino board, including power and ground. On the Edison, mraa, a low level skeleton library for communication on GNU/Linux platforms with Python bindings [3] is used to change the state of the pins and drive the stepper motor.

A small UDP socket server is used to listen simple, unauthenticated UDP datagrams. When the server receives either “open” or “close” command, the server runs the stepper motor in full-wave mode in either clockwise or counterclockwise direction by specified number of steps. By experimenting, 700 steps with 0.01 second interval between steps seems to be about right for the current gearing ratio for rolling the curtain up down.

Philips Hue

To control the lights, an off-the-shelf Philips Hue set is used. The set contains three lights and a bridge to control the lights. The basic setup, i.e. associating the lights to the bridge and other initial setup was done through an android app, but for the actual communications between the setup and lights were done using Phue library.[4] A small server listening for UDP datagrams was implemented on the laptop. This time, instead of using plain text open/close -messages, a Google Protobuf was used to create a small protocol for controlling lights. Currently, only ON/OFF and brightness commands for all lights is supported, but finer control would be straightforward to implement.

Network Sniffer
In this prototype, sniffing for network traffic was used to trigger the IoT-side, i.e. lights and curtains. For network sniffing, Scapy [6], a very powerful network sniffing, packet manipulation and dissecting tool, was used. With Scapy, the sniffer monitored network traffic, and when the sniffer detected relevant packets, lights and curtains were triggered. The sniffer created a Google Protobuf message to the IoT hub to trigger relevant actions.

In the demo, a UDP datagram stream to a Google Chromecast was used to trigger turning off lights and closing the curtains. When the stream ended, the sender does a HTTP GET request to port 8008, which was used to trigger turning the lights on and opening curtains.

Integration
To make things slightly simpler, most of the components are either running on the AP laptop or are connected through network. The laptop acts as a home gateway, i.e. acts as a NAT device and runs DHCP server. On the laptop, the IoT hub, bridge controller and the sniffer are running. The curtain controller is  running on the Edison, which in turn is connected to the laptop with WLAN.  The Hue bridge is connected to the laptop via Ethernet cable.

Since all relevant communications are IP based, the components could be spread around the network. The only device bound pieces are the curtain controller and the network sniffer. Curtain controller has to run on the Edison to drive the motor, while the sniffer has to see relevant traffic. Of course, multiple sniffers and curtains can be added to the system.

Problems and Future Work
Surprisingly few problems arose during the course. Some, such as elastic drive band slipping from wheel opening and closing the curtains would be trivial to fix, but others are not so easy to fix.

The heuristics used by the network sniffer are currently trivial, mainly matching packet headers and payloads to predefined rules. While relatively straightforward to get basic funtionality, more fine grained detection and reactions need more work.

The main unsolved problem is the crashing of Intel Edison. When the Edison is connected to main powers with charger, the Edison will crash with quite large probability when driving the 5V motor. If the Edison is also connected to a laptop through USB (only charging), the crashes will not happen. One likely reason is voltage fluctuation, but that is hard to prove.

As with many other IoT platforms, this platform currently suffers from the lack of authentication in the protocols and messages. But, unlike other networks, a straightforward way to mitigate this is the network setup. All network components, i.e. the controller, Hue Bridge and Edison are isolated in their own network and IP address space. Other devices can at best see WPA2 encrypted WiFi traffic and packets are not routed between IP address spaces.

Code is available at: https://github.com/shatonen/eg16

[1] http://www.thekelleys.org.uk/dnsmasq/doc.html
[2] https://w1.fi/hostapd/
[3] https://github.com/intel-iot-devkit/mraa
[4] https://github.com/studioimaginaire/phue
[5] https://developers.google.com/protocol-buffers/
[6] http://www.secdev.org/projects/scapy/