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:
November 20, 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
7
9
10
12
13
14
16
18
18
19
21
21
23
3 Design
3.1 System Description . . . . . . .
3.2 Rules . . . . . . . . . . . . . . .
3.2.1 Main loop for rules . . .
3.2.2 Use case example . . . .
3.3 Remembering the state of lights
3.4 Model Driven Software Design
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
25
25
27
28
28
29
31
.
.
.
.
.
.
v
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
vi
Contents
3.5
3.6
Implementation analysis . . . . . . . . .
3.5.1 Arduino C++ . . . . . . . . . . .
3.5.2 HVM Java . . . . . . . . . . . .
3.5.3 Choice of programming language
Operating System . . . . . . . . . . . .
3.6.1 Bare metal . . . . . . . . . . . .
3.6.2 NilRTOS . . . . . . . . . . . . .
3.6.3 Choice of operating system . . .
4 Architecture
4.1 Arduino . . . . . . . . . . . .
4.1.1 Pins . . . . . . . . . .
4.1.2 Functions . . . . . . .
4.1.3 Libraries . . . . . . . .
4.2 NilRTOS . . . . . . . . . . .
4.3 Libraries . . . . . . . . . . . .
4.3.1 RelayManager . . . .
4.3.2 Running time analysis
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
33
33
33
33
34
34
34
34
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
35
35
35
36
36
36
37
37
37
5 Implementation
39
6 Conclusion
41
Jiris House
41
Todo list
o
o
o
o
o
Overvej om den her sektion måske skal være til sidst i kapitel 2 - SBA . . .
husk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
hvad er den (worst-case), mere analyse af hardware vs limit, dynamisk etc. .
tiny . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
vii
23
26
31
34
34
viii
Contents
Preface
Here is the preface.
Aalborg University, November 20, 2014
David Junker
Lasse E. Nielsen
<djumke12@student.aau.dk>
<leni12@student.aau.dk>
Mads Mikkelsen
Martin Lykke
<mfpm12@student.aau.dk>
<mlykk12@student.aau.dk>
Martin Z. Kristensen
Søren B. Andersen
<mzkr12@student.aau.dk>
<sa12@student.aau.dk>
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 [?]. 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 [?]. 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 [?].
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 [?].
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 [?].
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 [?]. 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 will describe
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 [?]
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 [?].
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 [?].
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.
• Using the bootloader causes the program to be delayed by a few seconds at
boot time as the bootloader checks for a programming request [?].
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.
8
Chapter 2. Analysis
Figure 2.3: Arduino Ethernet Sheild-R3, picture taken from [?]
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 [?].
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" [?]. The chip from WIZnet supports up to four socket connections at the
simultaneously, by either UDP or TCP provided by a network stack [?]. The
WIZnet 5100 chip has a internal buffer of 16Kbytes for data transmission [?].
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
9
2.4. Equipment
by the Arduino project [?].
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 [?].
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 [?].
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.
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.5: A picture of the LCD display
10
Chapter 2. Analysis
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 [?]
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 [?]
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.
11
2.4. Equipment
Figure 2.7: Picture of an open circuit
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.
12
Chapter 2. Analysis
Figure 2.9: Button with internal resistor
2.4.5
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
2.4. Equipment
13
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
[?].
2.4.6
Sound sensor
A sound sensor is capable of detecting pressure differences in the air and transform
them into electric signals [?]. 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. [?]
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.
14
Chapter 2. Analysis
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.
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
15
2.4. Equipment
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.
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
16
2.4.8
Chapter 2. Analysis
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 [?]. 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 [?].
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.
17
2.4. Equipment
Figure 2.17: PIR diagram [?]
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.
18
Chapter 2. Analysis
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.
19
2.4. Equipment
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 [?]. 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.
20
Chapter 2. Analysis
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
21
2.4. Equipment
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.
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.22 illustrates how much electric current each component consumes and
how much the hardware consume together.
To measure the electric current consumed by each hardware component a voltmeter was used as shown in the following Figure 2.22.
22
Chapter 2. Analysis
Component
Relay with one open gate
LCD Display
LED
Ethernet Shield
Motion sensor
Sound sensor
AD keyboard
Standard active buzzer module
Real-time clock
Current per component (mA)
66.5
37.4
3.7
190
3.3
5.98
2.35
16.8
4.73
Amount
16
1
18
1
1
1
1
1
1
Total
Max (mA)
1064
37.4
66.6
190
3.3
5.98
2.35
16.8
4.73
1361.16
Table 2.6: Electric current used by each componenet
A
Arduino
Figure 2.22: Picture illustrating measurement of electric current.
The maximum allowed current of the Arduino ATmega 2560 is 800 mA [?]. 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 800mA −
297.61mA = 502.39mA. To ensure that the electric current does not exceed the limit
of 800 mA, only seven relays can be open at the same time, see Equation 2.1.
It should furthmore be possible to add new components which also use 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.
502, 39mA
= 7, 55 ≈ 7 Relays
66, 5mA
(2.1)
23
2.5. New setup
2.5
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
Overvej om den her sektion måske skal være til
sidst i kapitel 2 - SBA
24
Chapter 2. Analysis
Chapter 3
Design
In this chapter a description of the system is presented to give an overview of how
the equipment described in Section ?? is implemented in the system. The user has to
be able to configure the behavior of his house therefore a description of the structure
of the rules and its behavior has to be made. The intended behavior of the house is
modelled in order to clarify how to implement the system. Then the transition from
model to software is described. 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
System Description
The system consists of two main elements, namely an Arduino and a webserver. A
diagram of the different components of the system can be seen in Figure 3.1. The user
can communicate with the system through either the webserver, keypad or buttons
in the house.
Figure 3.1: Overview of the system
25
26
Chapter 3. Design
The webserver is used for most of the features of the system. The following features
are possible through the webserver:
• Configuration of the different hardware of the system.
husk
– The Arduino needs to know which pins the different hardware are connected to the Arduino with. When the configuration is complete, the
webserver sends something to the Arduino. The Arduino then reads
something, and create 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.
• See and toggle the state of lights.
– This makes it possible for the user to turn lights on/off through the webserver.
The keypad is used to communicate with the Arduino with the aid of 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 atleast one button.
• Set the time.
• Switch the logical state of a light.
27
3.2. Rules
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.
3.2
Rules
The rules for the house is used to ensure a specific behavior. The rules are based on
events and IDs which are defined as finite sets in Equation 3.1
(
ID
Events
)
= finite sets
(3.1)
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 3.1.




