University POLITEHNICA of Bucharest

Faculty of Automatic Control and Computers,

Computer Science and Engineering Department

BACHELOR THESIS

Content Delivery Network Using

Raspberry PI

Scientific Adviser: Author:

Prof. dr. ing. Decebal Popescu Mihai Valeriu Popescu

Bucharest, 2015
Abstract

Due to the fact that more and more people gain their information over the Internet, the IT
Domain is developing a wide range of software for different types of users.
The purpose of this application is to develop a software for content delivery network.
Each user will request access to the server, and upload information in order to be seen on a
display.
This project will be focused on multiple kindergartens, each and every one of them is basically
a user requesting access for different type of content. Through the displays, parents are able
to obtain information about the program of the kindergarten, activities, local and global news,
menu, etc.

i
Contents

Abstract i

1 Description 1
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.1 Kindergarten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.2 School . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.3 Private Companies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Hardware Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.2 Raspberry PI 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.3 Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Software Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.1 Software for Raspberry PI 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.2 Software for Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Related Work 9
2.1 Omnivex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Frontface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3 Visix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4 Advantages of the developed application . . . . . . . . . . . . . . . . . . . . . . . 9

3 Implementation of the project 11

3.1 Implementation for Raspberry PI 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1.1 Operating system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1.2 Front-end implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.3 Back-end implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2 Implementation for Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.1 Front-end implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.2 Back-end implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4 Case Study 21
4.1 Raspberry PI 2 client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1.2 Widget overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1.3 Synchronisation with the server . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2 Server web page overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2.1 Raspberry PI Client Settings . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2.2 Correspondence between educational institution and Raspberry PI client . 28
4.2.3 Raspberry PI clients status . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2.4 Synchronisation with the client . . . . . . . . . . . . . . . . . . . . . . . . 29

5 Testing 30

ii
6 Conclusions and Further Work 31

A Application screenshots 32

iii
List of Figures

1.1 Raspberry PI 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Raspberry PI 2 WiFi Dongle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Application Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.1 Client frontend overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2 Client template redesigned after CSS file . . . . . . . . . . . . . . . . . . . . . . 13
3.3 Client database overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.4 Client database overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.5 Django-dajax overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.6 Server design overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.7 Server database used for synchronization overview . . . . . . . . . . . . . . . . . 19
3.8 Server database used for synchronisation overview . . . . . . . . . . . . . . . . . 19

4.1 Widgets used by a Raspberry PI client . . . . . . . . . . . . . . . . . . . . . . . 21

4.2 The client process of synchronisation . . . . . . . . . . . . . . . . . . . . . . . . 23
4.3 Database tables used for educational institutions . . . . . . . . . . . . . . . . . . 24
4.4 Database tables required for menu . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.5 Database tables required for messages . . . . . . . . . . . . . . . . . . . . . . . . 26
4.6 The correspondence between a widget and a template . . . . . . . . . . . . . . . 26
4.7 Scripts and local settings for Raspberry PI client . . . . . . . . . . . . . . . . . . 27
4.8 Correspondence between educational institution and Raspberry PI client . . . . 28

A.1 Raspberry PI clients status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

A.2 Associated widgets for a planification . . . . . . . . . . . . . . . . . . . . . . . . 33
A.3 JSON list for Raspberry PI client . . . . . . . . . . . . . . . . . . . . . . . . . . 33
A.4 Adding a template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
A.5 Raspberry PI client display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

iv
List of Tables

5.1 Test Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

v
Listings

3.1 Chrome_Init bash file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.2 ID bash file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3 Widget placeholder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4 Widget file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.5 JSON Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1 Widget Photos File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.2 JavaScript function associated with widget . . . . . . . . . . . . . . . . . . . . . . 22
4.3 Widget implementation on server . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.4 Screenshot script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

vi
Chapter 1

Description

The Internet is in continuous expansion, becoming one of the most efficient ways of communi-
cation and information.
In the beginning the Internet was used by a small group of users, but nowadays almost all of
them have access to it.
Because users can access a webpage from different types of devices, is a constant need of
developing new software.
The major advantage of developing a web application represents its portability. The only
condition of using the application is having an Internet access. All users can access the platform
regardless their hardware resources, because all the computation is made on a server.
A constantly problem represents time management. People are working almost all part of the
day, in consequence they have limited time to resolve other issues. By using the Internet,
they have a much faster access to the needed information and also they have the possibility to
perform online transactions, payments, etc. They are now able to avoid distances, by searching
the product they desire, and buy it online, or go straight to vendor.
This project developed a software that is a CMS (Content Management Software) that allows
vendors to upload different type of publicity: images, text, video. The display can output adds
from multiple companies, or just for a single one. Every vendor must require a certain period
of time for his add.
The software has two components. First component is represented by the server, which is
designed to provide the backend functionality for this product. Secondly, the client will be able
to request the resources and display them in a user friendly component.
From a security point of view, the server is used to ensure that every user has the confidentiality
and security of its own and that they provide good policy. The client must first identify itself,
by providing its unique id and will be able to access its resources. The unique ID is randomly
generated by the client itself, which has a specific algorithm based on the serial CPU. The client
is entitled to perform this task.
Each user is able to upload data content which will be pushed to the server and then be shown
on the clients display.
The client is by its own a web server, which is synchronised with the main server at a predefined
timestamp. For the specific purpose of this work, the interval was chosen to be 5 minutes. The
client has a continuous communication with the server, providing screenshots, ping status,
CPU usage, memory usage and anything needed. It is completely customisable since the server
supports any kind of response.

1
1.1 Introduction

1.1.1 Kindergarten

