Há algum tempo, apresentamos a você . O artigo atual foi inicialmente pensado como uma demonstração de seu firmware e sistema de controle. Mas, para explicar a lógica de funcionamento do termostato e o que implementamos, é necessário delinear todo o conceito como um todo.
Sobre automação
Condições, toda a automação pode ser dividida em três categorias:
Categoria 1 — dispositivos “inteligentes” individuais. Você adquire lâmpadas, chaleiras etc., de diferentes fabricantes. Vantagens: cada dispositivo expande as possibilidades e aumenta o conforto. Desvantagens: para cada novo fabricante, é necessário um aplicativo próprio. Os protocolos de dispositivos de diferentes fabricantes frequentemente não são compatíveis entre si.
Categoria 2 — instalação de um PC de placa única ou compatível com x86. Isso remove as limitações de poder de computação, e neste equipamento é instalado o MajorDoMo ou qualquer outra distribuição de servidor para gerenciar a casa inteligente. Dessa forma, os dispositivos da maioria dos fabricantes se conectam em um espaço informacional único. Ou seja, um servidor para a casa inteligente é criado. Vantagens: compatibilidade sob um centro único, o que oferece amplas possibilidades de controle. Desvantagens: em caso de falha do servidor, todo o sistema retorna à fase 1, ou seja, torna-se fragmentado ou inútil.
Categoria 3 — a opção mais hardcore. Na fase de reparo, todas as comunicações são instaladas e todos os sistemas são duplicados. Vantagens: tudo é levado ao ideal e, assim, a casa se torna realmente inteligente. Desvantagens: extremo custo comparado às categorias 1 e 2, necessidade de planejamento antecipado de tudo e consideração de cada detalhe.
A maioria dos usuários escolhem a opção um e, em seguida, transita gradualmente para a opção dois. E, posteriormente, os mais determinados alcançam a opção 3.
Mas existe uma opção que pode ser chamada de sistema distribuído: cada dispositivo separado será tanto servidor quanto cliente. Essencialmente, é uma tentativa de unir a opção 1 e a opção 2. Reunir todas as suas vantagens e eliminar desvantagens, encontrando um meio-termo.
É possível que alguém diga que essa opção já foi desenvolvida. Mas essas soluções são específicas; destinadas a pessoas com conhecimento em programação. Nosso objetivo é reduzir a barreira de entrada em sistemas distribuídos, tanto na forma de dispositivos finais quanto na integração de dispositivos existentes em nosso sistema. No caso do termostato, o usuário simplesmente desinstala seu termostato antigo, instala um inteligente e conecta os sensores que já possui a ele. Sem nenhuma ação adicional.
Vamos considerar a integração em nosso sistema como exemplo.
Suponha que temos 8 módulos Sonoff na rede. Alguns usuários precisarão apenas do controle via nuvem Sonoff (categoria 1). Outros começarão a usar firmware de terceiros e migrarão gradualmente para a categoria 2. A maioria dos firmwares de terceiros opera pelo mesmo princípio: transmissão de dados para um servidor MQTT. OpenHub, Majordomo ou qualquer outro serve a um único propósito – unir dispositivos dispersos em um único espaço informativo, localizado na Internet ou em uma rede local. Portanto, a presença de um Servidor é obrigatória. Aqui surge o principal problema – se o Servidor falhar, todo o sistema deixa de funcionar de forma autônoma. Para evitar isso, os sistemas se tornam mais complexos, adicionando maneiras manuais de controle, que duplicam a automação em caso de falha do Servidor.
Nós, por outro lado, seguimos um caminho diferente, onde cada dispositivo é autossuficiente. Assim, o Servidor não desempenha um papel decisivo, apenas amplia a funcionalidade.
Vamos voltar ao experimento mental. Novamente pegamos os mesmos 8 módulos Sonoff e instalamos neles o firmware Lytko. Todas as implementações do firmware Lytko têm a função . SSDP é um protocolo de rede, baseado em um conjunto de protocolos da Internet, usado para anunciar e descobrir serviços de rede. A resposta a uma solicitação pode ser tanto padrão quanto estendida. Incorporamos a esse retorno, além das funções padrão, a criação de uma lista de dispositivos na rede. Assim, os dispositivos se encontram e cada um deles terá essa lista. Exemplo de lista SSDP:
"ssdpList":
{
"id": 94967291,
"ip": "192.168.x.x",
"type": "thermostat"
},
{
"id": 94967282,
"ip": "192.168.x.x",
"type": "thermostat"
}Como mostrado no exemplo, a lista inclui os IDs dos dispositivos, o endereço IP na rede, o tipo de bloco (neste caso, um termostato baseado em Sonoff). Esta lista é atualizada a cada dois minutos (esse intervalo é suficiente para responder às mudanças dinâmicas no número de dispositivos na rede). Assim, monitoramos a adição, alteração e desconexão de dispositivos sem qualquer ação do usuário. Esta lista é enviada para o navegador ou aplicativo móvel, e o script gera automaticamente a página com a quantidade especificada de blocos. Cada bloco corresponde a um dispositivo/sensor/controlador. Visualmente, a lista é assim:
Mas e se outros sensores de rádio estiverem conectados ao esp8266/esp32 através do cc2530 (ZigBee) ou nrf24 (MySensors)?
Sobre projetos
Existem diversos sistemas distribuídos no mercado. Nosso sistema permite integração com os mais populares.
Abaixo estão projetos que, de uma forma ou de outra, tentam mudar a situação de incompatibilidade entre diferentes fabricantes. Por exemplo, , ou . ligado a um servidor MQTT, portanto não é adequado para este exemplo.
Uma das opções para implementar MySensors é um gateway baseado em ESP8266. Os outros exemplos são baseados em ESP32. Neles, podemos implementar nosso princípio de operação para detectar e criar uma lista de dispositivos.
Vamos fazer mais um experimento mental. Temos o gateway ZESP32 ou SLS Gateway ou MySensors. Como podemos integrá-los em um único espaço de informação? Às funções padrão desses gateways, adicionaremos a biblioteca do protocolo SSDP. Ao consultar este controlador via SSDP, ele adicionará à resposta padrão uma lista de dispositivos conectados a ele. Com base nessa informação, o navegador gerará a página. Em termos gerais, isso parecerá assim:
Interface web
Aplicativo PWA
"ssdpList":
{
"id": 94967291, // identificador único do dispositivo
"ip": "192.168.x.x", // endereço ip na rede
"type": "thermostat" // tipo de dispositivo
},
{
"id": 94967292,
"ip": "192.168.x.x",
"type": "thermostat"
},
{
"id": 94967293,
"ip": "192.168.x.x",
"type": "thermostat"
},
{
"id": 13587532,
"type": "switch"
},
{
"id": 98412557,
"type": "smoke"
},
{
"id": 57995113,
"type": "contact_sensor"
},
{
"id": 74123668,
"type": "temperature_humidity_pressure_sensor"
},
{
"id": 74621883,
"type": "temperature_humidity_sensor"
}
A partir do exemplo, podemos ver que os dispositivos são adicionados de forma independente uns dos outros. Três termostatos estão conectados com seus próprios endereços IP e cinco sensores diferentes com IDs únicos. Se o sensor estiver conectado à rede Wi-Fi, terá seu próprio IP; se estiver conectado ao gateway, o endereço IP do dispositivo será o endereço IP do gateway.
Para a comunicação com os dispositivos, utilizamos WebSocket. Isso permite minimizar o consumo de recursos em comparação com solicitações GET e obter informações dinamicamente durante a conexão ou alteração.
Os dados são obtidos diretamente do dispositivo ao qual o bloco pertence, contornando o servidor. Assim, em caso de falha de qualquer um dos dispositivos, o sistema continua funcionando. No interface web, apenas o dispositivo que desapareceu da lista não será exibido. Mas o sinal de sua ausência, se necessário, chegará como uma notificação no aplicativo do usuário.
A primeira tentativa de implementar essa abordagem foi um aplicativo PWA. Isso permite armazenar a base de blocos no dispositivo do usuário e solicitar apenas os dados necessários. No entanto, devido às particularidades da estrutura, essa opção é incompleta. E a única saída é um aplicativo nativo para Android e iOS, que está atualmente em desenvolvimento ativo. Por padrão, o aplicativo funcionará apenas na rede interna. Se necessário, pode-se mudar tudo para controle externo. Assim, quando o usuário sai da rede local, o aplicativo comutará automaticamente para a nuvem.
O controle externo é uma duplicação completa da página. Ao ativar a página, o usuário pode se conectar ao servidor e gerenciar os dispositivos através do painel pessoal. Assim, o servidor amplia a funcionalidade, permitindo gerenciar dispositivos estando fora de casa e sem estar preso à configuração de encaminhamentos de portas ou a um IP dedicado.
Assim, a opção descrita acima está desprovida das desvantagens da abordagem do servidor e possui várias vantagens, como a flexibilidade na conexão de novos dispositivos.
Sobre o termostato
Vamos considerar o sistema de gerenciamento com base em nosso termostato.
Previsto:
- Regulação da temperatura de cada termostato (exibida como um bloco separado);
- Configuração da programação de operação do termostato (manhã, dia, noite, madrugada);
- Seleção da rede Wi-Fi e conexão do dispositivo a ela;
- Atualização do dispositivo "over-the-air";
- Configuração do MQTT;
- Configuração da rede à qual o dispositivo está conectado.
Além do gerenciamento através da interface web, também é possível usar o clássico — toques na tela. A bordo está um monitor Nextion NX3224T024 de 2,4 polegadas. A escolha recaiu sobre ele devido à facilidade de uso do dispositivo. No entanto, estamos desenvolvendo nosso próprio monitor baseado em STM32. Sua funcionalidade não é inferior à do Nextion, mas terá um custo menor, o que impactará positivamente no preço final do dispositivo.
Como qualquer tela de termostato respeitável, nosso Nextion pode:
- definir a temperatura necessária para o usuário (com os botões à direita);
- ligar e desligar o modo de operação programado (botão N);
- exibir o funcionamento do relé (seta à esquerda);
- possuir proteção contra crianças (as Pressões físicas são bloqueadas enquanto o cadeado não for liberado);
- exibir o nível do sinal WiFi.
Além disso, através do monitor é possível:
- selecionar o tipo de sensor que o usuário possui;
- gerenciar a função de proteção contra crianças;
- atualizar o firmware.
Ao clicar na barra WiFi, o usuário obtém informações sobre a rede conectada. O código QR é utilizado para emparelhar o dispositivo com a versão firmware do HomeKit.
Demonstração de operação com o display:
Desenvolvemos com três termostatos conectados.
Você pode perguntar: “Qual é a particularidade do seu termostato?” Atualmente, existem muitos termostatos no mercado com função Wi-Fi, operação programada e controle sensível ao toque. E entusiastas desenvolveram módulos para interagir com a maioria dos sistemas populares de casa inteligente (Majordomo, HomeAssistant etc.).
Nosso termostato é compatível com esses sistemas e possui todas as funções mencionadas. Mas a característica distintiva é que o termostato está sempre sendo aprimorado, graças à flexibilidade do sistema. A cada atualização, a funcionalidade será expandida. Ao método padrão de controle do sistema (programação), adicionaremos um adaptativo. O aplicativo permite obter a geolocalização do usuário. Graças a isso, o sistema mudará dinamicamente os modos de operação de acordo com sua localização. E o módulo de clima permitirá se adaptar às condições meteorológicas.
E escalabilidade. Qualquer um poderá substituir o termostato padrão instalado por nosso modelo. Com um mínimo de esforço. Selecionamos os 5 sensores mais populares disponíveis no mercado e adicionamos suporte para eles. Mas mesmo nos casos de características exclusivas de um sensor, o usuário poderá conectá-lo ao nosso termostato. Para isso, será necessário calibrar o termostato para trabalhar com o sensor específico. Forneceremos as instruções.
Ao conectar o termostato ou qualquer outro dispositivo, ele aparece simultaneamente em todos os lugares: tanto na interface web quanto no aplicativo PWA. A adição do dispositivo ocorre automaticamente: basta conectá-lo à rede Wi-Fi.
Nosso sistema não depende de um servidor, e em caso de falha, não se torna obsoleto. Mesmo com a falha de um dos componentes, o sistema não começa a operar em modo de emergência. Controladores, sensores, dispositivos — cada elemento é tanto servidor quanto cliente, portanto totalmente autônomo.
Para aqueles interessados — nossas redes sociais: , , , , .
E-mail: shop@lytko.com
P. S. não estamos sugerindo abrir mão do servidor. Também oferecemos suporte a servidores MQTT e temos nossa própria nuvem. Nosso objetivo é elevar a estabilidade e confiabilidade do sistema a um novo patamar. Para que o servidor não seja um ponto fraco, mas complemente a funcionalidade e torne o sistema mais conveniente.
Fonte: habr.com
