1

2

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

3

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

4

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.

5

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.

6

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

7

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)

8

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”).

9

2.3. Notiuni introductive despre Arduino

Arduino este o platformă gratuită destinată celor pasionați de electronică, studenți și ingineri din

domeniu deopotrivă, dar și celor care doar au ca hobby construirea de montaje electronice.

Arduino este atât un produs software cât și un concept, extinzând conceptul open source și asupra

realizărilor 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 funcționa de sine stătător dar pot interacționa

cu aplicații care funcționează pe un calculator precum Flash, Processing, MaxMSP.

Cu platformele fizice Arduino puteți transforma calculatorul dumneavoastră într-un instrument de

măsură 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 incărcate pe

platformele fizice Arduino. Interfața este scrisă in Java și mediul de programare folosește limbaje de

programare de tip open source precum Processing, avr-gcc. Interfața este multiplatformă, putând

rula în Windows©, Mac OS X© și Linux. Programul poate fi obținut atât ca executabil specific

platformei de lucru pe care o aveți dar și sub formă de cod sursă pe care il puteți compila conform

condițiilor specifice pe care le aveți.

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. Atât placa de bază cât și circuitul integrat

programabil pot fi diferite, ceea ce conferă proiectelor realizate o flexibilitate in proiectare deosebită.

10

2.4 Arduino Ethernet Shield

DescriereArduino 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. Chip—ul 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 tehniceScutul 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 comunicație ierarhică foarte des folosită pentru a realiza o rețea de calculatoare. OSI este un standard

al Organizației internaționale de standardizare, emis în 1984.

Modelul de Referință OSI oferă metode generale pentru realizarea comunicației sistemelor de

calcul pentru ca acestea să poată schimba informații, indiferent de particularitățile constructive ale

sistemelor (fabricant, sistem de operare, țară, etc). Modelul de Referință are aplicații în toate domeniile

comunicațiilor de date, nu doar în cazul rețelelor de calculatoare.

Modelul OSI divizează problema complexă a comunicării între două sau mai multe sisteme în 7 straturi

numite și niveluri (layers) distincte, într-o arhitectură ierarhică. Fiecare strat (nivel) are funcții bine

determinate și comunică doar cu straturile adiacente. Cele 7 niveluri ale Modelului de Referință se

numesc: Aplicație (nivelul 7, superior) , Prezentare, Sesiune, Transport, Rețea, Legătură de date, Fizic

11

(nivelul 1, inferior). Termenii corespunzători din engleză

sunt Application,Presentation, Session, Transport, Network, Data link, Physical

Notă. Pentru o mai bună înțelegere a imaginii de mai sus, comunicația pe verticală de la un element la cel

imediat superior sau inferior (săgețile albastre) respectă regulile interfeței respective, în timp ce

comunicația (indirectă) pe orizontală între un element verde și unul albastru respectă protocolul nivelului

respectiv.

Când 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ă

Aplicația 1 trimite Aplicației 2 mai întâi un prim mesaj, de exemplu "Ești liber și stăpânești

protocolul FTP?". Pentru "conversația" lor aplicațiile trebuie să folosească un protocol de aplicație

predefinit. Protocoalele de pe fiecare nivel prescriu până la ultimul amănunt cum anume se "vorbește", ce

se spune și mai ales în ce ordine, astfel încât participantul celălalt să "înțeleagă" despre ce este vorba. În

acest exemplu însă, Aplicația 1 nu are legătură directă/fizică cu Aplicația 2. O legătura fizică există, dar

se află departe - la fundul "stivei" de protocoale. Metoda Modelului OSI prevede ca mesajul Aplicației 1

destinat Aplicației 2 să fie mai întâi predat nivelului de mai jos = Prezentare 1, printr-o interfață specială.

Acest nivel "vorbește" la rândul său cu nivelul său omolog din stiva 2, anume Prezentare 2, pentru care

se folosește de protocolul necesar. Dar nici cele 2 niveluri de Prezentare nu sunt legate direct între ele.

12

Nivelul Prezentare 1 predă atunci cele dorite în jos, nivelului Sesiune 1 (iarăși printr-o interfață

specializată).