The need for developing this application is based on the fact that in modern families both
parents have jobs, and as much as they would like to spend time with their children they are
limited by their carriers.
The education of their children is still the main concern of their lives, so they would like to be
able to trust the entity responsible with the education of the children. How much they would
always like to be up to date with their children schedule, they can not speak with the teachers
every day, but however using this application they do know everything that is happening. From
this point on, they will be able to stay informed with their childrens activity. They are now
sure that the health being and the diet of the children are carefully supervised by professionals
and may focus on their work.
Each parent has an account linked to their own children, that can be accessed on the main
server. This feature can be accessed from any device, either mobile, tablet or pc from the web
browser.
The advantage of this account is represented by the privacy for your own children, and by the
fact that you are up to date of their schedule and activities. Also the parent can post messages,
requesting or supplying additional information.
They can view pictures of their own children involved in different types of activities. They can
hence known that children are well taken care of, and enjoying themselves while learning a new
skill set. When new images or news are presented, they get informed by receiving notifications.
For the parents with high professional carriers and that are by misfortune not able to follow
their children every step, they will receive at the end of each week a summary of their children
activities.
The parents may asses their satisfaction over the schedule that their children are currently
involved with. In the circumstances that they are not satisfied, they may request to the kinder-
garten management to change the classroom.
Regardless of the subjective factors the parents are able to obtain objective information about
their children, provided by the photos taken every day and by the fix schedule that they are
taking.
Another benefit of this application is the amount of time spent at the kindergarten, because
they do not have to speak to the teachers as you are already informed the basics facts, and that
you can only inquire more specific information.

1.1.2 School

This application has almost the same benefits in schools as in kindergarten for parents and
teachers. Taking into consideration the fact that now the children are a little bit older and can
take more care of themselves, this application can display another kind of information.
This information may consist on daily program, extra activities with the purpose of develop
the children background, competitions, trips, etc.
Both the children and the parents can procure the essential information on a manner that is
accessible and easy to follow. This application is also a benefit for the teachers since the main
information are provided through the software.

2
Being up to date with all the information displayed on the screens the parents can guide their
children through different type of activities provided by the school in order to improve the
childrens skills, their creativity.

1.1.3 Private Companies

Companies have the need of publicity in order to increase their number of customers. This
can be pursued by creating different types of adds that are displayed through TV, newsletters,
papers, banners.
Through this software private companies may display on screens that are disposed in their
building different adds. This adds can consist on new products, advantages for the clients,
promotions and other type of information that the company consider it is important and can
attract new clients or retain the old ones. The entire day this adds can be seen on the screens
for all the people that access that edifice.
People are more responsive to dynamic and visual content, because it is easier to follow the
message illustrated by a picture or a short movie.

1.2 Hardware Environment

1.2.1 Server

The server is designed to run on any type of operating system (Windows, Linux, Mac), due to
the fact that this application is web based, and it requires an Apache server.
This is an advantage because the client can choose the desired server and operating system to
host the application.
The application was developed using Django, a high-end Web Framework over Python, and
one of the main advantages consists in the performances and optimisations brought by this
language. Taking this into consideration it is not required to have a high technology for the
environment on which the server is running. This is also an advantage because the client do
not have to invest a lot of money to provide server hosting.
The hosting environment which was used for this application is a Linux Server, running on
Gentoo distribution.
The main reasons of using a Linux Server are represented by stability, performance, scalability.
The hardware configuration of the hosting server is 3,2 GHz CPU AMD AthlonTM X2 dual
core, 4 GB RAM memory DDR3 running at 1333 MHz and a 500 GB HDD.

1.2.2 Raspberry PI 2

Raspberry PI is PC which is smaller in dimension then a HDD, at a low cost, with performances
of a high technology smartphone which is running an operating system based on Linux.
The hardware configuration of a Raspberry PI 2 is 900 MHz CPU ARM Cortex A7 quad core,
1 GB RAM memory. For data storage Raspberry PI uses a microSD Card with a minimum 4
GB capacity, or a USB Flash Drive also with a minimum 4 GB capacity. As an output device,
Raspberry PI offers a HDMI port which can be used to display data to a monitor or TV. It
provides 4 USB ports, which can be used as input devices (mouse, keyboard and wifi module)
and also a LAN port. Currently it is used a microSD card of 8 GB memory for this project. Also

3
 Figure 1.1: Raspberry PI 2

Figure 1.2: Raspberry PI 2 WiFi Dongle

Raspberry PI 2 offers a micro USB, used for power supply that can provide at least 1.8Amp at
5V is essential.
Constraint to a certain budget offered by the client, Raspberry PI has almost the same perfor-
mances as a notebook, at a more advantage price.
This application has the need to use a Raspberry PI in order to extract data and also to push
certain type of data to the main server. It is used for the client environment along with a TV
that displays the desired information in a manner that can be readable by all users.

1.2.3 Monitor

The monitor is chosen by the client and it has no impact on the application. This implies that
the client can purchase a monitor that comes under a designated budget.
For this application is required at least one monitor for each client. This is used to display the
data received from the Raspberry PI.
Each client may choose their type of monitor as long as it has a HDMI output. Also each client
may dispose more than one monitor with the condition that each and every one of them has a
Raspberry PI designated. The resolution of the monitor has no impact on the data that will
be displayed and it bound by the performances of the monitor.
This application was tested on many monitors with a dimension around 80 cm Full HD (1920*1080).
This characteristics are enough to display the data clearly. Also the dimension is suited because

4
it has a range of cover of around 5 m between the display and the user. The information is not
altered by this distance.

1.3 Software Description

1.3.1 Software for Raspberry PI 2

