Sistema de automação para ambientes usando Arduíno e Android

(1)

ESTADO DO RIO GRANDE DO SUL

DEPARTAMENTO DE CIÊNCIAS EXATAS E

ENGENHARIAS

CIÊNCIA DA COMPUTAÇÃO

ÉDER PAULO PEREIRA

SISTEMA DE AUTOMAÇÃO PARA

AMBIENTES USANDO ARDUÍNO E ANDROID

Ijuí

2016

(2)

SISTEMA DE AUTOMAÇÃO PARA AMBIENTES

USANDO ARDUÍNO E ANDROID

Trabalho de Conclusão de Curso apresen-tado ao Colegiado de Coordenação do Curso de Ciência da Computação da Uni-versidade Regional do Noroeste do Estado do Rio Grande do Sul (UNIJUÍ), apresen-tado como requisito parcial para obtenção do Título de Bacharel em Ciência da Com-putação

Orientador: Dsc. Edson Luiz Padoin

Ijuí

2016

(3)

SISTEMA DE AUTOMAÇÃO PARA AMBIENTES

USANDO ARDUÍNO E ANDROID

Trabalho de Conclusão de Curso apresen-tado ao Colegiado de Coordenação do Curso de Ciência da Computação da Uni-versidade Regional do Noroeste do Estado do Rio Grande do Sul (UNIJUÍ), apresen-tado como requisito parcial para obtenção do Título de Bacharel em Ciência da Com-putação

Trabalho aprovado. Ijuí, 08 de Julho de 2016:

Dsc. Edson Luiz Padoin

Orientador

Msc. Romário Lopes Alcântara

Banca

Ijuí

2016

(4)

(5)

Agradeço à Deus, pela força, vida concedida e por tudo o que tem feito. À minha esposa Cristina, pela paciência e compreensão, foram momentos que abrimos mão de muitas coisas para que este trabalho ficasse pronto. Ao meu orientador, professor Padoin, pela dedicação, competência, e por acreditar e insistir em mim, mesmo quando nem eu acreditava no meu trabalho. À minha família em geral, sempre presente nos momentos em que precisei. Ao meu colega, Pablo Pavan, pela paciência e camaradagem no ensino dos conceitos mais básicos de eletrônica, valeu jovem. Ao meu outro colega, Mathias Berwig, pelos ensinamentos do Android. À todos, que de certa forma, ajudaram ou atrapalharam, afinal, é resultado de tudo isso este trabalho.

(6)

(7)

Vivemos em uma sociedade cada vez mais interconectada. Redes sociais estão à todo vapor, aplicativos para smartphones se tornam sucesso do dia para a noite. Isso tudo demonstra uma demanda cada vez mais por soluções que atendam à este escopo, e que nos proporcionem certa autonomia nas nossas vidas.

Pensando nisso, este trabalho tem como principal tema, tentar automatizar um ambiente remoto, de forma que possamos conseguir interagir com este ambiente à distância, usando a internet. O objetivo é tentar interligar diferentes dispositivos, no sentido de arquitetura, mas que através do software corretamente programado, seja viável realizar esta ligação para oferecer uma solução final adequada. Para isso, usaremos diversas tecnologias, como System on Chip, Android, Arduíno, Rest, Json, dentre outras. Cada uma destas partes compõem partes fundamentais para que o trabalho possa ser realizado.

A solução em que chegamos, atendeu a expectativa que esperávamos, a qual nos dá uma enorme lista de possibilidades para o futuro, que virão como melhorias do que já está implementado.

(8)

We live in a society increasingly interconnected. Social networks are at full speed, applications for smartphones become successful overnight. This all shows an increasing demand for solutions that comply with this scope, and we provide some autonomy in our lives.

Thinking about it, this work has as its main theme, try to automate a remote environment, so that we may be able to interact with this environment remotely, using the internet. The goal is to try to connect different devices in order architecture, but by properly programmed software performing the connection is feasible to provide a suitable final solution. For this, we use various technologies, such as System on Chip, Android, Arduino, Rest, Json, among others. Each of these parts make up key parts so that the work can be performed.

The solution we arrived we met the expectations we had hoped, which gives us a huge list of possibilities for the future, which will come as improvements than is already implemented.

(9)

Figura 1 – Arduíno Uno R3 . . . 19

Figura 2 – Shield Ethernet para Arduíno . . . 20

Figura 3 – ARDUÍNO com um Shield Ethernet sobre ele . . . 20

Figura 4 – Relé Shield para Arduíno . . . 21

Figura 5 – Código padrão de um sketch na IDE do arduíno . . . 22

Figura 6 – Mercado de sistemas operacionais mobile . . . 25

Figura 7 – Arquitetura do sistema Android . . . 26

Figura 8 – Objeto Json . . . 33

Figura 9 – Lista dentro do Json . . . 33

Figura 10 – Amazon - Seleção do Sistema Operacional . . . 36

Figura 11 – Página inicial na Amazon . . . 36

Figura 12 – Grupos de segurança da nossa instância . . . 37

Figura 13 – Tabela de leituras . . . 38

Figura 14 – Página inicial do site www.registro.br . . . 41

Figura 15 – Página de configuração de zonas do site . . . 42

Figura 16 – Página padrão do servidor Apache . . . 43

Figura 17 – Estrutura do projeto PHP . . . 45

Figura 18 – Classe DbConnect . . . 45

Figura 19 – Classe DbOperation . . . 46

Figura 20 – Includes no arquivo index . . . 47

Figura 21 – Rota que nos retorna as leituras ao longo do dia . . . 47

Figura 22 – JsonArray com as leituras do dia . . . 48

Figura 23 – IP fixo no Arduino . . . 50

Figura 24 – Nosso Arduino . . . 50

Figura 25 – Sensor DHT11 para Arduino . . . 51

Figura 26 – Relé que aciona a lâmpada . . . 55

Figura 27 – Lâmpada ligada através do Arduino . . . 56

Figura 28 – Lâmpada desligada através do Arduino . . . 57

Figura 29 – Tela inicial do Android Studio . . . 59

Figura 30 – Tela inicial do Android Studio com projeto padrão . . . 60

Figura 31 – Arquivo de layout padrão do Android Studio . . . 61

Figura 32 – Mockup do aplicativo . . . 64

Figura 33 – Definição do gráfico no arquivo de layout . . . 65

Figura 34 – Definição do método onCreate da Activity . . . 65

(10)

(11)

(12)

IoT Internet of Things

SGBD Sistema de Gerenciamento de Banco de Dados

ARM Advanced Risc Machine

RISC Reduced Instruction Set Computer CISC Complex Instruction Set Computer REST Representational State Transfer SDK Software Development Kit JVM Java Virtual Machine MVC Model View Controller

DNS Domain Name System

RFC Request For Comments

IETF Internet Engineering Task Force IDE Integrated Development Environment

EC2 Elastic Computing

SSH Secure SHell

TCP Transmission Control Protocol XML eXtensible Markup Language

(13)

1 INTRODUÇÃO . . . . 14 2 ESTADO DA ARTE . . . . 16 2.1 MPSoC . . . . 16 2.1.1 ARM . . . 17 2.1.2 ARDUÍNO . . . 19 2.2 Cloug Computing . . . . 22 2.3 SGBD . . . . 24 2.4 Android . . . . 24 2.5 Automação de Ambientes . . . . 26 2.6 API’s e Rest . . . . 27 2.6.1 GET . . . 28 2.6.2 POST . . . 28 2.6.3 Códigos de Status . . . 29 2.6.4 Json . . . 32 3 DESENVOLVIMENTO DO BACK-END . . . . 35

3.1 Alocando um Servidor na Amazon . . . . 35

3.2 O Banco de Dados . . . . 37

3.2.1 Instalação . . . 37

3.3 Instalação do Servidor Web . . . . 38

3.3.1 Reservando um Domínio no registro.br . . . 39

3.3.1.1 O Servidor DNS . . . 40 3.3.2 O Rest . . . 43 3.3.2.1 Semântica de Recursos . . . 43 3.3.2.2 Sobre o SlimFramework . . . 44 3.4 O Arduíno . . . . 49 4 DESENVOLVIMENTO DO FRONT-END . . . . 58 4.1 Android . . . . 58 4.1.1 Conceitos Básicos . . . 58 4.1.2 Material Design . . . 62 4.1.3 Aplicativo Desenvolvido . . . 62

4.2 Consumindo os Recursos do Rest . . . . 63

(14)

(15)

Atualmente, as pessoas estão cada vez mais conectadas. Se observarmos dez anos atrás, em 2006, jamais imaginaríamos que nos dias atuais, teríamos tantas possibilidades de conectividade na grande rede. A internet evoluiu, protocolos novos surgiram, novos gadgets cada vez mais modernos, com tantas possibilidades.

Permanecemos conectados ao trabalho, com nossos filhos, ou com outros dispositivos. Redes sociais nunca foram tão utilizadas como agora. Pais, ao nascer seu primeiro filho, já anunciam na rede social, para atingir um número cada vez maior de pessoas.