Această procedură se continuă în jos până se atinge Nivelul fizic 1. Abia acesta posedă o legătură fizică

cu omologul său, Nivelul fizic 2, de exemplu printr-un cablu. De aici informația se propagă spre

participantul 2 de jos în sus, printr-o serie de interfețe, până într-un bun sfârșit se atinge nivelul Aplicație

2, respectiv Participant 2, cu care Aplicația 1 voia inițial să "vorbească". Din punct de vedere al Aplicației

1, ea doar pare că duce o conversație directă cu Aplicația 2, conform prescripțiilor din protocolul de

aplicație ales. În realitate ea schimbă informații doar cu nivelul Prezentare 1, imediat vecin, prin interfața

respectivă.

Avantajul acestei metode stratificate este că nici Aplicația 1, și nici măcar programatorul ei (!!!) nu trebuie

să cunoască deloc sarcinile și soluțiile de la nivelurile inferioare, ci doar una sau 2 interfețe, î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 legătură (de la nivelul Nivelului fizic) printr-un canal radio. Specific pentru

canale radio poate fi rata mare de greșeli de transmisie, care desigur trebuiesc corectate automat, în

funcție de să zicem condițiile atmosferice, caz care însă nu se întâmplă niciodată la cablul de cupru. Și cu

toate astea, Aplicația 1 nu trebuie modificată.

Funcțiile nivelurilor

La baza stabilirii nivelelor arhitecturale ale modelului ISO OSI au stat o serie de principii generale, cum ar

fi:

crearea unui număr redus de nivele cu puține interactiuni între ele;

colectarea funcțiilor înrudite în același nivel;

crearea posibilitații de modificare a funcțiilor unui nivel, fără afectarea celorlalte;

crearea pentru fiecare nivel de linii de demarcație (interfețe) spre nivelul adiacent inferior și superior.

Nivelul Aplicație

Rol: realizează interfața cu utilizatorul și interfața cu aplicațiile, specifică interfața de lucru cu utilizatorul și

gestionează comunicația între aplicații. Acest strat nu reprezintă o aplicație de sine stătătoare, ci doar

interfața între aplicații și componentele sistemelui de calcul.

Unitatea de date: mesajul

Nivelul Prezentare

Rol: transformă datele în formate înțelese de fiecare aplicație și de calculatoarele respective,

asigură compresia datelor și criptarea.

Unitatea de date: -

13

Nivelul Sesiune

Rol: furnizează controlul comunicației între aplicații. Stabilește, menține, gestionează și închide conexiuni

(sesiuni) între aplicații.

Unitatea de date: -

Nivelul Transport

Rol: transferul fiabil al informației între două sisteme terminale (end points) ale unei comunicații.

Furnizează controlul erorilor și controlul fluxului de date între două puncte terminale, asigurând ordinea

corectă a pachetelor de date. Oferă un serviciu de transport de date care izolează nivelurile superioare de

orice specificitații legate de modul în care este executat transportul datelor.

Unitatea de date: segmentul, datagrama

Nivelul Rețea

Rol: determinarea căii optime pentru realizarea transferului de informație într-o rețea constituită din mai

multe segmente, prin fragmentarea și reasamblarea informației

Unitatea de date: pachetul

Nivelul Legătură de Date

Nivelul legatură de date se ocupă cu adresarea fizica, topologia rețelei, accesul la rețea, detecția și

anunțarea erorilor și controlul fluxului fizic (flow control).

Rol: furnizează un transport sigur, fiabil, al datelor de-a lungul unei legături fizice, realizând:

Controlul erorilor de comunicație

Controlul fluxului de date

Controlul legăturii

Sincronizarea la nivel de cadru

Unitatea de date: cadrul

Nivelul Fizic

Articol principal: Nivelul Fizic

Nivelul fizic definește specificații electrice, mecanice, procedurale și functionale pentru activarea,

menținerea și dezactivarea legăturilor fizice între sisteme.

Rol: transmiterea unui șir de biți pe un canal de comunicație. Se

precizează modulații, codări, sincronizări la nivel de bit. Un standard de nivel fizic definește 4 tipuri de

caracteristici:

14