This application was designed to use low consumption of CPU and RAM memory in order to
maintain a workload that does not impact the overall behaviour of the Raspberry PI 2 system.
Raspbian is used as the operating system, a Linux based on Debian distribution.
The client side of the application was developed using Django, a high-end Python Web Frame-
work, with a quick and easy implementation that has a built in ORM (Object-Relational Map-
ping). It also provides a high level of security, avoiding SQL Injection, CSRF (Cross-Site
Request Forgery) attacks, etc. Django provides a very good scalability, and for upgrading
the application it is not required to change large sequences of code. Beside this programming
language, it was used South, a database migration for Django application.
The client was build to use limited Internet bandwidth, and in consequence for every response
of the server, the client verifies the last update date for the information. Every information
has a field last update date, and if this field has been changed from the local one, then the
synchronisation will continue, otherwise the information will remain the same.
Taking into consideration that Internet connection can be lost, the client application needs a
database from which it will extract the information.
As a database solution, it was chosen SQLite because it is server-less, more lightweight and
faster then MySQL.
For the WSGI (Web Server Gateway Interface) over Python, it is used Gunicorn, a low resource
usage and fast web server comparing to Apache server or Tomcat.
A Linux supervisor is used in order to control the processes that are running in the system. In
the supervisor configuration, there is a sequence responsible for running the Gunicorn server
when the system boots. The main advantage of this supervisor is the existence of a configuration
file with a simple initialisation style on which the supervisor is configured. It has a lot of options
for each process such as a log rotation that is automatic and also the processes that are failed
are easier to restart. The sub processes of the supervisor are started using fork and exec and
they do not daemonize.
The solution of the application also uses the crontab facility provided by the Linux operating
system. It is used to execute tasks at a certain time and day. In crontab configuration file exists
the data synchronisation file running every day at a 5 minutes interval, and a database erasing
file, running every day at midnight.
In order to not overload the database, there is a script that erase the database every day at
midnight and so the application runs faster because it has a smaller database to interrogate.
All Python dependencies required for the current project are installed inside a virtual envi-
ronment, which allows to create multiple environments. One of the important advantage is
represented by the fact that they are isolated by the operating system. If appears for example
a python update, then the software may be altered. This situation is avoided by using a virtual
environment.
Every Raspberry PI has its own unique serial processor, that is retained in a environment
variable. This variable it is used to communicate to the main server. The server does a quick
verification of the provided ID, and if it is the database it will send the requested information.

5
Another used software is OpenVPN. Through it every Raspberry PI is connected to a inter-
nal VPN, obtaining the CA (Certificate Authority) and generating a key based on the serial
processor, which is going to be used for the authentication.
From a security point of view, the Raspberries PI can not pull data out of the server, until a
server administrator registers the boards. The advantage of using a VPN connection is based
on remote control and access. If a problem occurs on a Raspberry PI, an administrator can
connect remote and solve the issue.
When the operating system boots up, the VPN, Gunicorn server and the Chrome browser in
kiosk mode (full-screen mode) are loaded. The Chrome browser opens up displaying a page
running at Gunicorn server IP (Internet Address) designated.
The installation process was optimised by cloning the microSD card which was set up with a
clean environment for the solution. This cloned image is used for each new client in order to
reduce the installation time.

1.3.2 Software for Server

The server side is used for the main web page of the application, on which the users add data.
This data will be transferred to the client represented by the Raspberry PI. For the development
of the server was also used Django. Opposite to the client, which has a database with a limited
dimension, the server needs a large database. For this reason it was necessary MySQL language.
The communication between the client and the server was realised using Django REST (Repre-
sentational State Transfer) Framework through JSON(JavaScript Object Notation) messages.
It was chosen this type of messages because the dimension of the transferred package is smaller
then XML (eXtensible Markup Language) messages and also on the client it is more easy to
decode them.
To modify the tables and migrate them in the database was used South.
The library django-photologue allows to be added watermarks on the images, to resize them
when uploaded, to create thumbnails for them, to apply filters, etc.
From a security point of view, each page that allows to introduce and save data to server is
protected with CSRF, so the POST method can not be simulated from other web sites. The
authentication is made through a django-brutebuster library, which after three wrong tries
will block the user account for five minutes, avoiding the brute force attacks. All the failed
authentication are saved in the database and also the IP from which the authentication was
made, the hour and the user as well. The password of each user is saved in the database using
an SHA1(Secure Hash Algorithm) algorithm. Regarding the fact that on the web page are
many type of roles for a user, each user has restricted access considering his role permissions.
In this manner is avoided STO vulnerability (Security Through Obscurity).
Beside all that was mentioned above, also all the information that is uploaded on the server is
not erased and it has a flag that shows if it is displayed or not. In this way, if a user adds an
information and then it will be erased, this information will not be displayed but it will remain
on the server. This is an important fact because for each action can be created audits for the
eventual inconvenience like uploading false data and erase them without user taking any charge
of this action.
On the server is configured the OpenVPN solution, used for the internal network of the clients.
As it was said above, the advantage of this represents the possibility to connect via SSH(Secure
Shell) at a certain client if any problem occurs. An example of this usage is the blocked interface,
the data that are not synchronised with the server, etc.

6
Like the client, the server has jobs that are configured in crontab. For example, every day it
will run a backup for database to avoid the lost of data in case of an unpredicted accident. Also
the screenshots that are 30 days older will be erase to not overload the server memory - HDD.
On the frond-end side it was used the Bootstrap framework, the main advantage of this language
consists in its responsive side which makes the design of the web pages easy to adapt at the
resolution of the screen from which they are accessed. Along with Bootstrap it was used
HTML (HyperText Markup Language), CSS (Common Style Sheet), JS (JavaScript), AJAX
(Asynchronous JavaScript and XML). Beside all this was also used an inheritance template
from Django to define a main layout that is inherited by each view. This template will be
customised taking into consideration the purpose of the view.

Figure 1.3: Application Environment

In Figure 1.3 is an overview of the application. In the left side of the image it is represented the
environment of the server which will hold the web application. The web application contains
the data for each client that are synchronised with the client and the VPN configuration. In the
right side of the imagine is the client environment. Each client dispose of a Raspberry PI and
a monitor that are connected to the Internet and the VPN network. The clients communicate
with the server offering an id that is obtained from the processor serial. At a default interval
of 5 minutes that is set for this application, the clients synchronise their data with the main
server. This is responsible to add all the new clients and bound them with the data that are
required to be synchronised. During the synchronisation, for each information that is obtained
it will be checked the field last updated date and if this field is different from the local one it will
be changed. This is useful if the same images are transferred every day without downloading
them every moment. A case in which the field last updated date is modified, is for example the
case of the synchronisation the messages that are changed by a user.
On the main sever can be seen the clients that are connected to the VPN and their IPs. Each
client is displayed with a unique number mentioned above. If is requested a connection to a
client it will be accessed the main page from where it can be extract the client ID. After that