Agora, vivemos na era do que o IDC chama de terceira plataforma (IDC, 2015). De forma resumida, na primeira plataforma tivemos o que eram os Mainframes, depois na segunda, os computadores e redes lan, arquiteturas cliente e servidor. Tudo isso contribuiu para o surgimento da então falada terceira plataforma. Nela, temos uma explosão de novas tecnologias como por exemplo robótica, sistemas cognitivos, impressão 3D e também a famosa IoT. Tudo isso, em uma base sólida, como a computação em nuvem dando apoio computacional necessário. Termos novos surgiram, como por exemplo o BigData, onde temos um altíssimo volume de dados sendo gerado diariamente através dos mais diversos mecanismos, como redes sociais, dados de instituições financeiras, sensores conectados à internet gerando informações. Temos aí, um enorme background de milhões de aplicações, bilhões de usuários e trilhões de coisas conectadas. Estas coisas, são literalmente qualquer coisa que se queira ter conectividade. Podemos citar um tênis, nossa geladeira, nosso carro, nossa casa.

Neste contexto, falando de automação de ambientes, que é o objetivo deste trabalho, temos uma pesquisa recente, feita no ano de 2015 pelo instituto McKinsey, o qual pesquisou 2.000 americanos sobre algumas dificuldades sobre novos gadgets para conectividade, e os números são interessantíssimos. Das pessoas que não usam ainda estas novas tecnologias, temos: 51% acidentalmente já deixou a luz ligada em suas casas ao sair; 41% esqueceu o televisor ou outro aparelho ligado, consumindo energia; 36% gostaria de saber o que está acontecendo em seus lares, a partir de um ambiente remoto; 35% já esqueceu o aparelho de ar-condicionado ligado acidentalmente; por fim, 31% ao sair de casa, não lembra se trancou todas a portas e janelas da sua casa. O relatório da pesquisa demonstra que estes usuários frequentemente exibem comportamentos que indicam uma demanda latente para soluções conectadas. (KABIR AHUJA ; JEREMY, 2015).

(16)

Pegando uma carona no advento da Internet das Coisas, este trabalho visa demonstrar uma integração entre dispositivos que compõe-se de diferentes arquiteturas, mas que quando programados de forma correta, é possível integrá-los e fazer funcionar de forma correta. O resultado final é um aplicativo para o sistema operacional Android, onde de forma remota, se consegue obter dados relacionados à algum ambiente; feito isso, podemos aplicar este conceito à qualquer ambiente ou objeto que esteja em um ambiente remoto e desejamos controlar ou interagir. Também será possível, além de ler informações como temperatura e umidade, interagir, como acionar uma lâmpada, tudo isso eu repito, de forma remota.

No Capítulo 2, trataremos sobre o estado da arte das tecnologias que utilizamos neste trabalho. Basicamente, um apanhado geral sobre tecnologias como Android, PHP, Mysql, Rest, Cloud Computing, dentre outros termos que, juntando tudo, cada um será uma engrenagem que irá compor o trabalho final.

O terceiro capítulo irá tratar das ações tomadas no back-end, ou seja, o que fica atuando nos bastidores. Aqui, tratarei do processo de configuração do Arduíno, uso de bibliotecas, configuração do nosso servidor Rest na nuvem, definição dos métodos no Rest usanto o framework Slim, baseado na linguagem de programação PHP.

No Capítulo 4, abordaremos sobre o desenvolvimento do aplicativo em si. Aqui, iremos falar desde a concepção do aplicativo, os objetivos, como foi feito, baseado no modelo que foi definido no Capítulo 3.

Por fim, apresentamos algumas considerações finais, mencionando as dificul-dades envolvidas, o que seria recomendado para os trabalhos futuros.

(17)

2.1 MPSoC

Abreviação de Multi Processor System On Chip, ou em uma tradução livre, sis-tema em um chip multi-processado. Trata-se, basicamente, de um sissis-tema embarcado, com processador, memória Ram e armazenamento, tudo isso dentro de um único chip, como o nome sugere. Conforme o autor (MAGALHÃES, 2013, p. 26) diz que:

Em sistemas embarcados multiprocessados, duas ou mais CPUs com um consumo de energia reduzido são utilizadas, diminuindo assim suas frequências de operação e, consequentemente sua capacidade compu-tacional. Porém, graças ao uso de paralelismo, esses sistemas ainda são capazes de realizar tarefas complexas, pois a carga de processa-mento total pode ser dividida entre todas as unidades do sistema e executar em paralelo, compensando a menor capacidade de cada CPU.

Como podemos observar na citação do autor, vemos que as habilidades do software trabalhar com o paralelismo abrem caminho para estas arquiteturas de baixo consumo de energia. Um exemplo clássico, podemos dizer, é o uso dos smartphones, os quais normalmente têm 2 ou mais cores de processamento, alcançando facilmente a frequência de 1,2 GHz de frequência de clock de processamento.

Esta tecnologia nos proporciona seu emprego em diversas áreas, como pode-mos citar, um sistema de controle em uma usina nuclear, um smartphone como já foi citado, ou ainda, um sistema de controle de pouso de um avião. Todos eles são alguns exemplos de aplicações que antes, demandavam computadores mais poderosos e com consumo de energia maior, e agora, cabem na palma de nossa mão.

Em se tratando de smartphones, podemos ainda, ter divisões de tarefas. (MA-GALHÃES, 2013) cita que:

Um outro possível cenário de uso de clusters é a divisão das aplicações conforme suas características, isolando as tarefas que compõem o sis-tema entre diferentes domínios. Por exemplo, em um sissis-tema multimídia (...) aonde é possível observar quatro domínios, cada qual com uma especialização: vídeo, áudio, entrada/saída e memória.

Ou seja, agora podemos ter alguns cores dedicados à um tipo específico de serviço, o que nos traz algumas vantagens, como por exemplo, o consumo de energia que é ainda menor, em função de não termos todos os cores sempre ligados trabalhando na mesma função.

(18)

2.1.1 ARM

ARM é o acrônimo de Advanced Risc Machine, ou máquina com um conjunto de instruções reduzidas avançadas. Conforme os autores (TORRES; MOURA; PILLA, ) a arquitetura ARM é superescalar, ou seja, podemos ter a execução de vários processos, desde que estes processos não estejam no mesmo estágio do pipeline.

Isto é importante, pois podemos constatar atualmente que os nossos dispo-sitivos com esta arquitetura, rodando um software que foi projetado para ele, nos entrega uma experiência única, pois temos um desempenho muito bom, e um baixís-simo consumo de energia. Os autores (TORRES; MOURA; PILLA, ) nos dizem que se compararmos um core de utilização normal e um core ARM, o segundo é mais simples, o que nos possibilita uma construção de um processador com um conjunto pequeno de transístores, e permitindo a inserção de uma quantidade maior de componentes voltados às aplicações específicas.

Conforme o autor (SAMPAIO, 2011, Pg. 28), descreve sobre processadores ARM que:

Como todos os processadores RISC, o ARM usa uma arquitetura do tipo load-store. Isto quer dizer que existem dois tipos de instruções para mover dados para dentro ou para fora do computador: instruções de carregamento (ou load), que copiam dados da memória para os registros internos do processador e funções de armazenamento (ou store), que fazem a cópia de dados dos registros internos para a memória. Não há nenhuma instrução que faça a manipulação dos dados diretamente na memória, logo, todo o processamento é feito dentro do processador. Cada instrução que chega no processador é tratada inicialmente pelo Instruction Decoder. Dentre outras coisas, este bloco é responsável por identificar a qual conjunto de instruções cada instrução pertence. O Register File é responsável por armazenar os dados que chegam ao processador. Este bloco é composto por registros de 32 bits. O bloco Sign extend trata dados de 8 e 16 bits com sinal, transformando-os em 32 bits para que sejam armazenados no Register File. Esta etapa é importante porque o ARM é um processador de 32 bits, ou seja, ele interpreta os dados presentes nos registros internos como dados de 32 bits.

Isso comprova que, apesar de ser uma arquitetura com recursos limitados, comparando com outros computadores modernos, podemos ter um hardware que efetivamente nos sirva de forma eficiente, tanto energética quanto computacionalmente, pois temos dentro de sua arquitetura, otimizações para lidar com tarefas complexas, aliado à isso, a presença do sistema operacional Linux, que é onipresente neste tipo de arquitetura, e comprovadamente superior no que diz respeito à performance em sistemas com arquiteturas diversas, desde o ARM até supercomputadores.

(19)

No que diz respeito à construção dos processadores com arquitetura RISC, consequentemente os de ARM, são observados alguns ítens, a saber: arquitetura load-store, instruções, pipelines e registros. Conforme o autor (SAMPAIO, 2011, pg. 22), temos que:

• Arquitetura load-store

– A arquitetura load-store, ou carregar e guardar, permite a transferência de

dados entre a memória externa e os registros internos, permitindo uma maior eficiência na execução das tarefas, pois os acessos à memória externa, dependem de barramento, sendo por isso mais custosos, logo, como te-mos registradores internos, não precisate-mos realizar o acesso à memórias externas.

