Há algum tempo nós apresentamos você . Este artigo foi originalmente concebido como uma demonstração de seu firmware e sistema de controle. Mas para explicar a lógica do termostato e o que implementamos, é necessário delinear todo o conceito como um todo.
Sobre automação
Convencionalmente, toda automação pode ser dividida em três categorias:
Categoria 1 — dispositivos “inteligentes” separados. Você compra lâmpadas, bules, etc. de diferentes fabricantes. Prós: Cada dispositivo expande as capacidades e aumenta o conforto. Contras: Cada novo fabricante requer sua própria aplicação. Os protocolos de dispositivos de diferentes fabricantes muitas vezes 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 restrições ao poder de computação, e o MajorDoMo ou qualquer outra distribuição de servidor para gerenciar uma casa inteligente é instalado nesta máquina. Assim, os dispositivos da maioria dos fabricantes estão conectados em um único espaço de informações. Aqueles. seu próprio servidor para uma casa inteligente aparece. Prós: compatibilidade em um único centro, que oferece recursos aprimorados de gerenciamento. Contras: se o servidor falhar, todo o sistema retorna ao estágio 1, ou seja, torna-se fragmentado ou torna-se inútil.
Categoria 3 - a opção mais hardcore. Na fase de reparação, todas as comunicações são estabelecidas e todos os sistemas são duplicados. Prós: tudo fica perfeito e então a casa fica realmente inteligente. Desvantagens: extremamente caro em relação às categorias 1 e 2, necessidade de pensar tudo com antecedência e levar em consideração cada pequeno detalhe.
A maioria dos usuários escolhe a opção um e depois passa suavemente para a opção dois. E aí os mais persistentes chegam à opção 3.
Mas existe uma opção que pode ser chamada de sistema distribuído: cada dispositivo individual será um servidor e um cliente. Essencialmente, esta é uma tentativa de combinar a opção 1 e a opção 2. Pegue todos os seus prós e elimine os contras, para alcançar o meio-termo.
Talvez alguém diga que tal opção já foi desenvolvida. Mas tais decisões têm um foco restrito; para pessoas experientes em programação. Nosso objetivo é diminuir a barreira de entrada em tais sistemas distribuídos, tanto na forma de dispositivos finais quanto na forma de integração de dispositivos existentes em nosso sistema. No caso de um termostato, o usuário simplesmente remove seu termostato antigo, instala um inteligente e conecta a ele os sensores existentes. Sem quaisquer etapas adicionais.
Vejamos a integração em nosso sistema usando um exemplo.
Vamos imaginar que temos 8 módulos Sonoff em nossa rede. Para alguns usuários, o controle via nuvem Sonoff (categoria 1) será suficiente. Alguns começarão a usar firmware de terceiros e passarão suavemente para a categoria 2. A maior parte do firmware de terceiros funciona com o mesmo princípio: transferir dados para um servidor MQTT. OpenHub, Majordomo ou qualquer outro têm um propósito - unir dispositivos díspares em um único espaço de informação localizado na Internet ou em uma rede local. Portanto, a presença de um Servidor é obrigatória. É aqui que surge o principal problema - se o Servidor falhar, todo o sistema deixa de funcionar de forma autónoma. Para evitar isso, os sistemas tornam-se mais complexos, são adicionados métodos de controle manual que duplicam a automação em caso de falha do servidor.
Seguimos um caminho diferente, onde cada dispositivo é autossuficiente. Assim, o Servidor não desempenha um papel decisivo, apenas amplia a funcionalidade.
Voltemos ao experimento mental. Vamos pegar os mesmos 8 módulos Sonoff novamente e instalar o firmware Lytko neles. Todos os firmwares Lytko têm a função . SSDP é um protocolo de rede baseado no conjunto de protocolos da Internet para publicidade e descoberta de serviços de rede. A resposta a uma solicitação pode ser padrão ou estendida. Além das funções padrão, incluímos nesta resposta a criação de uma lista de dispositivos na rede. Assim, os próprios dispositivos se encontrarão e cada um deles terá essa lista. Exemplo de planilha SSDP:
"ssdpList":
{
"id": 94967291,
"ip": "192.168.x.x",
"type": "thermostat"
},
{
"id": 94967282,
"ip": "192.168.x.x",
"type": "thermostat"
}Como você pode ver no exemplo, a lista inclui IDs de dispositivos, endereço IP na rede, tipo de unidade (no nosso caso, um termostato baseado em Sonoff). Esta lista é atualizada uma vez a cada dois minutos (esse período é suficiente para responder às mudanças dinâmicas no número de dispositivos na rede). Dessa forma, rastreamos dispositivos adicionados, alterados e desativados sem qualquer ação do usuário. Essa lista é enviada para o navegador ou aplicativo mobile, e o próprio script gera uma página com um determinado número de blocos. Cada bloco corresponde a um dispositivo/sensor/controlador. Visualmente a lista fica assim:
Mas e se outros sensores de rádio estiverem conectados ao esp8266/esp32 via cc2530 (ZigBee) ou nrf24 (MySensors)?
Sobre projetos
Existem vários 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 de diferentes fabricantes entre si. Isto é, por exemplo, , ou . está vinculado a um servidor MQTT, portanto não é adequado para o exemplo.
Uma opção para implementação de MySensors é um gateway baseado no ESP8266. O resto dos exemplos estão no ESP32. E neles você pode implementar nosso princípio de funcionamento de detecção e criação de uma lista de dispositivos.
Vamos fazer outro experimento mental. Temos um gateway ZESP32 ou SLS Gateway ou MySensors. Como eles podem ser combinados em um único espaço de informação? Adicionaremos a biblioteca do protocolo SSDP às funções padrão desses gateways. Ao acessar este controlador via SSDP, ele adicionará à resposta padrão uma lista de dispositivos que estão conectados a ele. Com base nessas informações, o navegador irá gerar uma página. Em geral ficará assim:
interface web
Aplicativo PWA
"ssdpList":
{
"id": 94967291, // уникальный идентификатор устройства
"ip": "192.168.x.x", // ip адрес в сети
"type": "thermostat" // тип устройства
},
{
"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"
}
O exemplo mostra que os dispositivos são adicionados independentemente uns dos outros. Estão conectados 3 termostatos com seus próprios endereços IP e 5 sensores diferentes com IDs exclusivos. Se o sensor estiver conectado a uma rede Wi-Fi, ele terá seu próprio IP; se estiver conectado a um gateway, o endereço IP do dispositivo será o endereço IP do gateway.
Usamos WebSocket para nos comunicarmos com dispositivos. Isso permite minimizar os custos de recursos em comparação com a obtenção de solicitações e obter informações dinamicamente ao conectar ou alterar.
Os dados são retirados diretamente do dispositivo ao qual pertence o bloco, contornando o servidor. Assim, caso algum dos dispositivos falhe, o sistema continua funcionando. A interface da web simplesmente não exibe o dispositivo ausente na lista. Mas um sinal sobre a perda, se necessário, virá em forma de notificação no aplicativo do usuário.
A primeira tentativa de implementar esta abordagem foi uma aplicação PWA. Isso permite armazenar uma base de blocos no dispositivo do usuário e solicitar apenas os dados necessários. Mas devido às peculiaridades da estrutura, esta opção está incompleta. E só há uma saída - um aplicativo nativo para Android e IOS, que está atualmente em desenvolvimento ativo. Por padrão, o aplicativo só funcionará na rede interna. Se necessário, você pode transferir tudo para controle externo. Assim, quando o usuário sai da rede local, o aplicativo muda automaticamente para a nuvem.
Controle externo - duplicação completa da página. Quando a página é ativada, o usuário pode fazer login no servidor e gerenciar dispositivos através de sua conta pessoal. Assim, o Servidor amplia sua funcionalidade, permitindo gerenciar dispositivos fora de casa, e não ficar preso ao encaminhamento de porta ou a um IP dedicado.
Assim, a opção acima não apresenta as desvantagens da abordagem de servidor e também apresenta uma série de vantagens na forma de flexibilidade na conexão de novos dispositivos.
Sobre o termostato
Vejamos o sistema de controle usando nosso termostato como exemplo.
Oferecido:
- Controle de temperatura para cada termostato (exibido como um bloco separado);
- Configuração do horário de funcionamento do termostato (manhã, tarde, noite, noite);
- Selecionando uma rede Wi-Fi e conectando um dispositivo a ela;
- Atualização do dispositivo “over the air”;
- Configurando MQTT;
- Configure a rede à qual o dispositivo está conectado.
Além do controle pela interface web, disponibilizamos o clássico - clicando no display. Há um monitor Nextion NX3224T024 de 2.4 polegadas a bordo. A escolha recaiu sobre ele pela facilidade de trabalhar com o aparelho. Mas estamos desenvolvendo nosso próprio monitor baseado no STM32. Sua funcionalidade não é pior que a do Nextion, mas custará menos, o que terá um impacto positivo no preço final do aparelho.
Como qualquer tela de termostato que se preze, nosso Nextion pode:
- definir a temperatura desejada pelo usuário (através dos botões à direita);
- ligar e desligar o modo de operação programada (botão H);
- exibir operação do relé (seta à esquerda);
- possui proteção infantil (cliques físicos são bloqueados até que a trava seja removida);
- exibe a intensidade do sinal WiFi.
Além disso, usando o monitor você pode:
- selecione o tipo de sensor instalado pelo usuário;
- gerenciar o recurso de bloqueio para crianças;
- atualize o firmware.
Ao clicar na barra WiFi, o usuário encontrará informações sobre a rede conectada. O código QR é usado para emparelhar o dispositivo no firmware do HomeKit.
Demonstração de como trabalhar com o display:
Nós desenvolvemos com três termostatos conectados.
Você pode perguntar: “O que há de especial no seu termostato?” Já no mercado existem muitos termostatos com função Wi-Fi, operação programada e controle por toque. E os entusiastas escreveram módulos para interagir com os sistemas domésticos inteligentes mais populares (Majordomo, HomeAssistant, etc.).
Nosso termostato é compatível com esses sistemas e possui todos os itens acima. Mas o diferencial é que o termostato está em constante aprimoramento, graças à flexibilidade do sistema. A cada atualização a funcionalidade será expandida. Ao método padrão de gerenciamento do sistema (de acordo com um cronograma), 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 dependendo de sua localização. E o módulo meteorológico permitirá que você se adapte às condições climáticas.
E expansibilidade. Qualquer pessoa pode substituir o seu termostato convencional existente pelo nosso. Com o mínimo esforço. Selecionamos 5 dos sensores mais populares do mercado e adicionamos suporte para eles. Mas mesmo que o sensor tenha características exclusivas, o usuário poderá conectá-lo ao nosso termostato. Para fazer isso, você precisará calibrar o termostato para funcionar com um sensor específico. Forneceremos instruções.
Ao conectar um termostato ou qualquer outro dispositivo, ele aparece simultaneamente em todos os lugares: tanto na interface web quanto no aplicativo PWA. A adição de um dispositivo ocorre automaticamente: basta conectá-lo à rede Wi-Fi.
Nosso sistema não precisa de Servidor e, se falhar, não vira abóbora. Mesmo que um dos componentes falhe, o sistema não entra em operação em caso de emergência. Controladores, sensores, dispositivos - cada elemento é ao mesmo tempo um servidor e um cliente, portanto completamente autônomo.
Para os interessados, nossas redes sociais: , , , , .
E-mail: [email protegido]
PS Não encorajamos você a abandonar o Servidor. Também oferecemos suporte a um servidor MQTT e temos nossa própria nuvem. Nosso objetivo é levar a estabilidade e a confiabilidade do sistema a um nível totalmente novo. Para que o Servidor não seja um ponto fraco, mas complemente a funcionalidade e torne o sistema mais prático.
Fonte: habr.com