7
the ID will be checked in the VPN network in order to find out the IP and connect to it to
resolve the clients eventual problems.

8
Chapter 2

Related Work

In present there are developed similar applications on the market but they are quite expensive.
Some of them are described below:

2.1 Omnivex
Omnivex is a software that gathers data in order to process and deliver it in an organisation.
This information can be displayed on tablets, digital screens etc. The Omnivex solution has
the role to keep people up to date in real-time about different aspects because communication
is one of the most powerful tools nowadays. It is highly important to inform people and attract
them. This application is used by Calgary Stampede, Toronto Blue Jays as an instrument of
advertising and also to improve their business results.

2.2 Frontface
Frontface for Public Displays is a software solution for public displays that allows to load
data easily without having an extra server. It has a built-in content management system that
enables the users to manage different type of information or media content to displays that
are controlled remotely. This application can be used in environments like: education, civil
services, real estate business, enterprises, hotels, etc.

2.3 Visix
Visix software gives the customer the possibility to manage information such as media content,
scheduling, alerts on screens across campuses, organisations and many other environments.
Through it people are informed all the time in a manner that is easily to follow.

2.4 Advantages of the developed application

In the above software solutions only administrators have access to the manage the content and
the users are not able to post their own data. These applications are useful to inform people

9
because the platforms are not complex enough to support many type of users that are allowed
to update or change the media content.
This application has the capacity to eliminate the middleman when new content has arrived for
displays. This benefits the customer by giving him a fast-forward way to modify the content.
Beside saving money it also improves the efficiency in the environment where the informative
panel is situated by cutting down the time needed to modify the internal data.
Another advantage that can be mentioned is the ease of installation and ease of use. Even for
non-technical individuals using the interface (that is presented to them by order of privilege)
can be as easy as reading an email.
Stating this facts the customer can acknowledge using this software over similar products.

10
 Chapter 3

Implementation of the project

3.1 Implementation for Raspberry PI 2

3.1.1 Operating system

The operating system is based on Raspbian OS (Operating System), as was mentioned above in
the hardware description. For installing it on a card, a bootable microSD card containing the
image of the OS is used. After the process of installation is completed, the operating system
starts in CLI (Command Line Interface) mode. During the installation process it is used the
user: pi and the password: raspberry. The Raspbian OS has a graphic interface named LXDE
(LightWeight X11 Desktop Environment), which is lightweight compared with Unity interface,
Gnome or KDE. One of the advantages of this interface is that uses a small amount of resources
leaving the rest of them available for data processing. To automatically power on in graphic
interface the file /etc/inittab was modified by following the file format example:
<id>:<runlevels>:<action>:<process>
The line 1:2345:respawn:/sbin/getty --noclear 38400 tty1 was modified as follows: 1:2345:/
bin/login -f pi tty1 </dev/tty1 >/dev/tty1 2>&1. The -f parameter, according to the
manual page of the login script (man login), provides an authentication based on a specified
username without password. This is possible due to the fact that the script is run by the root
user which has privileged access rights.
As the solution represents a web application it is required a browser in order view and access
the webpage. The Chromium browser was chosen as it allows the application to be used in full
screen mode without toolbar, menu, etc. This mode is known as kiosk. A chrome_init.sh file
was created with execution rights in /home/pi/ folder. Below is the chrome_init.sh file:
1 # !/ bin / bash
2 LOGDIR = " / home / pi "
3 export DISPLAY =:0.0
4 if ps ax | grep " chromium "
5 then
6 echo " All ok "
7 else
8 echo " Starting chromium "
9 chromium -- incognito -- kiosk http :// localhost :8000 &
10 fi
Listing 3.1: Chrome_Init bash file

11
 For each Raspberry PI 2 is offered a unique number by the vendor, that can be seen in the
processor serial number. It was also created a bash file named id.sh which saves this value in
an environment variable. Below is the id.sh file:
1 # !/ bin / bash
2 export ID = cat / proc / cpuinfo | grep " Serial " | cut -d -f 2
Listing 3.2: ID bash file

By default, Raspberry PI does not use a FullHD resolution (1920x1080p). In order to use this
type of resolution it is required the modification of the /boot/config.txt file. The value of hdmi_-
group variable has become 1 instead of 2 as the CEA (Consumer Electronics Association) mode
was selected, and not the DMT (Display Monitor Timings) mode. A new value representing
the 1920x1080 resolution with pixel clock 74 MHz was added: hdmi_mode=20.

3.1.2 Front-end implementation

Figure 3.1: Client frontend overview

The view is implemented as a SPA (Single Page Application) with two templates available
(on.html, off.html), depending on the display status, thereupon.
The on.html template includes the jQuery library and the CSS file, used to stylish the page
elements and to organize them in the page. It consists in several div elements, each of them

12
 representing a widget. For example:
1 < div id = " widget1 " data - placeholder = " widget1 " >
2 < div id = " widget1 - author " > </ div >
3 < div id = " widget1 - news - title " > </ div >
4 < div id = " widget2 - news - content " > </ div >
5 </ div >
Listing 3.3: Widget placeholder

The date-placeholder attribute is used for the main server, which recognises the number of
widgets on the page, and associates them with the corresponding placeholders.
The widgets are loaded using AJAX calls. Each widget belongs to a html file, as shown in the
figure above. In the corresponding html file, the data for each widget is loaded as follows: the
global JavaScript objects for each widget are defined in on.html and the widget file will add the
necessary information in the JavaScript object. For example, a widget file might look like:
1 {% for object in data . content_objects . all %}
2 var local_news = { author : " {{ object . author }} " ,
3 title : " {{ object . title }} " ,
4 content : " {{ object . content }} " };
5 glob al_local _news . push ( local_news ) ;
6 {% endfor %}
Listing 3.4: Widget file