• Instruções

– Processadores RISC possuem um conjunto de instruções limitados, apenas

para realização de tarefas simples, tendo para isso, um tempo fixo para a execução de cada instrução, possibilitando a presença do pipeline.

• Pipeline

– Cada instrução é quebrada em tarefas menores, que dá a impressão de

estar sendo executada em paralelo pelo pipeline, logo, as fases de buscar, decodificar e executar são realizadas simultaneamente.

• Registros

– Processadores RISC possuem vários registros de propósito geral, que

po-dem ser usados tanto para armazenar dados quanto endereços. Desta forma, os registros servem como uma pequena porção de memória local para ser utilizada durante o processamento das instruções. Isto não ocorre nas má-quinas CISC, que possuem registros dedicados para propósitos específicos. Até pouco tempo atrás, dispositivos com arquitetura ARM não eram vistos como uma alternativa para a computação de alto desempenho, devido justamente à sua simplicidade. Mas justamente por esta simplicidade, aliada à capacidade de se colocar muitos cores, embora em baixa frequência, em um mesmo chip, foi que se tornou uma ótima alternativa para pesquisas e testes comparativos, especialmente no que diz respeito à eficiência energética. Um grande diferencial desta arquitetura, é que o compilador é muito importante, pois é ele que irá fazer a parte mais complexa das tarefas, e traduzir em uma linguagem mais simples para utilizar o que há disponível no processador, o que é diferente na arquitetura CISC por exemplo.

(20)

2.1.2 ARDUÍNO

O Arduíno é uma placa de prototipação eletrônica, a qual nos traz uma série de portas de entrada e saída digitais, bem como portas analógicas. O dispositivo que irei usar neste trabalho é o moelo Uno, o qual possui um chip micro controlador Atmel AVR normalmente de 8 bits, 8 Kbytes de memória Ram e 32Kbytes de ROM. O nível de abstração é tão alto, ao ponto de que não é necessário elevado conhecimento de eletrônica por parte da pessoa que quer implementar algo usando ele. A Figura 1 nos mostra uma visão geral da placa e de seus componentes e portas, sendo que a placa em questão é o modelo Uno.

Figura 1 – Arduíno Uno R3

Fonte : Graziosi (2015)

Nas portas digitais ou analógias do ARDUÍNO, podemos conectar dispositivos externos, como por exemplo, um led, um motor, uma bomba d’água, um leitor de impressões digitais, ou seja, o que queremos controlar ou monitorar, temos que ligar ao arduíno, que fará essa interação com o dispositivo externo.

Há componentes mais sofisticados para serem acoplados ao arduíno, também conhecidos como shields. Estes componentes, adicionam funcionalidades ao arduíno, como por exemplo, o shield ethernet, o qual provê conectividade via rede ao arduíno, conforme Figura 2; ou ainda, o “rele shield”, que é um shield com 1 ou mais relés, para acionar outros componentes, como uma lâmpada, ligar uma tomada ou alimentar um motor por exemplo.

(21)

Figura 2 – Shield Ethernet para Arduíno

Fonte: WebSite (2015)

Estes Shields são placas que normalmente se encaixam sobre do arduíno, fazendo uma extensão das portas digitais ou analógicas. Observamos a Figura 3, a qual temos uma placa ARDUINO UNO e sobre ela um shield ethernet.

Figura 3 – ARDUÍNO com um Shield Ethernet sobre ele

Fonte: Suim (2013)

A Figura 4 nos mostra uma placa de relés para o arduíno. Diferentemente da Shield Ethernet, este shield de relés não encaixa sobre o arduíno, apenas se conecta os fios na placa.

A placa arduíno, já vem de fábrica com uma porta USB, a qual é utilizada para conectar o ao computador e fazer “upload” do código escrito na IDE para ele. Esta

(22)

Figura 4 – Relé Shield para Arduíno

Fonte: Suim (2013)

porta é também usada para alimentá-lo com energia, mas há outro conector dedicado só para isso.

Paralelo ao hardware acima descrito existe um software que controla tudo isso. O principal requisito é conhecimento em C/C++, que é a linguagem básica para o arduíno. Existe uma IDE (Integrated Development Environment) denominada Arduíno IDE onde os códigos gerados são popularmente conhecidos como sketchs; ao compilar o sketch, a IDE se encarrega de gerar o código binário e enviar via porta USB para a placa. A Figura 5 nos mostra como é o código padrão do arduíno, que são os dois métodos obrigatórios que todo sketch deve ter.

(23)

Figura 5 – Código padrão de um sketch na IDE do arduíno

Fonte: Autoria própria

2.2 Cloug Computing

Atualmente, as organizações necessitam cada vez mais estar conectadas. Neste sentido, temos a internet para suprir algumas das necessidades, no caso a de conectividade. Com o passar dos anos, e com a demanda crescente de serviços de infra-estrutura dinâmicos, escaláveis, elásticos, surge um modelo de computação onde temos servidores disponíveis não mais em nossas empresas, mas sim disponíveis através da internet, acessíveis aonde quer que estamos. Esta é, de forma simplória, a computação em nuvem.

Tradicionalmente, as empresas têm seus próprios servidores, e elas então precisam se preocupar em geri-los da melhor forma, deixá-los disponíveis, com energia redundante, links de internet, segurança, e etc. Poderíamos elencar muitos outros

(24)

fatores, mas não é este o objetivo do trabalho. Quando colocamos nossas aplicações na nuvem, algumas destas preocupações desaparecem, como por exemplo a disponi-bilidade. Você passa esta responsabilidade para o fornecedor do serviço, então ele tem que se preocupar com energia, link de internet, escalabilidade e tudo mais.

Um dos grandes recursos que a computação em nuvem nos proporciona, é a elasticidade. Sobre elasticidade, o autor (SOUSA; MOREIRA; MACHADO, 2009, Pg. 6) nos diz que:

Recursos podem ser adquiridos de forma rápida e elástica, em alguns casos automaticamente, caso haja a necessidade de escalar com o aumento da demanda, e liberados, na retração dessa demanda. Para os usuários, os recursos disponíveis para uso parecem ser ilimitados e podem ser adquiridos em qualquer quantidade e a qualquer momento. Além disso, a virtualização é uma maneira de abstrair características físicas de uma plataforma computacional dos usuários, exibindo outro hardware virtual e emulando um ou mais ambientes que podem ser independentes ou não.

No mundo das startups e IoT, isto é sem dúvida muito importante, pois, empre-endedores lançam suas idéias, e já no outro dia tem-se milhões de usuários utilizando tal serviço. Se tivermos que nos preocupar com a elasticidade da aplicação, certamente o custo será bem mais elevado do que alocar dinamicamente na nuvem. Sem falar que, se dias depois, a demanda de recursos computacionais cair pela metade, então dinamicamente tais recursos são desalocados, logo, você só pagará no fim do mês pelo que você usou exatamente. Algo análogo à conta de energia elétrica, ou a de água de nossas casas.

O autor (ALMEIDA; MONÇÃO, 2010, pg. 15) nos diz o seguinte:

A Computação em Nuvem é uma tendência recente de tecnologia cujo objetivo é proporcionar serviços de Tecnologia de Informação (TI) sob demanda com pagamento baseado no uso.

Como profissionais da área de computação, devemos atentar ao fato de que nem todas as aplicações servem para a nuvem. Não do jeito em que se encontram atualmente. Elas devem sofrer alterações para conseguir atender este novo formato de entrega de serviços. Outro ponto a ser ressaltado é a questão da segurança, e também a criticidade dos dados lá armazenados. Tudo isso, na hora de projetar, deve ser levado em conta. Um dos fatores, é a latência da rede, que deve ser ajustado à cada aplicação específica, pois como teremos nossos serviços na nuvem, o acesso à eles não será como em uma rede local.

(25)

2.3 SGBD

SGBD é a abreviação de Sistema Gerenciador de Banco de Dados. Conforme (RAMAKRISHNAN; GEHRKE, 2000) :

Um sistema de gerenciamento de banco de dados, ou DBMS, é um software desenvolvido para ajudar na manutenção e utilização de gran-des volumes de dados, bem como servir estes mesmos dados para os sistemas que crescem rapidamente.

O mesmo autor continua, dizendo que na década de 1960, a IBM desenvolveu o primeiro sistema de gerenciamento de banco de dados, usado hoje na maioria das instalações, o qual era chamado de Information Management System. Já em 1970, Edgar Godd, pesquisador do laboratório da IBM, fez um framework para representação de dados, e chamou este framework de modelo de dados relacional, o qual é usado ainda até hoje nos bancos de dados modernos, (RAMAKRISHNAN; GEHRKE, 2000). Nos dias de hoje, praticamente todas as organizações dispõem de um sistema de gestão empresarial, o qual armazena todas as informações pertinentes à empresa em um banco de dados. A proposta do SGBD é organizar e dispor estes dados de maneira confiável e íntegra ao usuário, através do sistema de gestão.

2.4 Android

