Sunteți pe pagina 1din 21

1

2


























3

Cuprins

1. Introducere
1.1. Introducere in monitorizarea factorilor climatici
1.2. Scurta prezentare a proiectului


2. Componente si resurse
2.1. Componente necesare realizarii si exploatarii proiectului
2.2. Resurse necesare realizarii si exploatarii proiectului.
2.3. Notiuni introductive despre Arduino
2.4. Arduino Ethernet Shield
2.5. Transmiterea informatiei in Internet
2.5.1. Stiva OSI
2.5.2. Conectivitate IP, protocoale, MAC
2.6. Java script
2.7. Server, host

3. Coduri sursa
3.1. Sketch Arduino
3.2. Cod Java Script


4



4. Etapele realizarii proiectului

5. Probleme intampinate in realizarea proiectului (prezentarea in ordinea cronologica)
5.1. Probleme solutionate
5.2. Probleme nesolutionate

6. Concluzii

7. Bibliografie












5



1.INTRODUCERE

1.1. Introducere in monitorizarea factorilor climatici

Odata cu dezvoltarea industriei IT, se pune tot mai mult accentul pe
conceptual de casa inteligenta. De ce casa inteligenta? Pentru ca nu are nevoie
de prezenta fizica a omului pentru a fi controlati diversi parametrii ce acopera
necesarul si confortul acestuia.
Deasemenea cand spui casa inteligenta trebuie sa te gandesti la 2 lucruri:
automatizari si remote-control. Automatizarile sunt menite sa asigure mai
degraba confortul, in timp ce remote-control-ul are un rol esential mai mult pe
parte de siguranta a locuintei.
In acest proiect se va urmari partea de remote-control. Fiind un prim
proiect desfasurat in acest domeniu, este pusa prima caramida a casei
inteligente si anume monitorizarea factorilor climatici.







6


1.2. Scurta prezentare a proiectului

Aceasta este prima versiune (facand o analogie cu software-le ce apar pe
piata IT, este versiunea beta sau v.1.0) a proiectului ce are ca scop monitorizarea
factorilor climatici. Mentionez acest lucru, intru-cat proiectul de fata, mai are
nevoie atat de imbunatatiri (in special pe partea grafica), dar si de gasirea unor
solutii pentru a atinge scopul final al monitorizarii (posibilitatea accesarii
informatiei din internet, nu doar din LAN, precum si afisarea corecta si precisa a
temperaturii detaliere in capitolul 5).

In acest proiect este monitorizata temperatura dintr-o camera si este
transmisa in LAN, astfel incat sa poata fi accesata dintr-un browser de utilizatori
din acelasi LAN. Dupa cum se cunoaste LAN-ul se intinde deobicei pe o raza de
maxim 1 km (ceea ce nu exploateaza pe deplin proprietatiile generale ale remote-
controlului), motiv pentru care tot in cadrul acestui proiect sunt incercate si
propuse solutii pentru transmiterea informatiei in Internet (cu siguranta tema
urmatoarei versiuni a proiectului).

Am ales monitorizarea temperaturii din 3 motive:
-este cel mai important factor climatic
-este factorul climatic cu cea mai interesanta evolutie si cea mai bine inteleasa de
catre om
-este mai simplu sa incepi cu monitorizarea temperaturii, deoarece din punct de
vedere al documentatiei, internetul si cartile de specialitate reprezinta o resursa
ampla, spre deosebire de ceilalti factori climatici (umiditate, presiune, etc.); odata
ce proiectul de monitorizare a temperaturii este terminat, pe baza cunostintelor
acumulate se poate dezvolta usor o versiune pentru restul factorilor.
7

2. COMPONENTE SI RESURSE
2.1. Componente necesare realizarii si exploatarii proiectului

Pentru realizarea proiectului avem nevoie de:
a.O platforma Arduino (in acest proiect se foloseste versiunea UNO)





b.Un Arduino Ethernet Shield



8


c.Un cablu de imprimanta USB 2.0 cu mufare tip A-B


d. Un senzor de temperature ( ideal un senzor brick pentru o operare mai usoara)

