Realno-časovna komunikacija mobilnih aplikacij s senzorji · Arduino, Android Wear UDK: 621.397.7-026.364:681.586.6(043.2) Abstract In this diploma paper technologies and protocols

Smetanova ulica 17

2000 Maribor, Slovenija

Tomaž Orter

REALNO-ČASOVNA KOMUNIKACIJA MOBILNIH APLIKACIJ S SENZORJI

Diplomsko delo

Maribor, avgust 2016

I

REALNO-ČASOVNA KOMUNIKACIJA MOBILNIH

APLIKACIJ S SENZORJI

Diplomsko delo

Študent: Tomaž Orter

Študijski program: Univerzitetni študijski program

Računalništvo in informatika

Smer: Informatika

Mentor: doc. dr. Boštjan Šumak, univ. dipl. inž. rač. in inf.

Lektorica: Melita Račev, prof. slovenskega jezika

i

ii

Realno-časovna komunikacija mobilnih aplikacij s

senzorji

Ključne besede: Realno-časovna komunikacija, senzorji, internet stvari, nadzor

ogrevanja, mobilna aplikacija, MQTT, HTTP, CoAP, AMQP, XMPP, DDS, WiFi, Raspberry

Pi, Arduino, Android Wear

UDK: 621.397.7-026.364:681.586.6(043.2)

Povzetek

V diplomskem delu predstavimo tehnologije in protokole, ki omogočajo realno-časovno

komunikacijo med mobilnimi aplikacijami in senzorji. Z uporabo protokola MQTT na

praktičnem primeru nadzora ogrevanja stanovanja predstavimo njihovo uporabnost in

lastnosti.

Začnemo z izdelavo senzorja temperature, ki podatke zaznava in sporoča, ter centralnega

strežnika, ki jih obdela, se na njih odzove in jih posreduje do končnega odjemalca.

Nadaljujemo z izdelavo mobilne aplikacije, ki v tem primeru predstavlja končnega

odjemalca. Aplikacija podatke v realnem času prikazuje in uporabniku omogoča nadzor

nad ogrevanjem. Mobilno aplikacijo dopolnimo z izdelavo aplikacije za pametno uro. Ta s

pomočjo obvestil in lokacijskih podatkov uporabnika opozori na vklop ali izklop varčnega

načina ogrevanja. V zaključku dela preverimo, ali smo z uporabo namenske tehnologije

uspeli prihraniti na količini prenesenih podatkov in pohitriti njihovo prejemanje.

iii

Real-time communication between mobile

applications and sensors

Key words: Real-time communication, sensors, internet of things, heating control system,

mobile application, MQTT, HTTP, CoAP, AMQP, XMPP, DDS, WiFi, Raspberry Pi,

Arduino, Android Wear

UDK: 621.397.7-026.364:681.586.6(043.2)

Abstract

In this diploma paper technologies and protocols that enable real-time communication

between mobile applications and sensors are presented. On the basis of the heating

control system, the usefulness and features of the protocol MQTT are described.

We start with the production of temperature sensor and central server. The temperature

sensor detects and reports data and the central server processes, responds, and forwards

data to the final client. Then, the creation of mobile application follows which in this case is

represented as the final client. The application shows the data in real time and it allows

the user to control the heating. The mobile application is updated by the smart watch. The

smart watch alerts the customer via notifications and local data to enable or disable the

energy-efficient heating. In the conclusion we check whether we have saved on the

amount of transferred data and if the data receivement is speeded up.

iv

KAZALO

1 UVOD .............................................................................................................. 1

2 IZDELAVA SENZORJA ZA TEMPERATURO ................................................ 3

2.1 Platforme za izdelavo senzorjev ......................................................................................... 3

2.1.1 Pregled platform ................................................................................................................. 3

2.1.2 Predstavitev izbrane platforme ........................................................................................... 6

2.2 Brezžična komunikacija ....................................................................................................... 8

2.2.1 Pregled tehnologij ............................................................................................................... 8

2.2.2 Predstavitev izbrane tehnologije ........................................................................................ 9

2.3 Izdelava senzorja ................................................................................................................ 13

2.3.1 Uporabljene komponente ................................................................................................. 13

2.3.2 Delovno okolje .................................................................................................................. 13

2.3.3 Programiranje senzorja .................................................................................................... 16

3 KOMUNIKACIJA MOBILNIH APLIKACIJ S SENZORJI .............................. 19

3.1 Opis tehnologij in protokolov za realno-časovno komunikacijo ................................... 19

3.1.1 Predstavitev protokolov .................................................................................................... 20

3.1.2 Predstavitev izbranega protokola MQTT .......................................................................... 24

3.1.2.1 Komunikacija ............................................................................................................ 25

3.1.2.2 Teme......................................................................................................................... 31

3.1.2.3 Zagotavljanje kakovosti storitve (QoS) ..................................................................... 32

3.1.2.4 Zagotavljanje varnosti............................................................................................... 35

3.2 Izdelava centralnega strežnika .......................................................................................... 41

3.2.1 Predstavitev platforme in uporabljenih tehnologij ............................................................. 41

3.2.2 Postavitev strežnika.......................................................................................................... 42

3.2.3 Opis rešitve ....................................................................................................................... 47

3.3 Izdelava mobilne aplikacije ............................................................................................... 61

3.3.1 Predstavitev operacijskega sistema ................................................................................. 61

3.3.2 Razvojno okolje ................................................................................................................ 61

3.3.3 Razvoj grafičnega vmesnika ............................................................................................ 64

3.3.4 Implementacija komunikacije s centralnim strežnikom .................................................... 66

v

3.4 Primerjalna analiza implementacije rešitve s pomočjo izbranih tehnologij v primerjavi

s HTTP ............................................................................................................................................. 74

4 IZDELAVA APLIKACIJE ZA PAMETNO URO ............................................. 79

4.1 Predstavitev Android Wear platforme .............................................................................. 79

4.2 Predstavitev rešitve in opis implementacije .................................................................... 81

5 ZAKLJUČEK ................................................................................................. 84

5.1 Testiranje hipotez ............................................................................................................... 84

5.2 Omejitve diplomskega dela ............................................................................................... 84

5.3 Možne razširitve končne rešitve ....................................................................................... 85

5.4 Sklep .................................................................................................................................... 85

6 VIRI ................................................................................................................ 86

vi

KAZALO SLIK

SLIKA 1.1: NAPOVEDANA RAST NAPRAV POVEZANIH V INTERNET [55] ....................................................... 1

SLIKA 1.2: KOMPONENTE KONČNE REŠITVE ............................................................................................ 2

SLIKA 2.1: BEAGLEBONE BLACK [23] ..................................................................................................... 3

SLIKA 2.2: PARTICLE PHOTON [22] ........................................................................................................ 4

SLIKA 2.3: PLATFORMA C.H.I.P [22] ...................................................................................................... 4

SLIKA 2.4: PLATFORMA INTEL EDISON [22] ............................................................................................. 5

SLIKA 2.5: NAPRAVA ARDUINO UNO [22] ................................................................................................ 5

SLIKA 2.6: PLATFORMA RASPBERRY PI 3 [22] ........................................................................................ 6

SLIKA 2.7: NAPRAVA ARDUINO YUN [31] ................................................................................................ 7

SLIKA 2.8: PRIMER OMREŽJA WIFI ....................................................................................................... 10

SLIKA 2.10: SHEMA VEZAVE KOMPONENT ZA IZDELAVO SENZORJA TEMPERATURE [53] ........................... 13

SLIKA 2.11: ARDUINO RAZVOJNO OKOLJE ............................................................................................. 14

SLIKA 2.12: REZULTAT PREVAJANJA IN PRENOSA PROGRAMA NA MIKROKONTROLER ............................... 18

SLIKA 3.1: SHEMA NAJPRIMERNEJŠE UPORABE POSAMEZNEGA PROTOKOLA Z ODZIVNOSTJO [18] ............ 19

SLIKA 3.2: PRIKAZ SHEME XMPP ZA NASLAVLJANJE [18] ...................................................................... 20

SLIKA 3.3: PRIKAZ SUBJEKTOV DOMENE DDS [20] ............................................................................... 21

SLIKA 3.4: POTEK KOMUNIKACIJE MED ODJEMALCI AMQP .................................................................... 22

SLIKA 3.5: PRIKAZ TOKA SPOROČIL ZA POTRDITVENI (LEVO) IN NEPOTRDITVENI (DESNO) ZAHTEVEK......... 22

SLIKA 3.6: PRIMER VZORCA OBJAVI/NAROČI ......................................................................................... 25

SLIKA 3.7: VZPOSTAVITEV KOMUNIKACIJE MED ODJEMALCEM IN POSREDNIKOM ...................................... 26

SLIKA 3.8: PRIMER CONNECT IN CONNACK PAKETA ........................................................................ 27

SLIKA 3.9: TOK PUBLISH PAKETA ...................................................................................................... 28

SLIKA 3.10: PRIMER PUBLISH IN OPCIJSKEGA PUBACK PAKETA ........................................................ 29

SLIKA 3.11: PRIMER SUBSCRIBE IN SUBACK PAKETA ...................................................................... 29

SLIKA 3.12: ZAPOREDJE IZMENJAVE PAKETOV OB PRIJAVI NA TEMO ....................................................... 30

SLIKA 3.13: PRIMERK PAKETOV UNSUBSCRIBE IN UNSUBACK ....................................................... 30

SLIKA 3.14: ZAPOREDJE IZMENJAVE PAKETOV OB PRIJAVI NA TEMO ....................................................... 30

SLIKA 3.15: STRUKTURA IMENA TEME IN PRIMERI IMEN TEM [7] .............................................................. 31

SLIKA 3.16: PRIMER UPORABE ENONIVOJSKE SUBSTITUCIJE IMENA TEME [7] .......................................... 31

SLIKA 3.17: PRIMER UPORABE VEČNIVOJSKE SUBSTITUCIJE IMENA TEME [7] .......................................... 32

SLIKA 3.18: MQTT QOS NIVO 0 .......................................................................................................... 33



SLIKA 3.21: ŠIFRIRANJE POVEZAVE MED POŠILJATELJEM IN PREJEMNIKOM ............................................. 36

SLIKA 3.22: ŠIFRIRANJE POVEZAVE MED POŠILJATELJEM IN POSREDNIKOM ............................................ 37

SLIKA 3.23: TOK KOMUNIKACIJE MQTT PRI AVTORIZACIJI OAUTH 2.0 ................................................... 39

vii

SLIKA 3.24: POVEČANA PROCESORSKA ZMOGLJIVOSTI POSAMEZNE GENERACIJE RASPBERRY PI [39] ..... 41

SLIKA 3.25: ORODJE ZA OSNOVNO KOFIGURACIJO RASPBERRY PI ......................................................... 44

SLIKA 3.26: KONFIGURACIJSKA SHEMA CENTRALNEGA STREŽNIKA IN SENZORJEV ................................... 47

SLIKA 3.27: ER MODEL PODATKOVNE BAZE .......................................................................................... 51

SLIKA 3.28: ZASLONSKA SLIKA PRIJAVNEGA OKNA ................................................................................ 55

SLIKA 3.29: ZASLONSKA SLIKA PRIVZETE STRANI NADZORNE PLOŠČE Z OZNAČENIMI ELEMENTI ................ 56

SLIKA 3.30: ZASLONSKA SLIKA SEZNAMA ODJEMALCEV ......................................................................... 57

SLIKA 3.31: ZASLONSKA SLIKA SPREMINJANJA NASTAVITEV ................................................................... 57

SLIKA 3.32: ZASLONSKA SLIKA PRIKAZA STATISTIKE .............................................................................. 58

SLIKA 3.33: GRAFIČNI VMESNIK RAZVOJNEGA OKOLJA ANDROID STUDIO ............................................... 63

SLIKA 3.34: ZASLONSKA SLIKA MOBILNE APLIKACIJE, LEVO BREZ IZBRANEGA PROSTORA IN DESNO Z

IZBRANIM PROSTOROM ................................................................................................................ 64

SLIKA 3.35: ZASLONSKA SLIKA DIALOGA ZA SPREMEMBO NASTAVLJENE TEMPERATURE LEVO IN DIALOGA ZA

VKLOP/IZKLOP OGREVANJA DESNO ............................................................................................... 65

SLIKA 3.36: ZASLONSKA SLIKA ZAJEMA PODATKOV S POMOČJO PROGRAMA WIRESHARK ........................ 75

SLIKA 3.37: VELIKOST POSLANIH PODATKOV GLEDE NA ŠTEVILO POSLANIH SPOROČIL ............................ 76

SLIKA 3.38: TRAJANJE POŠILJANJA SPOROČIL GLEDE NA ŠTEVILO POSLANIH SPOROČIL .......................... 77

SLIKA 4.1: PAMETNA URA MOTO 360 PODJETJA MOTOROLA [50] .......................................................... 79

SLIKA 4.2: PODOBA URE S POGLEDOM KARTICE Z VRHA TOKA [49] ......................................................... 80

SLIKA 4.3: ZAČETNI ZASLON APLIKACIJE (LEVO) IN KARTICA PROSTORA (DESNO) .................................... 81

SLIKA 4.4: ZASLON ZA SPREMEMBNO VREDNOSTI TEMPERATURE (LEVO) IN VKLOPA/IZKLOPA OGREVANJA

(DESNO) ..................................................................................................................................... 82

SLIKA 4.5: OBVESTILO OB ODHODU OD DOMA (LEVO) IN VRAČANJU DOMOV (DESNO) ............................... 83

viii

KAZALO TABEL

TABELA 2.1: PREGLED BREZŽIČNIH TEHNOLOGIJ PO KLJUČNIH LASTNOSTIH [34] ....................................... 9

TABELA 3.1: PREDNOSTI IN LASTNOSTI POSAMEZNIH MEHANIZMOV ZA PODPISOVANJE SPOROČILA [16] .... 38

TABELA 3.2: NAJPOMEMBNEJŠE KARAKTERISTIKE POSAMEZNE GENERACIJE RASPBERRY PI ................... 42

TABELA 3.3: OPIS METOD PROGRAMSKEGA VMESNIKA .......................................................................... 58

TABELA 3.4: SEZNAM MQTT TEM ........................................................................................................ 60

TABELA 3.5: KONFIGURACIJA RAČUNALNIKOV ZA ANALIZO ..................................................................... 74

ix

SEZNAM UPORABLJENIH KRATIC

ADT Android Developer Tools

AES Advanced Encryption Standard

AMQP Advanced Message Queuing Protocol

BOSH Bidirectional streams over Synchronous HTTP

CoAP Constrained Application Protocol

CRL Certificate revocation list

D2D Device-to-device

D2S Device-to-server

DDS Data Distribution Service

GCM Google Cloud Messaging

GMS Google Mobile Services

GSM Global System for Mobile Communications

HDMI High-Definition Multimedia Interface

HTTP Hypertext Transfer Protocol

I2C Inter-Integrated Circuit

IP Internet Protocol

JDK Java Development Kit

JSON JavaScript Object Notation

MAC Media access control

MIT Massachusetts Institute of Technology

MQTT Message Queuing Telemetry Transport

OCSP Online Certificate Status Protocol

PWM Pulse-width modulation

QoS Quality of service

RF Radio frequency

S2S Server-to-server

SBC Single Board Computers

SD Secure Digital

SDK Software development kit

SIM Subscriber identity module

SOC System on Chip

SSH Secure Shell

x

TCP Transmission Control Protocol

TKIP Temporal Key Integrity Protocol

TLS Transport Layer Security

UART Universal asynchronous receiver/transmitter

UDP User Datagram Protocol

URL Uniform Resource Locator

USB Universal Serial Bus

UTF Unicode Transformation Format

UUID Universally unique identifier

VPN Virtual private network

WEP Wired Equivalent Privacy

WiFi Wireless Fidelity

WLAN Wireless local area network

WPA Wi-Fi Protected Access

WPAN Wireless personal area network

XML Extensible Markup Language

XMPP Extensible Messaging and Presence Protocol

Realno-časovna komunikacija mobilnih aplikacij s senzorji

1

1 UVOD

Živimo v svetu, kjer smo v vsakem trenutku življenja obdani s številnimi elektronskimi

napravami, ki so povezane v internet. Te postajajo vedno pametnejše in s pomočjo

različnih senzorjev nudijo številne informacije, s pomočjo katerih želijo izboljšati ter olajšati

življenje. Da te informacije na hiter ter učinkovit način dosežejo uporabnika, se vse

pogosteje kot končni odjemalci uporabljajo pametni telefoni in tablice, saj ti postajajo

vedno zmogljivejši, so ves čas povezani v omrežje in uporabniku konstantno na voljo.

Raziskava družbe Gartner napoveduje, da se bo število povezanih naprav do leta 2020

povzpelo na 26 milijard, kar je skoraj 30-kratno povečanje v primerjavi z letom 2009, ko je

ta številka znašala 0.9 milijard. Napovedane številke presegajo celo napovedi za pametne

telefone, tablice in računalnike, ki naj bi se do takrat povzpele do 7.3 milijarde naprav [54].

Slika 1.1: Napovedana rast naprav povezanih v internet [55]

Z večanjem števila teh naprav se veča tudi količina podatkov, ki se pretakajo po omrežju.

Ključnega pomena postaja, da so ti podatki dostavljeni pravočasno, učinkovito in na način,

ki omogoča preprost pregled in nadzor nad njimi.

Zaradi zgoraj naštetih ugotovitev pridobivajo na pomembnosti tudi tehnologije in protokoli,

ki to medsebojno komunikacijo omogočajo. V diplomskem delu jih bomo na kratko

predstavili in na praktičnem primeru nadzora ogrevanja stanovanja pokazali njihovo


2

uporabnost. Pri tem se bomo posebej posvetili realno-časovnemu vidiku takšne

komunikacije, saj ta po našem mnenju vse bolj pridobiva na relevantnosti. To dokazujejo

tudi številna vlaganja v podjetja, ki se ukvarjajo s to tematiko (Realtime.com 100 milijonov

USD, Firebase 7 milijonov USD, Meteor 11 milijonov USD, PubNub 15.5 milijonov USD,

Pusher 1 milijon USD) [51]. Na tem mestu moramo poudariti, da v kontekstu spleta z

realnim časom mislimo na mehki realni čas. Pomembno je, da je čas, med katerim se je

ustvaril podatek ali nastopil dogodek, dovolj majhen, da le-ta ne izgubi na relevantnosti.

Odzivni časi, ki jih pri takšni komunikaciji lahko dosežemo so pod 300 ms, po nekaterih

meritvah strokovnjakov pa v povprečju tudi pod 100 ms [56].

Diplomsko delo se začne z izdelavo senzorja temperature, ki podatke zaznava ter

sporoča, in centralnega strežnika, ki jih obdela, se na njih odzove ter jih posreduje do

končnega odjemalca. Nadaljuje se z izdelavo mobilne aplikacije, ki v našem primeru

predstavlja končnega odjemalca. Aplikacija podatke v realnem času prikazuje in omogoča

nadzor nad ogrevanjem. V zadnjem delu se posvetimo izdelavi aplikacije za pametno uro,

ki s pomočjo obvestil, ki se zavedajo svoje okolice, dodatno obogati uporabniško izkušnjo.

To zagotovimo z uporabo lokacijskih podatkov in zaznavanja domačega omrežja, kar

omogoča prikaz obvestila v trenutku, ko uporabnik odhaja ali se vrača domov. V primeru

odhoda ga z obvestilom opozorimo, da lahko z vklopom varčnega načina ogrevanja

prihrani na energiji. V primeru vklopljenega varčnega načina ogrevanja pa mu ob prihodu

domov s pomočjo obvestila ponudimo možnost preprostega izklopa. V zaključku naloge

bomo preverili, ali smo z uporabo namenske tehnologije uspeli prihraniti na količini

prenesenih podatkov in pohitriti njihovo prejemanje. Za večjo preglednost smo na sliki 1.2

predstavili komponente končne rešitve in njihovo medsebojno odvisnost.

Slika 1.2: Komponente končne rešitve


3

2 IZDELAVA SENZORJA ZA TEMPERATURO

2.1 Platforme za izdelavo senzorjev

2.1.1 Pregled platform

Prvi korak pri izdelavi končne rešitve je izdelava prototipa senzorja za temperaturo, ki bo

podatke brezžično pošiljal do centralnega strežnika. Zaradi raznolikosti področja, kjer se

te naprave lahko uporabljajo, obstajajo številne razvijalske platforme za izdelavo

prototipov, ki se med seboj razlikujejo po zmogljivosti, ceni, funkcionalnosti in namenu

uporabe. Izbiramo lahko med napravami, temelječimi na mikro kontrolerju, sistemih na

čipu (SOC - System on Chip), enokartičnimi računalniki (SBC - Single Board Computers)

in namenskimi sistemi [22]. Poleg uveljavljenih sistemov, ki že dlje časa obstajajo na trgu,

venomer na trg prihajajo nove rešitve, ki izboljšujejo konkurenco in ponujajo razvijalcu

večjo izbiro. V nadaljevanju bomo predstavili ožji izbor naprav, ki najbolje izpolnjujejo

zahteve za našo rešitev, in izbrano tudi podrobneje opisali.

Beaglebone Black je zelo znana nizkocenovna platforma za prototipiranje. Snovana je

okoli procesorja ARM Cortex A8 s taktom 1GHz, s 512 MB pomnilnika in 4 GB spomina

(slika 2.1). Ima že vgrajen mrežni in priključek HDMI (High-Definition Multimedia

Interface), dodatna povezljivost pa se lahko razširi s pomočjo vmesnika USB (Universal

Serial Bus). Je združljiva z različnimi, na Linuxu temelječimi operacijskimi sistemi (Debian,

Ubuntu, Android …). Ima zelo množično in aktivno skupnost, kar naredi platformo posebej