O Android é um sistema operacional desenvolvido pelo Google, para dispositi-vos móveis, como smartphones, tablets, e agora está em algumas smartTv’s.

Atualmente, o Android está em mais de 82% dos smartphones do mundo segundo IDC, seguido do IOS, sistema para smartphones da Apple, com mais 22%, e Windows Phone, com 4,2% do mercado mundial de smartphones, como podemos observar o gráfico da Figura 6 (LLAMAS, 2015).

(26)

Figura 6 – Mercado de sistemas operacionais mobile

Fonte: Llamas (2015)

O gráfico nos mostra que o Android é popular entre as pessoas, e o mercado de smartphones cresceu 13% no ano de 2015 no mundo, com cerca de 341 milhões de novos dispositivos vendidos, conforme (LLAMAS, 2015).

Para desenvolvermos o aplicativo para Android, o próprio Google disponibiliza um kit de ferramentas, chamado de SDK, uma delas, o Android Studio, a qual nos possibilita desenvolver e já testarmos em nosso próprio dispositivo o que está sendo desenvolvido. É importante lembrar que a linguagem de programação para o Android é o java, o que pode ser um grande facilitador para começar o desenvolvimento.

No entanto, ao invés de utilizar a JVM, o Google desenvolveu sua própria, chamada Dalvik VM, mencionando o nome da cidade do programador chefe da VM. A Dalvik é totalmente otimizada para dispositivos móveis, com seu Garbage Collection otimizado, e menor consumo de memória. A Figura 7 nos mostra uma ilustração de como seria internamente um dispositivo Android.

(27)

Figura 7 – Arquitetura do sistema Android

Fonte: Soares (2014)

2.5 Automação de Ambientes

Uma das áreas que vêm ganhando atenção de entusiastas e pesquisadores é a automação em ambientes. Controlar portas, janelas, climatizadores, ler tempera-turas, irrigar as plantas de forma remota, é o que muitas pessoas gostariam de fazer, preferencialmente pelo seu smartphone. Conforme (TEZA et al., 2002, pg. 23), nos diz que:

Transformar casas em confortáveis refúgios capazes de oferecer se-gurança e economia de custos é uma das vantagens da automação residencial. O que antes parecia ser um privilégio apenas da família Jetson, começa a se difundir nos empreendimentos residenciais de alto nível, transformando o conceito de casa do futuro em casa do presente.

No conceito de casas inteligentes, temos informações geradas automatica-mente, e baseado nestas informações, temos uma ou mais unidades computacionais capazes de tratar estas informações e tomar decisões no lugar do usuário. Imaginemos a seguinte situação: temos um sensor de temperatura em nossa sala de estar; a cada 5 minutos, ele lê a temperatura do ambiente, e a envia à um servidor, que armazena esta informação e processa ela. Ora, o dono da casa decidiu que, se a temperatura for maior que 30o_{, então o equipamento de ar condicionado da sala deve ser ligado}

na temperatura 25o_{. Tudo isso é automático, sem nenhuma interação humana para}

(28)

Podemos ver neste exemplo, que houve uma decisão automática, baseada na programação dos equipamentos. Podemos ter outras aplicações, como por exemplo, a verificação de movimentos, em caso negativo por mais de 1 hora, desliga todas as luzes da casa, ou ainda, se a irrigação do gramado está ligara há 30 minutos, desliga a água, evitando desperdícios, nos 2 casos acima. Ainda relacionado ao conforto o autor (DIAS; PIZZOLATO, 2004, pg. 10), diz:

Em geral, os projetos das residências convencionais não satisfazem por completo aos anseios dos moradores, o que se constitui num contra-senso, pois a habitação, por atender às necessidades básicas do ser humano como as de proteção, segurança e bem estar, é considerada como um dos bens de consumo de maior importância para a maioria das famílias. A moradia, o abrigo, o lar, deve ser prazeroso, eficiente, dignifi-cante e, por ser um bem de grande vida útil, flexível às transformações sociais e tecnológicas.

Ou seja, iremos ter, e vemos que isto é um caminho sem retorno, cada vez mais pessoas exigentes que querem fazer de suas casas ou ambientes, lugares únicos, como refúgios para ter momentos agradáveis com seus familiares e amigos.

Para o autor (DIAS; PIZZOLATO, 2004), o sistema domótico é composto de uma rede de comunicação que permite a interconexão de uma série de dispositivos, tais como detectores, sensores, atuadores, com o objetivo de obter informações sobre o ambiente residencial e o meio em que ele se insere, tomando ações ou não, conforme foi programado. O autor continua dizendo que um sistema bem integrado, possibilita ou potencializa as aplicações como: segurança, gestão de energia, comunicação, automação de tarefas domésticas dentre outras.

O fato é um só: as demandas irão surgir cada vez mais para esta área, como podemos ver nos autores que citamos acima. Casas ou ambientes automatizados, controlados através de nosso computador ou smartphone atualmente pode significar uma questão de status perante as pessoas, mas em um futuro muito próximo, será a realidade de nossas casas. Obviamente que muitas coisas precisam acontecer ainda, como uma maneira de incluir em nossas casas atuais, com arquitetura atual, produtos do futuro que irão garantir nosso bem-estar.

2.6 API’s e Rest

Com a recente explosão de aplicações mobile, aliás, com a disseminação de dispositivos mobile de todos os tipos e marcas, os desenvolvedores viram-se no desafio de atender toda esta demanda sem ter que reescrever suas aplicações. Tudo começou a fazer sentido, especialmente o modelo de desenvolvimento MVC, onde

(29)

separamos em camadas o desenvolvimento do nosso software, para reaproveitar o que já se tem feito. Um exemplo muito clássico que podemos citar de um webservice, é o portal onde empresas transmitem notas fiscais eletrônicas. Ora, cada empresa tem seu sistema, feito em linguagem ’X’, como os empresários poderiam notificar a Secretaria da Fazenda que a nota foi emitida? Bom, todas as linguagens modernas falam um ’idioma’ comum, no caso da nota eletrônica, o formato XML para troca de dados é essencial.

Eis que então, surge o padrão Rest, especialmente focado em reaproveitar regras de negócio, disponibilizando através de API’s, dados das mais diversas formas em formato de arquivos json ou xml. Feito isso, qualquer dispositivo poderá ’consu-mir’ estes dados, como uma aplicação mobile, web, desktop, enfim. Vemos que esta parte dos dispositivos é o ’V’ do MVC. A view, onde o usuário vai ver os dados, não interessa em que tamanho de tela ou dispositivo. A informação é disponibilizada, basta desenvolver para cada plataforma e tratar com os devidos cuidados.

Conforme (SAUDATE, 2014), temos que:

Rest significa REpresentational State Transfer (ou Transferência de Estado Representativo , em tradução livre), e é um estilo de desen-volvimento de web services que teve origem na tese de doutorado de Roy Fielding. Este, por sua vez, é co-autor de um dos protocolos mais utilizados no mundo, o HTTP.

Bom, como podemos ver, o homem que criou o HTTP agora está por trás do Rest também. Faz todo sentido, pois este conhece e muito o protocolo base para os serviços Rest rodarem em cima.

Basicamente, ao usarmos Rest, temos alguns métodos que são mais comuns. Se olharmos no site da W3C, temos muitos outros, mas vou discorrer sobre os dois que julguei necessário.

2.6.1 GET

O método Get serve para recuperarmos uma informação, algo como ’obter’. Quando acessamos uma página web no nosso browser, estamos fazendo uma requisi-ção do tipo get para o site em questão.

2.6.2 POST

O método Post nos ajuda a ’postar’ alguma coisa no nosso Rest. De forma sucinta, a idéia é que você vai inserir em algum lugar informações, que irão dentro da

(30)

URL de forma codificada. Claro que podemos adicionar aqui uma camada extra de segurança, usando por exemplo o protocolo https ao invés do http, ainda uma chave de api, e por aí vai.

Existem outros métodos, como por exemplo o Put e o Delete. O put atualiza um registro que já existe no Rest, e o delete apaga o referido registro.

2.6.3 Códigos de Status

Conforme o autor (SAUDATE, 2014), as requisições enviadas ao nosso servidor HTTP nos retornam códigos de respostas, sendo que o rest se beneficia delas. Temos cinco famílias de códigos de respostas, são elas:

• 1xx: informações funcionais; • 2xx: códigos de sucesso;

• 3xx: códigos de redirecionamentos; • 4xx: erros causados pelo cliente; • 5xx: erros originados no servidor;

E abaixo, vemos cada código de retorno e sua breve descrição: • 200 - OK

– Indica que a operação teve sucesso

• 201 - CREATED

– Indica que o recurso desejado foi criado com sucesso. Deve retornar um

cabeça- lho Location , que deve conter a URL onde o recurso recém-criado está disponível.

• 202 - ACCEPTED

– Indica que a solicitação foi recebida e será processada em outro momento.

É tipi- camente utilizada em requisições assíncronas, que não serão proces-sadas em tempo real. Por esse motivo, pode retornar um cabeçalho Location , que trará uma URL onde o cliente pode consultar se o recurso já está disponível ou não.

