Sensor de temperatura e umidade WiFi IoT. Parte: 8 IoT, Automação residencial: 9 etapas

2024 Autor: John Day | [email protected]. Última modificação: 2024-01-30 11:39

Preâmbulo

Este artigo documenta a robustez prática e o desenvolvimento progressivo de um Instructable anterior: 'Pimping' seu primeiro dispositivo WiFi IoT. Parte 4: IoT, Domótica, incluindo todas as funcionalidades de software necessárias para permitir a implantação bem-sucedida em um ambiente doméstico doméstico.

Introdução

Conforme mencionado acima, este Instructable descreve a combinação de um exemplo anterior de IoT com um design de sistema confiável, permitindo o tratamento bem-sucedido de casos de uso práticos, como; Perda de energia catastrófica, falha do MQTT Broker, falha do WiFi N / W, reconfiguração do sensor remoto, estratégia de relatório configurável para reduzir o tráfego de rede e calibração do sensor sob medida.

Um total de 6 dispositivos foram criados (veja a foto 1 acima) e distribuídos pela minha casa para formar minha primeira rede de sensores IoT.

O Instructable também vê uma revisão da convenção de nomenclatura MQTT, conforme usada na série IoT Home Automation inicial, dando lugar a uma estrutura mais equilibrada e prática, permitindo a depuração mais simples do tráfego IoT em um ambiente de dispositivo IoT múltiplo.

A seguir estão os detalhes completos do design do sensor IoT, incluindo; construção, código-fonte, estratégia de teste e configurações OpenHAB.

Quais peças eu preciso?

1. 1 de ESP8266-01,
2. 2 capacitores eletrolíticos de 1uF,
3. 3 resistores de 10K,
4. 1 resistor 330R,
5. 1 fora de 3 mm diâm. CONDUZIU,
6. 1 desligado LD1117-33v, 3v3 LDO VReg. (Farnell aqui),
7. 1 sensor de temperatura / umidade DHT22 desligado,
8. 1 conector Dual 4way 0,1 ",
9. 1 caixa de plástico CAMDENBOSS RX2008 / S-5, caixa de envasamento, ABS, 38 mm, 23 mm (Farnell aqui),
10. 1 conector de alimentação DC desligado, plugue, 1 A, 2 mm, montagem em painel (Farnell aqui),
11. 1 fora do dissipador de calor TO-220 24,4 ° C / W (Farnell aqui),
12. Vários tubos termorretráteis (amarelo, Ebay aqui),
13. Cabo de fita IDC de vários comprimentos,
14. Composto do dissipador de calor,
15. Veroboard,
16. Dispositivo de programação ESP8266-01. Veja aqui; Construção prática do circuito com placa de tira, etapa 9 em diante.

Qual software eu preciso?

1. Arduino IDE 1.6.9
2. Arduino IDE configurado para programar o ESP8266-01. Veja aqui; Configurando o Arduino IDE para programar o ESP8266-01

Quais ferramentas eu preciso?

1. Ferro de solda,
2. Broca e várias brocas,
3. Arquivos,
4. Serrote,
5. Torno robusto,
6. Pistola de calor,
7. DMM.

Quais habilidades eu preciso?

1. Domínio mínimo de eletrônica,
2. Conhecimento do Arduino e seu IDE,
3. Habilidades de fabricação rudimentar (solda, serragem, lixamento, perfuração etc.),
4. Um pouco de paciencia,
5. Alguma compreensão da sua rede doméstica.

Assuntos abordados

1. Visão geral do circuito
2. Visão geral do sistema de software
3. Visão geral do software
4. Calibração do Sensor
5. Convenção de Nomenclatura de Tópico MQTT
6. Configuração OpenHAB
7. Testando o Design
8. Conclusão
9. Referências usadas

Links da série

Para a Parte 7: Controlador de luzes de estudo (retrabalhado). Parte 7: IoT, automação residencial

Para a Parte 9: Controlador principal IoT. Parte 9: IoT, automação residencial

Etapa 1: Visão geral do circuito

A Figura 1 acima mostra o projeto do circuito completo do sensor IoT.