The HTML widget file uses the same syntax as the one provided by the template engine from
Django. This sequence of code iterates through all the widgets (messages in this case), and
creates a new JavaScript object that will be added to the global variable corresponding to each
widget defined in the on.html file.
Upon successful loading of all the widgets available to the customer, several JavaScript functions
are called in order to populate the page with media content. Each widget has a JavaScript
function assigned, which iterates through all the media content and adds it to the div elements.
After these steps, the interval between displaying new information on the screen will be set
using the setInterval function.

Figure 3.2: Client template redesigned after CSS file

The CSS file contains all the information about the styles used in order to display the page. By
using the IDs of the HTML elements, there can be specified the display modes for each widget
(e.g. set the background, etc.). The files corresponding to the templates are downloaded from
the main server, so each client can create its own design. The running period of a display can
be configured by a privileged user (the system administrator) if the customer requires so. This
is done by accessing the main web page in order to make a request to the server, which will
manage the status of the display.

13
3.1.3 Back-end implementation

Model implementation

Django ORM was used for the database implementation.

Figure 3.3: Client database overview

RemoteBasedModel and DownloadableMixin are abstract classes and all the other classes will
inherit these two ones.
Each Raspberry PI 2 client may have his own configuration: template, widgets and time sched-
ule.
The table Template is used to save all the templates received from the main server in a JSON
format.
The configuration has the followings fields: a start date, an end date and a specified template
and it is saved in the table named Planificare. For each configuration there is a certain set of
widgets saved in table InstantaWidget which has the next fields: a FK to Planificare, a FK to
Placeholder, a M2M (Many to Many) to ObiectContinut, template_name, language, timeout.
Placeholder table has information about the the positions of the widgets. At it was said before
the widgets can be placed in page by using attribute from a div. This tabled has the next
fields: a FK to Template and a div_id. Each widget may contain any type of data. To retain
the content it was created the table ObiectContinut with the fields: remote_class_name and
template_name.
The time schedule was saved in the LocalSettings table by using the fields key and value. The
server is responsible to acquire the time and send a flag which indicates the status of the display.
The table LocalClassesRepository contains information about media content that is required
by the widget. This type of information can be found also on the main server.
The UnitateDisplay table holds the unique number of Raspberry Pi 2.

14
 Figure 3.4: Client database overview

PushFiles table holds data about the files that are sent to the server. The UpdateJob table
contains scripts that are received from the server and also when these should be executed.

15
Controller implementation

There is only one controller, which is triggered when the page http://localhost:8000 is triggered.
The steps executed by the controller are:
1. The controller procures the configuration for the client at the time being.
2. If there is no configuration it is redirected to off.html view.
3. The settings for the display status are retained in LocalSettings. It is verified if the flag
video_disabled has the value set at 1, in which case this is locked and redirected to the
view off.html.
4. If all the above steps were executed successfully, the controller is redirected to the view
on.html in which are sent all the widgets.
For AJAX calls that are made in the view, it was used a django-dajax library. This library
enables writing AJAX calls without a lot of JavaScript by using the template tags. Below it is
explained the operation mode of this library:

1
Figure 3.5: Django-dajax overview

It was created the template tag content_helpers which is loading all the available widgets and
extracts all the widgets from the table InstantaWidget and renders them into the page using
the widgets template.
If the widget uses JavaScript as a language, then is needed the JavaScript eval function to
execute the widgets sequence of code. If it is used HTML, then an update to the respective
divs text it will be made.

1 https://django-dajax.readthedocs.org/en/latest/

16
Crontab

For the server communication are called bash scripts from crontab at a predefined time period:
1. Empty.sh it is called every day at midnight. This script is used to clean the database.
In consequence, the database will have a limited dimension and a quicker answer for
interrogations. Also it will be avoided the presence of objects that are no longer required.
2. Sync.sh is a script called every five minutes. It manages the synchronisation with
the server and the new data. A new file named SYNC_RUNNING is created when it is
executed Sync.sh. This file objective is to avoid multiple synchronisations at the same
time and is deleted after this script has come to an end. For each synchronisation the
client sends local data like screenshots. This screenshots are made every five minutes
to show the display status. After this step, the data received from the server will be
parsed and it will be also verified the last date when the objects state was modified.
If the object state is the same then no synchronisation will be made and the usage of
bandwidth will be diminished. The synchronisation will start only if the object does not
exist or it has been suffered changes. The client sends the unique id in order to start the
process of synchronisation and the server will procure all the necessary data. The server
will return a JSON answer and the client will parse each object from it. The object will
be as following:
1 {
2 " id " : objectID ,
3 " last_updated " : date ,
4 " remote_c lass_nam e " : objectType
5 }
Listing 3.5: JSON Object

Class ObiectContinut access for each object the URL (Uniform Resource Locator):
http://server/remote/single/objectType/objectID/?format=jsonhwid=IDUnique.
The widgets can retain any type of information and so objectType represents the type
of data corresponding to the widget: message, image, etc. After this URL is accessed a
new JSON answer is returned, containing the required object, which it will be saved in
the database.
3. Process.sh is a script that runs every two minutes and determines if there are jobs
which should be done like: screenshots, renewal of the VPN certificate, the connectivity
to the internet, reinitialising chromium, etc.
4. Check_internet.sh a script that runs every two minutes and manages the Internet
connectivity and sends to the main server connectivity status.

VPN

Each Raspberry PI 2 is connected to an internal VPN network. The major advantage of this
is represented by connecting to it via SSH from any network. Thus, if problems can be solved
remotely. As a solution it was selected to be used OpenVPN. When installing a new client,
during the first synchronisation with it are sent to it the necessary certificates, in order to
establish a network connection. The client will unzip the archive received and will save the
result in /etc/openvpn/client.crt, respectively /etc/openvpn/client.key. CA certificate
has been copied after installing the operating system.

17
3.2 Implementation for Server

