Fase idIoTa, capítulo 4
Fase idIoTa, capítulo 4
Este texto é praticamente uma continuação do Fase idIoTa, capítulo 3.
Continuo apostando no MicroPython rodando em ESP32 para meus dispositivos IoT, continuo satisfeito com a estabilidade tanto de hardware como de software. A produtividade do Python com o custo/benefício do ESP32, e ainda a ampla adoção do ESP32 pelos fabricantes de hardware, constituem um ponto ótimo no momento.
A quem interessar possa, o código-fonte está aqui. O projeto não está muito estruturado para consumo público, não tem nem um README. No momento, sua única possível serventia é servir como documentação para quem estiver brincando com MicroPython e queira tirar uma dúvida.
Apesar de estar uma bagunça, afirmo que o código é bastante robusto — o uptime dos módulos aqui já é de meses a fio — diferente de muito código IoT sem nenhuma preocupação com robustez que se encontra online. Possui até recurso de upgrade OTA (para os arquivos Python, não para o MicroPython em si) o que é importante para módulos que não têm conexão USB e/ou estejam em lugares de difícil acesso.
No médio prazo, pretendo dar uma organizada nesse código, para que ele fique mais palatável. Nunca vai concorrer com um projeto TASMOTA da vida, provavelmente ainda vai exigir que o interessado conheça um pouco de MicroPython. Mas pelo menos vai ter um README :)
Meu código tem basicamente a) uma parte em comum a todos os dispositivos, e b) diversos "perfis" opcionais, sendo que tipicamente cada caixinha roda apenas um perfil. Como disse em outro texto, os perfis de sensor de caixa de água e de cargas intermitentes já estão na ativa faz tempo.
No momento o que ocupa meu tempo livre é construir os módulos de automação de iluminação. O primeiro módulo já está em teste há vários meses (no meu escritório, para que em caso de problema, afete apenas a mim), e espero instalar os demais em breve.
O sistema de iluminação aqui em casa possui uma espécie de "pré-automação", com interruptores pulsantes e relés de impulso. Noves fora a mancada de não ter concentrado os relés num quadro de distribuição — o que me obriga agora a usar quadros de sobrepor, que ficarão escondidos em armários ou móveis planejados.
Apenas um fio foi puxado de cada relé de impulso até seu interruptor, que descarrega no neutro ao ser pulsado, acionando o motor do relé. Não é seguro ligar diretamente esse interruptor ao microcontrolador. A solução que encontrei foi usar relés de interface, com bobina de 220V. Os interruptores continuam operando em tensão de rede, apenas acionam um tipo diferente de relé.
Se tivesse passado dois fios até o interruptor, poderia ligá-lo diretamente ao módulo, ou pelo menos poderia usar um relé de interface de baixa tensão. Acho que usar algum relé é meio que obrigatório para isolação galvânica, pois longos lances de fio captam todo tipo de ruído. O relé também adiciona inércia mecânica e faz um pré-debouncing.
Do jeito que fizemos, mantivemos a compatibilidade elétrica com os relés de impulso, permitindo uma migração gradual, e mesmo um retorno temporário ao relé de impulso caso o módulo precise ser tirado de serviço.
Automação de iluminação é algo muito comum, então há muitos módulos prontos. Não faz sentido construir totalmente do zero. O critério de seleção foi: usar ESP32, possuir inputs para interruptores manuais, e permitir substituição do firmware. A princípio, adquiri três espécimes: DTWonder (AliExpress), Hoffer Automação (nacional), e um Sonoff Mini R4. (Este último atende apenas um ponto, então seu uso vai ser restrito a um caso onde o módulo tem de caber numa caixinha de luz.)
Escolhi o DTWonder como padrão local, porque a) são um pouco mais baratos (desde que adquiridos de 1 em 1, devido à absurda taxação que dobra o preço de encomenda internacional acima de US$ 50), b) vêm com encaixe DIN, c) são mais compactos, d) possuem versões de 2, 4, 8 ou 16 pontos, enquanto o Hoffer possui 6 pontos, demais para alguns usos e de menos para outros. O DTWonder ainda possui Ethernet, embora não seja possível usá-la a partir do MicroPython porque o chip JL1101 não é suportado.
O Hoffer também tem suas vantagens: a) o microcontrolador é literalmente um módulo de desenvolvimento ESP32, conectado à placa principal via soquete, e pode ser substituído; b) o acesso ao ESP32 é via cabo USB, enquanto no DTWonder é serial TTL usando jumpers; c) tem mais linhas de I/O, o que permite conectar outros sensores e atuadores; d) os inputs têm optoacoplador, o que permite dispensar o relé de interface (não para mim, mas para quem fizer a coisa certa e passar 2 fios até cada interruptor).
Quanto ao Mini R4, é necessário soldar fios para ter acesso à interface serial TTL (que não pode ser usada quando o Mini estiver ligado à rede elétrica!). Fora isso, ele se comporta como um ESP32 qualquer, inclusive no tocante ao MicroPython.
Para o caso de uso do Mini R4, poderia usar simplesmente um módulo Mini R2 com TASMOTA, que até já possuo. Até chegar o momento de instalar eu decido se vou pelo certo (R2) ou pelo "duvidoso" (R4).
Comecei a pesquisar sensores de tensão e corrente de corrente alternada. A maioria dos sensores disponíveis para Arduino/IoT é bastante amadora, basicamente rebaixadores de tensão que o software tem de interpretar como um sinal analógico. Não é algo que passa muita segurança ao ser conectado em 220V, embora possa ser interessante para aprendizado de elétrica. O software teria de analisar a forma de onda de tensão e corrente para calcular tensão eficaz, potência, etc. o que está num nível nerd um pouco além do desejado, mas novamente não dá pra negar o potencial didático.
Até agora, o dispositivo mais "civilizado" que encontrei foi o PZEM-004T. Ele é bem próximo do ideal: calcula e reporta digitalmente tensão, corrente, potência e fator de potência. A única pequena desvantagem é usar serial TTL e usar protocolo ModBus (esse módulo é para uso industrial sério, e pode ser conectado via RS-485 a uma rede ModBus). O ideal para uso "maker" seria protocolo I2C.