P
∈
Prog








R
∈
Rules











 id ∈ ID
e ∈ Events
(3.2)




0


w
∈
N







d ∈ N ∪ {∞} 







 m ∈ N0
The grammar in 3.2 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::= hC i starting in w for d ; hAi | ε
Function Call in 3.3 defines how the ID maps to N0 .
Call ID → N0
(3.3)
28
3.2.1
Chapter 3. Design
Main loop for rules
In order to describe the behavior of the rules structure, an algorithm will be used
which can be seen in Algorithm 1.
Data: (r1 , r2 ..., rk ) ∈ Rule and (e1 , ..., em ) ∈ Event
Result: Manage rules
Collect events;
while True do
for i := 1 to k do
if ri .isTriggered then
if ri ≡ ej ∈ (w,d) then
ej .Add(w,d);
else
ej .Remove(w,d);
end
end
end
for j := 1 to m do
if ej .isOn then
Turn ej On;
else
Turn ej Off;
end
end
end
Algorithm 1: Rule algorithm
3.2.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.2. 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 syntax of the rule associated with “Button A” could be:
3.3. Remembering the state of lights
29
If Button A pushed when day mode = 1 and Light 1 = 0 then light 1 = 1 starting
in 0s for 10s and light 2 = 1 starting in 10s for 20s and light 3 = 1 starting in
10s for 20s.
The syntax of the rule associated with the motion sensor could be: If Motion Sensor
A motion when night mode = 1 then light 1 = 1 starting in 0s for 30s and light
2 = 1 starting in 0s for 30s and light 3 = 1 starting in 0s for 30s.
MESSAGE FOR JIRI, HERE WE WOULD LIKE A PICTURE OF
HOW THE GUI WOULD LOOK LIKE WHEN CREATING THIS RULE,
WE WILL DISCUSS OUR IDEA FOR HOW THIS WORK AT THE
MEETING
Figure 3.2: A hallway with three lights, three buttons and a motion sensor
3.3
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 press and L1 is off then turn L1 on in 4s for 1s.
30
Chapter 3. Design
We assume that the default state of L1 is off. The user press B1 , which means that
R1 is triggered as seen in Figure 3.3. The user presses the button at time 0s, so L1
has to turn on at time 4s and turn off at time 5s. In this example, the system has
to remember two times to function as wished.
Figure 3.3: First example
In the next example, the user presses 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.4. In this example, the system has to remember four times to function as
wished.
Figure 3.4: Second example
In the last example, the user presses B1 at 0s, 1s and 2s. The behavior of this
example can be seen in Figure 3.5. In this example, the system has to remember
only two times, because the button press at 1s connects the time L1 has to be on
from 4s to 7s.
Figure 3.5: 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
3.4. Model Driven Software Design
31
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 numtime
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.4
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[?]. 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 [?]. Therefore three ways of creating the model transformation
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[?].
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,
1
http://www.uppaal.com/admin/anvandarfiler/filer/uppaal-tutorial.pdf
hvad er den (worst-case),
mere analyse af hardware
vs limit, dynamisk etc.
32
Chapter 3. Design
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
a simulator and a model checker. The above description of MDSD is illustrated
in Figure 3.6 in proportion to this project with a rule as the main model.
[H]
Model Rules
Format
transformation
Code
generation
Arduino
Executive
UPPAAL
Model
Verification
Rule
interpretation
Simulation
Figure 3.6: Illustration of Model Driven Design in our case
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.5. Implementation analysis
3.5
33
Implementation analysis
An programming language for developing the home automation system has to be
chosen. Two languages have been considered, Arduino C++ and HVM Java.
3.5.1
Arduino C++
C/C++ are the most common languages used for developing to an Arduino as all
Arduino libraries are written in C/C++ and the compiler used for the Arduino
translates from C/C++ code. When writing C/C++ code for the Arduino the AVR
Libc toolchain is used to compile the code. The AVR Libc toolchain does not include
the Standard C Library as some of the functions are not fitting for execution on a
small embedded device. 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.
3.5.2
HVM 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 translate
the code to C is that it executes faster than interpreting the code but interpreting
requires less memory. Executing code programmed with HVM is three times slower
than C/C++. 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.
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 the slower execution are considered critical disadvantages if they were to be used in this system. The avr-libc library provides an
interface between the Arduino and the developer which lets the developer abstract
from the specific implementation of the 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 require certain deadlines in the program to be successful.
B In terms of coding in Java and C++ they are both object-oriented programming
languages with support for classes and methods. Because two drawbacks of HVM
has been analysed and none of C++ has been found the home automation system
will be built in C++.
34
3.6
Chapter 3. Design
Operating System
In this section bare metal programming will be discussed. Furthermore the possibility
of using an operating system (OS) such as NilRTOS will be analysed. The method
which will be used is based on the following discussion.
3.6.1
Bare metal
Bare metal means running applications directly on the hardware without the use of
an OS. This gives the programmer full control of how an application suite is executed
as opposed to having an OS to e.g. schedule the applications. An application suite
may contain several applications which in this project would be a webserver and
the home automation system. The programmer would have to write code necessary
for the application suite to function properly. This could be a subset of an OS e.g.
it could be a scheduler and some memory allocation logic. The advantages of this
approach are that the programmer does not depend on an OS to work as expected
and only what is required for the application suite to function is implemented [?].
3.6.2
tiny
NilRTOS is a real-time OS library. The library provides functionality to e.g. define
threads, thread priority, binary and counting semaphores. It gives a lot of control
to the programmer by allowing the programmer to create a task, give it a priority,
make it sleep at given times and define where a task enters a critical region. It is
a tiny library and is made to be used on AVR Arduino boards. The advantages
of using an OS like NilRTOS is that the programmer does not have to write the
functionality that is needed but already implemented in the OS. A disadvantage is
that the programmer have to depend on the OS to work as expected and have the
functionality the programmer needs [?].
3.6.3
help
NilRTOS
Choice of operating system
NilRTOS contains the features that are necessary for the implementation of the
projects home automation system. Furthermore it is very light weight, both in space
and functionality, contains almost only functionality that fits this project and the OS
gives the programmer a lot of control which is necessary to make sure our system meet
its deadlines. If a bare metal approach was chosen a lot of additional coding would
have to be made and it would not necessarily prove to work better than NilRTOS.
Chapter 4
Architecture
4.1
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 [?].
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.
4.1.1
Pins
The pins on an Arduino can have the configurations OUTPUT, INPUT or INPUT_PULLUP:
• OUTPUT: When a pin is configured as output, the Arduino can provide up
to 40 mA from that pin.
• INPUT: 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.
• INPUT_PULLUP The Atmega chip have 20K (ER FORSKELLIGT FRA
MODEL TIL MODEL) pullup resistors built into it that can be accessed from
Arduino programs. 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.
35
36
Chapter 4. Architecture
4.1.2
Functions
The Arduino language have functions that can be used in Arduino programs. A list
of the different functions we are using can be seen in Table 4.1 with a description of
their functionality.
Digital I/O
pinMode(pin, mode)
digitalWrite(pin, value)
digitalRead(pin)
Analog I/O
analogRead(pin)
Time
millis()
Configures a specified digital pin to be either an input
pin or an output pin. Possible to use the internal
pullup resistor when input.
Write a HIGH (5V) or a LOW (0V) to a specified
digital pin.
Reads the value from a specified digital pin. This functions either returns HIGH or LOW.
Reads the value from a specified analog pin. The functions returns the input voltage converted to an integer,
mapped from 0 to 1023.
Returns the time since the Arduino was turned on in
milliseconds. This number will overflow after about
50 days, which will reset the time.
Table 4.1: The different functions from Arduino used in this project [?].
4.1.3
Libraries
Libraries are a collection of code used to easily connect and communicate with different devices through the Arduino.
4.2
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
N IL _T H RE A DS _ TA BL E _B E GI N ()
37
4.3. Libraries
13
14
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.
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.3
Libraries
4.3.1
RelayManager
4.3.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.
38
Chapter 4. Architecture
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 functions.
HomePage. Online; accessed 16/10-2014.
http://arduino.cc/en/Reference/
Arduino (2014e).
Arduino mega 2560.
https://arduino.cc/en/Main/
arduinoBoardMega2560. Online accessed 10/09-2014.
Arduino (2014f). 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.
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.
43
44
Bibliography
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. (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.
Okafor, U., Karne, R. K., Wijesinha, A. L., and Appiah-Kubi, P. (2013). Eliminating
the operating system via the bare machine computing paradigm. Also available as
http://triton.towson.edu/~karne/dosc/paper18/uzopaper2.pdf.
Patarroyo, J. (2013). Sound sensors.
Sensors. Online accessed 31/10-2014.
http://wiki.wiring.co/wiki/Sound_
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. Master’s 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.
WIZnet (2010). W5100 datasheet. Also available as http://www.wiznet.co.kr/
UpLoad_Files/ReferenceFiles/W5100_Datasheet_v1.2.2.pdf.