Mecanice (forma și dimensiunile conectorilor, numărul de pini)

Electrice (modulația, debite binare, codări, lungimi maxime ale canalelor de comunicație)

Funcționale (funcția fiecărui 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 puțin o adresă IP unică, care îl identifică între toate

computerele din rețea. Când cineva trimite sau primește informații (de ex.: poștă electronică, pagini web)

mesajul este împărțit î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 înțelege o mică parte din internet.

Calculatorul pasarelă citește destinația pachetelor și trimite pachetele către o altă pasarelă, și așa mai

departe, până ce pachetul ajunge la pasarela vecină cu computerul destinatar.

Adresa IP este utilizată la nivelul programelor de prelucrare în rețea. În schimb, la nivelul utilizatorilor cu

acces la Internet, identificarea calculatoarelor se face printr-un nume de gazdă gestionat de

sistemul DNS.

Funcționare

Comunicația în Internet funcționează după cum urmează: nivelul transport preia șiruri de date și le divide

în datagrame. Teoretic, datagramele pot avea fiecare până la 64 KO, dar în practică ele nu depășesc

1500 de octeți (pentru a intra într-un cadru Ethernet). Fiecare datagramă este transmisă prin Internet,

fiind eventual fragmentată în unități mai mici pe parcurs. Când toate aceste „fragmente” ajung la mașina

destinație ele sunt reasamblate de nivelul rețea î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 când sunt

pornite. Adresele IP cu 0 ca număr de rețea se referă la rețeaua curentă. Aceste adrese permit ca

mașinile să acceseze propria rețea fără a cunoaște numărul de rețea (dar trebuie cunoscută clasa rețelei

pentru a ști câte zerouri trebuie introduse). Adresele care constau numai din 1-uri permit difuzarea în

rețeaua curentă, în mod uzual o rețea locală. Toate adresele de forma 127.xx.yy.zz sunt rezervate pentru

15

testări în buclă locală. Pachetele trimise către 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

octeți și o parte opțională de lungime variabilă.

Fiecare gazdă și ruter din internet are o adresă IP, care codifică adresa sa de rețea și de gazdă.

Combinația este unică: în principiu nu există două mașini cu aceeași adresă IP. Toate adresele IP sunt

de 32 biți și sunt folosite în câmpurile „Adresă sursă” și „Adresă destinație” 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 rețea.

Cu alte cuvinte, dacă o gazdă este în două rețele, trebuie să folosească două adrese IP .

Rețelele sunt dinamice și este posibil ca 2 pachete IP de la aceeași sursă să plece pe căi diferite (BGP –

protocolul porților de graniță) și să ajungă la aceeași destinație. Pachetele IP (dupa cum s-a mai spus) nu

au garanția că vor ajunge la destinație, acest lucru fiind lăsat în seama protocoalelor adiacente (TCP

UDP etc).

Protocoale de comunicatie

Exemple de protocoale din stiva OSI

7 Aplicație ex.: HTTP, SMTP, SNMP, FTP, Telnet, SIP, SSH, NFS, RTSP, XMPP, Whois, ENRP

6 Prezentare ex.: XDR, ASN.1, SMB, AFP, NCP

5 Sesiuneex.: 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 Rețeaex.: IP, ICMP, IGMP, IPX, BGP, OSPF, RIP, IGRP, EIGRP, ARP, RARP, X.25 (Packet

Switching)

2Legătura

de dateex.: 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

16

Adresă MAC

În informatică, o adresă Media Access Control (adresă MAC) este un număr întreg pe 6 octeți

(48 biți) pe rețelele Token-ring sau Ethernet folosit la identificarea unui calculator într-o rețea locală. Inițial

s-a dorit ca aceste adrese MAC să fie unice distribuindu-se zone contigue de adrese MAC la diferiți

producători de interfețe de rețea. Relativ de curând adresele MAC sunt configurabile, așa că dezideratul

privind unicitatea lor a nu se mai poate realiza.

In domeniul rețelisticii 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 biți) sau EUI-64 (cea de 64 de biți), EUI reprezentând acronimul de la Extended

Unique Identifier.

17

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.

18

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.

19

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

20

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.

21