primerno za začetnike [23].

Slika 2.1: Beaglebone Black [23]

Particle Photon je ena manjših naprav za prototipiranje na trgu. Poganja jo procesor

STM32F205 120Mhz ARM Cortex M3, s 128 KB pomnilnika in 1 MB prostora. Za


4

povezljivost skrbi Broadcom BCM43362 WiFi modul. Zaradi majhnosti in nizke porabe je

idealna za uporabo v senzorjih, povezanih na internet [22]. Prikazuje jo slika 2.2.

Slika 2.2: Particle Photon [22]

C.H.I.P je zelo nova platforma, ki prepriča predvsem z nizko ceno (slika 2.3). Za

povezljivost že ima vgrajen Bluetooth 4.0 in WiFi B/G/N modul. Ima procesor Allwinner R8

1 GHz, 512 MB pomnilnika in 4 GB spomina za namestitev operacijskega sistema in za

shranjevanje podatkov, kar pomeni, da za delovanje ne potrebuje dodatne kartice SD

(Secure Digital). Ima 8 splošno namenskih vhodno/izhodnih zatičev, na katere je mogoče

povezati raznolike senzorje. Podpira PWM (Pulse-width modulation), UART (Universal

asynchronous receiver/transmitter) in I2C (Inter-Integrated Circuit) za opravljanje z

različnimi motorji in aktuatorji. Za operacijski sistem uporablja posebno distribucijo Debian

Linux in preko dodatkov omogoča razširljivost [22].

Slika 2.3: Platforma C.H.I.P [22]


5

Intel Edison je razvojna platforma v informacijski tehnologiji zelo znanega podjetja Intel.

Spada med zmogljivejše, saj jo poganja procesor Intel Atom in 32 bitni mikrokontroler Intel

Quark. Poleg tega ima 1 GB DDR pomnilnika in 4 GB prostora, ki je s pomočjo kartice SD

dodatno razširljiv. Povezljivost preko Bluetooth 4.0 in WiFi je že vgrajena v napravo, kar

izniči potrebo po dodatnih zunanjih modulih [22]. Naprava je upodobljena na sliki 2.4.

Slika 2.4: Platforma Intel Edison [22]

Platforma Arduino, prikazana na sliki 2.5, je ena starejših, vendar še vedno najpogostejša

izbira tako začetnikov kakor tudi izkušenih razvijalcev. Je ena prvih razvojnih platform,

temelječih na mikrokontrolerju. Na voljo imamo različne verzije, ki se razlikujejo po

funkcionalnosti in povezljivosti. Za nas zanimiva je predvsem verzija Yun, ki ima že

vgrajeno mrežno in WiFi povezavo. Arduino ima največjo skupnost, ki nudi veliko

podpore, naprave so razširljive z različnimi senzorji in aktuatorji. Zaradi omenjenih

lastnosti smo platformo izbrali za izdelavo senzorja, zato bo naprava v naslednjem

poglavju opisana podrobneje.

Slika 2.5: Naprava Arduino Uno [22]

Raspberry Pi s slike 2.6 spada med najbolj popularne platforme. Trenutno je aktualna

tretja verzija naprave, ki ima kot prva že vgrajen modul WiFi 801.11n in Bluetooth 4.1, kar

napravo uvršča med najbolj kompaktne računalniške sisteme. Napravo poganja štiri jedrni


6

procesor ARM Cortex-A53 s taktom 1.2 GHz in 1 GB pomnilnik. Dodatno naprava ponuja

omrežni, HDMI in USB priključek. Sistem je kompatibilen z različnimi distribucijami Linux

operacijskega sistema, najpogosteje na njem teče prilagojena distribucija Debian Linux,

imenovana Respbian. Pogosto se s strani manj tehničnih uporabnikov uporablja kot

multimedijski center. Zmogljivost, nizka poraba, neslišno delovanje ter združljivost so

glavni razlogi, zakaj smo omenjeni sistem izbrali za centralni strežnik naše rešitve in ga

bomo v podpoglavju 2.2 tudi podrobneje predstavili [22].

Slika 2.6: Platforma Raspberry Pi 3 [22]

2.1.2 Predstavitev izbrane platforme

Arduino je odprtokodna platforma, sestavljena iz programske opreme in elektronskih

komponent, ki so preproste za uporabo. Platformo je razvil inštitut Ivrea Interaction Design

Institute za študente, ki so se spoznavali z elektroniko in programiranjem, kot preprosto

orodje za prototipiranje. Namenjena je za uporabo tako začetnikov kakor tudi izkušenih

inženirjev.

Naprave se lahko na eni strani preko vhodnih vtičev povežejo z različnimi senzorji, kot so

senzorji temperature, vlage, vode, dima ali plinov in na drugi strani preko izhodnih vtičev

nadzorujejo aktuatorje, kot so svetila, motorji ali stikala. S pomočjo Arduino programskega

jezika in razvojnega okolja se lahko na preprost način prenesejo inštrukcije na

mikrokontroler, s čimer definiramo obnašanje naprave. Srce vsake naprave je 8-, 16- ali

32- bitni Atmel AVR mikrokontroler, najpogosteje je to ATmega8, ATmega168,

ATmega328, ATmega1280 in ATmega2560. Naprave obstajajo v različnih verzijah, ki se

med samo razlikujejo po zmogljivosti in funkcionalnosti. Med osnovne spadajo Arduino

Uno, Micro in Pro Mini. Zmogljivejše med njimi se imenujejo Mega, Zero in Yun. Poleg

uradnih verzij obstajajo tudi kompatibilne, ki jih izdelujejo tretji proizvajalci. Za vse

obstajajo različni dodatki, ki na preprost način omogočajo dodatne funkcionalnosti (Energy

Shield, Relay Shield, Music Shield, MicroSD Shield, BLE Shield, Joystick Shield, ipd) [31].


7

Projekti, ki platformo uporabljajo, segajo od preprostih senzorjev vse do kompleksnih

znanstvenih inštrumentov, ki jih razvija velika skupnost, sestavljena iz študentov,

raziskovalcev, razvijalcev, programerjev in hobiistov iz celega sveta. Ta skupnost je

ustvarila veliko bazo znanja, ki je preprosto dostopna začetnikom, zaradi česar

popularnost platforme hitro narašča. Dodatno k naraščanju popularnosti platforme

pripomore njena enostavnost, predvsem pa nizka cena [30]. Najcenejšo in hkrati tudi

najpreprostejšo verzijo lahko sestavi uporabnik sam, z le nekaj elektronskimi

komponentami, ki ga stanejo manj kot 10 €. Sestavljeno pa lahko dobi že tudi za 30 €.

Na podlagi dostopnosti, preprostosti in obsežne skupnosti smo tudi sami izbrali to

platformo za izdelavo senzorja temperature, ki bo vrednosti preko izbranega protokola

sporočal centralnemu strežniku. Med različnimi modeli, ki so na voljo, naše potrebe

najbolje zadovoljuje model Yun, saj ima med drugim že vgrajen modul za brezžično

komunikacijo. Poganja ga Atmel ATmega32u4 mikrokontroler, ki nudi 20 vhodno-izhodnih

vtičev, od katerih jih je 7 uporabnih za izhodni PWM in 12 kot analogni vhodi. Ima 32 kB

hitrega spomina (od tega je 4 kB porabljenega za nalagalnik), 2.5 kB SRAM-a in 1 kB

EEPROM-a. Dodatno ima že vgrajeno komunikacijo USB. Posebnost naprave je dodatni

procesor Atheros AR9331, na katerem teče Linux distribucija OpenWrt-Yun, ki predstavlja

prilagojeno verzijo distribucije OpenWrt, dobro poznane v svetu interneta stvari. Ta ima 64

mB DDR2 pomnilnika in 16 mB hitrega spomina. Dodatni procesor skrbi za brezžično,

žično in USB komunikacijo. Tudi microSD vhod, kamor lahko shranimo izmerjene ali

analitične podatke, je v domeni AR9331. Interakcija med procesorjema poteka preko

posebne knjižnice, imenovane Bridge, ki ukaze pošilja preko serijske komunikacije. To

omogoča Arduino komunikacijo s perifernimi enotami. Zaradi dveh procesorjev in večje

izbire vmesnikov sodi model med energijsko bolj potratne . Napaja se preko 5V micro-

USB priklopa. Fizična dimenzija naprave je 73 mm dolžine in 53 mm širine in tehta 32 g

[52].

Slika 2.7: Naprava Arduino Yun [31]


8

2.2 Brezžična komunikacija

2.2.1 Pregled tehnologij

Izbrana naprava iz prejšnjega poglavja že nakazuje na tehnologijo, ki jo bomo v našem

primeru uporabili pri brezžični komunikaciji. Ker obstaja več različnih tehnologij, ki se med

sabo razlikujejo tako po lastnostih (hitrost, poraba energije, domet, varnost, zanesljivost)

kakor tudi namembnosti uporabe, jih bomo v tem poglavju kljub temu na kratko predstavili

in v naslednjem podpoglavju nekoliko podrobneje opisali lastnosti izbrane tehnologije.

Komunikacija spada med najpomembnejše dele senzorja, zato je izbira prave tehnologije

bistvenega pomena. Med najpogosteje uporabljene spadajo Wifi, Bluetooth, Zigbee, GSM

(Global System for Mobile Communications) in RF (Radio frequency) [32].

Bluetooth je brezžični standard za izmenjavo podatkov na kratki razdalji. Je zelo pogosto

uporabljen, še posebej s predstavitvijo razširitve Bluetooth LE (Low Energy), ki s sabo

prenaša predvsem nizko porabo. To omogoča izdelavo naprav, ki se napajajo preko

baterije, z avtonomijo tudi do dveh let. Uporablja se pri krajših razdaljah in ni namenjen

prenosu datotek, ampak manjšim kosom podatkov. To ga naredi zelo primernega za

uporabo v različnih senzorjih [32]. Deluje na frekvenci 2.4 GHz in ima v aktualni verziji 4.2

domet od 50 do 100 metrov in dosega podatkovno hitrost do 1 Mbps [33].

Zigbee se imenuje specifikacija za paket visoko nivojskih komunikacijskih protokolov, ki se

uporabljajo za vzpostavitev zasebnih omrežij (WPAN - Wireless personal area network),

sestavljenih iz malih digitalnih radiev z nizko porabo. Standard nosi oznako IEEE

802.15.41. Zaradi nizke porabe je domet omejen od 10 do 100 metrov. Doseg lahko

povečamo z vzpostavitvijo mesh omrežja, ki preko vmesnih naprav poveča domet [32].

Podobno kot Bluetooth, tudi Zigbee deluje na frekvenci 2.4 GHz, vendar se pogosteje

uporablja v industriji in kadar poteka podatkovna izmenjava redkeje. Ima manjšo

podatkovno hitrost – do 230 Kbps. Aktualna verzija je 3.0 [33].

Kadar se morajo podatki pošiljati preko daljših razdalj in oddaljenih krajev, se

najpogosteje odločimo za uporabo mobilnega omrežja GSM/3G/4G. Prednost je

predvsem zanesljivost in hitrost prenosa – tudi do 10 Mbps. Posledično za svoje

delovanje potrebuje veliko več energije. Dodatno je potrebna kartica SIM (Subscriber

1 https://standards.ieee.org/getieee802/download/802.15.4-2011.pdf


9

identity module), ki je pogosto pogojena z naročnino in dodatnim zaračunavanjem

prenosa podatkov. Deluje na frekvenci 900/1800/1900/2100 MHz [33].

WiFi je zelo pogosta izbira predvsem, ker je v večini domov infrastruktura za namene

domačega omrežja že vzpostavljena. Omogoča hiter prenos in soliden domet. Vendar

posledično za delovanje potrebuje več energije in zahteva licenciranje strojne opreme, kar

naredi rešitev nekoliko dražjo. Kot že omenjeno, smo zaradi univerzalnosti, razširjenosti in

zanesljivosti za brezžičen prenos podatkov izbrali to tehnologijo. Iz tega razloga se bomo

tehnologiji v naslednjem podpoglavju nekoliko podrobneje posvetili.

Omeniti je potrebno tudi različne module RF, kot najcenejšo izbiro, ki brezžično

komunikacijo omogočajo za bistveno nižjo ceno. Takšna komunikacija je manj zanesljiva,

na krajše razdalje in z nizko podatkovno hitrostjo. Najpogosteje se uporablja pri direktni

komunikaciji med dvema napravama. Tehnologije smo v tabeli 2.1 za lažjo preglednost

razvrstili po ključnih lastnostih.

Tabela 2.1: Pregled brezžičnih tehnologij po ključnih lastnostih [34]

Tehnologija Frekvenca Domet Hitrost Poraba Varnost

WiFi 2,4 GHz 100 m 6-780 Mbps 1 W WPA, WPA2

Bluetooth 2,4 GHz 100 m do 3 Mbps 1 W 128 bit

Bluetooth LE 2,4 GHz 100 m do 1 Mbps 10-500 mW 128 bit AES

Zigbee 2,4 Ghz 10 m do 250 Kbps 1 mW 128 bit

GSM 900/1800/

1900/2100

Mhz

25 km do 1 Gbps 3 W GEA3, GEA4

RF-modul do 1 Ghz 50 m 20 Kbps 1 mW -

2.2.2 Predstavitev izbrane tehnologije

WiFi (Wireless Fidelity) je brezžična tehnologija, ki računalnikom in drugim napravam

omogoča medsebojno povezavo in povezavo v brezžična lokalna omrežja (WLAN -

Wireless local area network) (slika 2.8). Protokol je bil leta 1997 standardiziran pod

oznako IEEE 802.112. Implementacija standarda je bila draga in zahtevna, saj je

2 http://standards.ieee.org/getieee802/download/802.11-2012.pdf


10

vsebovala več kot 400 strani. Zaradi tega sta bila leta 1999 razvita standarda IEEE

802.11a1 in IEEE 802.11b1. Prvi zaradi manj motenj deluje na frekvenci 5 GHz in dosega

hitrosti do 54 Mbps. Zaradi frekvence ima protokol manjši domet, saj ima frekvenca večje

težave s preprekami. Na popularnosti je WiFi začel pridobivati z drugim standardom, ki je

deloval na običajni frekvenci (2,4 GHz) in je omogočal hitrosti do 11 Mbps [35].

Slika 2.8: Primer omrežja WiFi

Tehnologija se je najpogosteje uporabljala za dostop do interneta. Ker se je z njegovim

razvojem povečevala tudi zahteva po večji hitrosti, se je leta 2003 oblikoval standard IEEE

802.11g3, ki je dvignil hitrost prenosa podatkov do 54 Mbps tudi na običajni frekvenci.

Medtem ko se prva dva standarda več ne uporabljata, je IEEE 802.11g v uporabi še

danes. Danes se tehnologija uporablja v računalnikih, tiskalnikih, igralnih konzolah,

televizorjih, tablicah, telefonih in drugih napravah, ki komunicirajo z zunanjim svetom [35].

Leta 2009 je bil predstavljen nov standard, imenovan IEEE 802.11n4. Standard se je

uveljavil počasi, a ga trenutno podpira večina usmerjevalnikov, dostopnih točk in

računalnikov. Posebnost protokola je, da lahko deluje na obeh frekvencah (2,4 GHz in 5

GHz) in lahko za delovanje uporablja več kanalov. Preko enega kanala lahko doseže

maksimalno podatkovno hitrost 150 Mbps, kar skupaj znaša 600 Mbps. Za dosego te

hitrosti je potrebna strojna podpora na obeh koncih komunikacijskega kanala. Zaradi

3 https://standards.ieee.org/findstds/standard/802.11g-2003.html

4 https://standards.ieee.org/findstds/standard/802.11n-2009.html


11

razvoja različnih standardov je pomembno, da so novejši združljivi s starejšimi. V primeru

komunikacije dveh naprav, ki podpirata enak standard, to ne predstavlja problema, kadar

pa med sabo komunicirata napravi z različnima standardoma, bo hitrost komunikacije na

nivoju najpočasnejšega standarda [35].

Trenutno najnovejši standard je bil predstavljen leta 2014 in se imenuje IEEE 802.11ac5.

Predstavlja peto generacijo naprav, ki lahko podatke pretakajo po omrežju s hitrostjo do 1

Gbps. Hitrost prenosa podatkov posameznega standarda je prikazan na sliki 2.9.

Slika 2.9: Hitrost prenosa podatkov posameznega standarda WiFi [37]

Novi standard poleg hitrosti poveča tudi število naprav, ki so lahko istočasno povezane na

usmerjevalnike in dostopne točke, ter zmanjšuje motnje med napravami. Novi standard

pride do izraza pri pretoku video vsebin visoke ločljivosti, igranju iger, sinhronizaciji in

varnostnih kopijah naprav ter deljenju večjih datotek znotraj lokalnega omrežja [36].

Seveda hitrost prenosa ni edini faktor, na podlagi katerega se brezžične tehnologije med

sabo razlikujejo. WiFi je namenjen brezžični komunikaciji naprav, ki so med sabo

oddaljene do 100 m. Različne ovire pa lahko to razdaljo drastično zmanjšajo. S pomočjo

močnejših zunanjih anten se lahko domet kljub vsemu drastično poveča [36].

Pri uporabi protokola za namene brezžične komunikacije med senzorji in aktuatorji je

velikega pomena tudi varnost omrežja. Standard podpira različne možnosti zaščite.

Najpogosteje so na voljo WEP (Wired Equivalent Privacy), WPA-PSK (TKIP), WPA-PSK

(AES), WPA2-PSK (TKIP) in WPA2-PSK (AES). Čeprav je mogoče vzpostaviti brezžično

5 http://standards.ieee.org/news/2014/ieee_802_11ac_ballot.html


12

omrežje brez zaščite, je priporočljivo, da omrežje zaščitimo z eno od teh možnosti.

Najstarejša in tudi najranljivejša izbira je WEP. Priporočeno je, da se uporabi WPA-PSK

ali WPA2-PSK, pri čemer je TKIP (Temporal Key Integrity Protocol) starejši standard za

šifriranje podatkov in se ne smatra več za varnega. Največjo raven zaščite zatorej

omogoča WPA2-PSK (AES), ki pa lahko posledično upočasni hitrost prenosa podatkov na

manj zmogljivi strojni opremi. Opisan protokol bo zagotavljal, da bomo senzor, izdelan v

naslednjem poglavju, varno, zanesljivo in hitro brezžično povezali do centralnega

strežnika, kamor bo lahko pošiljal izmerjene podatke.


13

2.3 Izdelava senzorja

2.3.1 Uporabljene komponente

Slika 2.10: Shema vezave komponent za izdelavo senzorja temperature [53]

Komponente na sliki 2.10:

1. Arduino Yun, podrobneje opisan v podpoglavju 1.1.2.

2. DHT11, nizkocenovni digitalni senzor temperature in relativne zračne vlažnost z

naslednjimi lastnostmi:

a. od 3 do 5 V napajalna napetost;

b. 2.5 mA maksimalna poraba toka (med branjem vrednosti);

c. merjenje relativne zračne vlažnosti v območju 20-80% z natančnostjo 5 %;

d. merjenje temperature zraka med 0-50 °C z natančnostjo +-2 °C;

e. frekvenca merjenja 1 Hz;

f. velikost 15.5 x 12 x 5.5 mm.

3. Upor z upornostjo 4.7 K ohmov.

4. Žičke za povezavo.

2.3.2 Delovno okolje

Poleg odprtokodne strojne opreme je na voljo tudi odprtokodno razvojno okolje,

imenovano Arduino IDE, ki poskrbi za celovitost platforme. Izdelano je v programskem

jeziku Java in mogoča pisanje in prevajanje programov ter programiranje podprtih naprav.

Okolje je sestavljeno iz tekstovnega urejevalnika za pisanje kode, okna za sporočila,

tekstovne konzole, menija, serijskega monitorja in orodne vrstice z gumbi za najpogosteje


14

uporabljene funkcije (Verify, Upload, New, Open, Save in Serial Monitor). Vsi elementi so

prikazani na sliki 2.11. Okolje vsebuje podporo za različne naprave in osnovne knjižnice,

le-te se lahko dodatno razširijo preko tretjih ponudnikov. Aktualna verzija v času

namestitve je 1.6.10 in podpira operacijske sisteme Windows, Max OS X in Linux. Na

voljo je tako v 32- kakor tudi 64-bitni verziji [26].

Slika 2.11: Arduino razvojno okolje

Senzor bomo programirali na operacijskem sistemu Ubuntu 16.04. Za namestitev je tako

najprej potrebno iz uradne strani6 prenesti arhiv (datoteka arduino-1.6.10-linux64.tar.xz)

na lokalni računalnik. Namestitev se nadaljuje preko tekstovne konzole, kjer se

pomaknemo do mape, kamor smo arhiv prenesli, ga razširimo in poženemo ukaz za

namestitev [29].

6 https://www.arduino.cc/en/Main/Software


15

Preden smo začeli z uporabo razvojnega okolja, smo Arduino Yun preko vmesnika USB

povezali na računalnik. Z ukazom smo ugotovili, na katerem vmesniku je prepoznan in

uporabnika dodali med člane skupine, ki ima pravice za komunikacijo s priključeno

napravo [29].

Okolje smo s pomočjo bližnjice na namizju zagnali. Pravilnost namestitve in delovanja

smo preverili tako, da smo preko menija 'File > Examples > 01.Basic > Blink' naložili

osnovni program Blink, ki je kot primer že vključen v razvojno okolje. Preden smo program

prenesli na priključeno napravo, smo jo izbrali v meniju 'Tools > Board > Arduino Yun' in