No coração do dispositivo IoT está o ESP8266-01, que é conectado a um sensor de temperatura / umidade DHT22 por meio de um resistor pull up de 10K para GPIO2. Um 5v externo é fornecido com uma fonte de modo comutado e alimentado para o dispositivo através de um soquete de montagem em painel DC de 2 mm e regulado localmente com um regulador de tensão LDO 3v3 LD1117-33v montado em um dissipador de calor externo com um parafuso e porca BZP M3 de cabeça panela.

O design inclui um LED vermelho de 3 mm conectado ao GPIO0 que é usado para fornecer uma indicação local do status do dispositivo IoT durante a inicialização ou qualquer condição de erro subsequente. Também pode ser usado para identificar o dispositivo por ativação manual através da interface openHAB.

O projeto completo se encaixa perfeitamente em uma caixa de envasamento ABS conforme mostrado acima na figura 2 e foi projetado especificamente para garantir que o sensor esteja o mais longe possível do regulador para evitar polarização devido aos efeitos do aquecimento local (figura 7 acima).

A placa de circuito é uma peça única de veroboard, cortada sob medida e feita para caber no gabinete (foto 3 acima). Esta placa é fixada na posição com um parafuso de náilon escareado M3 e duas porcas que se encaixam perfeitamente na parte inferior do sensor, permitindo que ele se encaixe em uma superfície plana.

As imagens 4… 6 mostram vários estados de construção.

Etapa 2: Visão geral do sistema de software

Este dispositivo de detecção de temperatura e umidade IoT contém seis componentes de software principais, conforme mostrado na figura 1 acima.

SPIFFS

Este é o SPI Flash Filing System integrado e é usado para armazenar as seguintes informações (veja a figura 2 acima);

• Ícones e 'Página inicial de configuração do sensor' html: servido pelo dispositivo IoT quando ele não consegue se conectar à sua rede IoT WiFi (geralmente devido a informações de segurança incorretas) e fornece ao usuário um meio de configurar remotamente o sensor sem a necessidade para reprogramar ou fazer upload de novo conteúdo SPIFFS.
• Informações de segurança: contém as informações usadas na inicialização do dispositivo IoT para se conectar à sua rede IoT WiFi e MQTT Broker. As informações enviadas por meio da 'Página inicial de configuração do sensor' são gravadas neste arquivo ('secvals.txt').
• Informações de calibração: As informações contidas neste arquivo ('calvals.txt') são usadas para calibrar o sensor de temperatura / umidade integrado, caso seja necessário. As constantes de calibração só podem ser gravadas no dispositivo IoT por meio de comandos MQTT de um broker MQTT.

Nota: Para configurar inicialmente o dispositivo, veja aqui os detalhes completos sobre como usar SPIFFS com o Arduino IDE.

Servidor mDNS

Esta funcionalidade é invocada quando o dispositivo IoT não consegue se conectar à sua rede WiFi como uma estação WiFi e, em vez disso, torna-se um ponto de acesso WiFi semelhante a um roteador WiFi doméstico. No caso de tal roteador, você normalmente se conectaria a ele digitando o endereço IP de algo como 192.168.1.1 (geralmente impresso em uma etiqueta afixada na caixa) diretamente na barra de URL do seu navegador, quando você receberia uma página de login para entrar o nome de usuário e a senha para permitir a configuração do dispositivo.

Para o ESP8266 no modo AP (modo de ponto de acesso), o padrão do dispositivo é o endereço IP 192.168.4.1, no entanto, com o servidor mDNS em execução, você só precisa inserir o nome amigável 'SENSORSVR.local' na barra de URL do navegador para ver o 'Página inicial de configuração do sensor'.

Cliente MQTT

O cliente MQTT fornece todas as funcionalidades necessárias para; conecte-se ao seu broker MQTT da rede IoT, inscreva-se nos tópicos de sua escolha e publique cargas úteis para um determinado tópico. Resumindo, ele fornece a funcionalidade principal da IoT.

Servidor Web

Conforme mencionado acima, se o dispositivo IoT não puder se conectar à rede WiFi cujo SSID, P / W etc. está definido no arquivo de informações de segurança mantido em SPIFFS, o dispositivo se tornará um ponto de acesso. Uma vez conectado à rede WiFi fornecida pelo Ponto de Acesso, a presença de um Servidor Web HTTP permite que você se conecte diretamente ao dispositivo e altere sua configuração por meio do uso de um Navegador Web HTTP, cujo objetivo é servir a 'Página de Configuração de Sensor Página da web da página que também é mantida em SPIFFS.