(31)

– Usualmente enviado em resposta a uma requisição PUT , POST ou DELETE

, onde o servidor pode recusar-se a enviar conteúdo. • 206 - PARTIAL CONTENT

– Utilizado em requisições GET parciais, ou seja, que demandam apenas parte

do conteúdo armazenado no servidor (caso muito utilizado em servidores de download).

• 301 - MOVED PERMANENTLY

– Significa que o recurso solicitado foi realocado permanentemente. Uma

resposta com o código 301 deve conter um cabeçalho Location com a URL completa (ou seja, com descrição de protocolo e servidor) de onde o recurso está atualmente.

• 303 - SEE OTHER

– É utilizado quando a requisição foi processada, mas o servidor não deseja

enviar o resultado do processamento. Ao invés disso, o servidor envia a resposta com este código de status e o cabeçalho Location , informando onde a resposta do processamento está.

• 304 - NOT MODIFIED

– É utilizado, principalmente, em requisições GET condicionais - quando o

cliente deseja ver a resposta apenas se ela tiver sido alterada em relação a uma requisição anterior.

• 307 - TEMPORARY REDIRECT

– Similar ao 301, mas indica que o redirecionamento é temporário, não

perma-nente.

• 400 - BAD REQUEST

– É uma resposta genérica para qualquer tipo de erro de processamento cuja

responsabilidade é do cliente do serviço. • 401 - UNAUTHORIZED

– Utilizado quando o cliente está tentando realizar uma operação sem ter

forne-cido dados de autenticação (ou a autenticação fornecida for inválida). • 403 - FORBIDDEN

(32)

– Utilizado quando o cliente está tentando realizar uma operação sem ter a

devida autorização. • 404 - NOT FOUND

– Utilizado quando o recurso solicitado não existe.

• 405 - METHOD NOT ALLOWED

– Utilizado quando o método HTTP utilizado não é suportado pela URL. Deve

incluir um cabeçalho Allow na resposta, contendo a listagem dos métodos supor- tados (separados por “,”).

• 409 - CONFLICT

– Utilizado quando há conflitos entre dois recursos. Comumente utilizado

em resposta a criações de conteúdos que tenham restrições de dados únicos - por exemplo, criação de um usuário no sistema utilizando um login já existente. Se for causado pela existência de outro recurso (como no caso citado), a resposta deve conter um cabeçalho Location , explicitando a localização do recurso que é a fonte do conflito.

• 410 - GONE

– Semelhante ao 404, mas indica que um recurso já existiu neste local.

• 412 - PRECONDITION FAILED

– Comumente utilizado em resposta a requisições GET condicionais.

• 415 - UNSUPORTED MEDIA TYPE

– Utilizado em resposta a clientes que solicitam um tipo de dados que não é

suportado - por exemplo, solicitar JSON quando o único formato de dados suportado é XML.

• 500 - INTERNAL SERVER ERROR

– É uma resposta de erro genérica, utilizada quando nenhuma outra se aplica.

• 503 - SERVICE UNAVAILABLE

– Indica que o servidor está atendendo requisições, mas o serviço em questão

não está funcionando corretamente. Pode incluir um cabeçalho Retry-After , dizendo ao cliente quando ele deveria tentar submeter a requisição nova-mente.

(33)

Existem outros códigos de resposta do protocolo HTTP. Eles são importantes pois dentro de nossa aplicação podemos utilizá-los para detectar pontos de falha em nosso software, bem como para otimizar noso programa evitando processamento desnecessário.

2.6.4 Json

Conforme o autor (SAUDATE, 2014, Pg. 57), temos uma definição do Json como segue:

JSON é uma sigla para JavaScript Object Notation. É uma linguagem de marcação criada por Douglas Crockford e descrito na RFC 4627, e serve como uma contrapartida a XML.Tem por principal motivação o tamanho reduzido em relação a XML, e acaba tendo uso mais propício em cenários onde largura de banda (ou seja, quantidade de dados que pode ser transmitida em um determinado intervalo de tempo) é um recurso crítico.

Nesta definição, vemos que de imediato já nos atenderia muito bem este formato de arquivo, pois como o autor cita, é menor em tamanho, e mais leve, especial-mente onde largura de banda de internet é um problema. A vantagem de ser menor do que o XML nos é atraente pensando que quem vai fazer o decode do Json é um dispositivo Android, normalmente equipado com hardware nem tão poderoso, então, fazer esta operação com XML poderia custar computacionalmente bem mais.

O autor continua dizendo que, este formato atende ao seguinte modelo: • Um objeto contém zero ou mais membros

• Um membro contém zero ou mais pares e zero ou mais membros • Um par contém uma chave e um valor

• Um membro também pode ser um array

(34)

Figura 8 – Objeto Json

Fonte: (SAUDATE, 2014, Pg. 57)

Caso temos uma listagem, o autor nos indica a representação correta, onde vemos na Figura 9 uma lista dentro do objeto Json:

Figura 9 – Lista dentro do Json

Fonte: (SAUDATE, 2014, Pg. 58)

Na sequência, o autor nos diz que os tipos de dados que o Json suporta são: • array: ou seja, uma lista de dados;

(35)

• integer: um número inteiro qualquer. Note que JSON não define um número de bits possível, apenas o fato de ser um número pertencente ao conjunto dos número inteiros;

• number: um número pertencente ao conjunto dos números reais. Segue a mesma regra de integer, sendo que number também contempla integers;

• null: um valor nulo;

• object: um elemento que contém um conjunto de propriedades; • string: ou seja, uma cadeia de caracteres;

Feito isso, e de posse destas informações, já podemos começar a modelar como seria o nosso retorno do Rest que iremos criar.

(36)

END

Nesta parte do trabalho, iremos tratar o desenvolvimento do sistema que vai atuar na retaguarda, o qual compreende a aplicação Rest, o banco de dados e o Arduíno atuando lá na ponta com o sensor. Para este trabalho, temos 2 objetivos: medir a temperatura e umidade de um ambiente, e enviar estes dados para um servidor; o segundo objetivo, é podermos acionar um relé ligado à uma lâmpada, de onde quer que estamos.

3.1 Alocando um Servidor na Amazon

Na concepção do projeto, logo de começo entendemos que precisaríamos de um local onde seria centralizado todas as informações, e as ações a serem tomadas seriam refletidas neste local também. A idéia inicial do projeto era utilizarmos um computador local, ou um Raspberry Pi. Mas, observando os benefícios que já foram citados no capítulo 2, somando à isso o fato de já termos à nossa disposição um servidor na nuvem, então foi quase unânime a idéia de usarmos a própria nuvem em prol deste trabalho.

Para a criação da nossa instância na Amazon o processo é muito simples. Esta empresa possui um plano de 796 horas gratuítas, o qual foi o que escolhemos, então, teremos um servidor na nuvem sem custos em um primeiro momento.

Este servidor que alocamos possui um processador Intel Xeon E5-2676v3 contendo um core de 2,4Ghz; 1 Gb de memória Ram e um disco de 10 Gb. Para este projeto, seria mais do que suficiente. O sistema operacional escolhido foi o Linux RedHat de 64 bits, como podemos ver na Figura 10, onde temos uma lista com várias possibilidades de sistemas operacionais disponíveis.

(37)

Figura 10 – Amazon - Seleção do Sistema Operacional

Fonte: Amazon (2016)

A Figura 11 nos mostra a página incial do site, o qual nos mostra estatísticas da nossa instância na nuvem, basta clicarmos sobre a instância e ele já altera os gráficos de histórico de CPU, memória, entre outros, muito útil para quem administra várias instâncias de EC2.

Figura 11 – Página inicial na Amazon

Algo importante a ser comentado que observamos ao alocar esta máquina virtual, é que a própria Amazon já disponibiliza a chave para acesso via protocolo SSH

(38)

sem senha, o que do ponto de vista de segurança é ótimo; também temos outros extras, como por exemplo o fato de termos todas as portas fechadas no grupo de segurança da instância, então, para abrirmos a porta 80, porta esta que é a porta padrão do protocolo HTTP, bem como o de nossa aplicação, tivemos que liberá-la manualmente no grupo de segurança, como nos mostra a Figura 12, onde estamos abrindo a porta número 22 usando TCP para o protocolo SSH, a qual é a porta padrão do protocolo SSH, usado para acessarmos a nossa instância remotamente..

Figura 12 – Grupos de segurança da nossa instância

Neste ponto, já temos disponível uma máquina para podermos instalar os programas necessários para rodarmos o que precisamos. O grande diferencial, é que com poucos cliques a máquina já fica disponível, abstraindo para nós toda a parte de criação manual se tivéssemos que fazer isso localmente.

3.2 O Banco de Dados

3.2.1 Instalação

Nosso servidor linux RedHat possui o gerenciador de pacotes yum. Então, para instalar, desinstalar ou atualizar programas usamos este gerenciador, que já resolve pra nós uma série de dependências e assim conseguimos seguir adiante. Para a instalação

(39)