okolju v meniju 'Tools > Port > /dev/ttyACM0' sporočili, preko katerih vrat je naprava

dosegljiva. S klikom na gumb 'Upload' v orodni vrstici smo program prevedli in ga prenesli

na napravo. Po uspešnem prenosu se je v statusni vrstici pokazalo sporočilo ' Done

uploading', na napravi pa je začela utripati oranžna led dioda, ki je priključena na vtič 13,

kar je potrdilo uspešnost, saj je naložen program narekoval ravno takšno obnašanje [29].

Programi se v Arduino razvojnem okolju pišejo v tekstovnem urejevalniku in se shranjujejo

v datoteko s končnico ino. Preden se program prenese na napravo, ga je potrebno

preveriti in prevesti. Morebitne napake pri preverjanju ali prevajanju se izpišejo v polje s

sporočili. Programi se pišejo v jeziku C\C++ in se prevedejo s prevajalnikom avr-gcc v

strojno kodo [24]. Ob zagonu programa se kliče funkcija setup, katere namen je

inicializacija spremenljivk in knjižnic. Funkcija se kliče samo enkrat, ob zagonu naprave.

Ko se funkcija setup uspešno izvede, se kliče funkcija loop, ki se v nedogled izvaja v zanki

[25]. Minimalno strukturo Arduino programa naslednji izsek kode:

uporabnik@prenosnik:~$ ls -l /dev/ttyACM*

crw-rw---- 1 root dialout 166, 0 jul 27 14:51 /dev/ttyACM0

uporabnik@prenosnik:~$ sudo usermod -a -G dialout uporabnik

uporabnik@prenosnik:~$ cd Downloads/

uporabnik@prenosnik:~/Downloads$ tar -xvzf arduino-1.6.10-linux64.tar.xz

uporabnik@prenosnik:~/Downloads$ cd arduino-1.6.10/

uporabnik@prenosnik:~/Downloads/arduino-1.6.10$ ./install.sh

uporabnik@prenosnik:~/Downloads/arduino-1.6.10$ sudo usermod -a -G dialout uporabnik


16

Za dodajanje funkcionalnosti razvojno okolje omogoča dodajanje knjižnic. Knjižnico

vključimo v naš program s pomočjo menija 'Sketch > Include Library', ki vnese enega ali

več #include ukazov v naš program. Nekatere knjižnice so v razvojno okolje že

nameščene, dodatne pa se lahko namestijo v meniju 'Sketch > Import Library > Manage

Libraries' ali 'Sketch > Import Library > Add .ZIP Library' [26].

2.3.3 Programiranje senzorja

Preden smo lahko začeli s programiranjem senzorja za temperaturo, smo morali preko

menija 'Sketch > Import Library > Add .ZIP Library' namestiti knjižnici DHTlib in

PubSubClient. Knjižnica DHTlib služi za branje temperature in relativne vlažnosti

senzorjev iz skupine DHT (11, 21, 22, 33, 44). Avtor knjižnice je Rob Tillaart, ki je kodo

objavil na GitHub7, da je ta prosto dostopna javnosti [27]. PubSubClient je knjižnica, ki

implementira odjemalca MQTT in bo omogočala komunikacijo s posrednikom MQTT.

Avtor Nick O'Leary je knjižnico izdal pod licenco MIT (Massachusetts Institute of

Technology) in kodo objavil na GitHub8 [28].

Izvorna koda programa se začne z vključitvijo knjižnic, ki jih bomo potrebovali:

7 DHTlib repozitorij: https://github.com/RobTillaart/Arduino

8 PubSubClient repozitorij: https://github.com/knolleary/pubsubclient

#include <dht.h>

#include <BridgeClient.h>

#include <Bridge.h>

#include <PubSubClient.h>

void setup() {

// inicializacija spremenljivk in knjižnic

}

void loop() {

// izvajanje programa

}


17

in definiranjem osnovnih vrednosti, ki se v programu uporabljajo:

V funkciji setup preko razreda Serial inicializiramo serijsko komunikacijo, ki služi za

izpisovanje informacij za namene razhroščevanja, razredom Bridge, ki zagotavlja pretok

ukazov med mikrokontrolerjem in brezžičnim modulom, ter MQTT odjemalca, preko

katerega pošiljamo prebrane vrednosti do MQTT posrednika:

Glavna funkcionalnost je zapisana v funkciji loop, ki v zanki izvaja naslednji algoritem:

Za objavo podatka uporabljamo spodnjo funkcijo, ki vrednost temperature in relativne

zračne vlažnosti iz tipa double pretvori v string, ki se nato preko funkcije publish razreda

PubSubClient pošlje do MQTT posrednika.

rezultat_branja = preberi vrednost dht senzorja

if rezultat_branja == true

if prebrana vrednost > minimalne potrebne spremembe

vklopi statusni vtič

if povezava do MQTT posrednika ni vzpostavljena

vzpostavi povezavo do MQTT posrednika

objavi prebrano vrednost MQTT posredniku

izključi statusni vtič

izpiši prebrano vrednost in status komunikacije na serijski vmesnik

else

print dht error

// inicializacija serijske komunikacije

Serial.begin(9600); Bridge.begin();

// inicializacija mostu med mikrokontrolerjem in brezžičnim modulom

Bridge.begin();

// inicializacija mqtt odjemalca

mqttClient.setServer(mqttServerIp, MQTT_PORT);

mqttClient.setServer(mqttServerIp, MQTT_PORT);

// priprava vtiča za status led

pinMode(STATUS_PIN, OUTPUT);

#define DHT11_DATA_PIN 5

#define MQTT_CLIENTID "MQTT_DHT_Sensor_Dnevna"

#define MQTT_PASSCODE "[pascode]"

#define MQTT_PORT 1883

#define STATUS_PIN 13


18

Na koncu smo program morali prenesti na mikrokontroler, kjer se bo lahko začel izvajati.

V ta namen smo morali preko menija 'Tools > Board' izbrati ciljno napravo (v našem

primeru Arduino Yun) in v meniju 'Tools > Port' izbrati vmesnik, preko katerega je naprava

povezana do računalnika (v našem primeru /dev/ttyACM0). Za zaključek je preostalo

samo še prevajanje programa preko menija 'Sketch > Verify/Compile' in prenos na

napravo, ki ga izvede meni 'Sketch > Upload'. Rezultat prevajanja in prenosa prikazuje

slika 2.12.

Slika 2.12: Rezultat prevajanja in prenosa programa na mikrokontroler

void publish_mqtt(double temperature, double humidity) {

char char_array[20];

String val = String(temperature);

val.toCharArray(char_array, 20);

mqttClient.publish(MQTT_TEMPERATURE_TOPIC, char_array);

val = String(humidity);

val.toCharArray(char_array, 20);

mqttClient.publish(MQTT_HUMIDITY_TOPIC, char_array);

}


19

3 KOMUNIKACIJA MOBILNIH APLIKACIJ S SENZORJI

3.1 Opis tehnologij in protokolov za realno-časovno komunikacijo

Internet v večini temelji na klasičnem modelu odjemalec-strežnik, kar za komunikacijo

med napravami pogosto ni najprimernejši model, saj ne zagotavlja predvidljive zakasnitve

in učinkovitega zaznavanja spremembe stanja [17]. Zato se pri komunikaciji med

napravami uporabljajo različni protokoli, ki pomanjkljivosti klasičnega modela odpravljajo.

Ker se senzorji uporabljajo v raznoraznih situacijah, imajo protokoli različne

funkcionalnosti in lastnosti. Omogočajo komunikacijo med napravami (D2D - Device-to-

device), zbirajo podatke senzorjev in jih pošiljajo do strežnikov (D2S - Device-to-server)

ter delijo podatke med strežniki (S2S - Server-to-server), ki jih nato posredujejo do drugih

naprav, programov za analizo in uporabnikov [18]. Najpogosteje uporabljeni protokoli v te

namene so MQTT, XMPP, AMQP, DDS, CoAP [19]. Vsi omenjeni protokoli so splošno

sprejeti in za njih obstaja več različnih implementacij. Prvi štirje protokoli se smatrajo za

realno-časovne in med sabo povezujejo na tisoče naprav, ki med sabo komunicirajo po

vzorcu objavi/naroči [18]. Zadnji je predstavnik klasičnega modela komunikacije med

odjemalcem in strežnikom. Ker so snovani za različne namene, je ključnega pomena, da

se zavedamo njihovih lastnosti in razlik med njimi, saj bomo le tako lahko izbrali pravega,

ki bo služil našemu namenu uporabe. Shema na sliki 3.1 prikazuje najprimernejše

področje uporabe posameznega protokola.

Slika 3.1: Shema najprimernejše uporabe posameznega protokola z odzivnostjo [18]


20

V naslednjem podpoglavju bomo na kratko predstavili posamezne protokole in izbrali za

naš primer uporabe najprimernejšega, ki ga bomo v podpoglavju 3.1.2 tudi podrobneje

predstavili.

3.1.1 Predstavitev protokolov

Extensible Messaging and Presence Protocol (XMPP) je bil razvit za namene hipne

komunikacije med ljudmi preko tekstovnih sporočil. Sporočila se preko TCP (Transmission

Control Protocol) prenašajo v obliki XML (Extensible Markup Language). Glavna prednost

protokola je naslavljanje po shemi [email protected], ki uspešno pripomore pri medsebojni

povezavi dveh virov iz velike množice virov na internetu (prikazano na sliki 3.2) [18].

Slika 3.2: Prikaz sheme XMPP za naslavljanje [18]

Pri komunikaciji med napravami XMPP ponuja preprost način, kako naslavljati posamezno

napravo. To je predvsem uporabno pri pošiljanju sporočil med oddaljenimi, nepovezanimi

napravami. Ni oblikovan, da bi bil hiter in v večini implementacij za potisna sporočila

uporablja protokol, imenovan BOSH (Bidirectional streams over Synchronous HTTP).

Prenaša prednosti pri naslavljanju, varnosti in razširljivosti. Realno-časovnost se pri tem

protokolu meri v sekundah [18].


21

Data Distribution Service (DDS) se uporablja v napravah, ki neposredno komunicirajo z

drugimi napravami. Protokol je podatkovno orientiran in ima svoje korenine v industriji.

Uspešno lahko dostavi milijone sporočil na sekundo veliki količini prejemnikov istočasno.

Protokol implementira arhitekturo objavi/naroči. Realno-časovnost se pri protokolu meri v

mikrosekundah. Ponuja veliko različnih možnosti pri kontroli zagotavljanja storitve,

večvrstno oddajanje, nastavljivo zanesljivost in robustno redundanco. Ponuja učinkovito

filtriranje in natančno izbiro, kateri podatek je potrebno dostaviti kam. DDS implementira

neposredno podatkovno vodilo med napravami, ki nadzira dostop in posodablja veliko

količino naprav istočasno, kar je potrebno v okoljih, kjer mora velika količina zmogljivih

naprav sodelovati kot enotni sistem. Uporablja se v vojski, vetrnih farmah, medicini in

avtomobilski industriji [18]. Slika 3.3 prikazuje medsebojno povezanost subjektov domene

DDS.

Slika 3.3: Prikaz subjektov domene DDS [20]

Advanced Message Queuing Protocol (AMQP) kot sporočilno orientiran protokol v

ospredje postavlja vrsto (slika 3.4). Svoj izvor ima v bančni industriji in lahko uspešno in

varno obdela tisoče transakcij, ki so zanesljivo uvrščene v vrsto. Za komunikacijo

uporablja TCP in je osredotočen na to, da se sporočilo ne izgubi. Končna točka mora

prejem sporočila potrditi. Najpogosteje se uporablja pri poslovnem sporočanju, kjer

naprave komunicirajo s podatkovnimi centri in se podatki potrebujejo za analitiko [18].


22

Slika 3.4: Potek komunikacije med odjemalci AMQP

Constrained Application Protocol (CoAP) je razvit za uporabo na napravah z omejenimi

viri in nezanesljivo povezavo. Protokol implementira klasičen odjemalec-strežnik model

(slika 3.5). Strežnik preko naslova URL (Uniform Resource Locator) omogoča dostop do

virov, s katerimi lahko odjemalec s pomočjo metod GET, PUT, POST in DELETE

manipulira. Preko posrednikov je protokol združljiv s HTTP (Hypertext Transfer Protocol).

Ker za prenos uporablja UDP (User Datagram Protocol), potebuje manjše podatkovne

paketke z manj presežka. Načrtovan je tako, da deluje tudi na mikrokontrolerjih s samo 10

kB pomnilnika in omogoča dva različna nivoja zagotavljanja storitve (potrditveno in

nepotrditveno). V sam protokol so definirani mehanizmi za odkrivanje virov. Najpogosteje

se uporablja za sporočanje stanj pri napravah, ki so lahko dlje časa v spanju in iz katerega

se lahko hitro zbudijo [21].

Slika 3.5: Prikaz toka sporočil za potrditveni (levo) in nepotrditveni (desno) zahtevek


23

MQTT (Message Queuing Telemetry Transport) cilja na zbiranja podatkov iz več naprav in

jih prenese do strežnikov, kjer se lahko podatki nadzirajo in analizirajo. Komunikacija

poteka preko TCP. Naprave se morajo za prejemanje in objavljanje sporočil povezati do

posrednika, ki nato preko tem sporočila filtrira in ustrezno preusmerja. Protokol je

podrobneje opisan v naslednjem poglavju, saj smo ga zaradi preprostosti, zanesljivosti,

malo podatkovnega presežka ter zagotavljanja varnosti s pomočjo TLS (Transport Layer

Security), izbrali za najprimernejšega za naš primer uporabe.


24

3.1.2 Predstavitev izbranega protokola MQTT

MQTT je protokol za prenos sporočil med strežnikom in odjemalcem s pomočjo

arhitekture objavi/naroči (ang. publish/subscribe) (slika 3.6). Protokol je enostaven, odprt

in zasnovan tako, da se ga lahko preprosto implementira. Pogosto se uporablja pri

komunikaciji med napravami z omejenimi viri ali v situacijah, kjer je pasovna širina

omrežja omejena. Uporaben je tudi za potisna sporočila kot alternativa Googlovi lastni

rešitvi GCM (Google Cloud Messaging), ki na napravi ne zahteva nameščenih googlovih

mobilnih storitev (GMS - Google Mobile Services) [45]. Poleg že omenjenega protokol

omogoča tri različne načine preverjanje uspešne dostave sporočila, ima majhno količino

redundantnih podatkov, kar zmanjšuje število podatkov, prenesenih preko omrežja in

vključuje mehanizem za obveščanje zainteresirane strani o nepričakovani prekinitvi

povezave [1].

Protokol sta leta 1999 razvila Andy Stanford-Clark iz podjetja IBM in Arlen Nipper iz

podjetja Eurotech (takrat Arcom). Namen je bil oblikovati protokol, ki bo preko satelitske

povezave med sabo povezal naftovode, zaradi česar je moral biti prizanesljiv do baterije

in uporabljati malo pasovne širine. Protokol se je dolgo časa uporabljal znotraj omenjenih

podjetij, dokler ga novembra 2011 nista brezplačno ponudila javnosti, v verziji 3.1 [1]. Z

verzijo 3.1.1 je protokol oktobra 2014 uradno postal OASIS-standard9 [2]. Od leta 2016 je

le-ta tudi ISO-standard pod oznako ISO/IEC 2092210 [44].

Kot že omenjeno, protokol za komunikacijo uporablja vzorec objavi/naroči. V primerjavi s

tradicionalnim modelom odjemalca in strežnika so tukaj odjemalci, ki pošiljajo sporočilo

(ang. publishers), neodvisni od odjemalcev, ki sprejemajo sporočilo (ang. subscribers), kar

pomeni, da se drug drugega ne zavedajo in je za uspešno komunikacijo potrebna še tretja

komponenta, imenovana posrednik (ang. broker).

9 http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html

10 https://www.iso.org/obp/ui/#iso:std:iso-iec:20922:ed-1:v1:en


25

Slika 3.6: Primer vzorca objavi/naroči

V kontekstu MQTT se za odjemalca smatra vsaka naprava, ki je povezana do posrednika.

Implementacija odjemalca je zelo preprosta in nezahtevna, kar omogoča, da deluje tako

na preprostih mikrokrmilnikih kakor tudi zelo dovršenih računalnikih. Na voljo je za večino

popularnih programskih jezikov. Nasprotje tega je posrednik. Naloga posrednika je, da

sprejema vsa sporočila, jih filtrira in jih ustrezno posreduje do odjemalcev. Prav tako je

zadolžen za vzpostavitev in ohranjanje seje in skrbi za njihovo avtorizacijo in avtentikacijo.

V splošnem se lahko sporočila filtrirajo glede na predmet ali temo, glede na vsebino in

glede na tip [4]. V primeru MQTT se uporablja filtriranje glede na temo (angl. topic). Vsako

sporočilo vsebuje niz znakov v hierarhični strukturi. Odjemalec posredniku sporoči, katere

teme ga zanimajo in ta ga začne obveščati o vseh sporočilih, ki jih je na to temo prejel.

Strukturo in filtriranje na podlagi tem bomo podrobno opisali v podpoglavju 3.1.2.2.

3.1.2.1 Komunikacija

Protokol MQTT za komunikacijo uporablja TCP/IP, ki mora biti na voljo tako pri odjemalcu

kakor tudi pri posredniku. Komunikacija vedno poteka med odjemalcem in posrednikom,

nikoli neposredno med dvema odjemalcema. Povezava se vzpostavi tako, da odjemalec

pošlje CONNECT paket do posrednika (slika 3.7) [5].


26

Slika 3.7: Vzpostavitev komunikacije med odjemalcem in posrednikom

Primer paketa CONNECT prikazuje slika 3.8 in med drugim vsebuje naslednje elemente:

- clientId predstavlja identifikator odjemalca, ki se povezuje na posrednika in mora biti

unikaten;

- cleanSession z vrednostjo false predstavlja trajno povezavo, kar pomeni, da bo

posrednik hranil vse teme ter morebitna zamujena sporočila odjemalca in z vrednostjo

true sporoča posredniku, da naj vse obstoječe podatke iz prejšnjih sej zanj razveljavi.

Identifikacija seje poteka s parametrom clientId. Seja se bo ohranjala, vse dokler

odjemalec pri povezavi ne pošlje strežniku paket s cleanSession vrednostjo true. Trajna

povezava omogoča, da odjemalec prejme vsa sporočila na katera je bil naročen, četudi je

ta vmes bil neaktiven. Funkcionalnost je primerna predvsem za odjemalce z omejenimi

viri, ker se lahko tako ponovna povezava hitro vzpostavi, saj ponovno naročilo na teme ni

potrebno;

- username/password služi za namene avtorizacije in avtentikacije odjemalca in bo

podrobneje opisan v poglavju 3.1.2.4;

- lastWillTopic/lastWillMessage/lastWillQos predstavljajo temo, sporočilo in stopnjo

kakovosti storitve za primer, ko posrednik zazna nepredvideno prekinitev povezave do

odjemalca. Do tega pogosto pride pri manj stabilnih povezavah, ko napravam zmanjka

napajanja ali ko pride do druge nepredvidene prekinitve. Za te namene posrednik shrani

sporočilo (lastWillMessage) in temo (lastWillTopic). V primeru, da takšno prekinitev zazna,

pošlje sporočilo vsem odjemalcem, ki so na to temo naročeni in na takšen način vse

zainteresirane odjemalce obvesti o prekinitvi povezave. V primeru, da se odjemalec

pravilno odjavi s paketkom DISCONNECT, se shranjeni podatki za sporočilo in temo

razveljavijo;

- keepAlive je časovni interval, do katerega se odjemalec zaveže, da bo periodično pošiljal

zahtevek PING posredniku, če v tem intervalu ni potekala druga izmenjava podatkov. Na

zahtevek PING posrednik pošlje odgovor PING. Mehanizem omogoča, da obe strani


27

vesta, ali je povezava med njima še aktivna in odprta. To je posebej pomembno pri

mobilnih povezavah, kjer lahko pogosteje pride do pol odprte povezave (ena stran

povezave ne ve, da je druga stran povezave neaktivna). Odgovornost pošiljanja zahtevka

PING je na strani odjemalca. Naloga posrednika je, da do odjemalca, ki ni poslal paketka

v 1.5-kratniku intervala, prekine povezavo. Pogosto se zgodi, da se bo odjemalec, ki je

povezavo izgubil, želel ponovno povezati do posrednika, medtem ko ima ta še vedno pol

odprto povezavo. V tem primeru se s pomočjo clientId takšna povezava identificira in

posrednik izvede prevzem povezave (obstoječa pol odprta povezava se prekine in

vzpostavi nova).

Slika 3.8: Primer CONNECT in CONNACK paketa

Po uspešno prejetem paketu posrednik odgovori s paketom CONNACK, ki vsebuje

zastavico, ali ima odjemalec že aktivno sejo in statusno kodo (0 za uspešno povezavo, 1-

5 za neuspešno s pojasnilom), kot prikazuje slika 3.7. Po tem, ko je povezava

vzpostavljena, ta ostane odprta, vse dokler odjemalec ne pošlje paketa za prekinitev ali pa

se povezava izgubi [5]. Odjemalci lahko začnejo po njej pošiljati PUBLISH pakete. Ko

odjemalec pošlje takšen paket do posrednika, le-ta paket procesira, po potrebi prejem

potrdi in na podlagi teme ugotovi, do katerih odjemalcev ga mora dostaviti. Odgovornost

odjemalca, ki je sporočilo objavil, je uspešna dostava do posrednika, o tem kdo in koliko

odjemalcev bo sporočilo prejelo, pa nima podatka. Odgovornost za to prevzame

posrednik [6]. Tok takšne komunikacije prikazuje slika 3.9.


28