Estação WiFi

Esta funcionalidade dá ao dispositivo IoT a capacidade de se conectar a uma rede WiFi doméstica usando os parâmetros no arquivo de informações de segurança, sem isso seu dispositivo IoT não será capaz de assinar / publicar no MQTT Broker

Ponto de Acesso WiFi

A capacidade de se tornar um ponto de acesso WiFi é um meio pelo qual o dispositivo IoT permite que você se conecte a ele e faça alterações na configuração por meio de uma estação WiFi e um navegador (como o Safari no iPad da Apple).

Este ponto de acesso transmite um SSID = "SENSOR" + os últimos 6 dígitos do endereço MAC do dispositivo IoT. A senha para esta rede fechada é imaginativamente chamada de 'SENHA'

Etapa 3: Visão geral do software

PreamblePara compilar com sucesso este código-fonte, você precisará das seguintes bibliotecas extras;

PubSubClient.h

• Por: Nick O'Leary
• Objetivo: Permite que o dispositivo publique ou assine tópicos MQTT com um determinado Broker
• De:

DHT.h

• Por: Adafruit
• Objetivo: Biblioteca para Sensor de Temperatura / Umidade DHT
• De:

Visão geral do código

O software faz uso da máquina de estados conforme mostrado na figura 1 acima (cópia completa da fonte fornecida abaixo). Existem 5 estados principais abaixo;

• INICIAR

  Este estado de inicialização é o primeiro estado inserido após a inicialização

• NOCONFIG

  Este estado é inserido se após ligar um arquivo secvals.txt inválido ou ausente for detectado

• PENDENTE NO

  Este estado é transitório, inserido enquanto não existe nenhuma conexão de rede WiFi

• MQTT PENDENTE

  Este estado é transitório, inserido após uma conexão de rede WiFi ter sido feita e embora não exista nenhuma conexão com um broker MQTT nessa rede

• ATIVO

  Este é o estado operacional normal inserido depois que uma conexão de rede WiFi e uma conexão do MQTT Broker foram estabelecidas. É durante esse estado que a funcionalidade de temperatura e umidade do sensor é publicada no MQTT Broker

Os eventos que controlam as transições entre os estados são descritos na figura 1 acima. As transições entre estados também são regidas pelos seguintes parâmetros SecVals;

• Endereço IP do 1º MQTT Broker. Na forma decimal com pontos AAA. BBB. CCC. DDD
• 2ª Porta do Broker MQTT. Em forma de número inteiro.
• A terceira conexão do MQTT Broker tenta fazer antes de alternar do modo STA para o modo AP. Em forma de número inteiro.
• 4º SSID da rede WiFi. Em texto de forma livre.
• 5ª senha da rede WiFi. Em texto de forma livre.

Conforme mencionado acima, se o dispositivo IoT não puder se conectar como uma estação WiFi à rede WiFi cujo SSID e P / W estão definidos em secvals.txt mantido em SPIFFS, o dispositivo IoT se tornará um ponto de acesso. Uma vez conectado a este ponto de acesso, ele servirá a 'Página inicial de configuração do sensor' conforme mostrado acima na Figura 2 (inserindo 'SENSORSVR.local' ou 192.168.4.1 na barra de endereço URL do seu navegador). Esta página inicial permite a reconfiguração do sensor por meio de um navegador

Acesso remoto enquanto no estado ATIVO

Uma vez conectado ao MQTT Broker, também é possível recalibrar e reconfigurar o dispositivo por meio de publicações de tópico MQTT. O arquivo calvals.txt tem acesso R / W e secvals.txt tem acesso somente gravação exposto.

Depuração de usuário

Durante a sequência de inicialização, o LED do dispositivo IoT fornece o seguinte feedback de depuração

• 1 Flash curto: Nenhum arquivo de configuração localizado em SPIFFS (secvals.txt)
• 2 flashes curtos: o dispositivo IoT está tentando se conectar à rede WiFi
• Iluminação contínua: o dispositivo IoT está tentando se conectar ao MQTT Broker
• Desligado: o dispositivo está ativo
• Nota 1: A 'página inicial de configuração do sensor' não usa soquetes seguros e, portanto, depende da segurança da sua rede.
• Observação 2: para programar cada dispositivo IoT, a string MQTT exigirá edição antes do download. Isso ocorre porque o número do sensor foi integrado à sequência de tópicos MQTT. ou seja, 'WFD / THSen / 100 / HumdStatus / 1' para meus 6 dispositivos, eles são numerados de 1 a 6, respectivamente.