3.2.1 Front-end implementation

Figure 3.6: Server design overview

In order to implement the front-end for the main web server it was used template inheritance
pattern. As shown in the Figure 3.6, there are created the main blocks for the view. The
advantage of using a base template that contains all the common blocks of a web application,
that can be override by the child templates.
All the necessary CSS files, JavaScript files are included in the file base_general.html. In order
to facilitate the implementation process it was used Bootstrap framework. The Bootstrap
framework has all the necessary tools (HTML, CSS, JS) in order to develop a web application
in a more dynamic and responsive way. This means that the application is supported on
different types of devices and is also compatible with all the existing browsers. Beside this,
the framework provides elements for page such as top menu, buttons, alerts already customised
with CSS.
The base_general.html has the following block contents:
1. A top menu that changes depending on users role.
2. A sidebar that adjust dynamically in every page, including actions that can be done on
that page, taking into consideration the user role.
3. Breadcrumb that indicates the current location on the webpage.
4. Content that shows information about the page.
Same view may show different data, depending on the user role.
From a security point a view, every view is restricted to the users role, avoiding STO.
Another security measure is using CSRF tokens. This means, that every view that has a form,
has a hidden input field for the CSRF token, validated by the server.
Each view has a correspondent controller from which it receives data.

18
3.2.2 Back-end implementation

Model implementation

Abstract class SyncModel is used to synchronise all the objects with the client. It is inherited by
the abstract class ContentObject. The last one has the target to obtain the widgets template
name, its date and content. The aim of AsociereTipuriContinut class is to save the widgets
content.

Figure 3.7: Server database used for synchronization overview

Class LocalSettings contains settings for the displays. Through the class UpdateJob are saved
the scipts executed on the client. The connexion between the scripts and the clients is made in
the class AsociereUpdateJobUnitateDisplay.

Figure 3.8: Server database used for synchronisation overview

The information received from the client is saved using the class JobReport. The files that are
send by the client are saved using the class RemoteFile. The status received from the client
regarding the information is made in class RequestMonitoryEntry.

Controller implementation

The Django REST Framework was used for the controller implementation in order to create
the necessary synchronization with the client.
For each model, a class is defined to specify the fields which need to be serialized. A widget
must be created for each used object after they are declared. The role of this widget is to
transmit data to the client in the form of a JSON. The client must then parse the message

19
and save the information obtained from it. Each widget inherits the BaseTargetedWidget class
which is an association between the Raspberry PI client and its media content from the server.
For each client there is an associated vendor. Each widget has a corresponding model which
needs to be serialized and a corresponding query.
Thus, the client sends a request to the server, offering its unique ID. The server checks the ID
if it is a valid one and if it is in the database. If this phase is verified, the server will send a
response as a JSON containing the list of the elements belonging to the client. The client then
has to parse the list and using this, asks the server for more information for each object.
For each object, the client sends a request to a different controller, this returning the serialized
data of the requested object.
REST is an alternative to SOAP and WSDL and it is used frequently by a large number of
developers because of its simplicity. This framework contains architectural principles used for
the web services in order to offer a better management of the system resources. Through the
benefits of REST can be mentioned the followings:
The HTTP methods are used in a more explicitly manner.
Is stateless.
XML, JSON can be transferred.
An exposed directory structure.
The components of a page can be modified if required.
The application is a portable and reliable one.
It can support a considerable amount of interaction between the components so the ap-
plication is scalable.
The exchange of information among the components is visible for the service agents.
By using REST the architecture of the application is a performant one and also can easily be
maintained in time. It is specific to this framework to have HTTPS verbs like POST, GET,
DELETE or PUT that help the web browser to obtain information from the web pages and
send them to the server.

20
Chapter 4

Case Study

The architecture of the application was designed to be implemented for schools and kindergarten
environments. In this chapter is a brief presentation of all the facilities offered by this solution. It
was adopted to implement the solution on an educational environment because of its importance
in guideline each person from the beginning.

4.1 Raspberry PI 2 client

4.1.1 Overview

Figure 4.1: Widgets used by a Raspberry PI client

Fig. represents the skeleton of each display that can be customised by the kindergartens
requires. Currently there are six types of widget as it can be observed above.
Next it will be described the functionality of each widget and also its role:

21
 1. PHOTOS: the images are displayed to inform the parents about the activities of their
children. The widget loads the photos received by the server from the local database, in
order to create a slideshow containing all of them.
2. LOCAL NEWS: these are used to facilitate the communication between the parents
and the institution. These serve as remainders for the parents about all the important
news that take place during every week. Beside this the parents are also able to post their
messages such as lost objects and other things they consider relevant.
3. GLOBAL NEWS: are posted to notify the parents about activities such as generally
educational events.
4. LOGO: its the institution signature.
5. MENU / TIMETABLE: is depending on the type of the learning institution (kinder-
garten or school). By displaying this the parents are able to know the program or the
menu of their children.
6. ACTIVITIES: these constitute the programs in which children may take part such as
trips, competitions, etc.
Each widget changes his media type content at a predefined time stamp.

4.1.2 Widget overview

1 if ( jQuery ( " img [ src = {{ object . get_thu mbnail_ur l }} ] " ) . length ==

0) {
2 var poza = { autor : " {{ object . autorul }} " ,
3 titlu : " {{ object . titlu }} " ,
4 descriere : " {{ object . de sc rie re _n atu ra la }} " ,
5 data : " {{ object . last_updated }} " ,
6 url : " {{ object . download_url }} " ,
7 remote_id : " {{ object . remote_id }} " };
8 poze . push ( poza ) ;
9 }
Listing 4.1: Widget Photos File