Slika 3.9: Tok PUBLISH paketa

Osnovni sestavni deli tega paketa so prikazani na sliki 3.10. Ključnega pomena sta ime

teme (topicName) in tovor (payload). Ime teme je sestavljeno iz niza znakov, ki so s

poševnico razdeljeni v hierarhijo in posredniku služijo za posredovanje sporočila naprej do

odjemalcev (npr. 'hisa/kuhinja/temperatura). Tovor vsebuje dejansko sporočilo, ki ga

želimo prenesti. Točna oblika vsebine ni definirana in je odvisna od pošiljatelja.

Najpogosteje se uporablja JSON (JavaScript Object Notation) ali XML. Poleg že

omenjenih podatkov sporočilo vsebuje še:

- qos (1, 2 ali 3), ki zagotavlja garancijo dostave sporočila do posrednika ali odjemalca in

je podrobneje predstavljen v poglavju 3.1.2.3;

- retainFlag zastavica za zadržitev sporočila pove posredniku, ali naj sporočilo shrani kot

zadnjo znano vrednost za dano temo. Novi odjemalci, ki se prijavijo na to temo, bodo takoj

ob prijavi prejeli to sporočilo in jim ni potrebno čakati šele do naslednje posodobitve

vrednosti. Posrednik za vsako temo hrani samo zadnje takšno sporočilo. Takšno sporočilo

je posebej uporabno pri sporočanju statusov naprav v omrežju. V tem kontekstu bi lahko

rekli, da je takšno sporočilo zadnje znano stanje te naprave;

- pocketId je unikatni identifikator med odjemalcem in posrednikom in se uporablja v

primerih, ko je vrednost qos večja od 0;

- dupFlag zastavica pove, ali je sporočilo podvojeno, ker prejemnik ni potrdil prvotnega

prejema.


29

Slika 3.10: Primer PUBLISH in opcijskega PUBACK paketa

Poleg že omenjenih paketov MQTT za svoje delovanje potrebuje še dva ključna paketa,

SUBSCRIBE in UNSUBSCRIBE. S paketom SUBSCRIBE odjemalec posredniku sporoči,

katera sporočila želi prejemati. Slika 3.11 prikazuje elemente takšnega paketa, med

katerimi je ključnega pomena seznam, ki lahko vsebuje poljubno število naročil. Vsako

naročilo v seznamu je sestavljeno iz imena teme in nivoja zagotavljanja kakovosti storitve.

Vsako naročilo je s strani posrednika potrjeno s paketom SUBACK. Ta vsebuje seznam

vrnjenih kod za vsako naročeno temo v enakem zaporedju. Vrednosti kode od 0 do 2

potrjujejo uspešno naročilo na temo. V primeru neuspeha pa se vrne koda 128. Po

uspešni prijavi začne odjemalec prejemati vsa sporočila, ki so objavljena za dotične teme

[6]. Zaporedje komunikacije prikazuje slika 3.12.

Slika 3.11: Primer SUBSCRIBE in SUBACK paketa


30

Slika 3.12: Zaporedje izmenjave paketov ob prijavi na temo

Zadnji paket, ki ga bomo predstavili podrobneje, je namenjen odjavi odjemalca iz

tem/teme. Podobno kot SUBSCRIBE tudi paket UNSUBSCRIBE vsebuje seznam tem, od

katerih se odjemalec želi odjaviti. Po prejemu takšnega paketa posrednik izbriše

zahtevanje prijave za odjemalca in mu odgovori s paketom UNSUBACK. Slika 3.13

prikazuje primer takšnega paketka, sam potek pa je viden na sliki 3.14 [6].

Slika 3.13: Primerk paketov UNSUBSCRIBE in UNSUBACK

Slika 3.14: Zaporedje izmenjave paketov ob prijavi na temo


31

3.1.2.2 Teme

O temah smo sicer nekaj že povedali, a ker so pomemben koncept protokola, jih bomo v

tem poglavju spoznali nekoliko podrobneje. V osnovi je tema niz znakov, zakodiran v

formatu UTF-8. Na podlagi teme posrednik ugotovi, katerim odjemalcem mora prejeto

sporočilo poslati. S pomočjo poševnice ime teme strukturiramo v hierarhijo. Ime teme

mora imeti vsaj en znak, lahko vsebuje presledke, se loči glede na velike ter male črke, a

je drugače zelo fleksibilno (slika 3.15).

Slika 3.15: Struktura imena teme in primeri imen tem [7]

Nekaj primerov tem:

Odjemalec lahko ob prijavi na temo sporoči polno ime ali se s pomočjo posebnih znakov

prijavi na več tem hkrati. Posebni znaki se lahko uporabljajo samo pri naročilu na temo.

Znak + predstavlja enonivojsko substitucijo nivoja teme. Na sliki 3.16 je prikazana

uporaba takšnega posebnega znaka.

Slika 3.16: Primer uporabe enonivojske substitucije imena teme [7]

Primeri tem, ki jih v zgornjem primeru zajamemo:

myhome/groundfloor/livingroom/temperature

myhome/groundfloor/kitchen/temperature

myhome/groundfloor/livingroom/temperature

USA/California/San Francisco/Silicon Valley

5ff4a2ce-e485-40f4-826c-b1a5d81be9b6/status

Germany/Bavaria/car/2382340923453/latitude


32

Teme, ki jih zgornji primer ne zajema:

Poleg enonivojske je možna tudi večnivojska substitucije nivoja teme. Za ta namen služi

znak #. Znak je vedno zadnji v imenu teme. Odjemalec, prijavljen na takšen način, bo

prejemal vsa sporočila, ki se bodo ujemala z imenom teme do tega znaka, neodvisno od

tega, kako globoko je ime teme strukturirano. Uporaba znaka je prikazana na sliki 3.17 [7].

Slika 3.17: Primer uporabe večnivojske substitucije imena teme [7]

Navedenemo kriteriju ustrezajo naslednje teme:

Primer teme, ki ne ustrezajo kriteriju:

Pri poimenovanju tem imamo proste roke, razen tem, ki se začnejo z $. Te so

obravnavane posebno. Rezervirane so za posrednika in je odjemalcem onemogočeno

zanje objavljati sporočila [2]. Trenutno v standardu ni določeno, katere podatke mora

posrednik objavljati, pogosto se uporabljajo naslednje teme:

$SYS/broker/load/bytes/received, $SYS/broker/load/bytes/sent, $SYS/broker/clients/total,

$SYS/broker/clients/maximum, $SYS/broker/version … [8].

3.1.2.3 Zagotavljanje kakovosti storitve (QoS)

Pomembna funkcionalnost protokola MQTT je zagotavljanje kakovosti storitve (QoS -

Quality of service), kar tudi na manj zanesljivih povezavah zagotavlja dostavo sporočila do

myhome/firstfloorfloor/kitchen/temperature

myhome/groundfloor/livingroom/brightness

myhome/groundfloor/kitchen/temperature

myhome/groundfloor/kitchen/brightness

myhome/groundfloor/kitchen/brightness

myhome/firstfloorfloor/kitchen/temperature

myhome/groundfloor/kitchen/fridge/temperature


33

cilja. Na voljo so trije nivoji, za katere se lahko pošiljatelj in prejemnik dogovorita. Nivo

zagotavljanja kakovosti storitve lahko določamo tako za povezavo med posrednikom in

pošiljateljem sporočila kakor tudi med posrednikom in prejemnikom sporočila. V

nadaljevanju bomo podrobneje predstavili vse tri nivoje [9].

Najnižji in preprostejši nivo zagotavljanja kakovosti storitve, prikazan na sliki 3.18, je QoS

0 – največ enkrat. Zagotavlja, da bo sporočilo dostavljeno po najboljši moči (angl. best

effort). Sprejemnik prejema sporočila ne bo potrdil, pošiljatelj pa le-tega ne bo shranil za

ponovno pošiljanje. Nudi enak nivo zagotavljanja kot protokol TCP in se pogosto imenuje

sproži in pozabi (angl. fire and forget). Nivo se pogosto uporablja, kadar je povezava med

pošiljateljem in prejemnikom stabilna (žična), ni ključnega pomena, če se kakšno

sporočilo izgubi (manj pomembni podatki, kratek interval pošiljanja) ali kadar ni potrebe po

zadržanju sporočil, če odjemalec ni povezan [9].

Slika 3.18: MQTT QoS nivo 0

QoS 1 zagotavlja, da bo sporočilo vsaj enkrat dostavljeno do sprejemnika, pri čemer je

možno, da bo dostavljeno tudi večkrat. Pošiljatelj bo shranil sporočilo, dokler od

prejemnika ne dobi potrditve o prejemu. Če potrditve v doglednem času ne dobi, ponovno

pošlje sporočilo. Potek sporočil je prikazan na sliki 3.19. Je najpogosteje uporabljen nivo,

saj predstavlja kompromis med kakovostjo in hitrostjo. Uporablja se, kadar je potrebno, da

se sprejme vsako sporočilo in pri tem podvojitve ne predstavljajo težave [9].


34


Najvišja kakovost storitve je pri protokolu MQTT zagotovljena z nivojem 2, ki je hkrati tudi

najpočasnejši, saj zahteva dva obhoda paketov, kar je prikazano na sliki 3.20. Nivo

zagotavlja, da bo vsako sporočilo prejemnika doseglo natanko enkrat. Če prejemnik dobi

sporočilo z nivojem QoS nivojem 2, prejem potrdi s paketom PUBREC in hrani

identifikator paketka, vse dokler ne bo poslal paketa PUBCOMP, s čimer lahko zagotovi,

da sporočila ne bo ponovno obdelal. Na drugi strani lahko pošiljatelj po prejemu paketa

PUBREC smatra, da je bilo sporočilo uspešno dostavljeno. Posledično lahko pozabi na

prvotno sporočilo, shrani na novo prejet paket in odgovori s paketom PUBREL. Tok

komunikacije se zaključi tako, da prejemnik prejme paket PUBREL, ki signalizira, da lahko

zavrže vsa stanja za dotični paket in odgovori s paketom PUBCOMP, ki tudi pošiljatelja

obvesti, da lahko naredi enako, saj je izmenjava uspešno zaključena. Uporablja se, kadar

je kritičnega pomena, da je sporočilo dostavljeno natanko enkrat, saj bi podvojitev

negativno vplivala na prejemnika [9].



35

3.1.2.4 Zagotavljanje varnosti

Ker se protokol MQTT uporablja za komunikacijo med napravami, ki so med sabo

povezane na različne načine, je pomembno, da se med njimi zagotavlja varna, zaupna in

celovita povezava. Prav tako je za protokol značilno, da je uporabljen na raznovrstnih

napravah, ki so lahko tudi zelo omejene z viri (procesorska moč, pomnilnik, baterija). S

tega vzroka je možno varnost zagotoviti na več različnih načinov. Različne implementacije

posrednikov ponujajo raznovrstne možnosti in pogosto podpirajo tudi vtičnike za

razširljivost, da so lahko prilagodljivi potrebam v posameznih primerih uporabe. V MQTT

je varnost mogoče implementirati na različnih nivojih. Na omrežni plasti je pomembno, da

zagotovimo varno in zaupanja vredno povezavo med posameznimi napravami. To lahko

storimo s pomočjo fizično zavarovanih omrežij in omrežij VPN (Virtual private network).

Na transportni plasti se v večini primerov uporablja TLS za šifriranje. Nudi varen in

preverjen način komunikacije, ne da jo lahko kdo prestreza, ter s pomočjo digitalnih potrdil

ponuja še možnost avtentikacije. Pogosto si na napravah z omejenimi viri ne moremo

privoščiti dodatnih zahtevnosti, ki jih TLS prenaša s seboj. Zavoljo tega protokol na

aplikacijski plasti ponuja avtentikacijo s pomočjo uporabniškega imena in gesla.

V poglavju bomo na kratko opisali posamezne možnosti, ki jih je za doseganje višje

stopnje varnosti možno med sabo tudi kombinirati. Ker je protokol snovan v namene

nezahtevne ter preproste komunikacije in ker vsebuje specifikacija standarda le nekaj

jasno definiranih mehanizmov za zagotavljanje varnosti, se v večini primerov uporabljajo

splošno priznani in uveljavljeni standardi na področju zagotavljanja varnosti komunikacije

[10]. Podobno velja za avtorizacijo, ki je v večini primerov prepuščena implementaciji na

strani posrednika. Pri MQTT se najpogosteje z dostopom omeji tema, na katero se lahko

odjemalci naročijo ali na njo objavljajo [12].

Kot smo že omenili, je najbolj osnovni način avtentikacije, ki je tudi določen v specifikaciji

protokola, avtentikacija z uporabniškim imenom in geslom. Polji sta del paketa CONNECT

in lahko imata maksimalno dolžino 65536 bajtov, pri čemer je uporabniško ime podano z

nizom UTF-8 znakov, geslo pa v binarni obliki. Specifikacija tudi določa, da se lahko

pošlje uporabniško ime brez gesla ter prepoveduje obratno. Posrednik posredovane

podatke v takšnem paketu glede na implementacije ovrednoti in vrne ustrezno statusno

kodo (0 - Connection Accepted, 4 - Connection Refused, bad user name or password ali 5

- Connection Refused, not authorized) [11]. Pogosto se v kombinaciji z uporabniškim

imenom in geslom uporablja še identifikator odjemalca (parameter clientId v paketu


36

CONNECT). Parameter predstavlja unikatni identifikator dolžine do 65555 znakov, v

praksi velikokrat predstavljen z UUID (Universally unique identifier), naslovom MAC

(Media access control) ali serijsko številko naprave.

Na aplikacijski plasti se uporabniško ime in geslo prenaša v golem besedilu, zato je z

varnostnega vidika pomembno, da se na transportni plasti povezava šifrira. Vendar ta

možnost ni vedno na voljo. V tem primeru lahko zvišamo stopnjo varnosti s šifriranjem

sporočila v paketu PUBLISH (ostali metapodatki ostanejo nespremenjeni) ter s šifriranjem

uporabniškega imena in gesla. To omogoča, da lahko občutljive podatke zaščitimo od

pošiljatelja do prejemnika. Posrednik lahko metapodatke uporabi za posredovanje sporočil

do naročenih odjemalcev in zagotavlja kakovost storitve, v nobenem trenutku pa nima

vpogleda v vsebino sporočil. Samo zaupanja vredni odjemalci imajo dostop do ključa, ki

sporočilo dešifrira. Takšna implementacija je neodvisna od posrednika in se pogosto

uporablja v povezavi z javno dostopnimi posredniki, ki jih nimamo pod nadzorom, vendar

pa po drugi strani od nas zahteva popolni nadzor odjemalcev (Slika 3.21). Druga možnost

je, da podatke zaščitimo od odjemalca do posrednika. Omenjen način omogoča, da so

podatki zaščiteni med pošiljateljem in posrednikom, medtem ko končni prejemniki dobijo

dešifrirano sporočilo. Implementacija na ta način zahteva, da ima posrednik možnost

razširitve s pomočjo vtičnika, ki omogoča sprotno dešifriranje podatkov. V obeh primerih

lahko uporabimo simetrični ali asimetrični način šifriranja podatkov. Slednji je primeren,

kadar imamo manjše število zaupanja vrednih naročnikov, ki imajo dostop do privatnega

ključa za dešifriranje podatkov in večje število pošiljateljev, ki imajo dostop do javnega

ključa, s katerim podatke šifrirajo (Slika 3.22).

Slika 3.21: Šifriranje povezave med pošiljateljem in prejemnikom


37

Slika 3.22: Šifriranje povezave med pošiljateljem in posrednikom

S pomočjo šifriranja zagotovimo, da se sporočilo varno prenese do naslovnika in

omogočimo varnost tudi na napravah z manj razpoložljivimi viri. Vendar tudi takšno

šifriranje povzroča večjo obremenitev naprav, zahteva dodatno administracijo z

distribucijo ključev in nas ne obvaruje pred vsemi načini prestrezanj podatkov. Posledično

je priporočljivo, da se uporablja šifriranje prenosa s pomočjo TLS, ki varnost zagotavlja na

omrežni plasti, vedno, ko je to mogoče. In ker šifriranje podatkov poteka na aplikacijski

plasti, lahko varnost dodatno povečamo s skupno uporabo obeh mehanizmov [13].

Ugotovili smo, da lahko s pomočjo TLS zagotovimo varno povezavo med odjemalci in

posrednikom, ki je ni mogoče prestreči ali ji spremeniti vsebine. Standard za ta namen

specificira vrata 8883 in takšno povezavo imenuje secure-mqtt. S pomočjo validacije

strežniškega digitalnega potrdila dobimo možnost preverjanja identitete posrednika. Če

digitalna potrdila uporabimo tudi na strani odjemalcev, pa to omogoča njihovo

avtentikacijo tudi na aplikacijskem sloju. Omenjena dejstva zagotavljajo zelo visok nivo

varnosti, vendar vseh zaradi zahtevnega procesa varne distribucije in upravljanja

digitalnih potrdil (vključno s preklicem neveljavnih potrdil s pomočjo CRL ali OCSP) ni


38

mogoče uporabiti v vsakem okolju. Zlasti kadar imamo veliko količino odjemalcev, ali je

človeška interakcija z njimi težavna, če že ne nemogoča [15].

Varnost, ki jo TLS prenaša, ima tudi negativne vplive. Šifriranje poveča uporabo

procesorske moči in poveča količino podatkov, ki se po povezavi prenašajo. Medtem ko

za večino posrednikov to ne predstavlja težave, je to lahko pri marsikaterem odjemalcu

problem, saj ti pogosto niso prilagojeni za zahtevne računske naloge. Ker se največja

količina podatkov pri TLS izmenja pri vzpostavitvi povezave, posledice slednjega

problema zmanjšamo tako, da uporabimo čim dlje aktivne povezave TCP. Če dani primer

uporabe to ne omogoča, je priporočljivo, da se uporabi tehnika, imenovana nadaljevanje

seje (angl. session resumption), ki ponovno uporabi že vzpostavljeno sejo TLS, da

ponovno rokovanje za vzpostavitev povezave med danim odjemalcem in posrednikom ni

potrebno. Omenjene tehnike na žalost ne vsebujejo vse knjižnice.

Da bo povezava preko TLS tudi dejansko varna, je priporočljivo, da se uporablja čim višja

verzija protokola, se izbere varen nabor algoritmov, se veriga certifikatov vedno validira in

se ne uporablja lastno podpisanih certifikatov, ampak se uporabljajo certifikati, izdani s

strani zaupanja vrednih agencij. Prav tako je protokol priporočljivo uporabljati skupaj z

ostalimi omenjenimi mehanizmi (šifriranje sporočila, validacija podpisa sporočila,

avtentikacija z uporabniškim imenom in geslom) [14].

Kadar se zaradi omejenih virov vendarle odločimo za avtentikacijo s pomočjo šifriranja,

lahko integriteto podatkov zagotovimo s pomočjo digitalnega podpisa sporočila, ki ga

pripnemo pred ali za tovor v paketu PUBLISH. S tem zagotovimo, da vsebina sporočila ni

mogoče spremenjena s strani tretje osebe. Mnogokrat v MQTT za to uporabimo tovor in

temo in se izogibamo identifikatorju sporočila ali nivoju kakovosti storitve, saj se

parametra lahko med prenosom od pošiljatelja do prejemnika spremenita. Pogosto

uporabljeni mehanizmi so v te namene zgoščevalni algoritmi (MD5, SHA1, SHA2,

SHA256 ..), algoritmi za preverjanje pristnosti sporočil (MAC, npr. HMAC, CBC-MAC …)

in digitalni podpis (16). Vsi imajo svoje posebnosti in lastnosti, ki so prikazane v tabeli 3.1.

Tabela 3.1: Prednosti in lastnosti posameznih mehanizmov za podpisovanje sporočila [16]

Kontrolna vsota MAC Digitalni podpis

Integriteta podatkov + + +

Avtentikacija - + +


39

Nezatajljivost - - +

Hitrost Visoka Srednja Nizka

Varnost Nizka Srednja Visoka

Kompleksnost Nizka Srednja Visoka

Ključ - Simitrični Asimiterični

Pojasnimo še pomen zgornjih lastnosti. Integriteta podatkov zagotavlja, da je lahko

prejemnik prepričan, da vsebina ni bila spremenjena. Avtentikacija prejemniku zagotavlja,

da lahko zaupa izvoru sporočila. Nezatajljivost zagotavlja, da lahko samo pošiljatelj

podpiše sporočilo, saj ima edino dostop do privatnega ključa. Ostali lahko podpisa s

pomočjo javnega ključa samo preverijo.

Omeniti velja še avtentikacijo s pomočjo OAuth 2.0, ki jo je prav tako mogoče uporabiti za

varno avtentikacijo odjemalcev. V osnovi je avtorizacija namenjena protokolu HTTP,

vendar se v določenih primerih lahko uporaba aplicira tudi na MQTT. Eden takšnih

primerov je prikazan na sliki 3.23.

Slika 3.23: Tok komunikacije MQTT pri avtorizaciji OAuth 2.0

V poglavju smo na kratko predstavili, kako zagotoviti varnost na ravni protokola, ki le malo

koristi, če ne zagotovimo ustrezne varnosti tudi na ostalih nivojih. Na nivoju infrastrukture

se v prvi vrsti zaščitimo s pomočjo požarnega zidu. Na nivoju operacijskega sistema je

pomembno, da redno posodabljamo tako operacijski sistem kakor tudi programsko


40

opremo in knjižnice, ki so na njem nameščene. Še posebej knjižnice, katere

implementirajo šifrirne algoritme, ki jih uporabljamo pri samem protokolu. Podobno

moramo zaščititi tudi posrednika, tako da omejimo hitrost, s katero lahko posamezen

odjemalec pošilja podatke do posrednika, ter tako, da dodatno zmanjšamo maksimalno

velikost posameznega sporočila, če nam to posamezen scenarij omogoča. Tako lahko

preprečimo preobremenjenost in zagotovimo nemoteno in hitro delovanje.


41

3.2 Izdelava centralnega strežnika

3.2.1 Predstavitev platforme in uporabljenih tehnologij

Centralni strežnik, na katerem bo tekel posrednik MQTT in bo zbiral podatke za kasnejšo

analizo, bo poganjala platforma Raspberry Pi. Sestavljena je iz strojne opreme v velikosti

kreditne kartice in operacijskega sistema Raspbian. Idejo o platformi je leta 2006

predstavil Eben Upton, ki je takrat delal v računalniškem laboratoriju na Univerzi v

Cambridgu. Namen je bil izdelati cenovno ugodno platformo, ki se da preprosto

programirati. Na takšen način se bi študentom omogočilo pobližje spoznati inženirstvo in

matematiko. Zaradi dostopnosti in cene je platforma postala hitro popularna tudi pri drugih

hobiistih po svetu. Skupaj s sodelavci so izdelali prototip in maja 2009 ustanovili fundacijo

Raspberry Pi Foundation. Prve primerke računalnika so uspešno lansirali na trg aprila

2012. Na začetku so ponujali dva različna modela, A in B. Model A je bil cenejši in ni

vseboval mrežnega adapterja, imel je le en priključek USB in samo 256 MB pomnilnika.

Nizko ceno so lahko dosegli predvsem zaradi napredka tehnologije integriranih vezij.

Namesto ločenega centralnega procesorja, grafičnega procesorja, pomnilnika in

kontrolerja USB so uporabili SOC, ki vse te komponente združuje na enem samem čipu

[38]. Računalnik je bil prodan v 8 milijonov izvodih. Zaradi velikega uspeha so leta 2015

izdali še verzijo 2 in leta 2016 verzijo 3. Izboljšano procesorsko zmogljivost vsake iteracije

računalnika prikazuje slika 3.24, njihove najpomembnejše karakteristike glede na

posamezno generacijo pa povzema tabela 3.2.

Slika 3.24: Povečana procesorska zmogljivosti posamezne generacije Raspberry Pi [39]


42

Tabela 3.2: Najpomembnejše karakteristike posamezne generacije Raspberry Pi

Raspberry Pi Raspberry Pi 2 Raspberry Pi 3

Izid Feb. 2012 Feb. 2015 Feb. 2016

Čip Broadcom

BCM2835

Broadcom

BCM2836

Broadcom

BCM2837

Procesor ARM1176JZF-S ARM Cortex-A7 ARM Cortex-A53

Frekvenca 700MHz 900MHz 1,200MHz

Število jeder 1 4 4

Pomnilnik 512 MB 1 GB 1 GB

Grafična Broadcom

Videocore IV

Broadcom

Videocore IV

Broadcom

Videocore IV

USB vhodi 2 4 4

Povezljivost - - Wifi 802.11n in

Bluetooth 4.1

Priporočen jezik za programiranje je Python. V njem je izdelanih večina uradnih knjižnic in

je uporabljen v večini vodičev. Vendar, ker ga poganja operacijski sistem Linux, se lahko

na njem brez problema uporabljajo tudi vsi ostali moderni jeziki (Java, Php, C/C++,

Node.js in drugi).

Preden lahko računalnik začnemo uporabljati kot centralni strežnik za zbiranje podatkov in

posrednik MQTT, moramo nanj namestiti operacijski sistem, potrebne knjižnice in

odvisnosti ter potrebno programsko opremo za posrednika.

Na voljo imamo več različnih implementacij MQTT posrednikov. Implementirani so v

različnih jezikih in podpirajo različne verzije protokola. Ena popularnejših implementacij je

Eclipse Mosquitto, ki je odprtokodna in podpira verzijo 3.1.1 protokola MQTT. Avtor je

Roger Light, ki je kodo izdal pod licenco EPL/EDL. Je ena prvih implementacij, ki je bila

pripravljena za produkcijo. Napisana je v jeziku C, kar jo naredi zelo hitro in stabilno. V

času nameščanja je bila aktualna verzija 1.4.9 in jo je bilo mogoče namestiti na

popularnejše operacijske sisteme (Windows, Mac OSX, Linux) [40].

3.2.2 Postavitev strežnika

Namestitev in upravljanje strežnika bo potekalo na operacijskem sistemu Ubuntu 16.04.

Preden lahko začnemo s samo namestitvijo, potrebujemo 5 V adapter MicroUSB za


43

napajanje in MicroSD spominsko kartico velikosti vsaj 8 GB, kamor bomo namestili

operacijski sistem in programe. Ob prvem zagonu sta za osnovno nastavitev in nastavitev

mrežnih podatkov priporočljiva tudi tipkovnica in monitor s priključkom HDMI. Ker ima

Raspberry Pi 3 že vgrajen WiFi-modul, moramo le še omogočiti strežnik SSH (Secure

Shell), ki bo omogočal brezžično izvrševanje ukazov in upravljanje s strežnikom.

Preden prvič zaženemo Raspberry Pi, moramo iz uradne spletne strani sneti sliko

operacijskega sistema Raspbian11 in jo s pomočjo našega računalnika zapisati na

MicroSD spominsko kartico. Trenutno aktualna verzija je Raspbian Jessie May 2016,

izdana 27. 5. 2016 z Linux jedrom 4.4. Na voljo imamo dve različici, polno in okrnjeno

(Lite). Prva ima že prednameščeno grafično okolje, razvojna orodja in pisarniške

programe. Za naš primer smo izbrali okrnjeno različico, saj za delovanje centralnega

strežnika omenjenih stvari ne potrebujemo in tako prihranimo na sistemskih virih. Po

uspešnem prenosu se moramo pomakniti v mapo s prenosi, razširiti Zip arhiv in s

pomočjo dd ukaza sliko zapisati na spominsko kartico:

V primeru, da nismo prijavljeni kot root uporabnik, moramo pred ukaz dopisati sudo. V

dodatno pomoč sta tudi spodnja ukaza. Prvi služi za ugotovitev priklopne točke SD-kartice

in drugi za izpis napredka postopka kopiranja:

Ob uspešno izvršenem ukazu sync lahko vzamemo SD-kartico iz bralnika in jo namestimo

v Raspberry Pi. Po priklopu napajanja monitorja in tipkovnice je naprava pripravljena za

prvi zagon, ki bo razširil datotečni sistem na celotno spominsko kartico in prikazal ukazno

vrstico za prijavo z uporabniškim imenom pi in geslom raspberry. Prvi korak po prijavi je

zagon orodja raspi-config, prikazanega na sliki 3.25, s pomočjo katerega bomo spremenili

geslo za prijavo, ime gostitelja, lokalizacijo, časovni pas, razporeditev tipkovnice in

omogočili strežnik SSH:

11 URL-naslov za prenos: https://www.raspberrypi.org/downloads/raspbian/

uporabnik@prenosnik:~$ sudo fdisk -l | grep mmc

uporabnik@prenosnik:~$ sudo pkill -USR1 -n -x dd

uporabnik@prenosnik:~$ cd Downloads/

uporabnik@prenosnik:~/Downloads$ unzip 2016-05-27-raspbian-jessie-lite.zip

uporabnik@prenosnik:~/Downloads$ sudo dd bs=4M if=2016-05-27-raspbian-jessie-lite.img

of=/dev/mmcblk0

uporabnik@prenosnik:~/Downloads$ sudo sync


44

Slika 3.25: Orodje za osnovno kofiguracijo Raspberry Pi

Preden bomo lahko s strežnikom upravljali brezžično, moramo nastaviti brezžično

povezavo in avtorizacijo za SSH. Brezžične nastavitve se nahajajo v datoteki

/etc/wpa_supplicant/wpa_supplicant.conf, ki jo uredimo tako, da ji dodamo podatke o

brezžičnem omrežju, na katerega se želimo povezati, kar storimo z ukazom:

Podatke za povezavo na brezžično omrežje zapišemo v obliki:

Ko zaključimo z urejanjem, s kombinacijo tipk Ctrl+O zapišemo spremembe in s

kombinacijo Ctrl+X zapremo program za urejanje. Operacijski sistem spremembo

datoteke samodejno zazna in vzpostavi povezavo. V primeru, da se to ne zgodi, lahko s

spodnjimi ukazi sami vzpostavimo povezavo, preverimo stanje in vidimo pridobljen IP-

naslov (Internet Protocol):

network={

ssid="ime_omrežja"

psk="geslo_omrežja"

# RSN za WPA2; WPA za WPA1

proto=WPA

key_mgmt=WPA-PSK

# CCMP ali TKIP za (WPA2 ali WPA1)

pairwise=TKIP

}

pi@RPiServer3:~$ sudo nano /etc/wpa_supplicant/wpa_supplicant.conf

pi@RPiServer3:~$ sudo raspi-config


45

Dodatno si pri vzpostavitvi brezžične povezave lahko pomagamo s spodnjim ukazom, ki

izpiše vsa omrežja, ki so na voljo skupaj z imenom in možnimi protokoli za avtorizacijo:

Z ukazom ifconfig smo ugotovili IP-naslov, ki je bil dodeljen našemu strežniku (v našem

primeru 192.168.1.74), na katerega se sedaj že lahko preko SSH povežemo z ukazom:

Mrežna konfiguracija je odvisna od usmerjevalnika. V našem primeru se IP dodeli

dinamično. Da se bomo lažje povezovali na strežnik, smo na usmerjevalniku rezervirali IP-

naslov, tako da mu bo vedno dodeljen enak. Da se bomo do njega lahko povezali tudi

izven lokalnega omrežja, smo morali nastaviti tudi posredovanje vrat za dostop do

strežnika SSH (2222), strežnika HTTP (8888) in posrednika MQTT (8883) ter poskrbeti za

večjo varnost tako da sejo SSH avtoriziramo z javnim in privatnim ključem. Najprej s

pomočjo spodnjih ukazov naredimo nove unikatne ključe:

V naslednjem koraku moramo generirati javni in privatni ključ za avtentikacijo uporabnika.

Če ključe že imamo, lahko ta korak preskočimo in uporabimo obstoječe, v nasprotnem

primeru pa zaženemo sledeči ukaz:

Preko interaktivne ukazne vrstice nas bo orodje vprašalo po lokaciji, kamor želimo

generiran par ključev shraniti in po geslu, s katerim lahko ključa dodatno zaščitimo (če

gesla ne vnesemo, to pomeni, da ključa nista dodatno zaščitena). Privzeta lokacija za

zapis ključev je v mapi ~/.ssh. Ukaz ustvari dve datoteki z imenom id_rsa in id_rsa.pub.

Slednji predstavlja javni ključ, ki ga moramo skopirati na strežnik, do katerega se želimo

povezati. Preden lahko javni ključ prenesemo na strežnik, moramo tudi na strežniku s

pomočjo ukaza ustvariti mapo ~/.ssh:

uporabnik@prenosnik:~$ ssh-keygen -t rsa -C uporabnik@host

pi@RPiServer3:~$ sudo rm /etc/ssh/ssh_host_*

pi@RPiServer3:~$ sudo dpkg-reconfigure openssh-server

uporabnik@prenosnik:~$ ssh [email protected]

pi@RPiServer3:~$ sudo iwlist wlan0 scan

pi@RPiServer3:~$ sudo ifdown wlan0

pi@RPiServer3:~$ sudo ifup wlan0

pi@RPiServer3:~$ sudo ifconfig wlan0


46

Javni ključ prenesemo na strežnik z ukazom:

Preden se bo ukaz izvršil, bo za povezavo potrebno ponovno vnesti geslo. Ob uspešnem

zaključku pa se lahko do strežnika prijavimo brez vnosa gesla. Da bo takšna prijava tudi

bolj varna, moramo onemogočiti prijavo z geslom. Skupaj s tem bomo spremeniti tudi

vrata, na katerih teče strežnik SSH, iz privzetih 22 na 2222. Pot do konfiguracijske

datoteke je /etc/ssh/sshd_config. Uredimo jo z ukazom:

V datoteki moramo najti vrstico z besedilom 'Port 22' in jo spremeniti v 'Port 2222' ter

vrstico '#PasswordAuthentication yes' spremeniti v 'PasswordAuthentication no'. S

kombinacijo tipk Ctrl+O in Ctrl+X datoteko shranimo in zapustimo urejevalnik. Da bodo

spremembe stopile v veljavo, moramo ponovno zagnati strežnik SSH z ukazom:

Zadnji korak pri namestitvi sistema je posodobitev vseh knjižnic na najnovejšo verzijo, s

čimer zagotovimo večjo varnost, stabilnost, funkcionalnost in tudi najnovejše gonilnike:

Preden zaključimo z osnovno namestitvijo ter odklopimo monitor in tipkovnico, je dobro,

da ga ponovno zaženemo in se prepričamo, da se lahko do njega uspešno povežemo

pi@RPiServer3:~$ sudo apt-get update

pi@RPiServer3:~$ sudo apt-get upgrade

pi@RPiServer3:~$ sudo service ssh restart

pi@RPiServer3:~$ sudo nano /etc/ssh/sshd_config

uporabnik@prenosnik:~$ cat ~/.ssh/id_rsa.pub | ssh [email protected] 'cat >> .ssh/authorized_keys'

pi@RPiServer3:~$ cd ~

pi@RPiServer3:~$ install -d -m 700 ~/.ssh


47

3.2.3 Opis rešitve

Slika 3.26 prikazuje komponente naše rešitve in njihovo medsebojno komunikacijo.

Slika 3.26: Konfiguracijska shema centralnega strežnika in senzorjev

V prvem koraku smo na strežnik namestili MQTT posrednika Mosquitto. Najnovejšo

verzijo si lahko za izbran operacijske sisteme prenesemo iz uradnje spletne strani12.

Repozitorij za Raspberry Pi že vsebuje potrebnega posrednika, vendar je ta starejše

verzije (1.3.4). Da lahko na preprosti način namestimo najnovejšo vezijo, je za vse na

Debian bazirane distribucije na voljo poseben repozitorij. Za namestitev moramo najprej

namestiti ključ za podpisovanje, repozitorij dodati med vire in namestiti program.

Omenjeno izvedemo z naslednjim zaporedjem ukazov:

12 URL-naslova za prenos Mosquitto: https://mosquitto.org/download/


48

Dodatno smo namestili paketa mosquitto-clients in posredno preko pip tudi paho-mqtt.

Prvi namesti odjemalce, ki bodo služili za testiranje in debugiranje, drugi pa omogoča

odjemalca za programski jezik Python, v katerem bomo v naslednjem koraku izdelali

lokalnega odjemalca MQTT, ki bo prejete podatke senzorjev shranjeval v bazo za kasnejši

pregled in s pomočjo njihove analize preko izhodnega vtiča izklapljal ali vklapljal

ogrevanje.

Kot je za Debian distribucije značilno, je posrednik MQTT po namestitvi zagnan. Če ga

želimo konfigurirati, ga moramo najprej ustaviti, spremeniti konfiguracijsko datoteko

/etc/mosquitto/mosquitto.conf in ga nato ponovno zagnati. Pri tem nam pomaga naslednje

zaporedje ukazov:

Nastavitve smo v tem trenutku obdržali privzete, potrebno je bilo le omogočiti TLS- zaščito

in nastaviti pot do privatnega ključa, da smo tako zaščitili našo povezavo pred tretjimi

osebami. Za dodano pomoč naslednji ukazi vrnejo status posrednika MQTT, izpišejo

pakete, ki so na voljo pri namestitvi, in verzijo paketa, ki se bo namestil:

pi@RPiServer3:~$ sudo service mosquitto status

pi@RPiServer3:~$ sudo apt-cache search mosquitto

pi@RPiServer3:~$ sudo apt-cache policy mosquitto

pi@RPiServer3:~$ sudo service mosquitto stop

pi@RPiServer3:~$ sudo nano /etc/mosquitto/mosquitto.conf

pi@RPiServer3:~$ sudo service mosquitto start

pi@RPiServer3:~$ wget http://repo.mosquitto.org/debian/mosquitto-repo.gpg.key

pi@RPiServer3:~$ sudo apt-key add mosquitto-repo.gpg.key

pi@RPiServer3:~$ cd /etc/apt/sources.list.d/

pi@RPiServer3:~$ sudo wget http://repo.mosquitto.org/debian/mosquitto-jessie.list

pi@RPiServer3:~$ sudi apt-get update

pi@RPiServer3:~$ sudo apt-get install mosquitto mosquitto-clients python-setuptools

pi@RPiServer3:~$ sudo easy_install pip

pi@RPiServer3:~$ sudo pip install paho-mqtt


49

Preden namestitev posrednika zaključimo, bomo s pomočjo naslednjih ukazov preverili

delovanje nameščenega posrednika. Ukaza bomo najprej zagnali na strežniku lokalno in

potem še na lastnem računalniku. Prvi ukaz se prijavi na temo hello/world, drugi na to

temo pošlje sporočilo 'Hello Test!'. Če se ukaza uspešno izvedeta in v ukazni vrstici

zasledimo spodnji obvestili, je test uspel in posrednik MQTT je pripravljen.

V drugem koraku smo v programskem jeziku Python izdelali lokalnega odjemalca MQTT,

ki podatke iz senzorjev analizira, ter v primeru, da zazna potrebo po energiji v prostoru,

preko digitalnih izgodov in releja, vklopi/izklopi ogrevanje.

Dodatno bo odjemalec pridobljene podatke shranil v bazo, kjer bodo na voljo za kasnejšo

statistiko v spletni ali mobilni aplikaciji. Podatke bomo shranjevali v MySQL podatkovni

bazi. Trenutno aktualna verzija v Raspbian repozitoriju je 5.5.50, ki jo bomo skupaj z

odjemalcem MySQL namestili z ukazom:

Pri namestitvi podatkovnega strežnika smo izbrali geslo za uporabnika root in dodatno

namestili python-mysqldb, ki omogoča delo s podatkovno bazo MySQL v programskem

jeziku Python. S pomočjo orodja MySQL smo ustvarili novo podatkovno bazo

pi@RPiServer3:~$ sudo apt-get install mysql-server

pi@RPiServer3:~$ sudo apt-get install mysql-client python-mysqldb

pi@RPiServer3:~$ mosquitto_sub -d -t hello/world

Client mosqsub/30701-RPiServer sending CONNECT

Client mosqsub/30701-RPiServer received CONNACK

Client mosqsub/30701-RPiServer sending SUBSCRIBE (Mid: 1, Topic: hello/world, QoS: 0)

Client mosqsub/30701-RPiServer received SUBACK

Subscribed (mid: 1): 0

Client mosqsub/30701-RPiServer received PUBLISH (d0, q0, r0, m0, 'hello/world', ... (11 bytes))

Hello Test!

pi@RPiServer3:~$ mosquitto_pub -d -t hello/world -m "Hello Test!"

Client mosqpub/30702-RPiServer sending CONNECT

Client mosqpub/30702-RPiServer received CONNACK

Client mosqpub/30702-RPiServer sending PUBLISH (d0, q0, r0, m1, 'hello/world', ... (11 bytes))

Client mosqpub/30702-RPiServer sending DISCONNECT


50

'heating_data' in uporabnika 'heating_monitor' ter mu dodelili pravice za dostop do nove

baze. Na koncu smo s pomočjo ukaza ustvarili tabele, kot jih prikazuje slika 3.27.

pi@RPiServer3:~$ mysql -u root -p

Enter password:

mysql> CREATE DATABASE heating_data;

Query OK, 1 row affected (0.00 sec)

mysql> USE heating_data;

Database changed

mysql> CREATE USER 'heating_monitor'@'localhost' IDENTIFIED BY '[password]';

Query OK, 0 rows affected (0.00 sec)

mysql> GRANT ALL PRIVILEGES ON heating_data.* TO 'heating_monitor'@'localhost';


mysql> FLUSH PRIVILEGES;


mysql> quit

Bye

pi@RPiServer3:~$ mysql -u heating_monitor -p

Enter password:

mysql> USE heating_data;

Database changed

mysql> CREATE TABLE rooms (roomid int(11), …);


mysql> CREATE TABLE sensors (sensorid int(11), …);


mysql> CREATE TABLE readings (readingid int(11), …);


mysql> CREATE TABLE settings (settingsid int(11), …);


mysql> CREATE TABLE boiler_activity (boileractivityid int(11), …);


mysql> quit

Bye


51

Slika 3.27: ER model podatkovne baze

Program se začne z uvozom knjižnic, ki jih bomo uporabili, in deklariranjem osnovnih

nastavitev, kot so naslov MQTT posrednika, ime, vrata in interval pošiljanja signala PING:


52

Nato moramo inicializirati odjemalca MQTT in se do njega povezati. Odjemalec deluje

tako, da preko dogodkov proži povratne klice, ki smo jih ob inicializaciji nastavili:

Dogodki, na katere smo se prijavili, so naslednji:

1. on_connect(client, userdata, flags, rc): Dogodek se proži ob uspešni povezavi na

posrednika. Na tem mestu se bomo prijavili na teme, ki nas zanimajo, in tako tudi

po ponovni vzpostavitvi povezave poskrbeli, da smo na njih prijavljeni;

2. on_message(client, userdata, msg): Se proži, ko se na katero izmed prijavljenih

tem pošlje sporočilo. Ob prožitvi kličemo funkcijo obdelaj_sporocilo(msg), ki na

podlagi teme ugotovi, za kakšen podatek gre in ga obdela (zabeleži v bazo,

analizira);

# povezava do posrednika

mqtt_odjemalec = mqtt.Client(client_id=MQTT_CLIENT_ID)

mqtt_odjemalec.on_connect = on_connect

mqtt_odjemalec.on_disconnect = on_disconnect

mqtt_odjemalec.on_message = on_message

mqtt_odjemalec.on_subscribe = on_subscribe

mqtt_odjemalec.on_publish = on_publish

mqtt_odjemalec.connect(MQTT_HOST, MQTT_PORT, MQTT_PING_KEEPALIVE)

# blokiran klic, ki skrbi za povezavo in povratne klice

mqtt_odjemalec.loop_forever()

#!/usr/bin/python

import sys

import getopt

import time

import signal

import json

import RPi.GPIO as GPIO

import paho.mqtt.client as mqtt

import MySQLdb

# MQTT podatki

MQTT_CLIENT_ID = 'temperature_monitor'

MQTT_HOST = '192.168.1.74'

MQTT_PORT = 1883

MQTT_PING_KEEPALIVE = 60


53

3. on_subscribe(client, userdata, mid, gqos): Dogodek se proži ob naročilu na teme.

V funkciji zabeležimo uspešno ali neuspešno prijavo;

4. on_publish(client, userdata, mid): Ta funkcija se proži, kadar se uspešno pošlje

sporočilo do posrednika in ta potrdi, da je bilo sporočilo uspešno sprejeto;

5. on_disconnect(client, userdata, rc): Funkcija se proži ob prekinitvi povezave do

posrednika. V tej funkciji zabeležimo prekinitev in se v primeru nepredvidene

prekinitve poskušamo periodično ponovno povezati. V primeru namerne prekinitve

za sabo počistimo uporabljene vire in zaključimo izvajanje programa.

Za komunikacijo s posrednikom sta pomembni še funkciji publish(topic, payload=None,

qos=0, retain=False) in subscribe(topic, qos=0). Funkcija subscribe nas prijavi na temo in

funkcija publish na posredovano temo objavi podatek. Spodnja koda prikazuje, kako smo

ju uporabili v našem programu:

Glavno obnašanje lokalnega odjemalca MQTT se nahaja v funkciji on_message, ki se

proži op prejemu sporočila. Sporočilo posredujemo do funkcije obdelaj_sporocilo(msg), ki

ga obdela tako, da s pomočjo teme ugotovi pomen podatka, ga po potrebi zabeleži v bazi

in nanj ustrezno odreagira. Obnašanje funkcije ponazarja naslednji psevdokod:

# objava nastavitev temperatur prostorov

(mr, mid) = mqtt_odjemalec.publish(room.set_temperature_topic, room.value, 0, True)

if mr != mqtt.MQTT_ERR_SUCCESS:

raise Exception('MQTT napaka (' + str(mr) + ', ' + str(mid) + ') za ' + room.set_temperature_topic)

else:

print 'Objavljeno sporocilo(#' + str(mid) + ') ' + room.value + ' na temo ' +

room.set_temperature_topic

# prijava na teme Home in Devices - znak # nas prijavi tudi na vse podteme

odjemalec.subscribe([("Home/#", 1), ("Devices/#", 1)])


54

Na koncu smo v datoteko /etc/rc.local dodali ukaz za zagon programa in tako poskrbeli,

da se ob zaključku procesa zagona sistema zažene tudi lokalni odjemalec:

Dodajanje, pregled in urejanje senzorjev poteka s pomočjo nadzorne plošče, ki smo jo v

programskem jeziku PHP izdelali v tretjem koraku. Ta je preko Apache spletnega

strežnika dosegljiva na centralnem strežniku preko naslova

https://192.168.1.74/nadzorna_plosca/ in se povezuje na že ustvarjeno lokalno MySQL

podatkovno bazo. Dodatno bo spletna aplikacija omogočala pregled nad stanjem

pi@RPiServer3:~$ sudo nano /etc/rc.local

# zagon lokalnega MQTT odjemalca

printf "Zagon MQTT odjemalca\n"

screen -dmS mqtt_ojemalec python /home/pi/temperature_monitor/main.py

def obdelaj_sporocilo(msg):

if msg.topic == status_senzorja:

update_device_database_info(naprava, status)

if device == boiler and status_changed:

if status == ON:

vklopi_ogravanje()

else:

izklopi_ ogravanje()

elif msg.topic == trenutna_temperatura:


dodaj_meritev_v_bazo(naprava, vrednost)

if potrebna_energija == True:

vklopi_ ogravanje()

else:


elif msg.topic == trenutna_vlaznost:


dodaj_meritev_v_bazo(naprava, vrednost)

elif msg.topic == nastavitev_temperature


if potrebna_energija == True:

vklopi_ ogravanje()

else:


else:

raise Exception('Neprepoznano sporocilo')


55

posameznega senzorja, povezanimi odjemalci in zgodovino meritev. Dostop do aplikacije

pa bo zaščiten z uporabniškim imenom in geslom. Vsi potrebni paketki za gostovanje

aplikacije se že nahajajo v Raspbian repozitoriju, zato je namestitev hitra in preprosta.

Nameščena paketa sta verzije 2.4.10 za Apache strežnik in 5.6.24 za PHP. Namestitev

izvršimo z naslednjimi ukazi ter pri tem namestimu tudi PHP-modul za povezavo s

podatkovno bazo MySQL, modula curl in modul gd.

Izvorno kodo spletne aplikacije smo kopirali v /var/www/html/nadzorna_plosca in v

datoteki config.php ustrezno spremenili podatke za povezavo na lokalno podatkovno

bazo. V nadaljevanju bomo s pomočjo zaslonski slik na kratko predstavili osnovne funkcije

nadzorne plošče.

Slika 3.28: Zaslonska slika prijavnega okna

Na sliki 3.29 je zaslonska slika strani, ki se uporabniku odpre po uspešni prijavi (slika

3.28). Z različnimi barvami so označeni posamezni deli strani:

1. Rdeče: Avatar in ime trenutno prijavljenega uporabnika.

2. Oranžno: Glavni navigacijski meni (Domov, Odjemalci, Nastavitve in Statistika).

3. Modro: Trenutno nastavljene temperature prostorov in stanje kotla (aktiven,

neaktiven).

pi@RPiServer3:~$ sudo apt-get install apache2

pi@RPiServer3:~$ sudo apt-get install php5 libapache2-mod-php5

pi@RPiServer3:~$ sudo apt-get install php5-mysql php5-curl php5-gd


56

4. Zelena: Seznam prostorov z možnostjo brisanja in dodajanja novega. Ikona levo

od prostora prikazuje, ali so senzorji v prostoru uspešno povezani.

5. Vijoličasta: Glavna vsebina strani z naslovom trenutno izbrane strani na vrhu,

drobtinami pod naslovom in desno od drobtin možne akcijske elemente. V tem

primeru glavna vsebina prikazuje tabelo senzorjev s kolonami: ikona stanja

senzorja (povezan, nepovezan), ime, prostor, ip naslov, datum zadnje aktivnosti,

vrednosti in akcije (uredi, izbriši in prikaži). Skcijski element je dodajanje novega

senzorja.

6. Rumeno: Meni z akcijami za odjavo in nastavitve.

Slika 3.29: Zaslonska slika privzete strani nadzorne plošče z označenimi elementi

Poleg senzorjev nadzorna plošča nudi tudi pregled vseh odjemalcev, ki so se na strežnik

kadar koli povezali. Ob prvi prijavi se ti zapišejo v bazo, kjer jih lahko kasneje v nadzorni

plošči urejamo ali odstranimo. Unikatni identifikator je MAC-naslov naprave. Zraven

podatkov o napravi tabela na sliki 3.30 prikazuje tudi trenutno povezane naprave.


57

Slika 3.30: Zaslonska slika seznama odjemalcev

Tretja izbira v meniju omogoča pregled in spreminjanje nastavitev. Te zajemajo nastavitev

željenih temperatur in prijavne podatke. Vmesnik prikazuje slika 3.31.

Slika 3.31: Zaslonska slika spreminjanja nastavitev


58

Med pomembnejše funkcionalnosti spada pregled izmerjenih podatkov posameznega

senzorja. Za izris grafa lahko izberemo čas, med katerim nas podatki zanimajo, senzor in

podatek. Primer takšnega grafa prikazuje slika 3.32.

Slika 3.32: Zaslonska slika prikaza statistike

Četrti in s tem zadnji korak pri izdelavi centralnega strežnika je bil razvoj programskega

vmesnika, preko katerega mobilna aplikacija pridobi podatke o trenutnih nastavitvah,

prostorih, senzorjih in zgodovini meritev. Komunikacija poteka preko URL-naslova

https://192.168.1.74/api/, kjer se v zahtevku pošljejo argumenti za klic posamezne funkcije

v obliki JSON-, v kateri se vrne tudi odgovor strežnika. Glavne funkcije in oblike zahtevkov

in odgovorov so zajete v tabeli 3.3.

Tabela 3.3: Opis metod programskega vmesnika

Metoda VrniNastavitve

Vrne trenutne nastavitve temperature po prostorih in morebitne druge nastavitve.

Zahtevek Odgovor Statusne kode

- {

'nast_temp': [{

'prostor': [int],

'vrednost': [string]

},…],

202 – OK

801 – Napaka strežnika


59

}

Metoda VrniProstore

Vrne vse prostore skupaj z nastavljenimi željenimi temperaturami.


- {

'prostorid': [int],

'ima': [string],

'opis': [string],

'tema_nast_temp': [string]

}

203 – OK


Metoda VrniSenzorje

Vrne seznam senzorjev temperature skupaj z opisnimi podatki.


{

'senzorid': [int],

'prostor': [int],

'tema_temp': [string],

'tema_vlaznost': [string],

'tema_status': [string],

'zadnja_akt': [string(datum)]

}

204 – OK


Metoda VrniMeritve

Vrne podatke o izbranih meritvah za izbrani senzor med posredovanim intervalom.


{

'senzor': [int],

'meritev': [int],

'od': [string(datum)],

'do': [string(datum)]

}

{

'enota': [string],

'podatki': [{

'datum': [string(datum)],

'vrednost': [string]

},…]

}

205 – OK


802 – Napačni argumenti

803 – Neveljaven senzor

804 – Neveljaven tip

805 – Neveljaven datum


60

Tabela 3.4: Seznam MQTT tem

Tema Pomen

Naprava/DHT_Senzor_Dnevna/status Status senzorja temperature v dnevni sobi.

Naprava/DHT_Senzor_Kuhinja/status Status senzorja temperature v kuhinji.

Naprava/DHT_Senzor_Spalnica/status Status senzorja temperature v spalnici.

Naprava/DHT_Senzor_Kopalnica/status Status senzorja temperature v kopalnici.

Naprava/Lokalni_Odjemalec/status Status lokalnega odjemalca.

Dom/DnevnaSoba/tren_temperatura Trenutno izmerjena temperatura v dnevni.

Dom/DnevnaSoba/tren_vlaznost Trenutno izmerjena vlažnost v dnevni.

Dom/DnevnaSoba/nast_temperatura Nastavljena temperatura v dnevni.

Dom/Kuhinja/tren_temperatura Trenutno izmerjena temperatura v kuhinji.

Dom/Kuhinja/tren_vlaznost Trenutno izmerjena vlažnost v kuhinji.

Dom/Kuhinja/nast_temperatura Nastavljena temperatura v kuhinji.

Dom/Spalnica/tren_temperatura Trenutno izmerjena temperatura v spalnici.

Dom/Spalnica/tren_vlaznost Trenutno izmerjena vlažnost v spalnici.

Dom/Spalnica/nast_temperatura Nastavljena temperatura v spalnici.

Dom/Kopalnica/tren_temperatura Trenutno izmerjena temperatura v kopalnici.

Dom/Kopalnica/tren_vlaznost Trenutno izmerjena vlažnost v kopalnici.

Dom/Kopalnica/nast_temperatura Nastavljena temperatura v kopalnici.


61

3.3 Izdelava mobilne aplikacije

3.3.1 Predstavitev operacijskega sistema

Mobilna aplikacija, ki jo bomo uporabili za komunikacijo s senzorji, je izdelana za

operacijski sistem Android. Na svetu je trenutno 1.4 milijarde Android uporabnikov in ima

s 53.3 % največji delež na globalnem trgu [41]. Največja zbirka aplikacij je na voljo na

Google Play in zajema več kot 2 milijona aplikacij [42]. Razvoj operacijskega sistema se je

začel v podjetju Android, Inc., ki ga je leta 2005 kupil Google. Prvič je bil predstavljen

novembra 2007, skupaj z ustanovitvijo Open Handset Alliance – konzorcij 84 podjetij s

področja programske in strojne opreme ter telekomunikacijskih storitev. Z izidom verzije

1.5, imenovane Cupcake v aprilu 2009, se je nakazal hiter razoj, ki je skoraj vsake pol leta

prinesel novo verzijo operacijskega sistema. Kot zanimivost so vse verzije do sedaj

poimenovane po sladicah. Trenutno aktualna verzija 6.0 je bila izdana oktobra 2015 in se

imenuje Marshmallow. Operacijski sistem temelji na Linux-u in je dostopen preko

razvijalcu prijazne odprtokodne licence. To omogoča različnim proizvajalec mobilnih

naprav izdelavo in prilagoditev sistema svojim potrebam, kar s sabo prinaša raznolikost

obenem pa povzroča fragmentacijo sistema, počasne posodobitve in vejo podvrženost

ranljivostim. Na trgu trenutno obstaja več kot 4000 različnih naprav, od telefonov in tablic,

vse do avtomobilov in pametnih ur, ki jih poganja Android operacijski sistem [41].

Programski paket je sestavljen iz Linux jedra, knjižnic in programskih vmesnikov,

napisanih v C, ter programskega okvirja, ki je kompatibilen z Java knjižnicami, temelječimi

na Apache Harmony. Razvijalci lahko aplikacije pišejo v programskem jeziku Java, ki jih

poganja Delvik v virtualnem stroju.

3.3.2 Razvojno okolje

Do pred kratkim so se Android aplikacije razvijale v Eclipse razvojnem okolju s pomočjo

namestitve ADT (Android Developer Tools) vtičnika in Android SDK (Software

development kit). Junija 2015 je Google oznanil, da končuje razvoj in podporo za vtičnik

ter izbral Android Studio kot uradno razvojno okolje [46]. S to odločitvijo so pospešili

razvoj okolja in Android Studio je dobil številne nove funkcionalnosti, kot so takojšen

zagon, bolj inteligenten urejevalnik kode, bogatejši in hitrejši emulator naprav, integracijo z

Google oblačnimi storitvami ter druge pomembe izboljšave. Snovan na IntelliJ IDEA, za

delovanje zahteva JDK (Java Development Kit) 8 in operacijski sistem Windows, Linux ali

Mac. Aktualna verzija v času pisanja je 2.1.2, izdana junija 2016. Namestitveni paket, ki


62

se ga sname na uradni spletni strani13, že vsebuje vse potrebne komponente (razvojno

okolje IntelliJ IDEA, Android Studio vtičnik, Android SDK, Android platformo in Android

Emulator s sistemskimi slikami, ki vključujejo Google Play Services) [47]. Namestitev na

operacijskem sistemu Ubuntu je zelo preprosta:

1. S spodnjim ukazom preverimo verzijo namestitve JDK. Če le-ta ni nameščena, ali

je nižja od verzije 1.8, moramo na računalnik prenesti in namestiti verzijo JDK 8:

2. Če imamo 64-bitni sistem, z ukazom namestimo zahtevane 32-bitne knjižnice:

3. Z uradne spletne strani prenesemo aktualno verzijo orodja:

4. Prenesen arhiv s spodnjim ukazom premaknemo na lokacijo, kjer želimo orodje

namestiti, in ga razširimo:

5. Opcijsko lahko dodamo pot do mape bin ob zagonu sistema k spremenljivki PATH,

da bomo lahko orodje zagnali v vseh mapah sistema:

6. Pomaknemo se v mapo bin in zaženemo program:

7. V odprtem oknu potrdimo, ali želimo uvoziti nastavitve ali ne ter s tem odpremo

čarovnika, ki nas vozi skozi namestitev, ki je lahko standardna ali po meri.

Izbiramo lahko med temo razvojnega okolja, lokacijo namestitve Android SDK in

platformami, ki jih želimo namestiti.

13 Uradnja spletna stran orodja Android Studio: https://developer.android.com/studio

uporabnik@prenosnik:/opt$ cd android-studio/bin

uporabnik@prenosnik:/opt/android-studio/bin$ sudo ./studio.sh

uporabnik@prenosnik:~$ echo -e "\n# Android Studio\nexport PATH=\$PATH:/opt/android-

studio/bin" >> .bashrc

uporabnik@prenosnik:~/Downloads$ sudo mv android-studio-ide-143.2915827-linux.zip

/opt

uporabnik@prenosnik:~/Downloads$ cd /opt

uporabnik@prenosnik:/opt$ sudo unzip android-studio-ide-143.2915827-linux.zip

uporabnik@prenosnik:~/Downloads$ wget https://dl.google.com/dl/android/studio/ide-

zips/2.1.2.0/android-studio-ide-143.2915827-linux.zip

uporabnik@prenosnik:~$ sudo apt-get install lib32z1 lib32ncurses5 lib32bz2-1.0

lib32stdc++6

uporabnik@prenosnik:~$ javac 1.8.0_91


63

Po zaključku čarovnika se prikaže grafični vmesnik, kot ga prikazuje slika 3.33. Označeni

elementi na sliki so:

1. Orodna vrstica (modro).

2. Navigacijska vrstica (rdeče).

3. Orodna okna (zeleno).

4. Okno urejevalnika kode (rumeno).

5. Statusna vrstica (vijoličasto).

Slika 3.33: Grafični vmesnik razvojnega okolja Android Studio

Preden smo lahko začeli s programiranjem, smo morali s pomočjo čarovnika ustvariti nov

projekt, kjer smo izbrali ime aplikacije, ime paketa, lokacijo, platformo (v našem primeru

za telefone in tablice), minimalno verzijo Android SDK ter predlogo začetne kode. Po

končanem postoku je bilo okolje pripravljeno za razvoj aplikacije, ki je opisan v naslednjih

dveh podpoglavjih.


64

3.3.3 Razvoj grafičnega vmesnika

Uporabniški vmesnik mobilne aplikacije je zelo preprost, pregleden in intuitiven. Slika 3.34

prikazuje vstopno stran aplikacije. V modrem kvadratu je prikazana nastavljena

temperatura prostora. Nad vrednostjo temperature je indikator statusa povezave mobilne

aplikacije do posrednika MQTT, ki v zeleni barvi ponazarja vzpostavljeno povezavo in v

rdeči prekinjeno. Pod vrednostjo je prikazana trenutna izbira, za katero se vrednost

nastavlja. Izbira se lahko med katerimkoli prostorom s seznama. V primeru, da prostor na

seznamu ni izbran, se vrednost nastavlja za vse prostore hkrati. S klikom na segment se

odpre dialog, prikazan na sliki 3.35. Ta omogoča izbiro željene temperature, ki jo potrdimo

z izbiro akcije 'Potrdi'. Desno od segmenta za trenutno nastavljeno temperaturo se nahaja

segment s statusom ogrevanja – označen v zeleni barvi. Ta nad ikono vsebuje indikator

statusa povezave odjemalca MQTT na centralnem strežniku. Tudi tukaj indikator zelene

barve pomeni, da je povezava vzpostavljena, in rdeč, da je prekinjena. Pod ikono je

prikazano trenutno stanje ogrevanja (vklopljeno/izklopljeno), ki se ga lahko spremeni s

klikom na segment. Dialog je prikazan na sliki 3.35 in vsebuje stikalo za vklop/izklop in

akcijo 'Potrdi' za izvedbo spremembe.

Slika 3.34: Zaslonska slika mobilne aplikacije, levo brez izbranega prostora in desno z izbranim

prostorom


65

V rdečem okvirju je označen seznam vseh prostorov, ki smo jih pridobili s klicem metode

VrniProstore programskega vmesnika. Posamezen element seznama vsebuje naziv

prostora levo in trenutno izmerjeno temperaturo prostora desno, v prvi vrsti celice. Desno

ob nazivu prostora je indikator statusa povezave senzorja do posrednika MQTT. Pomen

indikatorja je enak kot v prvih dveh primerih. Informacija o trenutno izmerjeni relativni

zračni vlažnosti se nahaja pod nazivom prostora. Nastavljena temperatura prostora je

izpisana pod trenutno izmerjeno temperaturo prostora. Pritisk na element seznama le-

tega izbere in razširi pogled s prikazom grafa meritev temperatur prostora za preteklih 24

ur. Izgled razširjenega pogleda elementa seznama prikazuje slika 3.34 v vijoličastem

okvirju. Poleg izmerjenih temperatur je na grafu v rdeči barvi prikazana tudi nastavljena

temperatura prostora v razmerju s časom.

Slika 3.35: Zaslonska slika dialoga za spremembo nastavljene temperature levo in dialoga za

vklop/izklop ogrevanja desno


66

Poleg prikazanih pogledov smo izdelali tudi pogled za nastavitve, ki ga odpremo z izbiro

menija. Spreminjamo lahko naslednje nastavitve:

1. IP-naslov centralnega strežnika.

2. Uporabniško ime in geslo za avtorizacijo in avtentikacijo.

3. Interval poizkusa ponovne vzpostavitve povezave v primeru nepričakovane

prekinitve.

4. Vrednost znižane temperature za varčevanje z energijo.

5. Izbira domačega brezžičnega omrežja.

6. Izbira lokacije za dom.

3.3.4 Implementacija komunikacije s centralnim strežnikom

Tako kot obstajajo različne implementacije MQTT posrednikov, obstajajo tudi MQTT

odjemalci. Ti so tako v različnih programskih jezikih, kakor tudi platformah. Ena

funkcionalno bogatejših in popularnejših je Eclipse Paho, ki je na voljo za različna

programska okolja (Java, Python, JavaScript, Golang, C#, C, C++). Projekt je bil ustvarjen

z namenom, da se razvije zanesljiva odprtokodna implementacija, ki sledi aktualnemu

standardu MQTT. Začetno kodo, ki se aktivno razvija in vzdržuje, je na začetku projekta

doniralo podjetje IBM. Ker je mobilna aplikacija izdelana za Android operacijski sistem, se

izbira zoža na implementacije v Java programskem jeziku. Eclipse Paho v ta namen

ponuja posebno implementacijo za Android v obliki komponente Service, ki v ozadju

komunicira s Paho Java MQTT odjemalcem. Knjižnica implementira standarda MQTT 3.1

in MQTT 3.1.1 in vključuje funkcionalnosti, kot so LWT, SSL/TLS, Message Persistence,

Automatic Reconnect, Offline Buffering, WebSocket in Non-Blocking API [43]. Za uporabo

moramo imeti nameščen Android Studio in Android SDK verzije 19 ali višje. Za namestitev

projekt ponuja izbiro med Maven in Gradle upravljalcem odvisnosti ali gradnjo knjižnice

JAR iz izvorne kode. Sami smo uporabili Gradle upravitelja, za kar smo morali v datoteko

build.gradle Android projekta dodati naslednjo vsebino, ki doda Paho repozitorij:

repositories {

maven {

"https://repo.eclipse.org/content/repositories/paho-snapshots/"

}

}


67

In v datoteko build.gradle Android aplikacije sledeči vrstici, ki dodata odvisnosti aplikacije:

Osnovna logika knjižnice je servis, ki skrbi za vzpostavitev in vzdrževanje povezave ter

pošiljanje in prejemanje sporočil. Servis se zažene ob zagonu aplikacije in se zaključi ob

izhodu. Komunikacija z njim poteka asinhrono preko vmesnika, imenovanega

MqttAndroidClient, kar naredi uporabo preprosto in intuitivno [45]. Za zagon servisa

moramo v AndroidManifest.xml dodati potrebne pravice in pod značko application

deklarirati uporabo servisa:

Prvi korak je vzpostavitev povezave do strežnika. Poleg protokola, naslova, vrat in id

odjemalca lahko pri povezavi kot argument pošljemo tudi opcijski parameter, ki omogoča

še dodatne nastavitve verzije protokola, avtorizacije in avtentikacije (uporabniško

ime/geslo, digitalno potrdilo), 'oporoke', interval obujanja, čas prekinitve, samodejne

ponovne povezave, seje in drugih bolj ali manj pomembnih parametrov. V lastni mobilni

aplikaciji smo povezavo vzpostavili znotraj metode Activity.onCreate z naslednjim delom

kode:

<manifest>

…

<uses-permission android:name="android.permission.WAKE_LOCK" />

<uses-permission android:name="android.permission.INTERNET" />

<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />

<uses-permission android:name="android.permission.READ_PHONE_STATE" />

…

<application>

…

<service android:name="org.eclipse.paho.android.service.MqttService" />

…

</application>

…

<manifest>

dependencies {

…

compile 'org.eclipse.paho:org.eclipse.paho.client.mqttv3:1.0.3-SNAPSHOT'

compile 'org.eclipse.paho:org.eclipse.paho.android.service:1.0.3-SNAPSHOT'

}


68

// generiranje idja odjemalca

String idOdjemalca = MqttClient.generateClientId();

// dodatne nastavitve povezave

MqttConnectOptions moznosti = new MqttConnectOptions();

// moznosti.setMqttVersion(MqttConnectOptions.MQTT_VERSION_3_1);

// nastavitev Last Will And Testament (LWT)

moznosti.setWill("Naprava/" + idOdjemalca + "/status", "OFF".getBytes(), 1, false);

// nastavitev avtorizacije in avtentikacije

moznosti.setUserName("[uporabniško ime]");

moznosti.setPassword("[geslo]".toCharArray());

// inicializacija MQTT odjemalca

mMQTTClient = new MqttAndroidClient(getApplicationContext(), "tcp://192.168.1.74:1883", idOdjemalca);

try {

// definiranje povratnih klicev

mMQTTClient.setCallback(new MqttCallbackExtended() {

@Override

public void connectComplete(boolean reconnect, String serverURI) {

Log.d(TAG, "connectComplete(" + String.valueOf(reconnect) + "): " + serverURI);

}

@Override

public void connectionLost(Throwable cause) {

Log.d(TAG, "connectionLost(): " + cause.toString());

}

@Override

public void messageArrived(String topic, MqttMessage message) throws Exception {

Log.d(TAG, "messageArrived(" + topic + "): " + message.toString());

}

@Override

public void deliveryComplete(IMqttDeliveryToken token) {

Log.d(TAG, "deliveryComplete(): " + token.toString());

}

});


69

// vzpostavitev povezave

mMQTTToken = mMQTTClient.connect(moznosti);

mMQTTToken.setActionCallback(new IMqttActionListener() {

@Override

public void onSuccess(IMqttToken asyncActionToken) {

Snackbar.make(mSeznam, "Povezavi do MQTT posrednika vzpostavljena",

Snackbar.LENGTH_LONG).show();

}

@Override

public void onFailure(IMqttToken asyncActionToken, Throwable exception) {

Snackbar.make(mSeznam, "Napaka pri povezavi do MQTT posrednika!",

Snackbar.LENGTH_LONG).setAction("Ponovi", null).show();

}

});

}

catch (MqttException e) {

e.printStackTrace();

Snackbar.make(mSeznam, "Napaka pri povezavi do MQTT posrednika!",


}


70

Pogledati si moramo še naročanje na teme in objavljanje sporočil. Naročanje opravimo v

povratnem klicu connectComplete, kar zagotovi, da se tudi ob morebitni prekinitvi

povezave ponovno naročimo na teme, ko se povezava samodejno ponovno vzpostavi.

Naročanje na teme smo si od bliže pogledali v poglavju s predstavitvijo protokola MQTT.

Tukaj pa si bomo s pomočjo izseka kode pogledali, kako se to izvede v Paho Java MQTT

odjemalcu:

// prijava na temo Naprave/# in Home/#

try {

// tema je lahko tipa string, ali polje stringov, kar je v primeru večih tem učinkovitejše

IMqttToken subToken = mMQTTClient.subscribe(Config.MQTT_TEME,

Config.MQTT_TEME_QOS);

subToken.setActionCallback(new IMqttActionListener() {

@Override


// prijava na temo je bila uspesna

Log.d(TAG, "subscribe onSuccess()");

}

@Override


// prijava na temo ni uspela (tažava z avtorizacijo?)

Log.d(TAG, "subscribe onFailure()");

}

});

}



Snackbar.make(mSeznam, "Napaka pri prijavi na teme!",


}


71

Podobno preprosto je tudi objavljanje sporočil. Objavljanje uporabljamo ob spreminjanju

nastavljene temperature prostora ali spreminjanju stanja kotla (vklop/izklop). Prav tako ob

uspešni vzpostavitvi povezave do strežnika na temo naprave objavimo uspešno

povezavo, da se lokalnega odjemalca MQTT na centralnem strežniku obvesti o uspešni

prijavi in se ta zrcali tudi v nadzorni plošči. Objavljanje sporočila omogoča naslednja koda:

Omeniti velja, da je potrebno vsebino pretvoriti iz niza UTF-8 znakov v polje tipa byte. Če

imamo željo poslati zadržano sporočilo, lahko to storimo s klicem metode

setRetained(true) razreda MqttMessage.

Pri delu z razredom MqttAndroidClient sta pomembni še dve funkcionalnosti.

Unsubscribe, ki je v aplikaciji nismo uporabili in omogoča odjavo od prejemanja sporočil

na določeno temo, ter disconnect, ki zapre vzpostavljeno povezavo do posrednika MQTT.

// objava sporočila

String tema = "Dom/DnevnaSoba/nast_temperatura";

String vsebina = "22.1";

try {

MqttMessage sporocilo = new MqttMessage(vsebina.getBytes("UTF-8"));

// v primeru, da želimo poslati zadržano sporocilo

//sporocilo.setRetained(true);

mMQTTClient.publish(tema, sporocilo);

}

catch (UnsupportedEncodingException | MqttException e) {


Snackbar.make(mSeznam, "Napaka pri objavi sporočila!",

Snackbar.LENGTH_LONG).show();

}


72

Primer uporabe obeh prikazuje sledeči izsek kode:

// prekinitev povezave

try {

IMqttToken disconToken = client.disconnect();

disconToken.setActionCallback(new IMqttActionListener() {

@Override


// prekinitev povezave uspesna

}

@Override


// tezava pri prekinitvi povezave, ki je vrjetno vseeno prekinjena

}

});

}



}