Etapa 4: calibração do sensor

Quando o dispositivo IoT é inicializado, como parte da sequência de inicialização, um arquivo denominado 'cavals.txt' é lido do SPIFFS. O conteúdo deste arquivo são constantes de calibração conforme indicado acima na figura 1. Essas constantes de calibração são usadas para ajustar as leituras adquiridas do sensor para alinhá-las com um dispositivo de referência. Há um outro valor que define uma estratégia de relatório para o dispositivo e é descrito abaixo junto com o procedimento seguido para calibrar os sensores.

Estratégia de relatório Este parâmetro determina como o sensor remoto relata quaisquer alterações paramétricas do ambiente locais para ele. Se um valor de 0 for selecionado, o sensor remoto publicará qualquer mudança que vir nos valores de temperatura ou umidade cada vez que o sensor for lido (aproximadamente a cada 10 segundos). Qualquer outro valor atrasará a publicação de uma alteração em 1 a 60 minutos. A modificação deste parâmetro permite a otimização do tráfego de rede MQTT.

Calibração de temperatura

Para calibrar os sensores, eles foram colocados em estreita proximidade física uns com os outros, conforme mostrado acima na foto 2. Ao lado deles, coloquei um DMM com um termopar calibrado conectado (Fluke 87 V) e, em seguida, monitorei as saídas de cada dispositivo através da temperatura do OpenHAB página de tendências ao longo de um dia para obter uma boa oscilação de temperatura. Observei o deslocamento estático (elevado zero 'C') e a taxa de alteração de cada dispositivo (ganho ou inclinação do gráfico 'M') em relação ao valor proveniente do termopar calibrado. Em seguida, calculei a relação y = mx + c simples (descobri que era suficientemente linear como uma aproximação de um gráfico de linha reta) e programei todas as correções necessárias nas constantes de calibração via MQTTSpy.

Os dispositivos foram monitorados por mais 24 horas para garantir que a calibração foi bem-sucedida. Uma indicação disso eram os traços de temperatura na página de tendências de temperatura do OpenHAB, todos praticamente uns sobre os outros.

Claro, se você estiver interessado apenas em uma estimativa da temperatura, você pode deixar todos os valores de calibração como padrão.

Calibração de Umidade

Como não possuo meios para registrar com precisão ou mesmo controlar a umidade do ambiente local, para calibrar os sensores, usei uma abordagem semelhante à anterior, colocando todos os dispositivos em estreita proximidade física (imagem 2) e simplesmente monitorando sua saída através do OpenHAB Página de tendência de umidade. Em seguida, escolhi o dispositivo nº 1 como referência de calibração e calibrei todos os dispositivos em relação a ele.

Etapa 5: Convenção de Nomenclatura de Tópico MQTT

Depois de muita tentativa e erro, decidi sobre a convenção de nomenclatura de tópicos descrita na foto 1 acima.

A saber, 'AccessMethod / DeviceType / WhichDevice / Action / SubDevice'

Não é perfeito, mas permite que filtros úteis sejam aplicados para ver todas as saídas do sensor para um determinado valor paramétrico, permitindo assim uma comparação fácil como na figura 2 acima com MQTTSpy. Ele também oferece suporte a agrupamentos lógicos razoavelmente extensíveis de funcionalidade em um determinado dispositivo IoT.

Ao implementar esses tópicos em software, usei sequências de tópicos codificados permanentemente com identificadores numéricos fixos e incorporados para cada dispositivo, em vez de gerar dinamicamente os tópicos em tempo de execução para economizar na RAM e manter o alto desempenho.

Observação: se você não tiver certeza de como usar MQTTSpy, consulte aqui 'Setting Up an MQTT Broker. Parte 2: IoT, automação residencial '

Etapa 6: Configuração do OpenHAB

Modifiquei a configuração do OpenHAB fornecida em meu Instructable anterior (aqui) e adicionei entradas individuais para;

