1. No category

Smart House
- Subtitle -
Project Report
SW504E14
Department of Computer Science
Selma Lagerlöfs Vej 300
DK-9220 Aalborg Ø
http://cs.aau.dk
c Aalborg University 2014
Copyright Here you can write something about which tools and software you have used for typesetting
the document, running simulations and creating figures. If you do not know what to write,
either leave this page blank or have a look at the colophon in some of your books.
Department of Computer Science
Selma Lagerlöfs Vej 300
DK-9220 Aalborg Ø
http://cs.aau.dk
Title:
Smart House
Abstract:
Here is the abstract
Theme:
Embedded Systems
Project Period:
Fall Semester 2014
Project Group:
SW5504E14
Participant(s):
David Junker
Lasse E. Nielsen
Mads Mikkelsen
Martin Lykke
Martin Z. Kristensen
Søren B. Andersen
Supervisor(s):
Jiri Srba
Copies: 1
Page Numbers: ??
Date of Completion:
December 3, 2014
The content of this report is freely available, but publication (with reference) may only be pursued
due to agreement with the author.
Contents
Preface
ix
1 Introduction
1
2 Analysis
2.1 Home automation . . . . . . . . . . . .
2.1.1 Available features . . . . . . . .
2.1.2 Installation and Configuration
2.2 Current setup . . . . . . . . . . . . . .
2.3 Problem statement . . . . . . . . . . .
2.4 Equipment . . . . . . . . . . . . . . .
2.4.1 Arduino Mega Board . . . . . .
2.4.2 Arduino Ethernet Shield . . . .
2.4.3 LCD display . . . . . . . . . .
2.4.4 Buttons . . . . . . . . . . . . .
2.4.5 Relay module . . . . . . . . . .
2.4.6 Sound sensor . . . . . . . . . .
2.4.7 AD Keyboard module . . . . .
2.4.8 Motion Sensor . . . . . . . . .
2.4.9 Standard Buzzer Module . . .
2.4.10 Realtime clock . . . . . . . . .
2.4.11 Light dependent resistor . . . .
2.4.12 DC Voltage regulator . . . . .
2.4.13 Electric current measurement .
2.5 New setup . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
3
3
4
4
5
5
5
8
9
11
13
14
15
17
19
19
20
22
22
24
3 Design
3.1 Model Driven Software
3.2 System Description . .
3.2.1 Web Server . .
3.2.2 Clock . . . . .
3.2.3 Keypad . . . .
3.2.4 Button . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
25
25
27
28
29
29
29
Design
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
.
.
.
.
.
.
v
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
vi
Contents
3.3
3.4
3.5
3.6
Rules . . . . . . . . . . . . . . . . . . . .
3.3.1 Main loop for rules . . . . . . . .
3.3.2 Use case example . . . . . . . . .
Remembering the state of lights . . . . .
Implementation analysis . . . . . . . . .
3.5.1 Arduino C++ . . . . . . . . . . .
3.5.2 Embedded Java . . . . . . . . . .
3.5.3 Choice of programming language
NilRTOS . . . . . . . . . . . . . . . . .
4 Architecture
4.1 NilRTOS . . . . . . . . . . .
4.2 Libraries . . . . . . . . . . . .
4.2.1 RelayManager . . . .
4.2.2 Running time analysis
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
30
30
31
33
35
35
35
35
36
.
.
.
.
37
37
38
38
38
5 Implementation
39
6 Conclusion
41
Bibliography
43
Jiris House
45
Todo list
o Power wasted = (input voltage – output voltage) * load current - Help Jiri .
o husk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
o overvej om det lige er de tre komponenter der skal beskrives eller om det
giver bedre mening at beskrive grupperne i diagrammet . . . . . . . . . .
o hvad er den (worst-case), mere analyse af hardware vs limit, dynamisk etc. .
vii
22
28
30
35
viii
Contents
Preface
Here is the preface.
Aalborg University, December 3, 2014
David Junker
Lasse E. Nielsen
<[email protected]>
<[email protected]>
Mads Mikkelsen
Martin Lykke
<[email protected]>
<[email protected]>
Martin Z. Kristensen
Søren B. Andersen
<[email protected]>
<[email protected]>
ix
x
Preface
Chapter 1
Introduction
The idea behind home automation is to improve the every-day life of people. Home
automation is used to describe when components such as lighting, heating, ventilation, air conditioning, appliances, blinds and locks can be controlled and automated
through electronic devices. This can provide improved comfort, energy efficiency
and security in a house [Institut, 2013]. Automating different tasks could be a great
help to the elderly and disabled, and also be a way to optimize energy consumption.
The industry shows a great interest in home automation. In January 2014 Google
bought Nest Labs, which is known for their smart thermostat and smoke alarm, for
3.2 billion dollars [Griffith, 2014]. However even though there is a interest in the
technology some issues still remain. The task of configuring the different devices and
get them to cooperate is difficult for the end-user and is currently maintained by
domain experts. There have been different attempts to simplify the process but even
after these the task of configuring and expressing the desired behavior still requires
domain knowledge [Sørensen, 2014].
The objective of this project is to turn an old house into a modern smart house.
The task is to be able to achieve an advanced control of the lights through different
devices. Furthermore the end-user should be able to configure the house without
requiring domain knowledge about the system. The project will be based on the
house of our supervisor who got a traditional danish villa.
1
2
Chapter 1. Introduction
Chapter 2
Analysis
In this chapter home automation systems that are currently available is described
and analyzed as a basis for developing a product that ameliorates the properties
of existing home automation systems. Our supervisor’s house configuration will be
described to identify any specific requirements for a home automation system. A
problem statement will follow defining the issues that needs to be addressed. To
address the issues a description and analysis of the hardware components needed for
the home automation system will follow.
2.1
Home automation
This section describes possible features, advantages and disadvantages in existing
home automation solutions.
2.1.1
Available features
Some of the features that are available in current home automation systems can be
seen in Table 2.1. Some features such as light switches requires current components
to be replaced by new components supported by the home automation system.
Light control through light switches
Blinds control
Heating and cooling control
Fan control
Monitor the power consumption of the home
Allow users to program sequences of tasks and buttons
Allow users to schedule automated tasks
Different house configurations such as home theater
Simple configuration of devices through a network scan
Table 2.1: Possible features in a home automation system [Gavazzi, 2014].
3
4
Chapter 2. Analysis
Typically a home automation system is based on modules which can be added
to a head-unit and extend the existing features of a given home automation system.
The features can be managed through different devices such as smartphones, tablets
or Personal Computers (PC) with supported applications [Gavazzi, 2014].
2.1.2
Installation and Configuration
Home automation can be implemented in different ways. Some of the most common
ways of installing a home automation system includes replacing the houses existing
switches with new switches and devices that are plugged into existing switches and
gives remote control of the connected device. Most systems1 contain components that
require a certified technician to install and configure. A technician typically require
about 10 % of the total price of the home automation system as payment. In these
systems it is not possible for user to extend and configure the system, but requires
a technician to do this should it be needed [Company, 2014]. Some systems such
as Creston and Ninja Blocks include an application for the user to create rules and
configure the system but they may prove too difficult for users without programming
and hardware expertise to use.
2.2
Current setup
To get a better understanding of how to transform the current house into a new
smart house, we need to understand how the light installation of the house works.
A figure illustrating the layout of the house can be seen in Appendix 6. The house
have 16 relays each connected to buttons and lights. A section of these relays can
be seen in figure 2.1. Each relay is connected to buttons and lights in the house.
These relays work by receiving an impulse which switches them from on to off or the
opposite. Figure 2.1 illustrates this by having the relay switch on either on (|) or off
(o).
Figure 2.1: Section of the 16 relays in the house.
1
Smart House, Crestron, AMX, SavantAV, Control4 and more
2.3. Problem statement
5
The current installation in the house causes some problems that must be considered. A button works by creating a circuit when pressed. This circuit makes it
possible to provide the electrical impulse to the relay connected with the button.
However the relays may only receive a very brief impulse since they will burn out
if the duration of the impulse is too long. Therefore if a person on purpose or by
accident makes a long press on the button the relay will burn out. Another problem
is that sometimes the relay switch does not move from its current position when receiving the impulse. As the introduction states the project will aim at solving these
problems with low budget devices and by making it possible for the user to configure
the house without the need of external assistance.
2.3
Problem statement
As described in section 2.1 the examined solutions are expensive, require a certified
technician to install, maintain, extend and adjust. Furthermore some features can
require existing components in the house to be removed. In this project we will try
to remove these disadvantages while keeping the advantages of existing solutions.
Our problem statement is:
• How can a home automation system be build such that:
– the solution is cheap?
– it does not require a technician to install, maintain, extend and adjust?
– it works with existing electrical components in the house?
– the user can configure the system through several devices?
– the user can trust that the configuration work?
2.4
Equipment
To solve the problem statement various equipment is needed. The equipment has to
be cheap and require no technician to install. The following sections describes the
chosen equipment.
2.4.1
Arduino Mega Board
The Arduino Mega Board consists of several components which are shown in Figure
2.2.
ATMega2560 MCU: The Arduino Mega Board uses an ATmega2560 microcontroller unit (MCU). A feature of the ATmega2560 microcontroller is its 54
digital input/output pins. This makes it possible to connect a large number of
components to the microcontroller.
6
Chapter 2. Analysis
Figure 2.2: Arduino Mega Board [Arduino, 2014e]
Serial-to-USB circuitry: An ATMega 16U2 microcontroller is also included and
serves as an interface between a Universal Serial Bus (USB) cable and the
serial USART pins on the main microcontroller used, among other things, for
bootloading.
USB connector: Allows a USB cable to be connected to the Arduino Mega Board
to transfer compiled code to the bootloader. When the Arduino is connected
to a device through the USB it will run on a power supply of 5 volt.
MCU programming connector (ICSP): The ICSP is a hardware interface to
the ATMega2560 MCU making it possible to program directly to the ATMega2560 MCU without the use of a bootloader. This makes it possible to
take full advantage of the flash size of which the bootloader would use 8 KB.
6-20VDC input: When the Arduino is not connected through the USB connector,
it can use an external power supply. The Arduino can operate on 6 to 20 volts
but anything outside of 7 to 12 volts may prove unstable or damaging.
Debug LED: The LED will flash when code is being uploaded and stay lit when
the Arduino is running. It is connected to pin 13 making it possible to use the
LED for other purposes.
General I/O: These are digital input/output pins allowing the communication
2.4. Equipment
7
from and to connected components. The maximum DC current per I/O pin
is 40 mA and 20 mA is recommended [Arduino.cc, 2014]. Pins on an Arduino
have INPUT as default configuration. When a pin have the INPUT configuration, it is possible to get the status of the pin. The ATMega chip have 20 50 kOhms pullup resistors built into it that can be accessed from Arduino programs [Arduino, 2014f]. When a pin have the configuration INPUT_PULLUP,
the behavior of it is reverted. The INPUT_PULLUP configuration is preferred
to use because the INPUT configuration can pickup electronic noise from its
surroundings, which makes it unpredictable [Arduino, 2014g].
Analog-to-Digital convert inputs: These are the same as the general I/O pins
except they can also receive analog input from connected components. They
convert the analog input ranging from 0 to 5 volt to a digital number ranging
from 0 to 1023.
Power and auxilary pins: These pins provide power to other components such as
bread boards.
Bootloader
Ordinarily, ATMega microcontroller programs are written in C or Assembly and programmed via the In-circuit serial programming (ICSP)-interface using a dedicated
programmer. The most important characteristic of an Arduino is that it got an USB
interface. The interface makes it possible to upload code to the Arduino. This functionality is made possible by the Arduino bootloader. The bootloader is loaded onto
the ATMega at the factory (using the ICSP header), which allows a serial Universal Synchronous/Asynchronous Receiver/Transmitter (USART) to load a program
on the Arduino. Hereby knowledge about the ICSP interface is not needed [Blum,
2013].
When uploading a program to the Arduino it is saved to the flash, which on the
ATMega 2560 used in this project has a size of 256 KB of which 8 KB is used for
the bootloader.
The bootloader is a chunk of code stored in a reserved space in the flash memory
of the Arduino. At the first boot of the Arduino board, it enters the bootloader,
which runs for a few seconds. If it receives a programming command via the USART
it loads the program into the flash memory. If the bootloader does not receive
a programming command, it starts running the program that resides in the flash
memory, if any. When the Arduino receives an “upload” command, the USB-toserial chip, in this case an ATMega 16U2, is instructed to reset the main MCU,
hence forcing it into the bootloader. Bootloaders are great because they enable
simple programming via USB with no external hardware. However, they do have
two downsides:
• They take up valuable program space, in this case 8 KB.
8
Chapter 2. Analysis
• Using the bootloader causes the program to be delayed by a few seconds at
boot time as the bootloader checks for a programming request [Blum, 2013].
Programming an Arduino
A program for Arduino is called a sketch. A sketch contains two phases: the setup
phase and the loop phase.
Setup phase: The setup phase is the first phase that is called when a sketch is
executed. It is used to initialize variables, set the different pin modes, load libraries,
etc. The setup phase will only run once every time the Arduino is booted [Arduino,
2014h].
Loop phase: The loop phase is called after the setup phase. This phase makes
is possible for a program to respond and change to control the Arduino [Arduino,
2014d].
2.4.2
Arduino Ethernet Shield
The Arduino Ethernet Shield consists of several components which are shown in
Figure 2.3. This section describes the different components.
Ethernet port: The Arduino Ethernet Shield is connected to a network with the
integrated RJ45 Ethernet jack. The Ethernet port has a connection speed of
10/100mb [Arduino, 2014c].
WIZnet w5100 Ethernet chip: The Arduino Ethernet Shield is based on the
WIZnet w5100 Ethernet chip which is a single-chip Internet enabled 10/100
Ethernet controller. The following is cited from the WIZnet W5100 datasheet:
"The W5100 is a full-featured, single-chip Internet-enabled 10/100 Ethernet
controller designed for embedded applications where ease of integration, stability, performance, area and system cost control are required. The W5100 has
been designed to facilitate easy implementation of Internet connectivity without
OS. The W5100 is IEEE 802.3 10BASE-T and 802.3u 100BASE-TX compliant" [WIZnet, 2010]. The chip from WIZnet supports up to four socket
connections at the simultaneously, by either UDP or TCP provided by a network stack [Arduino, 2014c]. The WIZnet 5100 chip has a internal buffer of
16Kbytes for data transmission [WIZnet, 2010].
micro-SD card slot: The Arduino Ethernet Shield has an onboard micro-SD slot
which is compatible with the Arduino Mega board used in this project. The
slot combined with a SD card makes it possible to store files and serving these
on the network. The micro SD card is accessible with the SD library provided
by the Arduino project [Arduino, 2014c].
2.4. Equipment
9
Figure 2.3: Arduino Ethernet Sheild-R3, picture taken from [Arduino, 2014b]
Reset Button: The Arduino Ethernet Shield has a reset button as seen in figure
2.3, which ensures that the W5100 chip is reset properly on power-up [Arduino,
2014c].
Digital pins: The digital pins on the Ethernet Shield are used for communication
between the Shield and the attached Arduino. The Arduino Mega board is
able to communicate with the Micro SD and the WIZnet w5100 Ethernet chip
by using the SPI bus through the ICSP header. The Arduino Mega board uses
pin 50,51,52. Furthermore pin 10 is used for selecting the W5100 chip and pin
4 is used for the SD card. Because of the fact that the WIZnet Ethernet chip
and the SD card share the SPI bus only one of them can be active at same
time. Both the WIZnet Ethernet chip and the SD card is active by default,
to disable those pin 4 and 10 must be set as high output, for SD card and the
Ethernet chip respectively [Arduino, 2014c].
2.4.3
LCD display
This component is a low power consumption character LCD module with a built
in controller. The component can display 20 characters per line and is capable of
displaying four lines. The LCD makes use of white text on a blue background.
10
Chapter 2. Analysis
Furthermore the component needs a supply voltage of 5V.
In order to swap information a common communication protocol must be used.
There exist many protocols and each can be separated into one of two categories
namely parallel or serial communication. Parallel interfaces transfer multiple bits at
the same time, while serial interfaces stream their data one bit at a time. The LCD
uses serial communication which makes it possible to transfer data using less wires
than parallel communication, which can be seen in Figure 2.4. The LCD only needs
4 wires. Besides wires to GND and VCC a wire to the SDA (data line) pin and a
wire to the SCL (clock line) pin is needed. A picture of the LCD display used in this
project can be seen in Figure 2.5.
Figure 2.4: A: An 8-bit data bus, controlled by a clock. Each out transfer a byte every clock pulse.
B: A serial interface, one byte is transfered every clock pulse [Jimbo, 2014]
11
2.4. Equipment
Figure 2.5: A picture of the LCD display
2.4.4
Buttons
The buttons used in this project are two pins momentary on-off push buttons illustrated in Figure 2.6.
Figure 2.6: Picture of a push button, from [CircuitSpecialists, 2014]
The buttons work by changing from an open circuit or a closed circuit when the
button is pushed. An open cirtuit is illustrated in Figure 2.7.
Figure 2.7: Picture of an open circuit
12
Chapter 2. Analysis
In this project the buttons are used to open relays described in section 2.4.5 and
therefore the buttons are connected to the Arduino using a digital pin and a ground
pin. Listening to the digital pin can then indicate if a button is being pushed. When
the button is pushed the digital pin reads a 0. When the button is released the
digital pin reads a 1. When reading the digital input received from the button the
data looks very irregular as picture 2.8 illustrates.
Figure 2.8: Button without resistor
The graph was created by logging the digital input from the digital pin connected to
the button, using the Arduino serial monitor. The button was pushed at the time
where the graph flatlines at zero in the digital input axis. To get a precise reading
of the input received on the digital pin an internal 20K Ω pull-up resistor on the
Arduino is used. Figure 2.9 illustrates how the input received on the digital pin is
changed using the internal resistor.
Figure 2.9: Button with internal resistor
2.4. Equipment
2.4.5
13
Relay module
A relay is a mechanical switch used to connect and disconnect electronic circuits.
When the switch connects two circuits it is said to be normally opened and when it
disconnects the circuits it is said to be normally closed.
Figure 2.10: 5V Active Low 8 Channel Road Relay Module Control Board
The relay used in this project is an eight channel relay interface board which can
be controlled by microcontrollers such as the ones contained in Arduino boards, it
is illustrated in Figure 2.10. It supports up to 5 volt and can output up to AC250V
10A and DC30V 10A making it applicable in a real house.
It is an active-low relay meaning it is opened when receiving low or no voltage
and closed when receiving a high voltage up to 5V. The relay needs continuous power
to operate. There are three terminals on each relay: NO, COM and NC. The COM
(Common) connection of the relay is the part of the relay that moves. When the
relay is off, the COMMON is connected to the NC (Normally Closed). The NO
(Normally Open) connection of the relay is not connected until the relay turns on.
When the relay turns on, the COM move from NC to NO. The relay is mechanical
and creates a clicking sound that indicates movement to the COMMON terminal
[Devices, 2014].
14
Chapter 2. Analysis
2.4.6
Sound sensor
A sound sensor is capable of detecting pressure differences in the air and transform
them into electric signals [Patarroyo, 2013]. The signal received from the sound
sensor is usually too weak and has to be amplified to be utilized properly. The sound
sensor used in this project can be seen in Figure 2.11.
Figure 2.11: High Sensitivity Sound Microphone Sensor Detection. [Nakamura, 2014]
The sound sensor module used in this project has two outputs:
• Analog output - A real-time output voltage signal of the sensor
• Digital output - Transmits a low and high signal when the sound intensity
reaches a certain threshold.
The sensor uses a 5V DC power supply.
The following picture illustrates the recording of a human sound using the analog
read with the sound sensor.
Figure 2.12: Recording of a high pitched human sound
The following picture illustrates the recording of a human clap using the analog read
with the sound sensor.
15
2.4. Equipment
Figure 2.13: Recording of a human clap
According to the two pictures there is a distinct difference between the two sounds,
this is important to distinguish between sounds.
2.4.7
AD Keyboard module
The component has five buttons and uses one analog port. The keyboard has a
standard voltage output of 5 volt and to determine which button is pressed, the
buttons output different voltage ranging between 0 to 5 volt via the analog port.
The component can be seen in Figure 2.14.
Figure 2.14: AD Keyboard Electronic Blocks Simulate Five Key Module
Figure 2.15 shows how the analog input is read with an Arduino Nano w/AT
Mega2560. The diagram illustrates an integer value ranging from 0 to 1023, which
is scaled from the voltage output ranging from 0V to 5V. The y-axis is the voltage
output scaled to an integer value, and the x-axis is the time in milliseconds. As an
example when the first button, SW1 is pressed the integer value outputted is zero.
16
Chapter 2. Analysis
800
600
400
200
0
SW1
SW2
SW3
SW4
SW5
Figure 2.15: Illustration of the different voltage output scaled to an integer ranging from 0 to 1023
The measured voltages and the corresponding integer values can be seen in Table
2.2. The voltage output and its scaled integer value was for each button very steady
and only has a very small deviation.
Button
SW1
SW2
SW3
SW4
SW5
Output voltage
0.00
0.76
1.52
2.33
3.42
Integer scaled value
0
141-142
327-328
503
740
Table 2.2: Output voltage registered on button pushes
17
2.4. Equipment
2.4.8
Motion Sensor
Figure 2.16: Front and back of the motion sensor.
The sensor makes it possible to detect motion and is illustrated in Figure 2.16. The
sensor is a Passive Infrared (PIR) sensor and its basic specifications can be seen in
Table 2.3. A PIR is made of a pyroelectric sensor. This sensor detects the infrared
(IR) radiation in an environment. The hotter something is the more radiation it
gives. The sensor has two slots that each measure difference in IR levels. The reason
for having to slots is to make it possible to detect motion [LadyAda, 2014]. When
a human enters the sensing area it is first detected by one of the slots and then
detected by the other slot when leaving the sensing area again. When one slot is
sensing something and the other is not, a positive differential change between the
two slots appears. When the other slot is sensing something the reverse happens
and the sensor gives a negative differential change see Figure 2.17. These change
pulses are what is detected [LadyAda, 2014]. A chip on the sensor takes the analog
output of the sensor and transform it into a digital output. When the sensor detects
motion the digital output is high and when no motion is detected the output is low
see Figure 2.17.
18
Chapter 2. Analysis
Figure 2.17: PIR diagram [LadyAda, 2014]
Output
Sensitivity range
Power supply
Delay time
Blocking time
Ampere usage
Digital pulse high (3V) when triggered (motion detected) digital
low when idle (no motion detected). Pulse lengths are determined
by resistors and capacitors on the PCB.
Up to 6 meters with a 110◦ × 70◦ dectecing area.
3V-9V input voltage. The ideal is 5V.
Default 6 seconds. (5-300S).
Default 2.5 seconds.
less than 60uA.
Table 2.3: Basic specifications of the motion sensor
Testing the motion sensor
A test were conducted to verify the accuracy of the sensor. It was conducted by fixating the sensor and then detecting motion from different distances. Each movement
was a horizontal step and made while fronting the sensor. The number of movements
at each distance was 30.
19
2.4. Equipment
Distance
1m
2m
3m
4m
5m
6m
Number of movements
30
30
30
30
30
30
Detected
30
28
30
29
28
30
Deviation
0%
6,67 %
0%
3,33 %
6,67 %
0%
Table 2.4: Results of testing the motion sensor.
The test results seen in Table 2.4 show that the motion sensor is accurate. There
are some deviations, but the results show, that it is not due to the distance. The
sensor is supposed to detect human movements. In the test the sensor only detected
a single horizontally step, whereas in reality a human would make several movements
when being in front of the sensor. Overall the accuracy of the sensor is good enough
to be used to detect motion in a house since even though it can miss a single step, it
does not miss several movements.
2.4.9
Standard Buzzer Module
The module has a working voltage ranging from 3.5V to 5.5V. It is connected with
a ground pin and either a digital or analog pin.
The buzzer used in this project can be seen in Figure 2.18
Figure 2.18: Stanard Buzzer Module
2.4.10
Realtime clock
A realtime clock keeps track of the current year, month, day and time. The module
used in this project is called DS3231 and has a low-power consumption. It is a very
accurate I2C realtime clock and it has an integrated temperature compensated crystal
oscillator. It has two programmable time-of-day alarms. The clock can operate in
either a 24-hour format or a 12-hour format with AM/PM indication. The real time
clock makes use of serial communication through an I2C bidirectional bus to transfer
data.
20
Chapter 2. Analysis
A battery is integrated in the module. This makes it possible to maintain the
accurate date and time when there are no power connected to the module. The
longterm accuracy of the time and date is furthermore enhanced by the integrated
crystal resonator. The module needs a supply voltage of 3.3V [DALAS, 2005]. The
component can be seen in Figure 2.19
Figure 2.19: Realtime clock module
2.4.11
Light dependent resistor
A light dependent resistor (LDR) is a small device used to measure light levels.
Basically it is a resistor that changes its resistive value depending on the amount of
the present light. The resistive value can be affected by temperature and the LDR
is therefore not suited for a precise measurement of light. Furthermore there is a
delay from measuring a change in the light level before the resistive value updates.
When shifting from total darkness to light, the resistive value changes with latency
up to 10 ms, and when going from light to total darkness the latency can be up to
1 second.
To test the sensitivity of the LDR two tests were conducted. The desired result
of the tests were to see if the resistive value had a tendency to drift and to see how
much the deviation would be over time. The tests were performed by logging the
resistive value for four minutes in a room with two light levels. One light level with
the lights in the room turned off and a light level with the lights in the room turned
on.
The measured light resistance in the room with the lights turned off is illustrated
in Figure 2.20.
21
2.4. Equipment
Figure 2.20: LDR measurement in a dark room
The measured light resistance in the room with the lights turned on is illustrated in
Figure 2.21
Figure 2.21: LDR measurement in a bright room
To get a feeling of the two light levels the Lux of the two rooms is calculated from
the measured resistive values using the following equations.
Vm = (Vt /1024) ∗ Ri
RL = Rf (Vt − Vm )/Vm
Lux = 500/RL
22
Chapter 2. Analysis
In the first equation the measured voltage Vm is calculated by dividing the total
voltage read on an analog pin on the Arduino by the 1024 units that the Arduino
can read on an analog pin. Then the result is multiplied by the measured unit of
the analog input. In the second equation the resistive value of the LDR is calculated
by multiplying the resistive value of the resistor used with the subtraction of the
total voltage and the measured voltage. The result is then divided by the measured
voltage. From the resistive value measured with the LDR the Lux is calculated by
dividing the value with 500. The Lux levels are illustrated in Table 2.5
Room
Lights turned off
Lights turned on
Analog input (max)
286
781
Lux
19
159
Table 2.5: Table of calculated Lux levels
The measurements shows that there is a significant difference in the measured resistive values with the two light levels. The deviation of the measurement in the
room with the lights turned off has a deviation of 19 while the deviation in the room
with the lights turned on was 55. To conclude the results the measurements deviate
more the closer the resistive value is to the max of what the LDR can measure. It
is unlikely that the LDR will be used in a room that maxes the analog input due to
the fact that this will correspond to a Lux level of 51150. Even though there is a
deviation the deviation is small compared to the difference in the measured values
in the two light settings which was 495. So the conclusion is that the sensitivity of
the sensor satisfies the needs of this project.
2.4.12
DC Voltage regulator
The voltage regulator is used to ensure that the voltage output to the Arduino is
correct. The recommended input Voltage of the Arduino is 7-12V and the output
of the adapter used to power the Arduino outputs 18.5V. Therefore the regulator is
used to decrease the output from 18.5V to 7V. The regulator has an output power
of maximum 15 watts. Therefore the regulator can output the Arduinos with 15W
/ 7V = 2140 mA.
Power wasted = (input
voltage – output voltage)
* load current - Help Jiri
2.4.13
Electric current measurement
To ensure that the Arduino is supplied with sufficient power, the electric current used
by each component is measured. Table 2.6 illustrates how much electric current each
component consumes and how much the hardware consume together. The LEDs are
a part of the dummy Arduino and therefore not included in the table.
To measure the electric current consumed by each hardware component a voltmeter was used as shown in the following Figure 2.22.
23
2.4. Equipment
Component
Relay with one open gate
LCD Display
Ethernet Shield
Motion sensor
Sound sensor
AD keyboard
Standard active buzzer module
Real-time clock
Current per component (mA)
66.5
37.4
190
3.3
5.98
2.35
16.8
4.73
Amount
16
1
1
1
1
1
1
1
Total
Max (mA)
1064
37.4
190
3.3
5.98
2.35
16.8
4.73
1324.56
Table 2.6: Electric current used by each component
A
Arduino
Figure 2.22: Picture illustrating measurement of electric current.
The maximum allowed current of the Arduino ATmega 2560 is 800 mA [Arduino.cc, 2014]. In the Table 2.6 the sum of the electric current is 1361.16 mA which
is clearly above the allowed electric current. The most consumable is having all the relays opened at the same time. Without any relays opened, the used electric current is
summed up to 260.56mA which means that another 800mA−260.56mA = 539.44mA
electric current can be drawn from the Arduino. To ensure that the electric current
does not exceed the limit of 800 mA, only eight relays can be open at the same time,
see Equation 2.1.
It should furthermore be possible to add new components which also uses electric
current. A limit of two open relays is suitable. The limit will be controlled by a
software safety feature on the Arduino which ensures that not more than two relays
are open simultaneously.
539.44mA
= 8.11 ≈ 8 Relays
66, 5mA
(2.1)
24
2.5
Chapter 2. Analysis
New setup
In section 2.2 the current setup was explained. This section is dedicated to explain
the new setup, which can be seen in Figure 2.23. The relays of the house will be
connected to two Arduino Relay Boards (ARB). Each ARB has eight relays. This
makes it possible for each relay in the house to have a corresponding Arduino relay.
The impulse needed to switch the house relays from either on or off will be given
through the ARBs. The relay board is connected to an Arduino with the Home
automation system on. The buttons will now be connected to the Arduino board
instead of the relays in the house. Each button has a input pin and share a common
ground pin. By connecting the buttons to the Arduino it is possible for the user to
configure the behavior of lights. As an example, if a user wants to turn on the light
in another room from the bedroom, then the Arduino have to send a signal from
the Arduino relay that corresponds to the house relay connected to the light in the
hallway when a given button in the bedroom is pushed.
Figure 2.23: The new house setup
Chapter 3
Design
In this chapter the model driven software development method will be described to
give an overview of how a model created by an end user can be transformed with
several purposes. The model created in this project is refered to as rules and is
created using a web interface. The user has to be able to configure the behavior i.e.
change the model of his house, therefore a description of the structure of the rules and
its behavior has to be made. Furthermore programming languages suitable for the
system is analyzed and discussed. A discussion of two different ways to implement
scheduling of tasks follows.
3.1
Model Driven Software Design
Model driven software design (MDSD) is a software design method based on the
usage of models. Models used in MDSD do not constitute documentation, but is a
foundation for code. The main objective in MDSD is to be able to express software
structure and behavior in an efficient way. When a model is defined and described
it can be transformed into executable code by model transformations [Tekinerdoğan,
2013]. Hereby the move from programming the solution, to modelling the solution
with a human friendly abstraction the solution will be in favour of the end user. To
implement this view of MDSD the actual code has to automate tasks for constructing
and transforming the model [Sendall and Kozaczynski, 2003]. In this project the
model that needs to be transformed is a model of rules that the user creates using
a web interface. Three ways of transforming the model has been analyzed in this
project.
Code generation which transforms the model into executable Arduino code. This
approach requires code to be uploaded to the Arduino. One way of uploading
code without using extern resources can be done by uploading a hex file from
an SD card on the Arduino. Hereby the code to be uploaded has to be in hex
format, either written in hex or compiled to hex. If the code to be uploaded is
not in hex format it needs to be compiled with an avr-gcc compiler [Arduino,
25
26
Chapter 3. Design
2014a].
Rule interpretation is in this project used by loading JSON files with rules defined in the model. The loaded JSON data is interpreted by the existing code
uploaded to the arduino. In this way the model can be changed, transformed
into JSON and then interpreted by the Arduino avoiding the neccesity to upload and compile code. This approach uses more ram and is less efficient than
the previous mentioned Code generation strategy.
Verification can be done using UPPAAL1 . UPPAAL is an integrated model tool
environment that allows users to model, simulate and analyze the behavior of
models (processes). UPPAAL consists of three parts: A description language,
a simulator and a model checker. The above description of MDSD is illustrated
in Figure 3.1 in proportion to this project with rules as the model.
Simluation can be done using UPPAAL to examine the possible dynamic executions of the model. Hereby it can be used as a fault detection prior to the
verification. The simulator in UPPAAL can also be used to visualise executions generated by the verifier [UPPAAL, 2014].
Figure 3.1: Illustration of Model Driven Design in our case
1
http://www.uppaal.com/admin/anvandarfiler/filer/uppaal-tutorial.pdf
27
3.2. System Description
Cons
Recompilation is required
Rule Interpretation
Pros
Optimal executable code
Minimal use of memory
No recompilation
Verification
Ensures intended behaviour
Time consuming
Code Generation
Uses up more ram
Summary
This section introduced the idea behind the Model Driven Software Design method.
The MDSD method will be used in this project according to our model, which is
rules for the behavior of the house. The rules describes the houses behavior and they
are described in section ??.
3.2
System Description
The system consists of five groups of elements. A diagram of the different components
of the system can be seen in Figure 3.2. The control unit in our project is the
ATmega2560 but it could be any other control unit (CU). The CU can receive input
from the sensors. The sensors consist of components that register inputs but can
not change their state e.g. a button can nothing else than register a push. When
a sensor receives an input it will notify the CU and the CU will check with the
virtual objects which action to execute. The virtual objects consist of rules which
can trigger an event or change a mode. If the virtual object receives an input that
conforms with a rule it will notify the CU that some hardware needs to change its
state. Otherwise the virtual objects will periodically check if a rule has been fulfilled
and send a notification to the CU. The CU will then change the state of relevant
actuators. Actuators are any component which state can be changed by the CU.
Aditionally the CU can receive the current state that an actuator is in.
28
Chapter 3. Design
Figure 3.2: Overview of the system
3.2.1
Web Server
The web server is used for most of the features of the system. The following features
are possible through the web server:
• Configuration of the different hardware of the system.
husk
– The CU needs to know which pins the different hardware are connected to
the CU with. When the configuration is complete, the web server sends
something to the CU. The CU then reads something, and creates the
objects that are needed for the system to function.
• Creating modes that are used to represent the state of the house.
– Modes are used to ensure that different rules will only be triggered in
desired modes. Some examples of modes could be night mode and vacation
mode. The user has to create the different modes for the house on the
website.
• Creating rules to ensure a specific behavior for the system.
– The rules require information about the state of the house, the relays and
the different hardware added to the system. An example of a rule is to
turn on the light in the kitchen when the clock is 7am.
3.2. System Description
29
• See and toggle the state of lights and modes.
– This makes it possible for the user to turn lights on/off and set modes like
vacation mode through the web server.
3.2.2
Clock
The clock is used to check the current time. This is because the user can make
modes and rules that requires the time be between some period. The clock works
by periodically sending the time to the CU. The CU sends the time to the virtual
objects which will then check if the CU needs to be notified of an event.
3.2.3
Keypad
The keypad is used to communicate with the Arduino through the display. The
display is used to show information about the house. It is possible for the user to
configure some of the functionality of the system through the display. The features
of the display are:
• Start the setup phase.
– Used to configure the relationship between buttons and relays. When the
setup is activated, the system will turn a relay on and then wait for the
user to push a button. When the user pushes a button the system will
add an association between the relay and button. The user can then push
another button to create another button association to the relay or push
the same button to finish the configuration of the relay. This will continue
until all the relays have an association to at least one button.
• Set/show local time.
• Display the status of the system such as the current states of lights.
3.2.4
Button
The buttons have two purposes: The first purpose is to ensure the default behavior,
where a given button turn on the relay(s) it is paired with. The second purpose is
to trigger rules. The purpose of buttons with rules will be described below:
• Buttons can be used as triggers for rules. In this way, a user can make a rule
that turns off all the light in the house if the button at the front door is pushed.
In our system, there are three different types of button push:
– Short push: This works like a normal push of a button.
– Double push: This works as two consecutive short pushes.
– Long push: A long push is activated when the user pushes a button for
more than 2 seconds.
30
overvej om det lige er
de tre komponenter der
skal beskrives eller om
det giver bedre mening
at beskrive grupperne i
diagrammet
3.3
Chapter 3. Design
Rules
The rules for the house are used to ensure a specific behavior. The rules are based
on events and IDs which are defined as finite sets. The state function is a mapping
function from ID to a positive number 3.1.
State ID → N0
(3.1)
The positive number which the ID is mapped to is used to describe the state, e.g.
the state of lights or the state of modes. A light can be either switched off or on and
a more intelligent light could be switched off, dimmed and turned on. In this case
the intelligent light would have three states, 0 = Off, 1 = Dimmed, 2 = On. The
default state of every ID is 0.
The abstract syntax is used to formally describe the syntax of the rules. The
syntax is defined by assuming a collection of syntactic categories. Each category has
a finite set of formation rules. Equation 3.2 shows the different elements of the finite
sets defined in ??.




