Projeto universitário · Equipa de 2
Hotel Inteligente - Plataforma IoT
Sensores instalados em quartos a enviar leituras para uma aplicação web que as mostra num painel que se atualiza sozinho.
Contexto
Primeiro projeto da licenciatura. Fiquei responsável pela aplicação web e o meu colega pela parte do Arduino — mas acabámos os dois a aprender as duas coisas. Feito com o que sabíamos na altura: PHP, HTML, CSS e JavaScript, sem framework e sem base de dados.
O problema
Hardware a escrever de um lado, um browser a ler do outro, e no meio nada que soubéssemos usar. Ainda não tínhamos dado bases de dados. As leituras dos sensores tinham de ir para algum sítio, e esse sítio acabou por ser um ficheiro de texto — não por opção de arquitetura, mas porque era a ferramenta que tínhamos.
A minha parte
A aplicação web inteira: a API em PHP que recebe as leituras, a camada que as guarda e lê dos ficheiros, o painel de monitorização e a autenticação. O meu colega ficou com o Arduino e os sensores. Na prática acabámos ambos a perceber os dois lados, porque quase todos os problemas apareciam na fronteira entre eles.
Decisões técnicas
Guardar em ficheiros, e assumi-lo
Sem base de dados, cada leitura vai para ficheiro. Uma base de dados resolve por ti a escrita simultânea, a consistência e a pesquisa; com ficheiros, esses problemas passam a ser teus. Não foi uma escolha de engenharia — foi o que sabíamos fazer. Prefiro dizê-lo assim do que chamar-lhe arquitetura, porque a diferença entre as duas coisas é exatamente o que eu não sabia na altura.
Atualizar o painel sem recarregar a página
O painel pede dados novos periodicamente e atualiza só o que mudou. Num ecrã de monitorização que fica aberto horas, recarregar a página inteira desperdiça largura de banda e faz perder o contexto visual — quem está a olhar perde o sítio onde estava.
Tratar o hardware como uma fonte não confiável
Os dados vinham de um dispositivo na rede, e o que chega pela rede pode chegar mal formado, de propósito ou por acidente. Validámos os caminhos de ficheiro contra travessia de diretórios e sanitizámos tudo o que era escrito ou mostrado. Um sensor não é um atacante, mas o código não tem como saber a diferença.
O que correu mal
Houve bastantes erros, e a maior parte não estava em nenhum dos dois lados — estava na costura entre eles.
Leituras que chegavam mal formadas. Ficheiros que ficavam num estado estranho quando o sensor escrevia ao mesmo tempo que o painel lia. Dados que desapareciam sem deixar rasto do que tinha acontecido. E como não tínhamos registo de erros, cada problema começava por uma pergunta a que não sabíamos responder: o problema está no Arduino, na rede, ou no PHP?
Passámos mais tempo a descobrir de que lado estava o problema do que a resolvê-lo. No fim organizámos tudo e entregámos a funcionar.
A lição ficou: num sistema feito por duas pessoas em duas metades, a parte que falha quase nunca é uma das metades. É a costura — e ninguém é dono dela a menos que alguém decida ser.
Resultado
Entregue a funcionar, com os sensores a alimentar o painel em tempo real.
O que faria diferente
Duas coisas. Usaria uma base de dados: hoje sei que aquilo que estávamos a resolver à mão — escritas em simultâneo, consistência, não perder leituras — é precisamente o problema que uma base de dados existe para resolver, e resolvê-lo mal é muito mais trabalho do que usá-la.
E registaria erros desde o primeiro dia. Não teria evitado os problemas, mas teria transformado horas de adivinha em minutos de leitura.