do SGBD Mysql, rodamos o comando "yum install mysql-community-server.x86_64 -y". O sistema irá buscar as informações deste repositório na internet, verificar se existe este pacote, se a arquitetura do sistema operacional é compatível, etc, e vai fazer o download seguido da instalação do mesmo.

Uma vez instalado o banco de dados, precisamos acessá-lo localmente. Então, na hora da instalação, temos uma senha temporária que o SGBD gera aleatóriamente no caminho /var/log/mysqld.log, onde temos que dar um grep e procurar o termo ’temporary password’. De posse desta senha, rodamos o mysql_secure_instalation, para alterarmos a senha do usuário root (super usuário). Feito isso, podemos agora logar ao console do mysql para criação da tabela que vai armazenar os dados das leituras de temperaturas e umidades de nosso ambiente remoto.

Nosso banco de dados possui uma tabela que vai armazenar os dados das leituras, como podemos ver na Figura 13.

Figura 13 – Tabela de leituras

Para este trabalho, achamos que seria importante armazenar além da tempe-ratura e umidade, a data e a hora de leitura, para fins de histórico. A cada 10 minutos, o sensor realiza uma leitura, e envia ao nosso Rest, que por sua vez armazena estas informações junto ao banco através de um recurso do nosso Rest que iremos tratar mais adiante.

3.3 Instalação do Servidor Web

Para a instalação do servidor web, que vai hospedar o nosso , escolhemos o servidor Apache. Pesquisas de 2007 revelam que o apache detém cerca de 47% dos servidores do mundo todo. Sua instalação e configuração se torna um tanto simples no ambiente Linux, e também se revela um ótimo servidor para a aplicação que desejamos.

(40)

o processo de instalação do Apache no linux RedHat é muito simples: basta rodarmos o comando yum install httpd, e o gerenciador yum vai resolver as depen-dências, baixar e instalar os pacotes necessários. Entretanto, como teremos nosso rest rodando sobre a linugagem PHP, a qual irei falar depois, é necessário instalar o interpretador do PHP junto. Então, temos mais um comando: yum install php, o qual, instalará pra nós o referido pacote.

Bom, até aqui temos o banco de dados, o servidor web e o php instalados em nossa máquina na nuvem. Agora, temos que iniciar os serviços, e começar a programar. Para inicializarmos o banco de dados e o apache, rodamos, respectivamente: systemctl start mysqld.service e systemctl start httpd.service. Outro detalhe que já habilitamos, é o fato destes serviços iniciarem automaticamente ao dar um reboot no servidor, então temos os comandos para o apache e para o mysql, respectivamente: systemctl enable httpd.service e systemctl enable mysqld.servce.

Agora, por último, precisamos acertar a reescrita de URL. Irei falar sobre o que é na subseção que trata do desenvolvimento do nosso Rest. Por hora, precisamos editar um arquivo no servidor, o qual encontra-se em /etc/httpd/conf/httpd.conf. Dentro dele, temos algumas seções, que tratam dos diretórios que o servidor web vai disponibilizar para os usuários. Neste arquivo, temos a seção Directory /var/www/html, dentro dela temos um parâmetro denominado AllowOverride None. Devemos alterar o valor de None para All. Feito isso, nosso servidor apache está pronto.

3.3.1 Reservando um Domínio no registro.br

Quando alocamos uma instância de uma máquina na nuvem, ganhamos um endereço IP. IP significa Internet Protocol, ou protocolo da internet. Este protocolo é baseado na RFC 791 (REY, 1981), que define que cada computador na internet deve ter um endereço único que o identifica. Temos classes de ips que são usadas na internet, e algumas classes que usamos em redes internas, tais endereços não são alcançáveis na internet, logo, os roteadores da internet são configurados para não reconhecer estes ips.

Voltando ao assunto do endereço IP, seria desejável a possibilidade de aces-sarmos nossa instância na nuvem através de um nome, e não de um edereço ip. Um nome seria bem mais simples de memorizar do que um número aleatório. Baseado nisso, foi criado o protocolo DNS (Domain Name System), o qual vamos falar à seguir.

(41)

3.3.1.1 O Servidor DNS

O DNS é baseado nas RFC 1034 e 1035, onde temos toda a especificação deste protocolo. Nos primórdios da internet, havia poucos computadores, então, cada um recebia seu endereço IP, e seu nome era armazenado em um arquivo de texto, compartilhado por todos os outros hosts na rede. Com o passar do tempo, o número de computadores foi aumentando significativamente, sendo que atualizar este arquivo com os referidos nomes era uma tarefa onerosa.

Então, Paul Mockapetris juntamente com a equipe da IETF desenvolveram as RFC’s citadas acima, onde detalharam cada uma das partes do protocolo.

Atualmente, conforme o site (IANA, 2016) temos 13 servidores DNS no mundo, os quais são responsáveis por traduzir os nomes em endereços IP’s de cada computa-dor que está conectado na web. Destes, 10 estão nos EUA, 2 na Europa, e 1 na Ásia. De forma resumida, um servidor DNS armazena nomes e seus respectivos endereços IP. Seria análogo à uma agenda de telefones, onde temos nossos contatos. É muito mais simples memorizar o nome da pessoa do que seu respectivo número de telefone; o mesmo acontece na internet, pois memorizar um endereço IP versão 4 não é tão simples quanto o nome. Com o advento do IP versão 6, o DNS fará muito mais sentido, pois os endereços da versão 6 têm 128 bits, não mais 32 que são do IP versão 4.

No Brasil, temos o órgão responsável pela gestão dos nomes do domínio br que chama-se Comitê Gestor de Internet do Brasil (CGI). Para registrar um domínio, acessamos o site registro.br, criamos uma conta e pesquisamos se o nome que queremos já não está em uso. Caso negativo, então podemos usar o nome com a extensão br. A Figura 14 nos mostra a página inicial do site do registro.br onde temos a opção de pesquisar o nome do domínio que queremos reservar.

(42)

Figura 14 – Página inicial do site www.registro.br

Fonte: Registro (2016)

Como já tínhamos o endereço IP da nossa instância na Amazon, então, ao alocarmos um nome, já temos a possibilidade de apontar para onde deve ser redirecio-nado ao solicitar nosso nome de domínio. A Figura 15 nos mostra o painel de edição das configurações do nosso domínio, onde apontamos para um endereço IP que é o nosso IP da nossa intância da Amazon.

(43)

Figura 15 – Página de configuração de zonas do site

Fonte: Registro (2016)

O processo de atualização em todos os servidores DNS no mundo, pode levar até 24 horas para ocorrer, então é natural nas primeiras horas, digitarmos no nosso navegador o nome do domínio, e ele ainda não responder.

Feito isso, concluímos a parte de configuração do servidor Web, e passadas as 24 horas, nosso domínio já está respondendo ao nome, conforme podemos observar na Figura 16, onde temos a página padrão do servidor Apache, conforme foi descrito na seção 3.3.

(44)

Figura 16 – Página padrão do servidor Apache

Fonte: RedHat

3.3.2 O Rest

Chegamos agora na parte da definição do nosso servidor Rest. Para este trabalho, foi utilizado um framework baseado na linguagem PHP, o qual nos auxilia na criação dos nossos recursos que serão expostos para serem consumidos.

3.3.2.1 Semântica de Recursos

Conforme o autor (SAUDATE, 2014), temos que:

Todo serviço Rest é baseado nos chamados recursos, que são en-tidades bem definidas em sistemas, que possuem identificadores e endereços (URL’s) próprios.

Um recurso, conforme o autor acima, é o caminho da URL dentro do nosso servidor. Falamos em recursos quando queremos nos referir também aos métodos do mesmo, ou então à própria URL que já falamos.

A URL base do nosso Rest será www.sobreti.com.br/phpsmarthome/v1/, e os métodos serão os da tabela 3.3.2.1:

(45)

Tabela 1 – Recursos Rest

Caminho Retorno

setTemperaturaUmidade Nada

getTemperaturaUmidade JsonObject com a última leitura getTemperaturaUmidadeDia JsonArray de leituras do dia getStatusLampada Json com estado da lâmpada

setStatusLampada Não retorna nada

3.3.2.2 Sobre o SlimFramework

Quando desenvolvemos aplicações para a Web, é bem comum encontrarmos ferramentas que nos ajudam a fazer alguns trabalhos que são repetitivos, ou que são automatizados. Estas ferramentas, chamam-se frameworks, ou em uma tradução livre, uma caixa de ferramentas. Como analogia, podemos imaginar uma situação: você precisa parafusar um parafuso na parede; ora, pode-se usar uma chave de fenda para isso, que seria o jeito tradicional; ou ainda, pode-se usar uma parafusadeira, a qual faz a força para você, o que é muito mais fácil e rápido. No entanto, há lugares em que você não pode chegar com uma parafusadeira, devido ao seu tamanho. A aplicação de um framework é muito semelhante, ele faz o trabalho braçal, mas muitas vezes não é o mais indicado para esta ou aquela situação.