P ∈ Prog








R
∈
Rules











 id ∈ ID
e ∈ Events
(3.2)




0


w∈N








d
∈
N
∪
{∞}







 m ∈ N0
The grammar in 3.3 describes how to formulate rules for the house.
hPi ::= ε | hRi ; hPi
hRi ::= if e when hC i then hAi
hC i::= tt | id = m ∧ hC i
hAi::= ε | hid = mi starting in w for d ; hAi
3.3.1
Main loop for rules
In order to describe the behavior of the rules structure, an algorithm will be used
which runs forever, the algorithm can be seen in Algorithm 1.
3.3. Rules
31
Data: E ⊆ Events
Result: Manage rules
Collect new events E
forall the e’ ∈ E do
forall the (if e when C then A) ∈ A do
if e’ == e && C holds then
forall the (id = m start in w for d) ∈ A do
id.update(m, w, d)
end
end
end
end
forall the id ∈ ID do
set hardware to id.now
end
Algorithm 1: Rule algorithm
3.3.2
Use case example
This subsection will give an example of how a user could configure the rules for a
hallway in a house. The hallway has three buttons, a motion sensor and three lights,
which can be seen in Figure 3.5. The user wants a certain behavior of the hallway
at day and another at night. Therefore the user creates two modes namely a day
and night mode. In day mode the user would like the light to follow him through
the hallway when he pushes button “Button A”. To provide this functionality the
user assumes it takes 10 seconds to enter the center of the hallway and another 20
seconds to go to either the kitchen or living room.
At night the user wants to turn on all the lights in the hallway when motion
sensor “Motion Sensor A” detects motion. The user then configures the desired
rules on the home automation website. As mentioned in Section ?? the rules have
a specific syntax which it needs to be defined in. First the user needs to specify an
event that triggers the rules. The rule associated with “Button A” created using the
web interface would be:
32
Chapter 3. Design
Figure 3.3: Rule associated with Button A
The rule associated with “Motion Sensor A” created using the web interface would
be:
Figure 3.4: Rule associated with Motion Sensor A
3.4. Remembering the state of lights
33
Figure 3.5: A hallway with three lights, three buttons and a motion sensor
3.4
Remembering the state of lights
It is possible for the user, to turn on/off a light with a delay time and for a period.
This behavior, and its problems, will be explained through an example.
Example:
The user has a light, L1 , a button, B1 and a rule, R1 with the following behavior:
R1 : If B1 is pushed and L1 = 0 then set L1 = 1 in 4s for 1s.
We assume that the default state of L1 = 0. The user pushes B1 , which means
that R1 is triggered as seen in Figure 3.6. The user pushes the button at time 0s, so
after 4 seconds L1 = 1 and after 5 seconds L1 = 0. In this example, the system has
to remember one interval to function as wished.
34
Chapter 3. Design
Figure 3.6: First example
In the next example, the user pushes B1 again at time 2s. Now, L1 has to turn on
at 4s, turn off at 5s, then turn on at 6s, and off at 7s. This example can be seen in
Figure 3.7. In this example, the system has to remember two intervals to function
as wished.
Figure 3.7: Second example
In the last example, the user pushes B1 at 0s, 1s and 2s. The behavior of this example
can be seen in Figure 3.8. In this example, the system has to remember only one
interval, because the button push at 1s connects the time where L1 = 1 from 4s to
7s.
Figure 3.8: Third example
Now the question arises, what is the maximum number of times the system has to
remember for a specific light?
A rule that turns a light on/off consists of a delay time w, and a duration d. A
light can be turned on/off from m number of rules. We therefore have m amount of
pairs consisting of w and d: (w1 , d1 ), . . . , (wm , dm ). As a start, the largest delay
and the lowest duration must be found. This will be done by comparing all m and d,
and then save the largest delay in mmax and the lowest delay dmin . The maximum
amount of time the system has to know must be the largest delay added with the
largest duration, such that maxtime = mmax + dmin . The system has to save the
start and end time for every d. We know that dmin can appear a maximum num-
3.5. Implementation analysis
35
time
ber of times in the time line, calculated as max
dmin . Since every d has a start and
maxtime
end time, the system needs to save dmin × 2 for every light. In the worst case,
mmax = 24h and dmin = 1s. This means that the system could potentially need to
save 172,800 times which is unrealistic on the Arduino. Therefore a limitation must
be set . The amount of times the system needs to save can vary a lot therefore a
dynamic allocation of the times is preferable.
3.5
Implementation analysis
A programming language for developing the home automation system has to be
chosen. Two languages have been considered, Arduino C++ and an open source
Java execution environment called HVM.
3.5.1
Arduino C++
C/C++ are the most common languages used for developing to an Arduino as the
Arduino IDE uses the AVR Libc toolchain to compile C/C++/Ada and all Arduino
libraries are written in C/C++. The toolchain makes use of the AVR GCC compiler
which is a C/C++/Ada compiler targeting AVR devices. AVR GCC does not include the Standard C Library as some of the functions can cause problems on small
embedded devices. However AVR Libc uses a library avr-libc that provides libraries
specifically designed for use with an Arduino and its connected components as well as
a subset of the Standard C Library. Most unofficial libraries are written in C/C++
as well making some development aspects easier by simply using an existing library
[Boellmann et al., 2010]..
3.5.2
Embedded Java
The HVM development environment allows the developer to write code in Java and
to debug the code on an Arduino. HVM is capable of translating Java code to C
code but also capable of interpreting bytecode. The advantage of translating the code
into C is that it executes faster but interpreting the bytecode requires less memory.
Executing code programmed with HVM is approximately three times slower than
C/C++ [Korsholm, 2012]. HVM Java includes the whole standard library of Java
but allows the developer to explicitly exclude parts of the library that is not used
for the program [Korsholm, 2014]. However HVM Java does not provide additional
libraries designed specificially for the Arduino environment.
3.5.3
Choice of programming language
The lack of the avr-libc library and unofficial libraries and the slower execution are
considered critical disadvantages if HVM Java were to be used in this system. The
libraries available in C/C++ provides an interface between the Arduino and the
developer which lets the developer abstract from the specific implementation of the
hvad er den (worst-case),
mere analyse af hardware
vs limit, dynamisk etc.
36
Chapter 3. Design
hardware. Using HVM the developer would have to write directly to the hardware
components which is redundant compared to Arduino C++. The slower execution
is critical since the home automation system is safety critical and therefore requires
certain deadlines in the program to be successful. In terms of coding in Java and
C++ they are both object-oriented programming languages with a high abstraction
level. Because two drawbacks of HVM has been analysed and none of C++ has been
found the home automation system will be built in C++.
3.6
NilRTOS
In order to orchestrate the execution of the different tasks in the system a scheduler
is needed. NilRTOS is a real-time OS (RTOS) library for scheduling tasks and
communicating between them. The scheduler allows threads to be defined with
priority and allows them to sleep when other threads need attention. The tasks
may share resources which is managed by defining and using binary or counting
semaphores. The library is made for use with AVR microcontrollers and is therefore
developed to be a small and fast which is useful since the Arduino Mega does have
limited amount of memory and the home automation system needs to meet the
deadlines. Also the library almost only contains functionality that is needed for the
home automation system [Sirio and Greiman, 2014].
Chapter 4
Architecture
4.1
NilRTOS
In this section a short overview of how features of NilRTOS are implemented.
A single thread is implemented as in Listing ??.
1
2
SEMAPHORE_DECL ( sem , 1) ;
NIL_WORKING_AREA ( thread , 64) ;
3
4
5
6
7
8
9
10
NIL_THREAD ( Thread1 , arg ) {
while ( TRUE ) {
nilSemWait (& sem ) ;
nilSemSignal (& sem ) ;
nilThdSleep (1000) ;
}
}
11
12
13
14
N I L _ T H R E A DS _ TA BL E _B E GI N ()
N I L _ T H R E A DS _ TA BL E _E N TR Y ( " thread1 " , Thread1 , NULL , thread , sizeof (
thread ) )
N I L _ T H R E ADS _TABL E_EN D ()
Listing 4.1: Declaration of a single thread
In line 2 a stack is declared with a size of 64 bytes in addition to the memory needed
for context switch and interrupts. The thread function is defined in line 4 with a
reference to the thread given as the first argument. In line 12 the thread table begins.
Inside of it the threads are declared. In this case only one thread is declared. The
first argument is the name of the thread which could also have been NULL to save
RAM and since it is not going to be used anyway. Thread1 is used in line 4 so the
program knows which thread belongs to which function. Fourth and fifth argument
is the working area and the size of the working area which we defined in line 2. If
more threads were to be added it would be done by creating a new working area,
thread function and declaring the thread in the thread table. Then the thread table
would define the priority of the threads by their position in the table.
37
38
Chapter 4. Architecture
In Listing ?? a binary semaphore is declared in line 1. The second argument of
the declaration defines the limit of the semaphore. In line 6 the thread tries to take
the semaphore and if it succeeds the rest of the code will execute. If not it will wait
for the semaphore to be released which is done as seen in line 7.
Finally a thread can sleep which is done as in line 8 were the thread sleeps for
one second to let threads with a lower priority execute.
4.2
Libraries
4.2.1
RelayManager
4.2.2
Running time analysis
In order to make a real time scheduling analysis, the worst case execution time of
our different libraries must be known. To find the execution time, each library must
be run with a timer. We have decided to run each library X amounts of times, and
then take the worst case.
Chapter 5
Implementation
Introduction to Implementation here
39
40
Chapter 5. Implementation
Chapter 6
Conclusion
Introduction to Conclusion here
41
42
Chapter 6. Conclusion
Bibliography
Arduino (2014a). Arduino build process.
BuildProcess. Online accessed 04/11-2014.
http://arduino.cc/en/Hacking/
Arduino (2014b). Arduino ethernet shield. http://arduino.cc/en/uploads/
Main/ArduinoEthernetShield_R3_Front.jpg. Onlie acced 16/09-2014, notations
added to the picture.
Arduino (2014c).
Arduino ethernet shield.
http://arduino.cc/en/Main/
ArduinoEthernetShield. Online accessed 16/09-2014.
Arduino (2014d). Arduino loop phase. http://arduino.cc/en/Reference/loop.
Online; accessed 16/10-2014.
Arduino (2014e).
Arduino mega 2560.
https://arduino.cc/en/Main/
arduinoBoardMega2560. Online accessed 10/09-2014.
Arduino (2014f).
Arduino mega2560.
http://arduino.cc/en/Main/
arduinoBoardMega2560. Online; accessed 20/11-2014.
Arduino (2014g).
Arduino mega2560.
http://arduino.cc/en/Tutorial/
DigitalPins. Online; accessed 20/11-2014.
Arduino (2014h). Arduino setup phase. http://arduino.cc/en/Reference/Setup.
Online; accessed 16/10-2014.
Arduino.cc (2014). Arduino atmega 2560 max current. http://playground.
arduino.cc/Main/ArduinoPinCurrentLimitations.
Online accessed 24/092014, notations added to the picture.
R Tools and Techniques for Engineering WizBlum, J. (2013). Exploring Arduino:
ardry. John Wiley & Sons, Inc.
Boellmann, W., Camera, D., Conradie, P., Dean, B., Gudger, K., van Gulik, W.,
Haase, B., Haugen, S., Jansen, P., Jessich, R., Johansson, M., Kipp, H., Lamas,
C., Lawson, C., Lipowski, A., Michalkiewicz, M., Miller, T. C., Neswold, R.,
O’Flynn, C., Paddock, B., Pashchenko, A., Patommel, R., Petrov, F.-V., Popov,
A., Rickman, M., Roth, T. A., Schilling, J., Soeberg, P., Sokolov, A., Strom, N. K.,
43
44
Bibliography
Stumpf, M., Swanepoel, S., Wallner, H., Weddington, E. B., Wunsch, J., Xmelkov,
D., Corporation, A., and egnite Software GmbH (2010). avr-libc. http://www.
nongnu.org/avr-libc/user-manual/index.html. Online; accessed 19/10-2014.
CircuitSpecialists (2014). Push button. http://www.circuitspecialists.com/
content/117382/r18-29a%20red-0.jpg. Online; accessed 14/09-2014.
Company, H. A. (2014).
How much does home automation really
cost?
http://www.homeautomationcompany.co.uk/blog/
how-much-does-home-automation-cost/. Online accessed 13/10-2014.
DALAS (2005). Extremly Accurate I2C-integrated RTC/TCXO/Crystal. Dallas Semiconducor coperation, 120 San Grabiel Drive Sunnyvale CA.
Devices, N. C. (2014). Relay logic. https://www.controlanything.com/Relay/
Device/RELAY_LOGIC. Online accessed 17/09-2014, notations added to the picture.
Gavazzi, C. (2014).
Solutions for home automation.
Also available
as
http://smartbuilding.dk/smarthouse/download/brochurer/BRO_
HomeAutomation_EN_v03_1401.pdf.
Griffith, E. (2014). Nest and beyond: A beginner’s guide to home automation. http:
//www.pcmag.com/article2/0%2c2817%2c2410889%2c00.asp. Online; accessed
15/10-2014.
Institut, T. (2013).
Smart home teknologi (sht).
Also available as
http://www.digst.dk/~/media/Files/Velf%C3%A6rdsteknologi/Rapporter%
20og%20analyser/Bilag%201_Smarthometeknologi_Delrapport_fra_
Teknologisk_Institut.pdf.
Jimbo (2014). Serial communication. https://learn.sparkfun.com/tutorials/
serial-communication. Online; accessed 15/10-2014.
Korsholm, S. E. (2012). Java for Cost Effective Embedded Real-Time Software. Ph.d.
dissertation, Department of Computer Science, Aalborg University.
Korsholm, S. E. (2014). The hvm reference manual. http://icelab.dk/resources/
HVMRef.pdf. Online; accessed 24/09-2014.
LadyAda (2014). Overview, pir motion sensor. https://learn.adafruit.com/
pir-passive-infrared-proximity-motion-sensor/overview. Online; accessed
21/09-2014.
Nakamura, H. (2014). Arduino sound sensor. https://sites.google.com/site/
summerfuelrobots/arduino-sensor-tutorials/arduino-sound-sensor. Online; accessed 10/09-2014.
Patarroyo, J. (2013). Sound sensors.
Sensors. Online accessed 31/10-2014.
http://wiki.wiring.co/wiki/Sound_
Bibliography
45
Sendall, S. and Kozaczynski, W. (2003). Model transformation – the heart and soul
of model-driven software development. http://infoscience.epfl.ch/record/
52559/files/IC_TECH_REPORT_200352.pdf. Online accessed 05/11-2014.
Sirio, G. D. and Greiman, B. (2014). Nilrtos-arduino. https://github.com/
greiman/NilRTOS-Arduino. Online accessed 11/11-2014.
Sørensen, M. G. (2014). Controller synthesis for home automation. Masters thesis,
Department of Computer Science, Aalborg University.
Tekinerdoğan, B. (2013). Cs 587 model-driven software development. http://www.
cs.bilkent.edu.tr/~bedir/CS587-MDSD/. Online accessed 04/11-2014.
UPPAAL (2014). Uppaal simulation. http://www.uppaal.com/index.php?sida=
216&rubrik=101. Online accessed 24/11-2014.
WIZnet (2010). W5100 datasheet. Also available as http://www.wiznet.co.kr/
UpLoad_Files/ReferenceFiles/W5100_Datasheet_v1.2.2.pdf.