Construindo o projeto de IoT portátil

Finalmente chegamos na parte de começar a dar vida ao projeto IoT portátil. Até aqui você já aprendeu a dimensionar a bateria pro seu projeto e também a calcular o consumo médio. Então vamos prototipar o projeto!

As referências sobre instalação do ESP32 na Arduino IDE e também como usar o Google planilhas para enviar dados do microcontrolador para planilha são importantes.

Já foi citado como o projeto funcionará, mas vamos relembrar. Será um Datalogger que enviará a temperatura e umidade do local para um banco de dados online, usaremos o Google planilhas pois dispensa um servidor para host, gratuito, permite compartilhar os dados facilmente com qualquer pessoa, aplicar fórmulas, desenhar gráficos e muito mais ao estilo Excel. Vamos programar logo e depois as explicações.

Circuito

Código

#include <DHT.h>
#include <WiFi.h>
#include <WiFiClientSecure.h>
DHT dht(23, DHT11);
WiFiClientSecure client;
float t = 0, u = 0;//Variaveis que armazenam a leitura ATUAL
RTC_DATA_ATTR float lt = 0;//Variavel alocada na RTC RAM da ultima temperatura lida (Last Temp)
//Variaveis alocadas na RTC RAM não são perdidas entre Deep Sleep, então
//usamos para guardar a ultima temperatura lida e fazer uma nova verificação
//no proximo Wake UP
void setup()
{
		pinMode(23, INPUT);//Pino de dados do DHT11
		dht.begin();//Inicializa o DHT11
		
		t = dht.readTemperature();//Atribui a temperatura atual na variavel "t"
		u = dht.readHumidity();//Atribui a umidade atual na variavel "u"
		if (lt != t)//Se a ultima temperatura lida for diferente da atual, irá enviar ao banco de dados
		{
			lt = t;//Iguala a ultima temp. com a temp. atual
			WiFi.mode(WIFI_STA);//
			WiFi.begin("SUA REDE", "SUA SENHA");//Conecta no WiFi
			for (int i = 0; i < 500; i++)
			{
				delay(10);
				if (WiFi.status() == WL_CONNECTED)//Se conseguir conectar no WiFi
				{
					if (client.connect("docs.google.com", 443) == true)//Se conseguir conectar no servidor da Google
					{
						String toSend = "GET /forms/d/e/1FAIpXXXf6EKACSqEhAsXXXKb3qDBiNSh6MXn6ck44TBj7zRYH72SXXX/formResponse?ifq";
						toSend += "&entry.634150418=";	toSend += t;
						toSend += "&entry.2106983911=";	toSend += u;
						toSend += "&submit=Submit HTTP/1.1";
						client.println(toSend);
						client.println("Host: docs.google.com");
						client.println();
						client.stop();
					}
					break;//Encerra o loop FOR()
				}
			}
		}
		
		ESP.deepSleep(300000000);//Dorme por 5 minutos
}
void loop()
{
}

Explicação

Observações sobre os dados:

Os Melhores Treinamentos sobre Sistemas embarcados e IoT

Cursos com professores qualificados para acelerar sua carreira e projetos

MATRÍCULE-SE AGORA

• Intervalo entre leituras: 5 minutos;
• Total de leituras: 92;
• Tempo total de colheita: 9 horas
• Apesar das leituras de umidade oscilarem bastante por motivos desde protoboard até sensor ruim, com a linha de tendência linear foi possível notar a redução da umidade conforme o aumento da temperatura.

Como em todo projeto de sistemas embarcados, as condições do ambiente a ser monitorado podem influenciar no funcionamento, dando margem a melhorias de desempenho (e, nesse caso, consumo energético). Observando o ambiente cuja temperatura foi monitorada, nota-se que a temperatura do local demorou aproximadamente 2 horas para variar 1°C e, neste meio tempo, foram enviados 24 valores iguais de temperatura. Para este projeto, estes 24 valores iguais de temperatura significam 24 envios de um mesmo valor de temperatura, levando à conclusão que estes envios causaram grande consumo energético desnecessário (uma vez que o grande “vilão” do consumo no projeto é a transmissão de dados por Wi-Fi, conforme visto na parte 1 desta série). Logo, poderíamos enviar apenas valores diferentes de temperatura, diminuindo, assim, o uso do Wi-Fi e, por consequência, aumentando a economia da bateria, nesse caso para 24x.