// odjava od teme

String tema = "Naprave/#";

try {

IMqttToken unsubToken = client.unsubscribe(tema);

unsubToken.setActionCallback(new IMqttActionListener() {

@Override


// odjava na temo uspešna

}

@Override


// pri odjavi je prislo do nepredvidene napake

}

});

}



}


73

V poglavju smo želeli izpostaviti dele kode, ki prikazujejo delo z odjemalcem MQTT. V

splošnem smo opazili, da je delo s pomočjo vmesnika za komunikacijo s servisom, ki skrbi

za povezavo, preprosto in pregledno. Ker je knjižnica kvalitetno dokumentirana, tudi

odpravljanje težav ni bilo problematično. Izkazalo se je, da je implementacija stabilna in

komunikacija poteka brez težav. Izjemoma so se te lahko pojavile na javnih brezžičnih

omrežjih, kjer so dostopi pogosto bolj strogo nadzorovani in v nekaterih primerih dovolijo

komunikacijo samo preko določenih vrat, kot so vrata 80 za splet. Poleg izpostavljene

kode za komunikacijo, smo pri pisanju upoštevali priznane principe programiranja za

Android naprave in pri vmesniku upoštevali, da sledi modernim smernicam razvoja

Android aplikacij.


74

3.4 Primerjalna analiza implementacije rešitve s pomočjo izbranih