In Figure 4.1 is showed the HTML file corresponding to the photos widget. This is written in
JavaScripts in order to use the eval function. The widget file is used to iterate through all the
photos in the database, and add them to the poze global object.
1 function slideImages () {
2 try {
3 document . getElementById ( photo - title ) . innerHTML = poze [
counterImage ]. titlu ;
4 document . getElementById ( photo - tag ) . innerHTML = poze [
counterImage ]. descriere ;
5 document . getElementById ( photo - teacher ) . innerHTML = "
profesor : " + poze [ counterImage ]. teacher ;
6 document . getElementById ( photo ) . style . backgroundImage = " url
( " + poze [ counterImage ]. url + " ) " ;
7 document . getElementById ( photo ) . style . backgroundRepeat = " no
- repeat " ;
8 if ( counterImage < poze . length -1) {
9 counterImage ++;

22
10 } else {
11 counterImage =0;
12 }
13 } catch ( e ) {
14 document . getElementById ( photo ) . style . backgroundImage =
" url ( {{ TEM PL AT E_M ED IA _UR L }} img / slide_start . png ) " ;
15 }}
Listing 4.2: JavaScript function associated with widget

The above sequence of code is the corresponding JavaScript function associated to the widget
and it can be found in on.html file. This function is called every fifteen seconds and creates a
slideshow with all the photos from the database that the widget receives.

4.1.3 Synchronisation with the server

Figure 4.2: The client process of synchronisation

The Figure 4.2 above represents the client perspective about the synchronisation process.
1. First the client makes a request to the main server at a known URL, providing it the
unique id (serial from processor). Based on the unique ID, the server will recognise and
validate the client in order to create a list with the media content available to it.
2. A JSON answer is received and now the client is in charge to parse the JSON. This
answer contains all the data that is corresponding to the client. The client takes every
element from the JSON list and parse it in order to be able to access the data. If the
last_updated field from JSON element does not suffered any changes and object id is the
same as the one in the database, then the steps 3 and 4 are not executed. This represents
an advantage because the bandwidth will be diminished.
3. For each element, the client makes a new request to the main server knowing the object
type and id from the JSON list.
4. A JSON answer regarding the specified widget is returned. The JSON is parsed, and the
object is saved in the local database table named ObiectContinut.

23
 5. Steps 3 and 4 are a loop that will end when all the elements from the JSON list are saved
in the local database.
From a client point of view the synchronisation process is required in order to be able to keep
the data updated. Thus, if there is no Internet connection, the client is still able to provide
data to the display, using the local database.
This process is executed every five minutes and his absence will lead to an interruption in terms
of communication with the main server regarding the media content. This means that new
messages, photos, etc are no longer received.

4.2 Server web page overview

Figure 4.3: Database tables used for educational institutions

In this application the vendor is represented by an educational institution. Each institution has
a number of groups that contain children of a certain age.
Every media content must be associated with grupainvatamant (each educational institution is
formed by many groups) or unitateinvatamant (the educational institution).
The administrators of the web page server can add groups and educational institutions and
have full rights over all the operations of media content.
For each educational institution there can be defined different types of users which can see only
the information allowed to them. Taking this into consideration there are the following type of
users:

24
 1. The institution administrator: this type of user can see all the information from the
institution associated to him.
2. Teacher: this type of user can see only the information about his own groups of children.
3. Parent: this type of user is allowed to see information regarding his children.
4. Photographer: His attribution is to take pictures and add them to the educational unit
he belong to.
5. Children: each child is associated to an educational institutions group.
The media content that is allowed to be added has the next types:
1. Messages: a message is available to a specified unit and it has fields like content, time
stamp.
2. Photos: for each added photo there are tagged the children in it. The photos are visible
to the parents that have children tagged.
3. Calendar events: these can be trips, holidays, national days, shooting photo sessions,
etc.
4. Menu: each unit has its own menu planned for a whole week.
5. Timetable: the schools are responsible to define their own schedule for each week

Figure 4.4: Database tables required for menu

The Figure 4.4represents the contents of each menu. The menu type (tipmasa) differs by taking
into consideration the time at which it will be served for example: breakfast, lunch. A menu
contains multiple meals and these are stored in the database table named masa (table).
There are currently two types of messages: local messages and pop-up messages. As the name
suggest, the pop-up messages are the ones displayed at a specified interval. Of course, there can
be added another types of messages beside these and are stored in the tipmesaj table (message
type table).
The controllers are granted to a user regarding his role so that each type of user has a different
form input to complete. As an example, a parent does not need to specify the unit when posting
a message but an administrator must do this.
The status of the message, meaning if this was displayed or not on the screen, can be verified
by the client during the synchronisation process.

25
 Figure 4.5: Database tables required for messages

4.2.1 Raspberry PI Client Settings

Template

Figure 4.6: The correspondence between a widget and a template

To add a new template it is required to be an administrator user. The template is a zip archive,
containing on.html and all the dependencies files such as CSS, images, etc.
After the archive has successfully been uploaded to the server, the process of parsing it begins.
Data-placeholder attributes are searched in the html file and for each one is associated a defined
widget.

Planification

Each Raspberry PI client needs a configuration in order to be able to display the desired
information. This configuration retains the template archive which will be sent to the client

26
 during the synchronisation process and the associated widgets. To associate widgets is required
to define or use an existing planification. This consists in defining for each placeholder a widget.

Widgets

1 class St iriLocal eWidget ( Ba se Tar ge te dWi dg et ) :