Vamos fazer algumas contas para dar um norte a esta nova informação, que deixará o ESP32 dormindo por 2 horas:

• Capacidade da bateria: 3000mAh;
• Consumo médio com 2 horas de sleep: 36uA;
• Obs: A transmissão foi feita em média a cada 2 horas, portanto o ESP32 dormiu 2 horas e depois enviou.

Consumo médio com 2 horas de sleep:

Tempo de duração da bateria com 2 horas de sleep:

Veja que para este caso, com 2 horas de intervalo entre transmissões de dados, a bateria duraria (teoricamente) 9 anos e 200 dias! Incrível não?! Mas nem tudo são flores, todas contas desse projeto até agora foram apenas para dar um norte, excluindo todos componentes extras do circuito. O tempo real de execução do código ainda será calculado e o consumo provavelmente será bem maior por conta dos componentes extras no circuito.

Vamos começar a fazer alguns ajustes de tempo e consumo para que no próximo post seja calculado o tempo real de duração para nosso projeto.

Foi observado o tempo em que cada ação demora para ocorrer, separado por partes:

• Conexão com Wi-Fi: 2.5 segundos (por causa do Wi-Fi – SCAN);
• Comunicação com a planilha: 1.7 segundos;
• Total: 4.26 segundos.

Agora precisamos do real consumo do circuito, que anteriormente foi levado em consideração apenas o ESP32. Entretanto, há um componente a mais, o DHT11. De acordo com o Datasheet do DHT11, o consumo é:

• Em medições: 300uA;
• Em Standby (sleep): 60uA.

As medições do DHT11 podem demorar até ~25mS, o restante do tempo ele se encontra em Standby. Logo, vamos arrumar o último cálculo de consumo do projeto (Figura 4).

Consumo médio do projeto que se aproxima a realidade:

Tempo de duração da bateria que se aproxima à realidade:

Veja que arrumando as contas com novos tempos e componentes, o consumo ficou 4.5x maior que os anteriores, que eram apenas simulações para nos guiar. Entretanto, a bateria ainda irá durar ~2 anos, que é um bom intervalo.

Observações importantes em relação aos tempos do ESP32

1. A conexão com Wi-Fi pode chegar até ~300mS, entretanto, como o ESP32 é reiniciado totalmente, é preciso configurar toda pilha Wi-Fi novamente. E o ESP32 faz o uso da LWIP, que não é muito otimizada em velocidade, e algumas mudanças, como IP fixo, podem melhorar esses tempo;
2. Se você precisa de uma inicialização do Deep Sleep mais rápida, há inúmeras configurações que permitem isso, por exemplo, a calibragem do RTC_SLOW_CLK que leva por padrão 1024 ciclos do XTAL principal (~2.5uS) e o tempo extra de inicialização da FLASH (~2mS);
3. Você pode notar alguma perda de “temporização” ao usar longos períodos de Deep Sleep, isso acontece pois o cristal do RTC é mais instável que o cristal principal. Você pode melhorar a precisão configurando uma calibragem maior (como citado na Obs 2), que é útil em Deep Sleep’s de longo período.
4. A conexão com a planilha é relativamente lenta, pois a conexão ao servidor do Google planilhas é feita por SSL/TLS (HTTPS) e isso necessita de um processamento maior e maior número de trocas de mensagens entre cliente e servidor. Logo leva a um tempo de Wi-Fi ativo maior do que se comparado ao caso de uso de HTTP “simples” ou MQTT, por exemplo.

Nosso projeto finalmente está vivo e pronto, mas existe algo a mais que podemos fazer para melhorar o consumo e aumentar ainda mais a duração da bateria, caso seu projeto precise de extrema economia: estratégias de programação. Vamos melhorar a eficiência desse código apresentado, incluindo verificações de dados e um modo de economia a mais, o Modem Sleep.

Saiba mais sobre IoT

Enviando dados para a nuvem com Azure IoT Hub

IoT: Contexto geral, presente e perspectiva futura – Parte 1

Como conectar a DragonBoard 410C no IBM Watson IoT Platform

Editorial: IoT – Internet das Coisas – Mocinha ou Vilã?

Referências

Instalando ESP32 na Arduino IDE

Google planilhas para debug

Datasheet do DHT11