tehnologij v primerjavi s HTTP

V poglavju 3 smo do sedaj predstavili protokole za realno-časovno komunikacijo, izbrali za

naš primer uporabe najprimernejšega ter izdelali centralni strežnik in mobilno aplikacijo, ki

ga za medsebojno komunikacijo uporabljata. V zaključku poglavja bomo analizirali, ali

smo z izbranim protokolom MQTT v primerjavi s protokolom HTTP, komunikacijo pohitrili

in zmanjšali količino prenesenih podatkov.

Za analizo bomo uporabili dva računalnika Raspberry Pi 3, ki imata že integriran WiFi-

modul, preko katerega sta povezana do brezžičnega usmerjevalnika MikroTik hAP lite.

Računalnika sta hkrati tudi edini napravi, ki sta v to omrežje povezani. V obeh je 16 GB

kartica microSDHC podjetja Samsung, na kateri je po navodilih iz podpoglavja 3.2.2

nameščen operacijski sistem Raspbian Jessie. Podrobnejšo konfiguracijo posameznega

računalnika prikazuje tabela 3.5. Nastavitve za nameščene komponente smo pustili

privzete, spremenili smo le parametre, ki so bili potrebni za delovanje v testnem okolju.

Tabela 3.5: Konfiguracija računalnikov za analizo