O SlimFramework é um framework baseado na linguagem PHP, linguagem esta que é muito utilizada para desenvolvimento de páginas Web. Uma das características mais interessantes dele, é que ele é muito rápido e famoso para criação de API’s para serem consumidas por outros serviços ou aplicações em geral, pois já vem pronto com várias coisas legais.

Na linguagem dos frameworks web, temos um conceito que são as rotas. Rotas são mapeamentos de URL’s para o recurso em questão, sendo assim, para cada rota haverá o referido recurso. E o framework deve saber tratar estas requisições, sendo que nós programadores devemos dizer o que deve ser feito quando tal recurso for solicitado.

(46)

Figura 17 – Estrutura do projeto PHP

No nosso projeto, temos algumas classes, como mostra a Figura 17 que dividimos em pastas para organizar melhor. A pasta include é onde temos algumas classes como a DbConnect que como o nome sugere, nos conecta ao banco de dados e retorna esta conexão para a classe que precisa usar. A Figura 18 nos ilustra o código desta classe, bem pequeno mas funcional.

Figura 18 – Classe DbConnect

A classe DbConnect é a única que consome os recursos do do arquivo Cons-tants.php, o qual possui definições como o servidor do banco de dados, usuário, senha,

(47)

e algumas constantes que são usadas.

Já a classe DbOperation, faz as operações no banco de dados, como leitura ou gravação de dados na tabela de leituras. Iniciamos ela fazendo um include da classe DbConnect, que nos retorna a conexão com o banco de dados Mysql. Uma vez instanciada a classe, temos a conexão à nossa disposição para usarmos inserindo ou lendo dados no banco. Na Figura 19, temos o trecho de código que retorna ao nosso recurso do rest, as leituras do dia. Neste método, fizemos nossa consulta no banco de dados da seguinte forma: retorna as leituras das últimas 24 horas, agrupando por hora, a média de cada hora. Como temos leituras a cada 10 minutos, em 1 dia teríamos 24 horas X 6 leituras/hora, o que daria 144 leituras. Então, resolvemos fazer a média da hora, e retornar ela. Este método é o que vai alimentar o gráfico no nosso aplicativo no Android, que veremos adiante.

Figura 19 – Classe DbOperation

Na pasta libs, temos as bibliotecas (como sugere o nome) usadas no projeto, neste caso, temos o framework que baixamos da internet, no site oficial.

Na pasta v1, temos então o nosso arquivo chamado index.php, o qual tem as rotas do nosso Rest. Como podemos ver na Figura 20, começamos incluindo as classes que precisamos, uma do banco de dados, e outra do framework SlimFramework. Após, instanciamos um objeto do framework.

(48)

Figura 20 – Includes no arquivo index

Feito isso, começamos a tratar nossas rotas. Pegando o exemplo anterior, onde falamos do método que nos retorna as médias por hora das últimas 24 horas da classe DbOperation, vamos tratar da rota que chama este método. O nome dela, como especificado anteriormente, geTemperaturaUmidadeDia.

Figura 21 – Rota que nos retorna as leituras ao longo do dia

(49)

Observando a Figura 21, vemos que para criarmos nossa rota, chamamos nosso objeto do framework SlimFramework e dizemos que esta rota usará o método get, ou seja, iremos obter dados de algum lugar, como falamos no capítulo anterior. Feito isso, instanciamos a classe DbOperation, e chamamos o método respectivo. Caso o retorno seja diferente de null, percorremos o resultado e vamos adicionando em um array de dados. Após, chamamos o método echoResponse, que recebe como parâ-metro o número 200, indicando que deu tudo certo, e o array com os valores oriundos do banco de dados. Como podemos ver na Figura 22, este método echoResponse faz o encode para o formato Json do nosso array, e retorna ao usuário ou aplicação este resultado.

Figura 22 – JsonArray com as leituras do dia

Os outros métodos implementam basicamente a mesma coisa, alterando o que é necessário, pois temos um padrão a ser seguido no retorno do json, então ficou

(50)

fácil a implementação do código, uma vez que já tínhamos definido o modelo. A cada 10 minutos nosso Arduino faz as leituras do sensor, e faz um POST no Rest através do recurso setTemperaturaUmidade, o qual recebe os parâmetros t (temperatura) e u (umidade).

Json significa Java Script Object Notation, trata-se de uma representação de dados alternativa ao XML. Quando surgiu o padrão Rest, o json já veio junto

3.4 O Arduíno

Aqui chegamos no assunto central do trabalho, embora seja o mais simples. Toda a concepção deste projeto foi feita pensando sobre este pequeno componente capaz de interagir com sensores, autuadores, motores dos mais diversos tipos.

O Arduino compõe-se de várias portas digitais e analógias. Dependendo do modelo, podem haver mais ou menos portas. O modelo mais popular, que foi inclusive utilizado neste projeto, é o UNO, o qual possui 16 portas digitais e 6 portas analógicas.

Para o desenvolvimento do nosso programa no Arduino, utilizamos algumas bibliotecas externas, feitas por terceiros, que nos facilitaram a integração com nosso Rest. Trata-se de uma biblioteca denominada RestClient, a qual pode ser encontrada neste endereço: https://github.com/csquared/arduino-restclient. Toda a documentação dela encontra-se nesta página também. Outra biblioteca, chama-se ArduinoJson, a qual serve para fazer a leitura do objeto Json que vem do nosso servidor.

Para o desenvolvimento do nosso código no Arduino, utilizamos a IDE para ele, que pode ser baixada no site oficial. Uma vez feito o download da IDE, instalamos a mesma. Dentro da pasta do nosso usuário do sistema, seja ele Windows ou Linux, temos uma pasta criada, chamada Arduíno. Por padrão, ali a IDE armazana os sketchs que criamos, sendo que temos uma subpasta chamada Libraries, onde devemos armazenar as bibliotecas que baixamos da internet.

Algo que nos chamou muito a atenção, foi o fato de haver centenas de bi-bliotecas para o desenvolvimento. Em contrapartida, apredemos que temos que ter cuidado ao adicioná-las aos nossos programas, pois, como temos armazenamento limitadíssimo no ARDUINO, não é difícil receber a mensagem ao compilar nosso sketch de que o programa ultrapassa a capacidade de armazenamento do arduíno. Uma das características que mais me marcou, foi o fato de termos que tirar a habilidade de obter um IP dinamicamente da rede, pois aumenta cerca de 20% o tamanho do programa fazendo isso, então decidimos deixá-lo com IP fixo. A Figura 24 nos mostra nosso Arduino, e a Figura 23 nos mostra como obter o endereço de IP fixo.

(51)

Figura 23 – IP fixo no Arduino

Figura 24 – Nosso Arduino

A linguagem para o desenvolvimento nesta IDE é muito semelhante ao C++, logo, as bibliotecas são construídas nesta linguagem também. No ambiente da IDE, especificamente para o Arduino, temos dois métodos que são fundamentais ao nosso programa, mas não só para nós, como para qualquer programa para ARDUINO. O primeiro, chama-se void setup. Este método, é invocado uma única vez, ao ligarmos o Arduino, depois disso não é mais necessário.

Como podemos observar na Figura 23, temos o método de setup inteiro ali. Como usamos uma porta USB para comunicarmos com o Arduino e nosso computador,

(52)

esta porta faz a emulação de uma porta serial. Logo, podemos fazer nosso debug enviando o que está sendo feito para a porta serial ’imprimir’ e nos mostrar o que está acontecendo. Deste modo, é muito sensato inicializarmos ela já na inicialização do Arduino. Para isto, chamamos ali o método begin() da classe Serial, o qual recebe como argumento o baudrate da porta, que definimos como 9600 bytes por segundo.

Uma vez inicializado a porta serial, podemos imprimir mensagens, como na segunda linha, onde chamamos o método println da mesma classe Serial, e passamos como argumento o que desejamos imprimir. Após, inicializamos nosso sensor de umidade e temperatura. Neste trabalho, utilizei um sensor DHT11, como mostra a Figura 25, onde temos a imagem do sensor.

Figura 25 – Sensor DHT11 para Arduino

Temos 3 pinos de conexão neste sensor. O positivo, que vai conectado ao pino de 5 volts, um negativo, que vai no pino GND do Arduino, e o S, que é o pino do sinal, o qual vai conectado em qualquer porta analógica, no nosso caso, a porta A0. Feito isso, para funcionar no programa, devemos importar a biblioteca para então o Arduino ’entender’ o que o sensor está dizendo. Neste caso, realizamos um ’include’ da biblioteca DTH.h no cabeçalho do programa. O código à seguir nos mostra como ficou o nosso programa completo, o qual irei explicar mais algumas partes.

1

2 # i n c l u d e < A r d u i n o J s o n . h >

3 # i n c l u d e " R e s t C l i e n t . h "

(53)

5 # i n c l u d e < SPI . h > 6 # i n c l u d e " DHT . h " 7 # i n c l u d e < avr / wdt . h > 8 9 # d e f i n e D H T P I N A0 // p i n o do s e n s o r 10 # d e f i n e D H T T Y P E D H T 1 1 // DHT 11 11 # d e f i n e LED 6 // p o r t a do led 12 13 DHT dht ( DHTPIN , D H T T Y P E ) ; 14