• Garagem,
• Corredor,
• Sala de estar,
• Cozinha
• Quarto de visitas
• Suíte master

No mapa do site, veja a foto 1 acima.

Para cada uma dessas entradas, adicionei mapas de sites individuais expondo os valores do ambiente local (ver foto 2 acima);

• Temperatura
• Umidade
• Índice de calor

Também incluí um interruptor para controlar o led local montado dentro do sensor.

As imagens 3 a 5 mostram traços individuais ao vivo durante o período de 24 horas para temperatura, umidade e RSSI (Indicação de intensidade do sinal recebido, basicamente uma medida de quão bem o sensor pode ver a rede WiFi).

A Figura 6 dá um exemplo de uma tendência de umidade de longo prazo durante o período de uma semana.

Observação 1: se você não tiver certeza de como usar o OpenHAB, consulte aqui 'Setting Up and Configuring OpenHAB. Parte 6: IoT, automação residencial '

Nota 2: Uma cópia do mapa do site modificado, regras e arquivos de itens, ícones, etc. é fornecida abaixo.

Etapa 7: Testando o Design

Na maior parte, testei o dispositivo IoT na conexão MQTT com o MQTT Spy, monitorando a saída do led e depurando o tráfego na interface serial. Isso me permitiu exercitar todos os tópicos assinados disponíveis e verificar as respostas publicadas. Embora isso fosse feito manualmente e às vezes se tornasse um pouco tedioso, permitia uma cobertura de 100%.

No entanto, a máquina de estado principal provou ser um pouco complicada de testar, pois dependia da presença ou ausência de uma rede WiFi, cujo acesso exigia conjuntos de parâmetros específicos. Simplesmente não era prático usar a rede doméstica para isso.

Para contornar esse problema, criei meu próprio conjunto de redes fictícias usando ESP8266-01 configurados como pontos de acesso (foto 1) com SSIDs de 'DummyNet1' e 'DummyNet2', respectivamente. Usando o circuito na foto 2 acima do led deu uma indicação se um dispositivo IoT tinha sido conectado a ele. Embora essa não fosse uma solução de teste perfeita (ou seja, cada uma dessas redes WiFi fictícias não continha um servidor MQTT), foi possível testar totalmente a máquina de estado.

Incluí uma cópia do código-fonte abaixo.

Etapa 8: Conclusão

Em geral

O software nos dispositivos IoT funcionou de forma confiável por muitos meses, agora se recuperando de quedas de energia em casa (principalmente causadas por mim). No geral, eles são dispositivos bastante robustos, fornecendo dados consistentes e precisos.

Melhorias

Ao desenvolver rotinas de software para ler e escrever em SPIFFS, escrevi código que, em retrospectiva, pode ser um pouco mais avançado do que eu pretendia, usando ponteiros vazios, reformulação e ponteiros para ponteiros. Embora seja muito flexível e faça um bom trabalho, da próxima vez, poderei usar JSON algo como ConfigFile.ino para mantê-lo um pouco mais simples.

• Arduino GIT HUB Core

  https://github.com/esp8266/Arduino

• Fonte de ConfigFile.ino

  https://github.com/esp8266/Arduino/tree/master/libraries/esp8266/examples/ConfigFile

Lista de Desejos

Eu pretendia usar um cliente mDNS para conectar ao Broker, mas a biblioteca era muito instável. É por isso que é necessário especificar o endereço IP do MQTT Broker em vez de 'MQTTSVR.local'. Se a biblioteca mDNS se tornar mais estável no futuro, adicionarei esse recurso ao dispositivo.

Teria sido bom ter um meio de monitorar e controlar com precisão a umidade do ambiente para calibrar os sensores. No entanto, dito isso, o método de calibração escolhido fornece boas leituras relativas e parece razoavelmente preciso, de acordo com a especificação na folha de dados DHT22.

Finalmente, dada a complexidade do software, descobri que testar totalmente o código depois de uma grande mudança estava se tornando demorado. Posso considerar o teste automatizado em uma data posterior.

Etapa 9: Referências usadas

Usei as seguintes fontes para colocar este Instructable junto;

PubSubClient.h

• Por: Nick O'Leary
• De:

DHT.h

• Por: Adafruit
• De:

Folha de Dados DHT22