Ime Odjemalec Strežnik

Platforma Raspberry Pi 3 Raspberry Pi 3

Operacijski sistem Raspbian Jessie Raspbian Jessie

IP-naslov 192.168.2.61 192.168.2.64

Nameščene komponente Mosquitto-clients v1.4.9

Paho-mqtt v1.2

Wireshark v2.0.3

Apache v2.4.10 (port 80)

Mosquito v1.4.9 (port

1883)

V prvem delu smo med sabo primerjali velikost podatkov, ki se pošiljajo po omrežju. V ta

namen smo pripravili Python skripto, ki teče na odjemalcu in s pomočjo izbranega

protokola podatek pošlje do strežnika. Pri tem smo sporočilu, poslanemu preko protokola

MQTT, določili QoS nivoja 1, ki potrjuje sprejem sporočila, in s tem zagotovili boljšo

primerljivost med protokoloma. S pomočjo programa Wireshark, ki je namenjen

analiziranju omrežnih protokolov, smo zajeli pakete, ki se za posamezni protokol pošljejo,

in tako ugotovili njihovo velikost. Rezultat takšne analize prikazuje slika 3.36. Zajem

podatkov smo omejili na protokol in IP-naslov strežnika. V ta namen smo uporabili

naslednji filter:

(http || mqtt) && ip.addr == 192.168.2.64


75

Slika 3.36: Zaslonska slika zajema podatkov s pomočjo programa Wireshark

S skripto smo poslali sporočilo, ki je vsebovalo časovni žig v mikrosekundah in niz znakov

obliki v JSON. Poskrbeli smo, da je spletni naslov HTTP zahtevka enake dolžine kot ime

teme pri protokolu MQTT in tudi v tem pogledu zagotovili enakost. Vsebino v skupni

velikost 158 B smo poslali s tem ukazom:

pi@odjemalec:~/analiza$./data_test.py -p oba -n 1 -s 192.168.2.64

Zagon odjemalca ...

Streznik: 192.168.2.64

Protokol: oba

Stevilo sporocil: 1

Cas zagona: 2016-08-20 11:09:16.583420

Posiljanje http ...

Podatek 1 {'cas': 1471691358.586515, 'niz': 'Lorem…', 'id': 'c672…'}

Podatek 1 200 OK

Trajanje: 0.121195

Posiljanje mqtt ...

Podatek 1 {'cas': 1471691362.721499, 'niz': 'Lorem…', 'id': 'c8e9…'}

Podatek 1 0 1

Trajanje: 0.101551


76

Opazili smo, da se je pri zahtevku HTTP preneslo 448 B in pri odgovoru 324 B podatkov,

skupaj torej 772 B. Pri MQTT se je za vzpostavitev povezave preneslo 166 B, za

prekinitev povezave 68 B in za prenos vsebine skupaj s potrditvijo prejema (QoS 1) 332

B, skupaj 566 B podatkov. Ugotovili smo, da MQTT pri pošiljanju enega sporočila porabi

26,68 % manj podatkov. Prednost protokola pride še bolj do izraza v primeru pošiljanja

večih sporočil, saj se vzpostavljanje povezave izvede samo prvič. Pri poslanih 100

sporočilih tako prihranimo že 56,69 % podatkov. Odvisnost med številom poslanih sporočil

in velikostjo poslanih podatkov prikazuje graf na sliki 3.37.

Slika 3.37: Velikost poslanih podatkov glede na število poslanih sporočil

Drugi del analize govori o hitrosti pošiljanja posameznega sporočila. Tudi v ta namen smo

v programskem jeziku Python implementirali skripto, ki z naslednjim ukazom preko

izbranega protokola pošlje določeno število sporočil do strežnika in izmeri čas, ki je bil za

izvedbo potreben:


77

To smo storili za 100, 1000 in 10000 poslanih sporočil. Za vsak sklop smo test trikrat

ponovili, izračunali povprečje in rezultate zabeležili na graf v sliki 3.38.

Slika 3.38: Trajanje pošiljanja sporočil glede na število poslanih sporočil

Iz grafa lahko razberemo, da je MQTT v primerjavi s HTTP hitrejši. Če za primer izberemo

1000 poslanih sporočil, smo za pošiljanje preko HTTP potrebovali 17.75 sekund, kar

znaša 0.01775 sekunde za posamezno sporočilo. Pri MQTT smo za enako pošiljanje

pi@odjemalec:~/analiza$./test_hitrosti.py -p mqtt -n 100 -s 192.168.2.64

Zagon odjemalca ...

Streznik: 192.168.2.64

Protokol: mqtt

Stevilo ponovitev: 100

Cas zagona: 2016-08-20 19:04:52.695458

Posiljanje mqtt ...

Trajanje: 0.03001

pi@odjemalec:~/analiza$./test_hitrosti.py -p http -n 100 -s 192.168.2.64

Zagon odjemalca ...

Streznik: 192.168.2.64

Protokol: http

Stevilo ponovitev: 100

Cas zagona: 2016-08-20 19:06:21.571901

Posiljanje http ...

Trajanje: 1.770747


78

potrebovali 0.1602 sekunde in posamezno sporočilo prenesli v 0.0001602 sekunde. S

pomočjo MQTT smo torej sporočilo prenesli 110.8-krat hitreje kot s HTTP.

Na podlagi analize smo ugotovil, da z uporabo protokola MQTT pridobimo tako na

velikosti prenesenih podatkov kakor tudi na hitrosti. Glavna prednost protokola v

primerjavi s HTTP je, da je povezava do posrednika ves čas odprta, kar omogoča tako

hitrejše pošiljanje kakor tudi manjšo količino prenesenih podatkov, saj se metapodatki za

vzpostavitev podatkov prenesejo samo enkrat in ne vsakič znova. Omenjeni lastnosti sta

posebej pomembni v mobilnem svetu, kjer smo pogosto omejeni s količino prenesenih

podatkov. S tega vidika ima MQTT še dodatno prednost pred HTTP, saj ta na mobilnih

napravah Android pri pošiljanju porabi 11.89-krat in pri sprejemanju 170.9-krat manj

baterije [75]. Seveda takšna primerjava ni povsem poštena. Protokola sta bila izdelana za

različne namene, zato moramo vedeti, da je pomembno v pravi situaciji izbrati pravi

protokol, saj lahko ta pomembno vpliva na kakovost in delovanje naše rešitve.


79

4 IZDELAVA APLIKACIJE ZA PAMETNO URO

4.1 Predstavitev Android Wear platforme

Za boljši pregled nad stanjem temperatur v prostoru ter še lažje in hitrejše upravljanje smo

izdelali tudi aplikacijo za platformo Android Wear, ki se uporablja za poganjanje pametnih

ur. Platformo je podjetje Google predstavilo marca 2014 z izdajo posebne verzije

operacijskega sistema Android, namenjenega pametnim uram in drugim dodatkom. Kmalu

za tem sta na trg prišli tudi prvi napravi, ki ju je nova verzija poganjala, Samsung Gear

Live and LG G Watch, katerima se je hitro pridružila tudi pametna ura Moto 360 podjetja

Motorola, ki je prikazana na sliki 4.1.

Slika 4.1: Pametna ura Moto 360 podjetja Motorola [50]

Sistem deluje tako, da se preko Bluetooth ali WiFi povezave poveže z Android pametnim

telefonom in si z njim deli informacije ter obvestila, kot so prihajajoči klici, tekstovna

sporočila, dogodki koledarja in obvestila drugih aplikacij. Te prikaže in uporabniku

omogoča, da se s preprostimi akcijami na njih odzove. Poleg informacij si s povezanim

telefonom deli tudi funkcionalnost. Od telefona lahko zahteva informacijo o GPS-

koordinatah ali na njem izvaja določena opravila, kot so začetek in prekinitev predvajanja

glasbe. Pomemben del sistema je tudi glasovno upravljanje, ki omogoča izvrševanje

preprostih nalog, kot so pošiljanje tekstovnega sporočila, povpraševanje po poti,

dodajanje opomnika, dodajanje beležk, zagon aplikacij na telefonu, in drugih nalog, ki se

lahko s pomočjo dodatnih aplikacij tudi razširijo [48].


80

Medtem ko ima nova platforma z osnovno verzijo veliko skupnega, je med njima tudi

veliko razlik. Največja je v grafičnem vmesniku, ki je povsem nov, prilagojen manjšim

zaslonom. Sestavljen je iz začetnega zaslona, ki vsebuje ozadje z vsebino odprte kartice

ali podobo ure. Podoba lahko vsebuje pokazatelje različnih statusov (povezava, polnjenje,

število neprebranih sporočil …) in na dnu pogled prve kartice iz toka, kot je to prikazano

na sliki 4.2. Če z navpično kretnjo povlečemo z vrha zaslona, se prikaže statusni zaslon,

ki prikaže datum in stanje baterije. S pomikanjem levo in desno lahko vklapljamo ali

izklapljamo funkcije: brez motenja, način kina, povišana svetlost, in odpremo nastavitve. V

nastavitvah se lahko spreminja svetlost, podoba ure, velikost pisave, vklop/izklop gest,

vedno vklopljen zaslon, brezžična povezava, Bluetooth povezava, letalski način,

dostopnost, datum in ura, zaklep zaslona, pravice, informacije o sistemu ter izklop in

ponovni zagon naprave. Podobno lahko z gesto potega levo, na domačem zaslonu,

prikličemo seznam nameščenih aplikacij. Z izbiro se ta zažene v celozaslonskem načinu.

Slika 4.2: Podoba ure s pogledom kartice z vrha toka [49]

Osnovni koncepti delovanja so predlogi, ki predstavljajo navpičen tok kartic, po katerem

se lahko pomikamo s pomočjo navpične geste povleci. Na zaslonu se hkrati pokaže samo

ena kartica, ki vsebuje za uporabnika v danem trenutku relevantno informacijo. S pomočjo

slik v ozadju se uporabniku informacija predstavi tudi vizualno. Dodatno se lahko karticam

dodajo tudi akcije, do katerih se pride z vodoravno gesto povleci levo. Če želimo kartico

zapreti, to naredimo z vodoravno gesto povleci v desno. Prednost pristopa je v tem, da se

uporabniku ni potrebno prebijati skozi seznam aplikacij, da pridobi željeno informacijo,

ampak mu je ta pri roki, ko jo potrebuje. S tem namenom lahko tretje aplikacije kartico

ustvarijo in jo v relevantnem trenutku dodajo v tok.

Drugi koncept je koncept povpraševanja, ki se uporablja, kadar se željena informacija ne

