Boa tarde, queridos Khabrovites! Alguns anos atrás, comprei um anúncio zWave colorido e instalei sensores de janela com base nesse protocolo. Um zWave-Stick USB foi conectado ao servidor doméstico, que desempenhou o papel de um controlador, um pequeno módulo Java foi gravado que recebeu dados desse controlador e um pequeno aplicativo para Android foi gravado, exibindo lindamente o status de todos os sensores. Baterias são inseridas, sensores são registrados no controlador, tudo funcionou. Mas depois de alguns meses, houve uma terrível decepção. Em primeiro lugar, esses sensores zWave trabalham com o princípio de "enviar uma mensagem e adormecer sem aguardar confirmação". No meu caso, isso levou ao fato de que o sinal dos sensores mais distantes do controlador simplesmente não chegou ao controlador. Mesmo a instalação de um repetidor zWave adicional não ajudou. Em segundo lugar, eles descarregaram a bateria tão rapidamente que, após cerca de seis meses, todos os sensores pararam de funcionar. O motivo é que eles acordavam a cada hora para informar o controlador sobre sua condição. Desabilitar ou alterar esta opção não funcionou, pois o software padrão categoricamente não permitiu isso. Após dois anos de tormento com essa tecnologia bruta, não confiável e hostil, decidi que tinha o suficiente. Mas, em vez de guardar tudo e jogá-lo fora, tive a ideia de deixar os estojos, mas alterei os eletrônicos neles. A escolha recaiu sobre um transceptor RFM69 bastante simples (433 MHz), com base no qual foi possível criar uma placa para o sensor e um controlador conectado via USB ao servidor. O novo sistema já está em operação há 5 meses, a confiabilidade é próxima de 100% (mas ainda existem algumas falhas), as baterias ainda não parecem vazias. Ou seja, já é visível que todas as deficiências do sistema antigo baseado no zWave foram eliminadas e quero compartilhar os detalhes técnicos deste artigo, veja a figura.
Quem se importa, por favor, debaixo do gato.
Parece-me que o zWave, no meu caso, se mostrou inoperante por dois motivos: a casa tem dois andares com piso de concreto armado e uma grande área (isto é, uma remoção significativa de alguns sensores do controlador). Bem, falhas no software proprietário, que não permitiam desativar a ativação periódica dos sensores, o que levava a uma rápida descarga da bateria. Quando ficou claro que não estava a caminho do zWave, comecei a procurar outras opções que pudessem ser empurradas para as mesmas caixas de sensores.
Meu primeiro protótipo de sensores foi baseado no ESP8266. O controlador - com base no meu pagamento sobre o qual eu já
escrevi no Habré . O sistema até funcionou como um protótipo, mas tive que abandoná-lo por dois motivos. A primeira razão é a mesma: na casa havia cantos com um nível muito baixo de sinal WiFi, o que levou a um tempo de ativação muito longo do ESP8266 ao acordar e, como resultado, a uma forte descarga de bateria. Embora eu admita que simplesmente não sei cozinhar isso muito ESP8266 (artigos
como este confirmam esta tese). Mas o segundo motivo foi mais sério. Como decidi deixar não apenas o estojo, mas também o compartimento da bateria, fiquei limitado a uma bateria CR123A, que é de 3,0 volts. Ou seja, o preço e a complexidade do sensor aumentaram devido ao aumento do conversor DC / DC. Embora
exista um artigo maravilhoso sobre este tópico em Habré. Mas, enfim, esses dois motivos superaram e eu rejeitei o ESP8266.
O segundo protótipo foi conectado. Fiz um protótipo do sensor e do controlador USB, adicionei um módulo de servidor para que ele entendesse esse controlador além do zWave-Stick. Havia uma ideia de puxar gradualmente os fios e o sensor após o sensor para mudar a placa zWave para uma com fio. Mas no final, ele não escolheu paredes e esse protótipo também foi descartado.
Então ele decidiu olhar para os módulos de rádio em 433 e 868 MHz e encomendou vários módulos para experimentos:
RFM69HCW ,
A110LR09A e
MRF89XAM8A . Em termos de tamanho, preço e também devido à disponibilidade de bibliotecas e
bons exemplos, optei pelo RFM69HCW, que formava a base do sistema.
O sistema possui apenas quatro componentes:
- sensores sem fio (433 MHz, bateria CR123A 3.0V),
- controlador de rede (433 MHz, alimentado via USB a partir do servidor)
- o servidor (sobre o qual eu já escrevi no Habré neste artigo ) e o módulo do programa do servidor
- cliente móvel (aplicativo Android)
Abaixo, descreverei cada módulo em detalhes e, no final, darei estatísticas sobre a operação do sistema nos últimos meses de operação.
Sensores
Os sensores usam o
módulo de rádio
RFM69HCW . Possui uma ampla faixa de tensão operacional (1,8V-2,4V 17dBm, 2,4V-3,6V 20dBm) e é controlada via SPI. Ou seja, você precisa de um microcontrolador. Algum tempo atrás, eu me familiarizei com a série STM32L e pedi o STM32L051 para experimentos. Ele me subornou como uma pequena corrente no modo de suspensão (0,27 μA) e a tensão de operação, quase idêntica à tensão do módulo de rádio (1,65V-3,6V). Mais baixo preço.
O resultado foi o seguinte:
A tensão de alimentação do microcontrolador e do módulo de rádio é tal que eles podem ser alimentados diretamente a partir do elemento CR123A. O STM32L051 possui uma referência de tensão interna conectada ao canal ADC 17, bem como o valor de calibração dessa fonte, que permite medir o valor atual da tensão de alimentação VDD. O módulo de rádio está conectado à energia através do dispositivo de campo Q1, que permite controlar a energia do microcontrolador.
O modo de suspensão é implementado transferindo o microcontrolador para "Em espera". Nesse modo, o STM32L051 possui um núcleo desativado, quase todos os periféricos e um regulador de tensão interno, o que garante um consumo no nível de 0,29 μA (com o relógio em tempo real desativado). Mas neste modo há uma característica - o microcontrolador acorda apenas ao longo da borda ascendente do sinal no pino WKUP (A0). Como um interruptor magnético é usado, que está ligado / desligado (fechado ou aberto), você precisa de um pequeno bloco que gere um pulso de curta duração, ao fechar e ao abrir um contato magnético. Esse pulso é alimentado na entrada A0 do microcontrolador e o desperta. Esse conversor é implementado no chip OR-IC3 exclusivo da série 74AUP de baixo consumo de energia (74AUP1G86), que opera na faixa de tensão de 0,8V-3,6V e consome 0,2 μA. Assim, o consumo total no modo de suspensão deve ficar em torno de 0,5 μA, o que é confirmado por medições em um sensor totalmente montado.
Quando o microcontrolador acorda, ele primeiro mede a tensão de alimentação e, se for menor que 1,8 volts, não é o destino - o transmissor não pode ser iniciado e o microcontrolador adormece.
Se a tensão da bateria for superior a 1,8 volts, o microcontrolador liga e inicializa o módulo de rádio, transfere o estado para o controlador de rede e aguarda confirmação. O pacote de dados inclui um número exclusivo de pacote de 32 bits (evento), tensão da bateria, temperatura, status do contato magnético, byte de controle (CRC7). Em caso de confirmação bem-sucedida, o microcontrolador adormece. Caso contrário, envia o status novamente, mas no máximo 10 vezes. Defino esse limite para que o sensor não tente esperar indefinidamente por uma resposta em uma situação em que o controlador de rede é simplesmente desligado. O último número de evento exclusivo transmitido é armazenado na EEPROM interna do microcontrolador.
Durante a transferência de dados, o microcontrolador pisca um LED (onde sem ele). O LED é ligado usando PWM, onde o ciclo de serviço depende do valor da tensão atual, o que permite que você tenha quase o mesmo brilho em quase toda a faixa de tensão operacional.
As placas são projetadas no EagleCAD, o design da placa
está disponível aqui . As placas são de dupla face: o microcontrolador e seu chicote estão localizados no lado superior voltado para a moldura da janela, e o módulo de rádio e o LED estão no lado inferior voltado para a sala. Eu pedi na China, me soldado em um forno de cozinha convencional (camada superior) e um secador de cabelo (camada inferior).
O módulo de rádio precisa de uma antena. Este é apenas um pedaço de fio com 164 mm de comprimento.
Após a instalação, cada sensor deve ser programado, para o qual é fornecido um conector SWD. Deixei os contatos restantes no quadro para possíveis experiências no futuro.
O firmware é escrito em C ++, parte do código é realizada em classes básicas bastante universais que encapsulam chamadas para a biblioteca ST HAL. O código fonte
está aqui . Para o desenvolvimento, foi utilizado o System Workbench for STM32. O tamanho do arquivo final do firmware binário é 22 kB.
E aqui está o sensor no caso:
Dependendo da posição do sensor, para alguns sensores deixei a antena do lado de fora (contra o fundo da moldura branca, no entanto, ela não é visível) e, para alguns sensores, dobrei o fio na moldura e o enfiei completamente dentro do gabinete.
Por uma questão de interesse, calculei o custo dos componentes para um sensor (aos preços do catálogo da Mouser, preço e preço total em euros)
| Item | Descrição do produto | Valor | Número MOUSER | Qtde | Custo |
| IC3 | OU exclusivo | 1G86 | 771-74AUP1G86GW-G | 1 | 0,254 |
| IC1 | Microcontrolador | STM32L051 | 511-STM32L051K6T6 | 1 | 2,14 |
| SV1 | Conector | Swd | 68602-406HLF | 1 | 0,157 |
| LED1 | LED 3 mm | 3mm | 630-HLMP-K155 | 1 | 0,351 |
| Q1 | P-mosfet | BSH205 | 771-BSH205G2R | 1 | 0,276 |
| S1 | Contato magnético | ORD211-0810 | 876-ORD211-0810 | 1 | 0,625 |
| IC2 | Módulo de rádio RFM69HCW | RFM69HCW | 474-COM-13910 | 1 | 5,36 |
| C1, C2, C3, C6 | Capacitor SMD | 0.1uF | 80-C0805C104J5RAC | 4 | 0,1 |
| C5 | Capacitor SMD | 0.4nF | C0805C471K8HACTU | 1 | 0,021 |
| C4 | Capacitor SMD (tântalo) | 47uF | 581-TAJR225K016RNJ | 1 | 0,334 |
| R1 | Resistor SMD | 10K | 660-RK73H2ATTDD1002F | 1 | 0,01 |
| R10 | Resistor SMD | 330 | 660-RK73H2ATTDD3300F | 1 | 0,01 |
| R3, R4, R6, R7, R8, R11 | Resistor SMD | 47K | 660-RK73H2ATTDD4702F | 6 | 0,06 |
| R5 | Resistor SMD | 56. | 660-RK73H2ATTD56R0F | 1 | 0,013 |
| R9 | Resistor SMD | 56M | 603-RC0805JR-0756ML | 1 | 0,037 |
| | | | | 9,748 |
A propósito, ficou exatamente três vezes mais barato que o sensor zWave original. Embora este seja apenas o custo de peças, excluindo o caso. Mas, na minha opinião, no varejo, os sensores zWave são indecentemente caros.
Controlador de rede
Para o controlador, o mesmo módulo de rádio e o mesmo microcontrolador foram utilizados nos sensores. Isso permitiu reutilizar a maior parte do código do firmware. Para o controlador, escolhi esse formato da placa para usar o gabinete pronto do Raspberry Pi. Comparado ao sensor, foram adicionados um conector de antena externa e um loop USB baseado no isolador FT232RL e SI-8621. Obviamente, em vez disso, pode-se levar algum STM32 com USB a bordo. Mas então, primeiro, seria necessário separar o código do firmware e, segundo, fazer a implementação do software do próprio USB. A opção com um FT232RL externo, embora seja mais cara, é mais confiável e mais rápida de implementar. O resultado é o
seguinte esquema :
E na forma montada ficou assim:
O microcontrolador não dorme aqui, o módulo de rádio funciona para recepção, mas após receber com êxito um pacote de qualquer um dos sensores, o módulo entra no modo de transmissão e envia uma confirmação. Além disso, qualquer pacote recebido com sucesso é transmitido via USB para o servidor. O formato do pacote é uma sequência de valores separados pelo símbolo ";":
GW; 3; 12; -57; 0; 146; 30; 18
onde:
- primeira posição é a etiqueta do pacote (sempre “GW”)
- segunda posição - tipo de dados (status do sensor ou código de erro)
- terceira posição - número do sensor
- quarta posição - qualidade do sinal na lateral do controlador de rede (o RFM69HCW preserva a qualidade do sinal durante a recepção e permite que você a interrogue quando a recepção termina)
- quinta posição - estado da janela (0 aberto, 1 fechado)
- sexta posição - um número exclusivo do pacote (evento) do sensor. Esse número permite controlar no lado do servidor se todos os eventos foram recebidos pelo servidor ou se um ou mais eventos foram perdidos.
- sétima posição - tensão atual da bateria (30 corresponde a 3.0V)
- a última, oitava posição é a temperatura do sensor interno do microcontrolador. Ainda não descobri como usá-lo
O código fonte do firmware está
no mesmo local que o sensor . Eles têm um arquivo principal comum e uma biblioteca comum de classes base. A opção de firmware (sensor ou controlador) é selecionada usando a diretiva define no arquivo main.cpp.
O custo do controlador de rede é maior devido ao circuito USB, antena e conectores adicionais. Mas esse aditivo pode ser negligenciado, pois existe apenas um controlador. Mas, mesmo com este suplemento, ele também se mostrou três vezes mais barato que o zWave-Stick, que estava antes em seu lugar.
Módulo servidor
O controlador de rede está conectado a um servidor executando o CentOS 7. O servidor executa um programa escrito em Java. E em sua estrutura, implementação e tarefas, o programa é bastante simples:
- Usando uma biblioteca RxTx muito antiga e aparentemente sem suporte, a porta USB especificada na configuração é monitorada (no meu caso / dev / ttyUSB0). No momento, essa é a parte menos otimizada de todo o sistema, pois a biblioteca carrega muito o processador do servidor.
- Se os dados são recebidos da porta USB, eles são gravados em um arquivo de log e armazenados na classe de status do sensor. Quando você reinicia o servidor, o estado é perdido. Para restaurá-lo, você precisa percorrer a casa e abrir e fechar manualmente todas as janelas. Essa é provavelmente a maior desvantagem do meu sistema, mas eu me recusei conscientemente a pesquisar periodicamente os sensores com o objetivo de economizar suas baterias.
- O aplicativo também é um pequeno servidor TCP / IP e escuta na porta TCP / IP especificada na configuração. Nesta porta, ele pode aceitar conexões de um cliente móvel.
- Se o cliente móvel se conectar ao servidor, ele envia o status atual de todos os sensores. Usando mensagens periódicas de heartbit, o servidor também monitora a atividade da conexão.
- O servidor e o cliente móvel trocam mensagens no formato XML. Essas mensagens são implementadas na forma de uma pequena biblioteca Java , que é compartilhada no lado do servidor e no lado do aplicativo móvel Android.
- Embora isso não faça muito sentido, por uma questão de interesse, adicionei a função de autorizar um cliente móvel via IMEI, bem como a criptografia AES de mensagens entre o servidor e o cliente usando uma chave costurada no código-fonte (pacote Java javax.crypto). Mas isso é apenas para o experimento, já que a porta TCP / IP deste módulo de servidor é acessível apenas a partir da rede interna e não é visível a partir do exterior. Embora, se eu quiser abrir essa porta para o grande mundo, agora não será tão assustador fazê-lo.
Quem se importa, o código fonte do módulo do servidor está
aqui .
Cliente móvel (aplicativo Android)
Você não escreve muito aqui, apesar de esse aplicativo ser o resultado final de todo o projeto. Este é um aplicativo Java padrão e muito simples, com três guias: o estado das janelas do primeiro andar, o estado do segundo andar e uma pequena telemetria do servidor (consulte o
código-fonte aqui ):
Os gráficos são baseados em um conjunto de arquivos SVG, que são empilhados uns sobre os outros, dependendo do estado dos sensores. Uma pressão longa é suportada na área de cada janela, segundo a qual uma dica é exibida com o horário em que esta janela foi aberta:
Em princípio, nada impede que você adicione um ícone de bateria a essa dica de ferramenta, mas suas mãos ainda não o alcançaram.
Experiência operacional
"Todo espirro" é registrado em um arquivo de log no lado do servidor. A análise desses arquivos nos últimos 5 meses nos permite entender um pouco mais detalhadamente como esse sistema se sente.
A análise é muito simples - apenas grep na pasta de arquivos de log no servidor.
Quantos erros houve na transmissão de dados no canal de rádio? Durante 5 meses, 8 erros foram registrados quando a mensagem foi recebida no tamanho errado e 25 erros no CRC errado. Nos dois casos, você não pode dizer diretamente qual sensor teve problemas, pois o pacote de dados neste caso está completamente danificado. Como o controlador de rede não confirma a recepção de dados em todos esses casos, o sensor deve enviar os dados de uma nova maneira, o que na maioria dos casos corrige esses erros.
E aqui está uma tabela de resumo sobre a operação dos sensores por 5 meses.
| Pavimento | Sensor | Quantidade
De eventos | Dos perdidos
De eventos | Tensão
Baterias | Mediana
Poder
Signal |
| 1 | 10 | 105 | 0 0 | 3.1. | -66 |
| 1 | 11 | 52 | 0 0 | 3.3. | -70 |
| 1 | 12 | 122 | 0 0 | 3.3. | -61 |
| 1 | 13 | 89 | 0 0 | 3.3. | -74 |
| 1 | 14 | 2573 | 0 0 | 3.3. | -68 |
| 1 | 15 | 261 | 0 0 | 3.3. | -60 |
| 1 | 16 | 543 | 2 | 3.3. | -70 |
| 1 | 17 | 156 | 2 | 3.3. | -74 |
| 1 | 18 | 177 | 2 | 3.2. | -68 |
| 1 | 19 | 384 | 3 | 3.3. | -56 |
| 2 | 3 | 368 | 2 | 3.3. | -62 |
| 2 | 4 | 86 | 0 0 | 3.3. | -71 |
| 2 | 5 | 521 | 2 | 3.3. | -59 |
| 2 | 6 | 115 | 0 0 | 3.3. | -62 |
| 2 | 7 | 316 | 2 | 3.3. | -63 |
| 2 | 8 | 419 | 1 | 3.3. | -60 |
| 2 | 9 | 89 | 0 0 | 3.3. | -68 |
O sensor n ° 10 congela uma vez. Aparentemente, isso levou a uma diminuição significativa na tensão da bateria. A razão do congelamento ainda não está clara. Ele trava novamente, você precisa descobrir.
O sensor n ° 14 está instalado na porta da frente, e é por isso que ele tem um número tão grande de respostas. Mas um número tão grande de viagens ainda não afetou a tensão da bateria.
Um evento perdido é quando o sensor tenta enviar um estado, mas o servidor não o confirma. Todos os eventos perdidos se devem ao fato de eu desligar o servidor por cerca de meio dia para a limpeza.
A coluna Mediana da força do sinal mediana mostra o valor mediano do RSSI (em dBm), onde cada valor individual é obtido após o recebimento de cada pacote. O sensor com o melhor sinal (nº 19, -56 dBm) está localizado a 2 metros do controlador de rede, mas a antena desse sensor está enrolada dentro do gabinete. O próprio controlador de rede está localizado no térreo. No entanto, o sinal dos sensores do segundo andar é muito bom. Isso se deve ao fato de que em todos os sensores do segundo andar a antena é removida da carcaça do sensor.
Em vez de um posfácio
Por um lado, fico feliz que, por conta própria, como hobby, tenha saído do zero para projetar, montar e executar um sistema desse nível. E ainda mais feliz por funcionar melhor que o sistema "proprietário", baseado na tecnologia hype da zWave. Também há espaço para desenvolver e melhorar esse sistema. Eu sou apenas roído por pequenas dúvidas. Ou seja, que uma pessoa sem educação elétrica especializada colete de joelhos algo que funcione de maneira mais confiável do que produtos de marca conhecidos em círculos estreitos de marcas IOT. Provavelmente, o progresso virou em algum lugar na direção errada.