Fase idIoTa, capítulo 3
Fase idIoTa, capítulo 3
Diferente das outras vezes, esta fase idIoTa da minha vida continua firme e forte, certamente porque os experimentos encontram aplicações práticas e estimulam novas incursões. Segue algumas novidades e informações, a quem interessar possa.
Não marquei a data exata, mas por esses dias fez 1 ano que o primeiro dispositivo IoT, o controlador da caixa de água, foi colocado em serviço. Um pouco antes, tinha sido instalada a Internet na casa.
Era até engraçado, uma casa sem portas nem janelas, nem alarme, totalmente aberta, dava pra ver lá da rua os LEDs vermelhos dos equipamentos. Não houve nehum furto — apenas os típicos curiosos que visitam casas em construção, como meus pais faziam no meu tempo e no dos outros era refresco.
Antes mesmo do controlador, tinha instalado um Raspberry Pi Zero com VPN, que ficava junto do roteador do provedor. Inicialmente não servia para nada, era apenas pela satisfação de estar presente remotamente. Foi o "primeiro morador honorário". Depois ele passou efetivamente a ser o controlador de água, pois reduzimos a função do Arduino a simples ponte entre sensores e MQTT.
Pelo menos neste 1 ano, a parte digital do IoT apresentou confiabilidade excelente. Até um transiente ela aguentou (as fontes queimaram todas, mas todos os chips continuam bem). Já a parte analógica do IoT apresentou diversas falhas, tanto em sensores quanto em conectores. Se for montar um sistema IoT "para produção", procure componentes de qualidade — que certamente custarão caro.
A coisa mais bizarra que aconteceu foi a seguinte: na minha instalação, a bomba de poço está a 100m da casa. O Arduino comanda um relê, que alimenta o contactor remoto, que aciona a bomba. Outros dois dispositivos são controlados de forma similar. O condutor de controle é um PP de 4 vias (1 descida para cada contactor + 1 retorno comum), totalmente separado dos condutores de força, corre até por eletroduto separado. Os contactores são de 220V.
Adicionei um disjuntor de 2A para proteção adicional do circuito de controle (do contrário, um curto faria cair o disjuntor de todo o quadro lógico). Para minha surpresa, quando o contactor estava acionado, ao desarmar o disjuntor, ele permanecia acionado!
A única explicação possível era alguma fuga de corrente, baixa o suficiente para não desarmar o disjuntor DR, mas suficiente para manter um contactor acionado. Era algo que achava impossível de acontecer num circuito de apenas 100m; mas aconteceu na minha frente, não tinha como negar. Suspeito agora que o contactor estava acionando sozinho de vez em quando, porque havia indicações esporádicas de fluxo de água com a bomba desligada, até então atribuídas por mim a ruídos do sensor de fluxo.
O que resolveu foi rearranjar a fiação de controle de forma mais deliberada: passando a fase primeiro pelo disjuntor, então para os relés, só então para as descidas até os contactores.
É como temos dito: a parte analógica do IoT é a parte mais cara e a mais envolvente — às vezes ao ponto de parecer estar possuída de espíritos...
Também é uma lição de por que devemos prestar atenção a padrões bem estabelecidos. Contactores de 24VDC são muito mais comuns e fáceis de achar que os de 110/220VAC. Além da segurança, corrente contínua tem menos tendência a fugas; e um contactor de 24V exige 10 vezes mais corrente para fazer o mesmo trabalho, portanto é 10 vezes menos provável que uma fuga de corrente consiga manter esse contactor ativado.
Há 8 meses, os "Arduinos" foram convertidos para ESP32 e MicroPython, e estou muito contente com os resultados. O interpretador mostra-se muito estável e maduro, e não tive problemas de performance. Hesitei muito entre dedicar meus esforços a Rust ou a MicroPython, talvez dedicar-me ao Rust seria mais saudável para meu currículo, mas no contexto dos meus projetinhos de IoT acho que escolhi certo.
O código pode ser encontrado aqui. Não está fartamente documentado, não tem por enquanto a pretensão de ser algo no estilo pegue-e-use. Mas pode servir de referência para as técnicas que emprego para que o negócio seja minimamente confiável. (Investir num projeto de software livre "pronto para uso" não está na minha lista de prioridades, mais adiante vou choramingar sobre isso.)
Idem quanto à escolha do ESP32 como chip padrão para todos os projetos IoT. Reitero o que disse em outros textos: nada chega perto dele em recursos (Wi-Fi, Bluetooth, memória flash, memória não-volátil) e custo-benefício.
Para humilhar ainda mais, a Espressif lançou recentemente a variante ESP32-H, com suporte a redes 802.15.4 ("Zigbee"), mais apropriadas que Wi-Fi para IoT. Ainda estão difíceis de conseguir, o suporte no MicroPython vai demorar um pouco, mas abre uma caixa de Pandora do bem.
MicroPython é amplamente usado, mas seu público é muito menor que o Python convencional, e por outro lado roda num ecossistema muito mais variado e fragmentado. Para quem gosta de participar da "komunidade" de software livre e/ou quer colaborar ativamente para algum projeto a fim de fazer seu nome, é um prato cheio. Você pode colaborar ao MicroPython em si, ou pode escrever drivers para módulos ainda não suportados (geralmente há um driver em C++ para Arduino para servir de ponto de partida), ou pode melhorar a compatibilidade de bibliotecas Python com MicroPython (exemplo).
Quem faz afirmações peremptórias demais acaba queimando a língua. Queimei a minha quando disse que automação de iluminação residencial é coisa de moleque, a versão tamanho-família de fazer piscar um LED no Arduino. Agora estou desejando iluminação automatizada na minha casa, e pagarei o preço de não ter feito logo de saída. Mas por que motivos mudei de opinião?
a) Agora que a casa "funciona", começam a aparecer oportunidades de automação que envolvem iluminação. Coisas simples como acender uma luz externa quando se desativa o alarme, ou apagar todas as luzes se não há ninguém. Ou mesmo apagar a luz do quarto usando o celular, porque levantar no frio para alcançar a chave é chato...
b) Compliquei demais a iluminação. Por exemplo, a área da cozinha está com 9 pontos. A rigor, isto dá 512 combinações possíveis, mas na prática apenas umas 3 ou 4 combinações fazem sentido. Poder-se-ia usar uma única chave para comutar entre as combinações, em vez de nove. De longe a combinação mais comum é simplesmente ligar todas as luzes (sou mais da penumbra, mas a esposa gosta de muita luz). Adicionando automação, é possível programar essa simplificação por software.
c) Um motivo de usar relés de impulso analógicos foi a impressão de que seriam muito mais confiáveis. Porém, três deles (de um universo de 30) já estragaram, logo depois da instalação pronta. Pode ter sido culpa do eletricista, pode ter sido mortalidade infantil, mas já fica a sensação que deveria ter adotado módulos Sonoff logo de saída, uma vez que têm custo similar, e confiabilidade certamente não pior que 90%.
Uma vez que faço questão de um sistema baseado em software livre e padrões abertos — não só por ideologia, mas também para que nenhum fabricante tenha o poder de transformar meu investimento em lixo eletrônico de um dia para o outro, porque foi à falência ou porque resolveu desativar sua nuvem proprietária — estou selecionando hardware para essa tarefa, sem pressa.
Iluminação é o alvo mais freqüente de esforços de automação, e existe bastante hardware aberto pronto. Não faz muito sentido construir algo do zero. Além dos já conhecidos módulos Sonoff rodando TASMOTA, achei placas baseadas no ESP32: DTWonder (comprável no AliExpress) e Hoffer Automação (nacional!). Óbvio que pretendo rodar meu próprio código MicroPython nessas placas ESP32; já comprei uma de cada para testar.
Como tenho dezenas de pontos de iluminação, os módulos Sonoff Mini ficariam muito numerosos, o que poderia sobrecarregar o Wi-Fi, então usar placas multipontos é mais racional. Além do mais, pretendo usar menos chaves para controlar mais pontos; orquestrar isso entre vários Sonoff é possível (via MQTT) porém é mais simples fazer isso agrupando os pontos relacionados numa única placa.
No momento a balança pende para os módulos DTWonder, porque são mais baratos e vêm com caixa que encaixa num trilho DIN, o que casa bem com a ideia de usar quadros de disjuntores de sobrepor (baratos e fáceis de achar) para alojar a automação. O módulo Hoffer vai para uma peça nova, cuja instalação elétrica será feita do zero. A principal vantagem do Hoffer é permitir a conexão de debug via USB.
Na figura acima, a caixinha azul é um relé de interface, necessário pois as chaves pulsantes, originalmente conectadas a relés de impulso, descarregam ao neutro, e ligar o neutro da rede no GND do módulo seria temerário. Mesmo que tivéssemos acesso aos dois fios da chave pulsante, o relé de interface ainda é interessante, pois os fios até a chave ainda podem captar ruídos elétricos.
Ainda sobre rede, por diversos motivos o ideal seria usar o protocolo Zigbee, com um único gateway entre Zigbee e rede IP. Mas por enquando a mistura de software livre com dispositivos Zigbee é indigesta. Quem sabe no futuro, com o ESP32-H2?
Estou brincando com o alarme (Intelbras AMT-8000) desde início de 2022, e finalmente ele está em operação real. Assim como aconteceu com as câmeras de vigilância, a cara-metade resistiu bastante à instalação dos sensores de alarme, por questões estéticas; mas passou a gostar entusiasmadamente do sistema quando percebeu suas vantagens, e inclusive sugere (e cobra) melhorias e automatismos.
O sistema AMT-8000 usa sensores sem fio conectados por um protocolo (proprietário) baseado no 802.15.4 e na freqüência de 900MHz. A penetração em alvenaria é excelente; pode-se adicionar repetidores ao sistema, mas dificilmente você vai precisar de um. Isto nos lembra novamente que Zigbee seria mesmo o protocolo ideal de automação, não fosse pelas incompatibilidades de hardware e pela prevalência de software fechado.
Não contratei (pelo menos ainda não) uma empresa de vigilância; faço uso de um sistema próprio de monitoramento remoto, que foi longamente testado e comprovou funcionar muito bem na vida real.
Sou suspeito em falar, mas tenho certo orgulho desse projeto. Até onde sei, é único no seu nicho, tem potencial para muitos casos de uso, e prestigia um produto nacional.
No momento, tenho pouco tempo para trabalhar nele, e ainda por cima meu único exemplar de hardware está em uso. Há recursos que gostaria de implementar inclusive para uso próprio mas não faço por medo de desprogramar a central. Há melhorias como por exemplo suporte MQTT que poderia fazer de forma mais "limpa" se tivesse incentivo, mas vou fazer de forma rápida e suja metendo um mosquitto_pub num script. Há ainda recursos que seriam mais úteis a uma empresa de monitoramento, mas ainda seriam interessantes de fazer por completeza.
Por conta disso, procurei alguns contatos para ver se conseguia alguma forma de patrocínio, de qualquer tipo. O ideal seria uma subvenção para dedicar algumas horas a mais ao projeto (afinal, cada hora dedicada a ele é uma hora a menos dedicada a atividade remunerada ou mesmo doméstica). Mas doação ou empréstimo de hardware também ajudaria — não possuo todos os sensores da série 8000, e há outras centrais compatíveis com o protocolo "Receptor IP" que nunca tive oportunidade de testar.
Para minha decepção, ainda não tive nenhuma resposta. O brasileiro continua bundão, continua com o velho cacoete de desejar os benefícios de uma "komunidade" esquecendo que ela precisa ser cultivada.
Em tempo: sim, já tive ofertas para trabalhar desenvolvendo versões customizadas do software, mas isso não me interessa no momento. Trabalho "convencional" já tenho até demais. A ideia era que o projeto tivesse auto-sustentação sem perder o caráter de software livre e aberto.