nahaja med predlogi. Uporabnik kartico aktivira s pomočjo glasovnega ukaza »OK


81

Google« ali z dolgim pritiskom na privzeti zaslon. Željen ukaz lahko nato izgovorimo ali ga

izberemo s seznama. S pomočjo namere (angl. Intent), ki se s takšnim ukazom ustvari, se

lahko tudi tretje aplikacije na to odzovejo in razširijo funkcionalnost celotnega sistema

[49].

Pri načrtovanju aplikacij za Android Wear moramo upoštevati, da njihov namen ni

podvajanje celotne funkcionalnosti, ki jo ponujajo aplikacije na pametnih telefonih, temveč

njihovo dopolnjevanje. Z zgornjo mislijo smo v naslednjem poglavju načrtovali tudi lastno

aplikacijo.

4.2 Predstavitev rešitve in opis implementacije

Aplikacije, ki tečejo na pametni uri, morajo biti preproste in pregledne. Naloge, ki jih z

njihovo pomočjo lahko opravimo, pa se morajo izvesti hitro in z malo uporabnikove

interakcije. S tega vidika smo izdelali dve komponenti. Prva komponenta je aplikacija, ki

omogoča pregled in nadzor nad temperaturami v prostoru. Najdemo jo na seznamu

nameščenih aplikacij. Ob odprtju se prikaže začetni zaslon, ki ga prikazuje slika 4.3. Na

zaslonu imamo izpisano trenutno nastavljeno temperaturo za vse prostore in status kotla.

Obe vrednosti lahko spremenimo z izbiro akcije pod posamezno informacijo. Akcija za

spremembo nastavljene temperature odpre zaslon, prikazan na sliki 4.4, s pomočjo

katerega lahko spremenimo nastavljeno temperaturo. S klikom desnega gumba (potrditev)

na zaslonu spremenimo nastavljeno temperaturo v vseh prostorih v enem koraku. Če

želimo spremembo prekiniti, to storimo z levim gumbom (prekinitev). Desna akcija na

začetnem zaslonu omogoča vklop/izklop ogrevanja. Izbira akcije odpre zaslon na sliki 4.4.

Ta vsebuje stikalo za vklop/izklop in gumba za prekinitev ali potrditev spremembe.

Slika 4.3: Začetni zaslon aplikacije (levo) in kartica prostora (desno)

S pomočjo navpične geste povleci se lahko pomikamo med začetnim zaslonom in zasloni

posameznih prostorov, ki se pridobijo s strežnika. Na sliki 4.3 je prikazan primer takšnega


82

zaslona. Ta ima v naslovu izpisano ime prostora, pod katerim je informacija o trenutno

izmerjeni temperaturi prostora, ki ga desno spremlja podatek o nastavljeni temperaturi le-

tega. Spremembo trenutno nastavljene temperature prostora lahko izvedemo z akcijo, ki

se nahaja pod omenjenimi podatki. Ta odpre zaslon, prikazan na sliki 4.4, z že opisanimi

funkcionalnostmi.

Slika 4.4: Zaslon za spremembno vrednosti temperature (levo) in vklopa/izklopa ogrevanja (desno)

Eden pomembnejših principov Android Wear je, da ta ne moti uporabnika pri njegovem

delu ter tako zagotavlja tekočo in nemotečo uporabniško izkušnjo. V ta namen se morajo

aplikacije zavedati svojega okolja in konteksta, da lahko v pravem trenutku nudijo pravo

informacijo. S pomočjo bogatih obvestil, ki se prikažejo ob pravem trenutku, lahko sistem

uporabniku asistira pri njegovih opravkih.

Z omenjeno mislijo smo izdelali drugo komponento, ki kot servis teče na telefonu in

zaznava lokacijo uporabnika. V primeru, da preko prekinitve povezave do domačega

brezžičnega omrežja ali spremembe lokacije zazna, da uporabnik odhaja od doma, v tem

primeru pošlje obvestilo, ki se uporabniku prikaže na pametni uri in z vibracijo nanj tudi

opozori. Obvestilo uporabnika pozove za potrditev vključitve varčnega načina ogrevanja,

ki zniža temperaturo v vseh prostorih na nastavljeno vrednost. Nasprotno omenjenemu je

obvestilo, ki se prikaže, kadar se zazna prihod uporabnika domov in delovanje ogrevanja

v varčnem načinu. Takrat se uporabnika vpraša za potrditev izklopa varčnega načina

ogrevanja. Takšni obvestili ponazarja slika 4.5. Omeniti je potrebno, da je v primeru, kadar

uporabnik obvestilo spregleda ali zavrne, mogoče vklopiti/izklopiti varčni način ogrevanja s

pomočjo mobilne aplikacije.


83

Slika 4.5: Obvestilo ob odhodu od doma (levo) in vračanju domov (desno)

Implementacija zgoraj opisane rešitve je potekala v Android Studio. Ker platforma Android

Wear temelji na platformi Android z nekoliko omejenimi funkcionalnostmi, je tudi

načrtovanje grafičnega vmesnika ter obnašanje in razvoj kode zelo podoben. Ob

upoštevanju osnovnih smernic razvoja grafičnega vmesnika za naprave iz tega razreda, je

tudi tukaj razvoj hiter in preprost. Pri razvoju za pametne ure je bilo potrebno posebno

pozornost posvetiti delovanju grafičnega vmesnika ne samo na pravokotnih, ampak tudi

okroglih oblikah zaslonov. V te namene imamo na voljo posebne poglede, kot so

WatchViewStub in BoxInsetLayout, ki nam delo olajšajo. Tako implementirana rešitev je

tudi v celoti izpolnila v začetku postavljene cilje.


84

5 ZAKLJUČEK

5.1 Testiranje hipotez

Hipoteza 1: S pomočjo namenskih tehnologij in protokolov lahko v primerjavi s HTTP

zmanjšamo velikost podatkov, ki se prenašajo med senzorjem in odjemalcem.

Rezultat: Pri razvoju končne rešitve smo za realno-časovno komunikacijo med mobilno

aplikacijo in senzorjem uporabili protokol MQTT. V poglavju 3.4 smo preverili velikost

podatkov, ki se za pošiljanje sporočila prenesejo in te primerjali z velikostjo prenesenih

podatkov pri protokolu HTTP. Ugotovili smo, da lahko z uporabo MQTT prenesemo 56,69

% manj podatkov in s tem hipotezo potrdili.

Hipoteza 2: S pomočjo namenskih tehnologij in protokolov je prenos informacij od

senzorja do odjemalca v primerjavi s HTTP hitrejši.

Rezultat: Želeli smo realno-časovno komunikacijo med mobilno aplikacijo in senzorjem.

Da je pogoj izpolnjen, mora izbrani protokol podatek v čim krajšem času prenesti od

senzorja do aplikacije. Ugotovitve iz poglavja 3.4 nakazujejo, da smo lahko s protokolom

MQTT v primerjavi s HTTP, podatek prenesli 110.8-krat hitreje. Hipotezo smo s tem

potrdili.

5.2 Omejitve diplomskega dela

Omejitev 1: Pri predstavitvi protokolov in tehnologij za realno-časovno komunikacijo med

senzorji in mobilnimi aplikacijami smo se omejili na tiste, ki se v praksi najpogosteje

uporabljajo.

Omejitev 2: Pri komunikaciji smo se osredotočili na realno-časovnost. Zanesljivosti in

varnosti se nismo posebej posvečali.

Omejitev 3: Pri izdelavi senzorja temperature smo se posvetili komunikaciji, sama

izdelava senzorja je bila sekundarnega pomena.

Omejitev 4: Pri platformah za pametne ure smo predstavili Android Wear. Ostalih platform

nismo preverili. Tudi končna rešitev je izdelana izključno za to platformo.


85

Omejitev 5: Delovanje mobilne aplikacije smo omejili na pametne telefone z operacijskim

sistemom Android 6.0.

5.3 Možne razširitve končne rešitve

Rešitev, izdelana v nalogi, se uspešno uporablja. Izkazalo se je, da je zanesljiva in

preprosta za uporabo. Da bi končni izdelek lahko ponudili tudi na trgu, se bi morali

dodatno posvetiti še varnosti, saj je ta pri napravah, povezanih v internet, velikega

pomena. Dodali bi lahko nove funkcionalnosti, kot je nadzor rolet, in postopoma razvili

sistem za nadzor celotne hiše. Senzor temperature bi lahko razširili s senzorji za kvaliteto

zraka, zaznavanje dima in ogljikovega monoksida. S tem bi lahko poleg udobja izboljšali

tudi kvaliteto in varnost življenja v prostorih. Zanimiva funkcionalnost bi bila tudi časovno

upravljanje temperatur v prostoru. Dodatno bi bilo smiselno preveriti možnosti uporabe

končnih rešitev MQTT- posrednikov, kot so HiveMQ, RabbitMQ in VernMQ in ponuditi

funkcionalnost centralnega strežnika kot storitev v oblaku. Rešitev bi s tem bila za

končnega uporabnika bolj privlačna in preprosta za uporabo.

MQTT ima v primerjavi s HTTP tudi slabosti. Ena takšnih so javna brezžična omrežja, ki

pogosto dostop do interneta omejujejo tako, da promet filtrirajo ali omogočajo samo

komunikacijo preko določenih vrat. Delovanje MQTT je lahko v takšnih primerih

onemogočeno. Za bolj zanesljivo delovanje mobilne aplikacije bi bilo smiselno raziskati

možnosti, kako takšno omejitev zaobiti.

5.4 Sklep

V diplomskem delu smo predstavili tehnologije in protokole, ki omogočajo realno-časovno

komunikacijo med mobilnimi aplikacijami in senzorji. Na praktičnem primeru nadzora

ogrevanja stanovanja smo pokazali uporabnost protokola MQTT, ki smo ga za naš primer

uporabe izbrali za najprimernejšega. Ugotovili smo, da lahko s pravo izbiro prihranimo

tako na količini prenesenih podatkov, kakor tudi povečamo hitrost prenosa. Pri tem smo

pridobili tudi dodatne funkcionalnosti, kot je zagotovljena dostava in zadržano sporočilo, ki

jih MQTT ponuja. Cilje, ki smo si jih zastavili v uvodu, smo tako uspešno izpolnili.

Prav tako smo spoznali, da je izbira protokola pogojena s problemom, ki ga rešujemo. Ker

je senzorje mogoče uporabiti v različnih scenarijih, obstajajo različni protokoli, ki vsak po

svoje rešujejo probleme, ki v posameznih okoljih nastanejo. Za razvijalca je pomembno,

da je z njimi seznanjen ter pozna prednosti in slabosti posameznega. Le tako bo lahko

rešitev pravilno načrtoval in uporabil primerne tehnologije.


86

6 VIRI

[1] MQTT.org. Frequently Asked Questions. Dostopno na: http://www.mqtt.org/faq [9. 3.

2016].

[2] Banks A., Gupta R. MQTT Version 3.1.1 Plus Errata 01, 2015. Dostopno na:

http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html [9. 3. 2016].

[3] IBM. IBM Podcast with Piper, Diaz and Nipper. Dostopno na:

http://www.ibm.com/podcasts/software/websphere/connectivity/piper_diaz_nipper_mq_tt_

11182011.pdf [9. 3. 2016].

[4] Hohpe G., Woolf B. Enterprise Integration Patterns: Designing, building and deploying

messaging solutions.

[5] HiveMQ. MQTT Essentials Part 3: Client, Broker and Connection Establishment.

Dostopno na: http://www.hivemq.com/blog/mqtt-essentials-part-3-client-broker-

connection-establishment [8. 3. 2016]

[6] HiveMQ. MQTT Essentials Part 4: MQTT Publish, Subscribe & Unsubscribe.

Dostopno na: http://www.hivemq.com/blog/mqtt-essentials-part-4-mqtt-publish-subscribe-

unsubscribe [8. 3. 2016].

[7] HiveMQ. MQTT Essentials Part 5: MQTT Topics & Best Practices. Dostopno na:

http://www.hivemq.com/blog/mqtt-essentials-part-5-mqtt-topics-best-practices [8. 3. 2016]

[8] Obermaier D. MQTT: SYS Topics. Dostopno na:

https://github.com/mqtt/mqtt.github.io/wiki/SYS-Topics [8. 3. 2016].

[9] HiveMQ. MQTT Essentials Part 6: Quality of Service 0, 1 & 2. Dostopno na:

http://www.hivemq.com/blog/mqtt-essentials-part-6-mqtt-quality-of-service-levels [8. 3.

2016].

[10] HiveMQ. Introducing the MQTT Security Fundamentals. Dostopno na:

http://www.hivemq.com/blog/introducing-the-mqtt-security-fundamentals [8. 3. 2016].

[11] HiveMQ. MQTT Security Fundamentals: Authentication with Username and

Password. Dostopno na: http://www.hivemq.com/blog/mqtt-security-fundamentals-

authentication-username-password [8. 3. 2016].

[12] HiveMQ. MQTT Security Fundamentals: Authorization. Dostopno na:

http://www.hivemq.com/blog/mqtt-security-fundamentals-authorization [8. 3. 2016].

[13] HiveMQ. MQTT Security Fundamentals: MQTT Payload Encryption. Dostopno na:

http://www.hivemq.com/blog/mqtt-security-fundamentals-payload-encryption [8. 3. 2016].

[14] HiveMQ. MQTT Security Fundamentals: TLS / SSL. Dostopno na:

http://www.hivemq.com/blog/mqtt-security-fundamentals-tls-ssl [8. 3. 2016].


87

[15] HiveMQ. MQTT Security Fundamentals: X509 Client Certificate Authentication.

Dostopno na: http://www.hivemq.com/blog/mqtt-security-fundamentals-x509-client-

certificate-authentication [8. 3. 2016].

[16] HiveMQ. MQTT Security Fundamentals – MQTT Message Data Integrity. Dostopno

na: http://www.hivemq.com/blog/mqtt-security-fundamentals-mqtt-message-data-integrity

[8. 3. 2016].

[17] Rowe W. Non-real-time data interchange IoT protocols: Consider your options

Dostopno na: http://internetofthingsagenda.techtarget.com/feature/Non-real-time-data-

interchange-IoT-protocols-Consider-your-options [9. 3. 2016].

[18] Schneider S. Understanding The Protocols Behind The Internet Of Things. Dostopno

na: http://electronicdesign.com/iot/understanding-protocols-behind-internet-things [12. 3.

2016].

[19] Schuster D. IoT Messaging Protocols: Welcome. Dostopno na

https://iotprotocols.wordpress.com/2014/11/03/welcome/ [12. 3. 2016].

[20] Object Management Group, Inc. What is DDS?. Dostopno na:

http://portals.omg.org/dds/what-is-dds-3/ [12. 3. 2016].

[21] Eclipse Foundation. MQTT and CoAP, IoT Protocols. Dostopno na:

http://www.eclipse.org/community/eclipse_newsletter/2014/february/article2.php [12. 3.

2016].

[22] Janakiram M. 10 DIY Development Boards for IoT Prototyping, 2016. Dostopno na:

http://thenewstack.io/10-diy-development-boards-iot-prototyping/ [13. 3. 2016].

[23] Donald F. 10 best IOT Hardware platforms, 2015. Dostopno na:

http://www.gadgetronicx.com/10-best-iot-hardware-platforms/ [13. 3. 2016].

[24] Arduino. Arduino Build Process. Dostopno na:

https://www.arduino.cc/en/Hacking/BuildProcess [14. 3. 2016].

[25] Arduino. Learning: Language Reference. Dostopno na:

https://www.arduino.cc/en/Reference/HomePage [14. 3. 2016].

[26] Arduino. Getting Started: Arduino Software (IDE). Dostopno na:

https://www.arduino.cc/en/Guide/Environment [14. 3. 2016].

[27] Arduino. Class for DHTxx sensors. Dostopno na:

http://playground.arduino.cc/Main/DHTLib [14. 3. 2016].

[28] O'Leary N. Arduino Client for MQTT. Dostopno na: http://pubsubclient.knolleary.net/

[15. 3. 2016].

[29] Arduino. Getting Started: Install the Arduino Software (IDE) on on Linux. Dostopno

na: https://www.arduino.cc/en/Guide/Linux [16. 3. 2016].


88

[30] Arduino. Getting Started: What is Arduino?. Dostopno na:

https://www.arduino.cc/en/Guide/Introduction [16. 3. 2016].

[31] Arduino. Arduino Products. Dostopno na: https://www.arduino.cc/en/Main/Products

[16. 3. 2016].

[32] Ruggeri L. Top 5 Wireless Ways to Communicate with your Controller, 2015.

Dostopno na: http://www.open-electronics.org/top-5-wireless-ways-to-communicate-with-

your-controller/ [28. 3. 2016].

[33] RS Components. 11 Internet of Things (IoT) Protocols You Need to Know About.

Dostopno na: http://www.rs-online.com/designspark/electronics/knowledge-item/eleven-

internet-of-things-iot-protocols-you-need-to-know-about [28. 3. 2016].

[34] RF Wireless World. IoT Wireless Technologies OR IoT Wireless Standards. Dostopno

na: http://www.rfwireless-world.com/Terminology/IoT-wireless-technologies.html [28. 3.

2016].

[35] Smith M. Understanding The Common WiFi Standards [Technology Explained], 2011.

Dostopno na: http://www.makeuseof.com/tag/understanding-common-wifi-standards-

technology-explained/ [18. 4. 2016].

[36] Voo B. 802.11ac Wi-Fi Explained: What Is It & Why It’s Cool. Dostopno na:

http://www.hongkiat.com/blog/wireless-ac-explained/ [18. 4. 2016].

[37] Winkle W. Gigabit Wireless? Five 802.11ac Routers, Benchmarked, 2013. Dostopno

na: http://www.tomshardware.com/reviews/wi-fi-802.11ac-router,3386.html [18. 4. 2016].

[38] Orsini L. How To Set Up Your Raspberry Pi For The First Time, 2014. Dostopno na:

http://readwrite.com/2014/01/20/raspberry-pi-everything-you-need-to-know/ [7. 5. 2016].

[39] Klosowski T. How the Raspberry Pi 3 Benchmarks Against Older Models, 2016.

Dostopno na: http://lifehacker.com/how-the-raspberry-pi-3-benchmarks-against-older-

models-1762417275 [7. 5. 2016].

[40] Eclipse Foundation. Mosquitto. Dostopno na:

http://projects.eclipse.org/projects/technology.mosquitto [16. 5. 2016].

[41] Smith C. By the Numbers: 85+ Amazing Android Statistics, 2016. Dostopno na:

http://expandedramblings.com/index.php/android-statistics/ [22. 5. 2016].

[42] Statista, Inc. Number of apps available in leading app stores, 2016. Dostopno na:

http://www.statista.com/statistics/276623/number-of-apps-available-in-leading-app-stores/

[8. 6. 2016].

[43] Eclipse Foundation. Eclipse Paho Android Service. Dostopno na:

http://www.eclipse.org/paho/clients/android/ [7. 7. 2016].


89

[44] International Organization for Standardization. ISO/IEC 20922:2016: Information

technology - Message Queuing Telemetry Transport (MQTT) v3.1.1. Dostopno na:

http://www.iso.org/iso/catalogue_detail.htm?csnumber=69466 [7. 7. 2016].

[45] White M. MQTT: An Open Source Push Messaging Alternative, 2014. Dostopno na:

https://developer.zebra.com/docs/DOC-2315 [7. 7. 2016].

[46] Meier R. An update on Eclipse Android Developer Tools, 2015. Dostopno na:

http://android-developers.blogspot.si/2015/06/an-update-on-eclipse-android-

developer.html [7. 7. 2016].

[47] Android Open Source Project. Android Studio: The Official IDE for Android. Dostopno

na: https://developer.android.com/studio [14. 7. 2016].

[48] Thornsby J. Code Introduction to Android Wear: The Basics, 2014. Dostopno na:

http://code.tutsplus.com/articles/introduction-to-android-wear-the-basics--cms-22042 [22.

7. 2016].

[49] Android Open Source Project. Design: Android Wear. Dostopno na:

https://developer.android.com/design/wear/index.html [22. 7. 2016].

[50] Motorola Mobility LLC. Moto 360. Dostopno na:

http://www.motorola.com/us/products/moto-360 [2. 8. 2016].

[51] Leggetter P. Realtime Web Apps: Approaching $150 million invested in realtime web

companies, 2013. Dostopno na: http://realtimewebapps.com/approaching-100-million-

invested-in-realtime-web-companies/ [9. 8. 2016].

[52] Arduino. Products: Arduino Yun. Dostopno na:

https://www.arduino.cc/en/Main/ArduinoBoardYun [14. 8. 2016].

[53] DomoticX. Temperatuur en luchtvochtigheid sensor DHT11. Dostopno na:

http://domoticx.nl/webwinkel/index.php?route=product/product&product_id=230 [17. 8.

2016].

[54] Gartner, Inc. Forecast: The Internet of Things, Worldwide, 2013. Dostopno na:

http://www.gartner.com/newsroom/id/2636073) [17. 8. 2016].

[55] Ironpaper. Marketing Opportunities for the Internet of Things, 2014. Dostopno na:

http://www.ironpaper.com/webintel/articles/marketing-opportunities-for-the-internet-of-

things/ [17. 8. 2016].

[56] Leggetter P. History, Background, Benefits & Use Cases of Realtime, 2013. Dostopno

na: https://www.leggetter.co.uk/2013/10/28/history-background-benefits-use-cases-

realtime.html [17. 8. 2016].

Documents

Realno-časovna komunikacija mobilnih aplikacij s senzorji · Arduino, Android Wear UDK: 621.397.7-026.364:681.586.6(043.2) Abstract In this diploma paper technologies and protocols