Algum tempo atrás, apresentamos um
termostato inteligente . Este artigo foi originalmente concebido como uma demonstração do seu firmware e sistema de controle. Mas, para explicar a lógica do termostato e o que implementamos, é necessário delinear todo o conceito.
Sobre automação
Convencionalmente, toda a automação pode ser dividida em três categorias:
Categoria 1 - dispositivos "inteligentes" separados. Você recebe lâmpadas, bules, etc. de diferentes fabricantes. Vantagens: cada dispositivo expande oportunidades e aumenta o conforto. Contras: cada novo fabricante precisa de sua própria aplicação. Protocolos de dispositivos de diferentes fabricantes geralmente 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 no poder de computação e o MajorDoMo ou qualquer outra distribuição de servidor para gerenciar uma casa inteligente é instalada nesta máquina. Assim, os dispositivos da maioria dos fabricantes estão conectados em um único espaço de informação. I.e. aparece seu servidor para casa inteligente. Prós: compatibilidade em um único centro, que oferece recursos avançados de gerenciamento. Contras: em caso de falha / falha do servidor, todo o sistema retorna ao estágio 1, ou seja, torna-se fragmentado ou inutilizado.
Categoria 3 é a versão mais hardcore. Na fase de reparo, todas as comunicações são estabelecidas e todos os sistemas são duplicados. Prós: tudo é levado ao ideal e a casa se torna realmente inteligente. Contras: custo extremo em comparação com as categorias 1 e 2, a necessidade de pensar à frente de tudo e levar em conta tudo.
A maioria dos usuários seleciona a opção um e depois muda para a opção dois. E no futuro, a opção de alcance mais persistente 3.
Mas existe uma opção que pode ser chamada de sistema distribuído: cada dispositivo individual será um servidor e um cliente. De fato, esta é uma tentativa de combinar e combinar a opção 1 e a opção 2. Pegue todas as vantagens e elimine os desvantagens, pegue o meio termo.
Talvez alguém diga que essa opção já foi desenvolvida. Mas essas decisões são restritas; para pessoas mais experientes em programação. Nosso objetivo é diminuir o limite 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 do termostato, o usuário simplesmente remove seu termostato antigo, instala um inteligente e conecta seus sensores a ele. Sem nenhuma ação adicional.
Vamos considerar a integração em nosso sistema usando um exemplo.
Imagine que temos 8 módulos Sonoff em nossa rede. Alguns usuários podem ter controle suficiente sobre a nuvem Sonoff (categoria 1). Alguns usarão firmware de terceiros e passarão suavemente para a categoria 2. A maior parte do firmware de terceiros funciona com o mesmo princípio: transferência de dados para o servidor MQTT. O OpenHub, Majordomo ou qualquer outro serve ao mesmo objetivo - combinar dispositivos diferentes em um único espaço de informações localizado na Internet ou em uma rede local. Portanto, a presença do servidor é obrigatória. A partir daqui, o principal problema surge - quando o servidor falha, todo o sistema deixa de funcionar de forma autônoma. Para evitar isso, os sistemas se tornam mais complicados, são adicionados métodos de controle manual que duplicam a automação no caso de uma falha do servidor.
Seguimos um caminho diferente, onde cada dispositivo é auto-suficiente. Portanto, o servidor não desempenha um papel decisivo, mas apenas expande a funcionalidade.
De volta ao experimento mental. Novamente, pegue os mesmos 8 módulos Sonoff e instale o firmware Lytko neles. Em todo o firmware Lytko, a função
SSDP é implementada. O SSDP é um protocolo de rede baseado em um conjunto de protocolos da Internet usados para anunciar e descobrir serviços de rede. A resposta à solicitação pode ser padrão ou avançada. 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 encontram e cada um deles terá essa lista. Exemplo de folha SSDP:
"ssdpList": { "id": 94967291, "ip": "192.168.xx", "type": "thermostat" }, { "id": 94967282, "ip": "192.168.xx", "type": "thermostat" }
Como você pode ver no exemplo, a lista inclui identificação do dispositivo, endereço IP da rede, tipo de bloco (no nosso caso, um termostato baseado em Sonoff). Essa lista é atualizada a cada dois minutos (esse intervalo é suficiente para responder a uma alteração dinâmica no número de dispositivos na rede). Assim, rastreamos a adição, modificação e desconexão de dispositivos sem nenhuma ação do usuário. Essa lista é enviada para um navegador ou aplicativo móvel, e o próprio script forma uma página com um determinado número de blocos. Cada bloco corresponde a um dispositivo / sensor / controlador. Visualmente, a lista fica assim:
Mas 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 que você se integre aos mais populares.
Abaixo estão os projetos que, de alguma forma, estão tentando mudar a situação com a incompatibilidade de diferentes fabricantes entre si. Por exemplo,
SLS Gateway ,
MySensors ou
ZESP32 .
O ZigBee2MQTT está vinculado a um servidor MQTT, portanto, não é adequado, por exemplo.
Uma opção de implementação para o MySensors é um gateway baseado no ESP8266. Outros exemplos estão no ESP32. E neles você pode implementar nosso princípio 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 de protocolos SSDP às funções padrão desses gateways. Ao acessar este controlador via SSDP, ele adicionará à resposta padrão uma lista de dispositivos conectados a ele. Com base nessas informações, o navegador formará uma página. Em termos gerais, ficará assim:
Interface da web
Aplicação PWA "ssdpList": { "id": 94967291, // "ip": "192.168.xx", // ip "type": "thermostat" // }, { "id": 94967292, "ip": "192.168.xx", "type": "thermostat" }, { "id": 94967293, "ip": "192.168.xx", "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 um do outro. 3 termostatos com seus próprios endereços IP e 5 sensores diferentes com identificação única estão conectados. Se o sensor estiver conectado a uma rede Wi-Fi, ele terá seu próprio ip; se estiver conectado ao gateway, o endereço IP do dispositivo será o endereço IP do gateway.
Para se comunicar com os dispositivos, usamos o WebSocket. Isso permite minimizar o custo dos recursos em comparação com as solicitações de recebimento e receber informações dinamicamente ao conectar ou alterar.
Os dados são coletados diretamente do dispositivo ao qual a unidade pertence, ignorando o servidor. Portanto, se algum dos dispositivos falhar, o sistema continuará funcionando. A interface da web não exibe apenas o dispositivo que está faltando na lista. Mas o sinal da perda, se necessário, virá na forma de 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. Mas, devido às peculiaridades da estrutura, essa opção é inferior. E existe apenas uma 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, você pode transferir tudo para o controle externo. Portanto, quando o usuário sai da rede local, o aplicativo muda automaticamente para a nuvem.
Gerenciamento externo - duplicação total da página. Quando a página é ativada, o usuário pode efetuar login no servidor e gerenciar dispositivos por meio de uma conta pessoal. Assim, o servidor expande a funcionalidade, permitindo gerenciar dispositivos enquanto estiver fora de casa e não estar vinculado ao encaminhamento de porta ou a um ip dedicado.
Assim, a opção acima é desprovida das desvantagens da abordagem do servidor e também possui várias vantagens na forma da flexibilidade de conectar novos dispositivos.
Sobre o termostato
Considere um sistema de controle usando nosso termostato como exemplo.
Fornecido por:
- Controle de temperatura de cada termostato (exibido como uma unidade separada);
- Definir a programação do termostato (manhã, dia, tarde, noite);
- Escolhendo uma rede Wi-Fi e conectando um dispositivo a ela;
- Atualização do dispositivo "over the air";
- Configure o MQTT;
- Configure a rede à qual o dispositivo está conectado.
Além de gerenciar via interface da Web, eles forneceram a clássica - tocando no visor. A bordo está o monitor Nextion NX3224T024 de 2,4 polegadas. A escolha recaiu sobre ele devido à simplicidade de trabalhar com o dispositivo. Mas no desenvolvimento está o seu próprio monitor baseado no STM32. Sua funcionalidade não é pior que a do Nextion, mas custará menos, o que afetará positivamente o preço final do dispositivo.
Como qualquer tela de termostato que se preze, nossa Nextion pode:
- defina a temperatura necessária para o usuário (usando os botões à direita);
- ligar e desligar o modo de operação programado (botão H);
- operação do relé do display (seta à esquerda);
- tem proteção contra filhos (cliques físicos são bloqueados até que a trava seja removida);
- exibe a força do sinal WiFi.
Além disso, usando o monitor, você pode:
- selecione o tipo de sensor instalado pelo usuário;
- gerenciar a função de proteção à criança;
- atualizar firmware.
Ao clicar na barra de WiFi, o usuário descobrirá informações sobre a rede conectada. O código QR é usado para emparelhar o dispositivo no firmware HomeKit.
Demonstração do trabalho com a tela:
Desenvolvemos uma
página de demonstração com três termostatos conectados.
Você pergunta: “Qual é a peculiaridade do seu termostato?” Agora existem muitos termostatos no mercado com função Wi-Fi, trabalho programado, controle por toque. E os entusiastas criaram módulos para interagir com os sistemas domésticos inteligentes mais populares (Majordomo, HomeAssistant etc.).
Nosso termostato é compatível com esses sistemas e possui todas as opções acima. Mas a característica distintiva é que o termostato está sendo aprimorado constantemente, graças à flexibilidade do sistema. A cada atualização, a funcionalidade será expandida. À maneira padrão de gerenciar o sistema (de acordo com o cronograma), adicionaremos um adaptável. O aplicativo permite que você obtenha a geolocalização do usuário. Devido a isso, o sistema alterará dinamicamente os modos de operação, dependendo da sua localização. E o módulo climático permitirá que você ajuste as condições meteorológicas.
E extensibilidade. Qualquer um pode substituir o termostato habitual instalado com ele pelo nosso. Com esforço mínimo. Selecionamos os 5 sensores mais populares do mercado e adicionamos seu suporte. Mas mesmo no caso de características exclusivas do sensor, o usuário poderá conectá-lo ao nosso termostato. Para fazer isso, você precisa calibrar o termostato para trabalhar com um sensor específico. Forneceremos instruções.
Ao conectar um termostato ou qualquer outro dispositivo, ele aparece simultaneamente em todos os lugares: na interface da Web e no aplicativo PWA. A adição de um dispositivo é automática: basta conectá-lo a uma rede Wi-Fi.
Nosso sistema não precisa de um servidor e, em caso de falha, não se transforma em abóbora. Mesmo se um dos componentes falhar, o sistema não inicia de acordo com o cenário de emergência. Controladores, sensores, dispositivos - cada elemento é um servidor e um cliente, portanto, é completamente autônomo.
Para os interessados, nossas redes sociais:
Telegrama ,
Instagram ,
Telegram News ,
VK ,
Facebook .
E-mail: shop@lytko.com
PS , não pedimos para abandonar o servidor. Também temos suporte para o servidor MQTT e temos nossa própria nuvem. Nosso objetivo é levar a estabilidade e a confiabilidade do sistema a um nível totalmente novo. Portanto, o servidor não é um ponto fraco, mas complementa a funcionalidade e torna o sistema mais conveniente.