2 model = Mesaj
3
4 def get_queryset ( self , * args , ** kwargs ) :
5 try :
6 tip_mesaj = TipMesaj . objects . get ( nume = u " Stiri
locale " )
7 mesaje = Mesaj . objects . filter ( tip_mesaj = tip_mesaj ,
u n i t a t e _ i n v a t a m a n t _ _ i n = [ self . unitate_invatamant ,
] , moment_end__gte = datetime . datetime . now () )
8 return mesaje
9 except TipMesaj . DoesNotExist :
10 logger . debug ( " Nu am gasit stiri locale " )
11 return []
12 except Exception , e :
13 import traceback
14 logger . debug ( u " A aparut o eroare la obtinerea de
stiri locale % s % s " % (e , traceback . print_exc () ) )
Listing 4.3: Widget implementation on server

The 4.3 shows the database query filter necessary to find the local messages that are available
to an educational institution. To add a widget is used the class WidgetDisplay as shown in the
Figure 4.6. For this class is required to fill the fields: name of widget, description, widget class
from the server (for example StiriLocaleWidget) and the template name.

Figure 4.7: Scripts and local settings for Raspberry PI client

Scripts

UpdateJob class is required for adding a new script on the server. Each script can be sent to
the Raspberry PI client in order to be executed and it is composed by a bash file. For example
a screenshot script is attached below:

27
1 # !/ bin / bash
2
3 PROJECT_ROOT = " / var / X / "
4 FILE_NAME = " static / general / pushfiles / screenshot - " $ ( date +% s ) " . jpg "
5
6 export DISPLAY =:0.0
7 scrot -q 30 $ P R O J E C T _ R O O T $ F I L E _ N A M E
8
9 / usr / bin / python / var / X / src / X / administrative / scripts / push_file . py
$ P R O J E C T _ R O O T $ F I L E _ N A M E " screenshot "
Listing 4.4: Screenshot script

Local settings

Local settings are added by filling the fields key and value as shown in Figure 4.7. Each local
setting is correspondent to a Raspberry PI client. This can be used to determine either if the
display should be turned on or off, interval for different JavaScripts functions, etc.

4.2.2 Correspondence between educational institution and Raspberry

PI client

Figure 4.8: Correspondence between educational institution and Raspberry PI client

28
Each educational institution may have one or more Raspberry PI clients. It is required the
unique ID of the client to associate it with an educational institution. All media content
associated with a school is now also associated with a Raspberry PI client.
For

4.2.3 Raspberry PI clients status

An administrator user is able to see all the Raspberry PI clients. A controller is used to display
information about each client such as: last internet connection, last screenshot, VPN IP. Also
from here the user can assign different planification to each client, send them scripts to execute,
monitor their activity.

4.2.4 Synchronisation with the client

A main controller is defined to obtain all the necessary data for a Raspberry PI client. It
is required the client unique ID in order to filter the information that belongs to it. After
planification is obtained for the client, there is created a JSON list with all the objects that
will be synchronised.
For every different type of media content retained in JSON list exists a dedicated controller.
This will outputs the data afferent to the specified object.

29
Chapter 5

Testing

The server for the web application was tested on a Linux environment with the following
specifications:
1. 3,2 GHz CPU AMD AthlonTM X2 dual core
2. 4 GB RAM memory
3. 500 GB HDD
All the monitors displaying the client application support a resolution of 1920x1080p.
This application has suffered a process of test scenarios. This was needed to be aware of the
potential bugs, unsynchronised media content or even bad media information.
Below there are attached a few of the test cases that were made. This tests are required to
improve the quality and security of the software.

Table 5.1: Test Cases

Test FAILED / PASSED

Adding media content PASSED
Removing media content PASSED
Different planifications for clients PASSED
Client status PASSED
Monitor time schedule for the client PASSED
Correct content between server and the client PASSED
Client schedule jobs PASSED
User role limitations PASSED
Offline functionality of the client PASSED
VPN client connection PASSED

All the executed tests have the role to show the specified functionality of the application.

30
Chapter 6

Conclusions and Further Work

This application comes in help to fulfill the need of publicity for companies or in educational
environments to gather and organise the media content. Through this software users are up to
date with all kind of information and also they have the opportunity to make their own posts.
Even if you are not there, you are still able to follow the display status through the screenshots
that are sent every five minutes.
Even if the client does not wish to have the information displayed on a screen, he can still use the
software in order to manage the media content. This is useful because having the information
in an electronic format is more reliable and easy to access it.
To improve the security of the application each type of user is restricted to actions taking
into consideration his role. Also every user password it is saved using a cryptographic SHA1
algorithm. SQL Injection is avoided using Django ORM. Having all this, the user can work in
a secure environment, which is very important nowadays.
In conclusion this web application is a trustful one and has the advantage of being used in
different environments depending on the customer needs with or without an Internet connection
In the future the application has the possibility to suffer different improvements. For example:
1. native mobile apps - there is taken into consideration the requirement of developing
mobile apps for this application for each platform: Windows, Android, iOS. This is helpful
because the users often access the web page from their mobile as they are not in front of
a computer.
2. real time update - for now it takes a five minutes delay between the main server and the
client to synchronise. The aim is to bring the synchronisation in real time using triggers
for each new media content.
3. real time status - currently in order to see the status of a display there are provided
screenshots that are taken by the client every five minutes. The target is to bring this
interval to a minimum possible one or to have a real time response for the client.
4. interface user friendly - even though the design is modern and easy to use, there is still
a considerable amount of users that does not have an information technology background
and they confront with problems when using the current interface.
5. animated content - in this moment all the media content is dynamic but not animated.
By adding animated content the page will be more attractive for the users and also more
appealing.

31
Appendix A

Application screenshots

Figure A.1: Raspberry PI clients status

32
Figure A.2: Associated widgets for a planification

Figure A.3: JSON list for Raspberry PI client

33
 Figure A.4: Adding a template

Figure A.5: Raspberry PI client display

34
Bibliography

[1] Douglas Crockford. Javascript: The good parts. 2011.

[2] Julia Elman and Mark Lavin. Lightweight django. 2014.
[3] Jonathan Hayward. Django javascript integration: Ajax and jquery. 2011.
[4] Adrian Holovaty and Jacob Kaplan-Moss. The definitive guide to django: Web development
done right. 2009.
[5] Wesley Chun Jeff Forcier, Paul Bissex. Python web development with django. 2009.
[6] Clifford Johnson. Raspberry pi 2: Basic user guide for projects, operating system, and
programming. 2015.
[7] Arun Ravindran. Django design patterns and best practices. 2015.
[8] Leonard Richardson and Mike Amundsen. Restful web apis. 2015.
[9] Eben Upton and Gareth Halfacree. Raspberry pi user guide. 2014.

35