15 b y t e mac [] = {0 x00 , 0 xAA , 0 xBB , 0 xCC , 0 xDE , 0 x02 };

16 b y t e ip [] = { 1 9 2 , 1 6 8 , 7 0 ,5 } ; 17 b y t e gw [] = { 1 9 2 , 1 6 8 , 7 0 ,1 } ; 18 b y t e s u b n e t [] = { 2 5 5 , 2 5 5 , 2 5 5 , 0 } ; 19 b y t e d [] = {8 ,8 ,8 ,8}; 20 21 v o i d s e t u p () { 22 S e r i a l . b e g i n ( 9 6 0 0 ) ; 23 S e r i a l . p r i n t l n (" I n i c i a l i z a n d o ... ") ; 24 dht . b e g i n () ; 25 // i n i c i a a r e d e 26 S e r i a l . p r i n t l n (" I n i c i a n d o r e d e ... ") ; 27 E t h e r n e t . b e g i n ( mac , ip , d , gw , s u b n e t ) ; 28 p i n M o d e (6 , O U T P U T ) ; 29 } 30 31 // l o n g i n t e r v a l o = 1 0 0 0 0 ; // 10 s e g u n d o s 32 l o n g i n t e r v a l o = 6 0 0 0 0 0 ; // 10 m i n u t o s 33 l o n g i n t e r v a l o l a m p a d a = 2 0 0 0 ; // 2 s e g u n d o s 34 l o n g t e m p o a n t e r i o r l a m p a d a = 0; 35 l o n g t e m p o a n t e r i o r = 0; 36 37 38 v o i d l o o p () { 39 40 l o n g t e m p o a t u a l = m i l l i s () ; 41 42 if(( t e m p o a t u a l - t e m p o a n t e r i o r l a m p a d a ) > i n t e r v a l o l a m p a d a ) { 43 t e m p o a n t e r i o r l a m p a d a = t e m p o a t u a l ; 44 v e r i f i c a L a m p a d a () ; 45 }

(54)

46 47 if (( t e m p o a t u a l - t e m p o a n t e r i o r ) > i n t e r v a l o ) { 48 t e m p o a n t e r i o r = t e m p o a t u a l ; 49 50 /* O b t e m a u m i d a d e */ 51 f l o a t h = dht . r e a d H u m i d i t y () ; 52 /* O b t e m a t e m p c o m o g r a u s c e l s i u s */ 53 f l o a t t = dht . r e a d T e m p e r a t u r e () ; 54 if ( i s n a n ( h ) || i s n a n ( t ) ) { 55 S e r i a l . p r i n t l n (" F a i l e d to r e a d f r o m DHT s e n s o r ! ") ; 56 r e t u r n; 57 } 58 S e r i a l . p r i n t (" U m i d a d e : ") ; 59 S e r i a l . p r i n t ( h ) ; 60 S e r i a l . p r i n t (" %\ t ") ; 61 S e r i a l . p r i n t (" T e m p e r a t u r a : ") ; 62 S e r i a l . p r i n t ( t ) ; 63 S e r i a l . p r i n t (" * C ") ; 64 S e r i a l . p r i n t l n (" ") ; 65 66 r e q u e s t W e b ( t , h ) ; 67 } 68 } 69 70 v o i d r e q u e s t W e b (f l o a t t , f l o a t u ) { 71 S e r i a l . p r i n t l n (" E n v i a n d o p a r a o r e s t ... ") ; 72 R e s t C l i e n t c l i e n t = R e s t C l i e n t (" s o b r e t i . com . br ", 80) ; 73 S t r i n g r e s p o n s e = " "; 74 c h a r aux [ 1 8 ] ; 75 S t r i n g tag = " "; 76 tag = " t = "+ S t r i n g ( t ) + " & u = " + S t r i n g ( u ) ; 77 tag . t o C h a r A r r a y ( aux , 1 8 ) ; 78 S e r i a l . p r i n t l n (" F a z e n d o p o s t ... ") ; 79 int i = c l i e n t . p o s t (" / p h p s m a r t h o m e / v1 / s e t T e m p e r a t u r a U m i d a d e ", aux , & r e s p o n s e ) ; 80 S e r i a l . p r i n t l n (" S t a t u s c o d e de r e t o r n o : " + S t r i n g ( i ) ) ; 81 S e r i a l . p r i n t l n (" R e s p o s t a : ") ; 82 S e r i a l . p r i n t l n ( r e s p o n s e ) ; 83 } 84 85 v o i d v e r i f i c a L a m p a d a () { 86 S e r i a l . p r i n t l n (" B u s c a n d o i n f o r m a c o e s ... ") ;

(55)

87 R e s t C l i e n t c l i e n t = R e s t C l i e n t (" s o b r e t i . com . br ", 80) ; 88 S t a t i c J s o n B u f f e r <20 > j s o n B u f f e r ; 89 S t r i n g r e s p o n s e = " "; 90 c l i e n t . get (" / p h p s m a r t h o m e / v1 / g e t S t a t u s L a m p a d a ", & r e s p o n s e ) ; 91 S e r i a l . p r i n t l n (" R e s p o s t a do r e s t : " + r e s p o n s e ) ; 92 c h a r j s o n [ 2 0 ] ; 93 r e s p o n s e . t o C h a r A r r a y ( json , 20) ; 94 95 J s o n O b j e c t & r o o t = j s o n B u f f e r . p a r s e O b j e c t ( j s o n ) ; 96 if (! r o o t . s u c c e s s () ) { 97 S e r i a l . p r i n t l n (" p a r s e O b j e c t () f a i l e d ") ; 98 r e t u r n; 99 } 100 b o o l e a n e s t a d o = 0; 101 e s t a d o = r o o t [" l i g a d a "]; 102 l i g a D e s l i g a L a m p a d a ( e s t a d o ) ; 103 } 104 105 v o i d l i g a D e s l i g a L a m p a d a (int s t a t u s ) { 106 if (! s t a t u s ) { 107 d i g i t a l W r i t e (6 , H I G H ) ; 108 } e l s e { 109 d i g i t a l W r i t e (6 , LOW ) ; 110 } 111 }

O outro método, é o void loop. Como o nome sugere, este método fica em execução infinitamente, não vai parar nunca, salvo se o hardware for desligado. Neste método que desenvolvemos nosso código principal. Definimos que a cada 10 minutos, seria feita uma leitura da temperatura e da umidade do ambiente, e então estes valores seriam enviados para nosso Rest que está na Amazon. No começo, fiz um sketch onde era incrementada uma variável até chegarmos no intervalo de 10 minutos. No entando, este não era o jeito mais ’correto’ de se fazer. Pesquisando a documentação do Arduino, chegamos à uma função denominada millis(), a qual nos diz quanto tempo, em milisegundos, o Arduino está ligado. Baseado nisso, podemos calcular o tempo e guardá-lo em uma variável, que vai servir nas próximas iterações do código, como está na linha 40 do código acima.

Bom, se já se passaram 10 minutos desde a última leitura, então o programa irá ler temperatura e umidade do sensor, nos mostrar na porta serial caso estamos conectados ao Arduino, e também vai chamar a função requestWeb(), a qual recebe 2

(56)

parâmetros do tipo float: a temperatura e a umidade lidas do sensor DHT11.

Dentro desta função, instanciamos um objeto da classe RestClient, a qual deve receber no seu construtor o IP ou nome do domínio; se a porta padrão for a porta 80, então não é necessário especificar a porta, caso contrário, deve-se especificar a porta de onde iremos fazer a requisição web.

Após, criamos algumas variáveis auxiliares, que vão nos ajudar a fazer o POST no nosso Rest, pois o método que envia, recebe um array de char, e não uma String. Realizadas as devidas conversões (vide linhas 73 a 77 do código), invocamos o método post do nosso objeto RestClient (client). Este método, nos retorna 1 se houve sucesso na comunicação, ou 0 caso haja falha. O mesmo recebe como parâmetro o recurso do nosso Rest, o que iremos postar, e opcionalmente podemos armazenar o retorno desta chamada, o que fizemos e armazenamos na variável reponse. Feito isso, imprimimos na serial os dados vindos do Rest para sabermos se tudo deu certo. Tudo funcionando aqui, chegamos na última parte, que é falar do aplicativo Android que vai obter estes dados através do Rest e mostrar de forma amigável ao usuário.

Outra função que temos, é a função que vai ligar ou desligar a lâmpada. Esta, por sua vez, está ligada ao relé, o qual é ligado junto à porta 6 do Arduino. Podemos ver na Figura 26 onde temos imagem do relé conectado ao Arduino.

Figura 26 – Relé que aciona a lâmpada

O método é o verificaLampada(), o qual é chamado à cada dois segundos. Este método, como mostra no código, instancia o objeto da classe RestClient e faz uma requisição do tipo GET no nosso servidor da Amazon, o qual retorna um dado do tipo boolean orientando se a lâmpada deve estar ligada ou desligada. Ao receber