e. Fire de legatura (ideal gata mufate, cu conexiune tata-tata)


9

Pentru exploatare este nevoie de un end-device ce se poate conecta la Internet si
suporta o versiune ceva mai noua de Java:

Sistem desktop Laptop


PDA Smartphone


2.2. Resurse necesare realizarii si exploatarii proiectului
Este nevoie de conectivitatea LAN si o conexiune Internet, ideal cat mai mare (inca nu a fost
testat proiectul cu o conexiune modem de 56k, dar este foare posibil sa nu functioneze
corespunzator, intru-cat rata de plotare a datelor este de aproximativ 3 puncte/secunda, ceea
ce se traduce printr-un schimb de 6 replici intre server si client, daca nu punem la socoteala
pe cele necesare initializatii si finalizarii conexiunii (detalii : cautare pe google dupa 3 hand-
shake).
10


2.3. Notiuni introductive despre Arduino

Arduino este o platform gratuit destinat celor pasionai de electronic, studeni i ingineri din
domeniu deopotriv, dar i celor care doar au ca hobby construirea de montaje electronice.
Arduino este att un produs software ct i un concept, extinznd conceptul open source i asupra
realizrilor tehnice concrete (scheme, cablaje electronice, etc.).
Partea de software a platformei este integrat ntr-o interfa grafic de tip IDE bazat pe limbajul de
programare Processing . Programarea controllerului de pe platforma fizic se face folosind limbajul
de programare Arduino
Proiectele fizice realizate pe platformele Arduino pot funciona de sine stttor dar pot interaciona
cu aplicaii care funcioneaz pe un calculator precum Flash, Processing, MaxMSP.
Cu platformele fizice Arduino putei transforma calculatorul dumneavoastr ntr-un instrument de
msur complex sau ntr-un dispozitiv inteligent de testare i evaluare a prototipurilor.
Mediul Integrat de Dezvoltare (IDE) Arduino
Mediul integrat de dezvoltare Arduino este destinat scrierii programelor ce pot fi incrcate pe
platformele fizice Arduino. Interfaa este scris in Java i mediul de programare folosete limbaje de
programare de tip open source precum Processing, avr-gcc. Interfaa este multiplatform, putnd
rula n Windows, Mac OS X i Linux. Programul poate fi obinut att ca executabil specific
platformei de lucru pe care o avei dar i sub form de cod surs pe care il putei compila conform
condiiilor specifice pe care le avei.
Platforma hardware Arduino
Pe scurt, platforma este o plac (de test, de circuit imprimat, etc.) de diferite forme fizice i design
care are ca element central un circuit integrat programabil. Att placa de baz ct i circuitul integrat
programabil pot fi diferite, ceea ce confer proiectelor realizate o flexibilitate in proiectare deosebit.



11

2.4 Arduino Ethernet Shield
Descriere
Arduino Ethernet Shield este un scut care permite conectarea la internet a placii de
dezvoltare Arduino. Acest scut se bazeaza pe un chip W5100 Ethernet Wiznet. Chipul
W5100 Wiznet se poate conecta la o retea (IP) fiind capabil atat TCP si UDP. Acest scut
poate sustine pana la patru conexiuni socket simultane.
Specificatii tehnice
Scutul contine un numar de LED-uri informationale:
PWR: indica faptul ca placa si scutul sunt alimentate;
LINK: indica prezenta unei legaturi de retea si clipeste atunci cand scutul transmite
sau primeste date;
FULLD: indica faptul ca exista o conexiunea la retea este full duplex;
100M : indica prezenta unei conexiuni la retea de MB 100/s (spre deosebire de 10
Mb/s);
RX: se aprinde intermitent atunci cand scutul primeste date;
TX: se aprinde intermitent atunci cand scutul trimite datele;
COLL: clipeste atunci cand coliziuni de retea sunt detectate.
Pe langa LED-urile informationale scutul prezinta si un conector de card MicroSD



2.5. Transmiterea informatiei in Internet
2.5.1. Stiva OSI
Modelul de Referin OSI (OSI este un acronim pentru interconectarea sistemelor
deschise,englez Open Systems Interconnection), pe scurt: OSI, este o structur
de comunicaie ierarhic foarte des folosit pentru a realiza o reea de calculatoare. OSI este un standard
al Organizaiei internaionale de standardizare, emis n 1984.
Modelul de Referin OSI ofer metode generale pentru realizarea comunicaiei sistemelor de
calcul pentru ca acestea s poat schimba informaii, indiferent de particularitile constructive ale
sistemelor (fabricant, sistem de operare, ar, etc). Modelul de Referin are aplicaii n toate domeniile
comunicaiilor de date, nu doar n cazul reelelor de calculatoare.
Modelul OSI divizeaz problema complex a comunicrii ntre dou sau mai multe sisteme n 7 straturi
numite i niveluri (layers) distincte, ntr-o arhitectur ierarhic. Fiecare strat (nivel) are funcii bine
determinate i comunic doar cu straturile adiacente. Cele 7 niveluri ale Modelului de Referin se
numesc: Aplicaie (nivelul 7, superior) , Prezentare, Sesiune, Transport, Reea, Legtur de date, Fizic
12

(nivelul 1, inferior). Termenii corespunztori din englez
sunt Application,Presentation, Session, Transport, Network, Data link, Physical




Not. Pentru o mai bun nelegere a imaginii de mai sus, comunicaia pe vertical de la un element la cel
imediat superior sau inferior (sgeile albastre) respect regulile interfeei respective, n timp ce
comunicaia (indirect) pe orizontal ntre un element verde i unul albastru respect protocolul nivelului
respectiv.
Cnd participantul 1 (o persoan sau un calculator sau dispozitiv "inteligent") vrea s "converseze" cu
participantul 2 (de asemenea o persoan sau un dispozitiv), aceasta se face de fapt prin aceea c
Aplicaia 1 trimite Aplicaiei 2 mai nti un prim mesaj, de exemplu "Eti liber i stpneti
protocolul FTP?". Pentru "conversaia" lor aplicaiile trebuie s foloseasc un protocol de aplicaie
predefinit. Protocoalele de pe fiecare nivel prescriu pn la ultimul amnunt cum anume se "vorbete", ce
se spune i mai ales n ce ordine, astfel nct participantul cellalt s "neleag" despre ce este vorba. n
acest exemplu ns, Aplicaia 1 nu are legtur direct/fizic cu Aplicaia 2. O legtura fizic exist, dar
se afl departe - la fundul "stivei" de protocoale. Metoda Modelului OSI prevede ca mesajul Aplicaiei 1
destinat Aplicaiei 2 s fie mai nti predat nivelului de mai jos = Prezentare 1, printr-o interfa special.
Acest nivel "vorbete" la rndul su cu nivelul su omolog din stiva 2, anume Prezentare 2, pentru care
se folosete de protocolul necesar. Dar nici cele 2 niveluri de Prezentare nu sunt legate direct ntre ele.
13

Nivelul Prezentare 1 pred atunci cele dorite n jos, nivelului Sesiune 1 (iari printr-o interfa
specializat).
Aceast procedur se continu n jos pn se atinge Nivelul fizic 1. Abia acesta posed o legtur fizic
cu omologul su, Nivelul fizic 2, de exemplu printr-un cablu. De aici informaia se propag spre
participantul 2 de jos n sus, printr-o serie de interfee, pn ntr-un bun sfrit se atinge nivelul Aplicaie
2, respectiv Participant 2, cu care Aplicaia 1 voia iniial s "vorbeasc". Din punct de vedere al Aplicaiei
1, ea doar pare c duce o conversaie direct cu Aplicaia 2, conform prescripiilor din protocolul de
aplicaie ales. n realitate ea schimb informaii doar cu nivelul Prezentare 1, imediat vecin, prin interfaa
respectiv.
Avantajul acestei metode stratificate este c nici Aplicaia 1, i nici mcar programatorul ei (!!!) nu trebuie
s cunoasc deloc sarcinile i soluiile de la nivelurile inferioare, ci doar una sau 2 interfee, n sus i n
jos. n plus, ea nu trebuie modificat reactiv la orice schimbare de pe straturile inferioare. De exemplu,
dac se schimb cablul de legtur (de la nivelul Nivelului fizic) printr-un canal radio. Specific pentru
canale radio poate fi rata mare de greeli de transmisie, care desigur trebuiesc corectate automat, n
funcie de s zicem condiiile atmosferice, caz care ns nu se ntmpl niciodat la cablul de cupru. i cu
toate astea, Aplicaia 1 nu trebuie modificat.


Funciile nivelurilor
La baza stabilirii nivelelor arhitecturale ale modelului ISO OSI au stat o serie de principii generale, cum ar
fi:
crearea unui numr redus de nivele cu puine interactiuni ntre ele;
colectarea funciilor nrudite n acelai nivel;
crearea posibilitaii de modificare a funciilor unui nivel, fr afectarea celorlalte;
crearea pentru fiecare nivel de linii de demarcaie (interfee) spre nivelul adiacent inferior i superior.


Nivelul Aplicaie
Rol: realizeaz interfaa cu utilizatorul i interfaa cu aplicaiile, specific interfaa de lucru cu utilizatorul i
gestioneaz comunicaia ntre aplicaii. Acest strat nu reprezint o aplicaie de sine stttoare, ci doar
interfaa ntre aplicaii i componentele sistemelui de calcul.
Unitatea de date: mesajul

Nivelul Prezentare
Rol: transform datele n formate nelese de fiecare aplicaie i de calculatoarele respective,
asigur compresia datelor i criptarea.
Unitatea de date: -
14

Nivelul Sesiune
Rol: furnizeaz controlul comunicaiei ntre aplicaii. Stabilete, menine, gestioneaz i nchide conexiuni
(sesiuni) ntre aplicaii.
Unitatea de date: -

Nivelul Transport
Rol: transferul fiabil al informaiei ntre dou sisteme terminale (end points) ale unei comunicaii.
Furnizeaz controlul erorilor i controlul fluxului de date ntre dou puncte terminale, asigurnd ordinea
corect a pachetelor de date. Ofer un serviciu de transport de date care izoleaz nivelurile superioare
de orice specificitaii legate de modul n care este executat transportul datelor.
Unitatea de date: segmentul, datagrama

Nivelul Reea
Rol: determinarea cii optime pentru realizarea transferului de informaie ntr-o reea constituit din mai
multe segmente, prin fragmentarea i reasamblarea informaiei
Unitatea de date: pachetul

Nivelul Legtur de Date
Nivelul legatur de date se ocup cu adresarea fizica, topologia reelei, accesul la reea, detecia i
anunarea erorilor i controlul fluxului fizic (flow control).
Rol: furnizeaz un transport sigur, fiabil, al datelor de-a lungul unei legturi fizice, realiznd:
Controlul erorilor de comunicaie
Controlul fluxului de date
Controlul legturii
Sincronizarea la nivel de cadru
Unitatea de date: cadrul

Nivelul Fizic
Articol principal: Nivelul Fizic
Nivelul fizic definete specificaii electrice, mecanice, procedurale i functionale pentru activarea,
meninerea i dezactivarea legturilor fizice ntre sisteme.
Rol: transmiterea unui ir de bii pe un canal de comunicaie. Se
precizeaz modulaii, codri, sincronizri la nivel de bit. Un standard de nivel fizic definete 4 tipuri de
caracteristici:
15

Mecanice (forma i dimensiunile conectorilor, numrul de pini)
Electrice (modulaia, debite binare, codri, lungimi maxime ale canalelor de comunicaie)
Funcionale (funcia fiecrui pin)
Procedurale (succesiunea procedurilor pentru activarea unui serviciu)
Unitatea de date: bitul




2.5.2. Conectivitate IP, protocoale, MAC

Protocolul Internet (sau IP din engl. Internet Protocol) este o metod sau un protocol prin care datele
sunt trimise de la un calculator la altul prin intermediu Internetului. Fiecare calculator (cunoscut sub
denumirea de gazd), are pe Internet cel puin o adres IP unic, care l identific ntre toate
computerele din reea. Cnd cineva trimite sau primete informaii (de ex.: pot electronic, pagini web)
mesajul este mprit n blocuri de mici dimensiuni denumite pachete. Fiecare pachet cuprinde adresa
expeditorului i pe cea a destinatarului. Fiecare pachet este trimis, prima dat la un calculator-pasarel,
care nelege o mic parte din internet.
Calculatorul pasarel citete destinaia pachetelor i trimite pachetele ctre o alt pasarel, i aa mai
departe, pn ce pachetul ajunge la pasarela vecin cu computerul destinatar.
Adresa IP este utilizat la nivelul programelor de prelucrare n reea. n schimb, la nivelul utilizatorilor cu
acces la Internet, identificarea calculatoarelor se face printr-un nume de gazd gestionat de
sistemul DNS.

Funcionare
Comunicaia n Internet funcioneaz dup cum urmeaz: nivelul transport preia iruri de date i le divide
n datagrame. Teoretic, datagramele pot avea fiecare pn la 64 KO, dar n practic ele nu depesc
1500 de octei (pentru a intra ntr-un cadru Ethernet). Fiecare datagram este transmis prin Internet,
fiind eventual fragmentat n uniti mai mici pe parcurs. Cnd toate aceste fragmente ajung la maina
destinaie ele sunt reasamblate de nivelul reea n datagrama original. Datagrama este transparent
nivelului transport, care o insereaz n irul de intrare al procesului receptor. Cea mai mic adres este
0.0.0.0, iar cea mai mare 255.255.255.255. Adresa IP 0.0.0.0 este folosit de gazde atunci cnd sunt
pornite. Adresele IP cu 0 ca numr de reea se refer la reeaua curent. Aceste adrese permit ca
mainile s acceseze propria reea fr a cunoate numrul de reea (dar trebuie cunoscut clasa reelei
pentru a ti cte zerouri trebuie introduse). Adresele care constau numai din 1-uri permit difuzarea n
reeaua curent, n mod uzual o reea local. Toate adresele de forma 127.xx.yy.zz sunt rezervate pentru
16

testri n bucl local. Pachetele trimise ctre aceast adres nu sunt trimise prin cablu ele sunt
prelucrate local i tratate ca pachete sosite.
O datagram IP (un pachet) const dintr-o parte de antet i o parte de text. Antetul are o parte fix de 20
octei i o parte opional de lungime variabil.
Fiecare gazd i ruter din internet are o adres IP, care codific adresa sa de reea i de gazd.
Combinaia este unic: n principiu nu exist dou maini cu aceeai adres IP. Toate adresele IP sunt
de 32 bii i sunt folosite n cmpurile Adres surs i Adres destinaie a pachetelor IP. Este
important de observat c o adres IP nu se refer la o gazd. Se refer, de fapt, la o interfa de reea.
Cu alte cuvinte, dac o gazd este n dou reele, trebuie s foloseasc dou adrese IP .
Reelele sunt dinamice i este posibil ca 2 pachete IP de la aceeai surs s plece pe ci diferite (BGP
protocolul porilor de grani) i s ajung la aceeai destinaie. Pachetele IP (dupa cum s-a mai spus) nu
au garania c vor ajunge la destinaie, acest lucru fiind lsat n seama protocoalelor adiacente (TCP
UDP etc).



Protocoale de comunicatie
Exemple de protocoale din stiva OSI
7 Aplicaie ex.: HTTP, SMTP, SNMP, FTP, Telnet, SIP, SSH, NFS, RTSP, XMPP, Whois, ENRP
6 Prezentare ex.: XDR, ASN.1, SMB, AFP, NCP
5 Sesiune
ex.: ASAP, TLS, SSH, ISO 8327 / CCITT X.225, RPC, NetBIOS, ASP, Winsock, BSD
sockets, NCP (Network Core Protocol),NFS (Network File System)
4 Transport ex.: TCP, UDP, RTP, SCTP, SPX, ATP, IL
3 Reea
ex.: IP, ICMP, IGMP, IPX, BGP, OSPF, RIP, IGRP, EIGRP, ARP, RARP, X.25 (Packet
Switching)
2
Legtura
de date
ex.: Ethernet, Token ring, HDLC, Frame relay, ISDN, ATM, 802.11 Wi-Fi, FDDI, PPP
1 Fizic ex.: cablu coaxial, radio, fibr optic, cablu bifilar torsadat, fire cupru


17


Adres MAC

n informatic, o adres Media Access Control (adres MAC) este un numr ntreg pe 6 octei
(48 bii) pe reelele Token-ring sau Ethernet folosit la identificarea unui calculator ntr-o reea local. Iniial
s-a dorit ca aceste adrese MAC s fie unice distribuindu-se zone contigue de adrese MAC la diferii
productori de interfee de reea. Relativ de curnd

adresele MAC sunt configurabile, aa c dezideratul
privind unicitatea lor a nu se mai poate realiza.
In domeniul reelisticii mai este cunoscuta i sub denumirile echivalente de adresa fizica sau adresa
hardware. Denumirea oficiala data de IEEE (Institute of Electrical and Electronics Engineers) este EUI-
48 (pentru varianta de 48 de bii) sau EUI-64 (cea de 64 de bii), EUI reprezentnd acronimul de
la Extended Unique Identifier.









18


4.Etapele realizarii proiectului
Prima etapa a proiectului a fost constituita de interpretarea corecta a
conditiilor proiectului; astfel a trebuit in primul rand, sa inteleg exact cu ce fel de
server trebuie sa lucrez: server-ul este chiar Arduino.
Odata inteleasa problema, a urmat partea de documentare. Exista foarte
multe aplicatii pe Internet ce masoara temperatura, insa extrem de putine care sa
o faca accesibila si din alt device decat cel cu care se lucreaza cu Arduino. In plus
aplicatia avea nevoie si de o parte grafica (tablel si inca un obiect grafic dinamic).
Dupa cautari indelungate, doar doua aplicatii semanau cu ceea ce se dorea a fi
obiectul proiectului; fiecare dintre acestea aveau un anumit neajuns (prima
aplicatie compromitea partea grafica, insa spre deosebire de cea de-a doua oferea
o stocare profesionista a datelor: spun profesionista pentru ca stoca datele intr-o
baza de date MySQL, care putea fi exploatata web, bineinteles cu ajutorul unui
server Apache si prin intermediul mediului de programare web PHP).
Initial am ales varianta care oferea si stocarea datelor, gandindu-ma ca voi
rezolva si partea grafica printr-un javascript chiar daca o faceam intr-un mod mai
rudimentar, insa aceasta varianta s-a dovedit infunctionabila (detalii in capitolul 5)
prin urmare am fost nevoit sa recurg la cea de-a doua metoda.
Trebuia gasita o solutie de hosting a site-ului. In cele din urma am optat
pentru un (sub)domeniu platit, host-at pe unul din serverele celor de la Urlmania.
A urmat crearea site-ului, cu importarea scripturilor ce asigura partea de
grafica (un tabel dinamic, o solutie ce imbina cele doua obiecte grafice, din
cerintele proiectului) si uploadarea sketch-ului in memoria Arduino (desi acesti
ultimi doi pasi, la prima vedere pareau o formalitate, in practica lucrurile s-au
dovedit a fi diferite; deasemenea detalii in capitolul urmator).
Ultimul pas si cel mai important a fost stabilirea parametrilor de retea (IP,
MAC, default gateway, subnet mask) cu rol in stabilirea legaturii dintre server si
clientul web.
19

Nici una din etapele de mai sus nu a fost lipsita de problema. O mare parte
a lor a fost rezolvata, motiv pentru care proiectul a prins conturul dorit si astfel s-
a definitivat si prima versiune a acestuia.
Desi din cele scrise mai sus se poate asteapta la o grafica extraordinara, tin
sa precizez ca am facut referire la motorul grafic sau elementul de baza al
graficii proiectului: tabelul dinamic. Grafica site-ului este aproape inexistenta,
dintr-un motiv simplu de inteles: in prima faza lucrurile trebuie facute sa
functioneze corespunzator si abia apoi trebuie sa impresioneze din punct de
vedere grafic. Astfel urmatoarea versiune a proiectului va aduce o imbunatatire
considerabila si in acest sens.














20


5. Probleme intampinate in realizarea proiectului (prezentarea in ordinea
cronologica)
5.1. Probleme solutionate

Prima problema cu care m-am confruntat a fost, dupa cum am precizat si in
capitolul anterior, problema gasirii serverului. Am inceput prin a cauta notiuni
generale despre servere; aproape toate cautarile imi afisau un server hardware
dedicat (care era aproximativ cat jumatatea dintr-un sistem desktop). Era evident
ca nu era ceea ce cautam, avand in vedere ca una din calitatiile proiectului era
portabilitatea. Dupa cautari repetate, in ceea de-a doua zi, m-am oprit asupra
unei pagini web care descria un server Apache (si in prima zi am gasit cateva
pagini care faceau referire la Apache, insa le-am ignorat necunoscand ce
presupunea). Mi se parea ca seamana destul de mult cu ceea ce aveam nevoie din
punct de vedere al serverului, insa era doar o parere gresit (intr-adevar Apache
era o solutie pentru un server web, dar nu trebuie confundat cu serverul de unde
clientul web trebuia sa preia datele). Dupa ce am mai citit despre relatia client-
server si facand legatura cu ceea ce cunosteam atat din domeniul retelisticii cat si
depre Arduino, mi-am dar seama ca serverul este chiar Arduino. Logic! clientul se
conecteaza la Arduino, iar acesta din urma detine datele instantanee referitoare
la temperatura. Ceea ce ma inducea in eroare era faptul ca asociam serverul cu
ceva care stocheaza informatia; in fapt asa se si intampla, insa Arduino stocheaza
informatia doar instant, suficient cat sa fie transimisa catre client, gratie functiei
call-back care efectueaza cereri repetate catre server (in acest caz aproximativ 3
cereri pe secunda)
O alta problema solutionata a fost aceea a dublei adaptari a codului: codul
trebuie adjustat atat pentru situatia de lucru ( IP, default gateway si network
mask variabile in functie de punctul unde era conectat laptop-ul cu care lucram la
retea), cat si pentru shield-ul Ethernet de care am dispus aproape intreaga
perioada a desfasurarii proiectului (era o versiune ceva mai veche si nu mai
corespundeau toate numele functiilor; am rezolvat aceasta problema prin
21

urmarirea unor exemple proprii Ethernetului pe care lucram, de exemplu: functia
Client trebuia apelata ca EthernetClient s.a.m.d.).
Pentru setarea datelor de conectare trebuie tinut cont de urmatoarele: IP-
ul setat pentru shield-ul Ethernet trebuie sa faca parte din range-ul de IP-uri ale
retelei in care va functiona proiectul (pentru acest lucru ne ajutam de comanda:
ipconfig /all pe care o dam in linie de comanda), default gateway va fi adresa
primului router, iar network mask va fi acceasi cu cea atribuita de provider
(deasemenea se foloseste linia de comanda pentru determinarea acesteia; este
de tipul 255.x.x.x , unde x=0...255)

Scripturile care sustineau partea grafica (tabelul dinamic) au pus si ele o
problema destul de serioasa: tabelul era afisat, insa nu se plota nimic. Solutia a
fost sa preiau nu numai html-ul si scripturile; trebuia preluat si codul CSS pe care
l-am omis.
Dupa ce am cumparat spatiu pentru hostare, nu puteam accesa panoul de
control al serverului. Problema: portul pe care asculta serverul, era blocat sau
inclus in lista de untrusted de catre administratorul retelei capusului. Solutia:
folosirea de trafic extern; existau 2 posibilitati: fie folosirea unui smartphone cu
Android pentru share de trafic, sau folosirea unei metode de tunelare (port
forwarding) care sa ocoleasca firewall-ul providerului (era necesar si un calculator
ce facea parte dintr-o retea externa). Detalii :
http://www.irongeek.com/i.php?page=videos/sshdynamicportforwarding
Am ales prima din cele doua variante, fiind de altfel si mai putin costisitoare.