{"id":55356,"date":"2020-01-18T00:00:00","date_gmt":"2020-01-17T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/lytko-obedinyaet"},"modified":"2020-02-18T14:03:28","modified_gmt":"2020-02-18T11:03:28","slug":"lytko-obedinyaet","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/news\/lytko-obedinyaet","title":{"rendered":"Lytko integra","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

H\u00e1 algum tempo, apresentamos a voc\u00ea um termostato inteligente<\/a><\/noindex>. O artigo atual foi inicialmente pensado como uma demonstra\u00e7\u00e3o de seu firmware e sistema de controle. Mas, para explicar a l\u00f3gica de funcionamento do termostato e o que implementamos, \u00e9 necess\u00e1rio delinear todo o conceito como um todo.<\/p>\n

\"Lytko
\n<\/a><\/noindex><\/p>\n

Sobre automa\u00e7\u00e3o<\/h3>\n

\nCondi\u00e7\u00f5es, toda a automa\u00e7\u00e3o pode ser dividida em tr\u00eas categorias:
\nCategoria 1<\/u> \u2014 dispositivos \u201cinteligentes\u201d individuais. Voc\u00ea adquire l\u00e2mpadas, chaleiras etc., de diferentes fabricantes. Vantagens: cada dispositivo expande as possibilidades e aumenta o conforto. Desvantagens: para cada novo fabricante, \u00e9 necess\u00e1rio um aplicativo pr\u00f3prio. Os protocolos de dispositivos de diferentes fabricantes frequentemente n\u00e3o s\u00e3o compat\u00edveis entre si.<\/p>\n

Categoria 2<\/u> \u2014 instala\u00e7\u00e3o de um PC de placa \u00fanica ou compat\u00edvel com x86. Isso remove as limita\u00e7\u00f5es de poder de computa\u00e7\u00e3o, e neste equipamento \u00e9 instalado o MajorDoMo ou qualquer outra distribui\u00e7\u00e3o de servidor para gerenciar a casa inteligente. Dessa forma, os dispositivos da maioria dos fabricantes se conectam em um espa\u00e7o informacional \u00fanico. Ou seja, um servidor para a casa inteligente \u00e9 criado. Vantagens: compatibilidade sob um centro \u00fanico, o que oferece amplas possibilidades de controle. Desvantagens: em caso de falha do servidor, todo o sistema retorna \u00e0 fase 1, ou seja, torna-se fragmentado ou in\u00fatil.<\/p>\n

Categoria 3<\/u> \u2014 a op\u00e7\u00e3o mais hardcore. Na fase de reparo, todas as comunica\u00e7\u00f5es s\u00e3o instaladas e todos os sistemas s\u00e3o duplicados. Vantagens: tudo \u00e9 levado ao ideal e, assim, a casa se torna realmente inteligente. Desvantagens: extremo custo comparado \u00e0s categorias 1 e 2, necessidade de planejamento antecipado de tudo e considera\u00e7\u00e3o de cada detalhe.<\/p>\n

A maioria dos usu\u00e1rios escolhem a op\u00e7\u00e3o um e, em seguida, transita gradualmente para a op\u00e7\u00e3o dois. E, posteriormente, os mais determinados alcan\u00e7am a op\u00e7\u00e3o 3. <\/p>\n

Mas existe uma op\u00e7\u00e3o que pode ser chamada de sistema distribu\u00eddo: cada dispositivo separado ser\u00e1 tanto servidor quanto cliente. Essencialmente, \u00e9 uma tentativa de unir a op\u00e7\u00e3o 1 e a op\u00e7\u00e3o 2. Reunir todas as suas vantagens e eliminar desvantagens, encontrando um meio-termo. <\/p>\n

\u00c9 poss\u00edvel que algu\u00e9m diga que essa op\u00e7\u00e3o j\u00e1 foi desenvolvida. Mas essas solu\u00e7\u00f5es s\u00e3o espec\u00edficas; destinadas a pessoas com conhecimento em programa\u00e7\u00e3o. Nosso objetivo \u00e9 reduzir a barreira de entrada em sistemas distribu\u00eddos, tanto na forma de dispositivos finais quanto na integra\u00e7\u00e3o de dispositivos existentes em nosso sistema. No caso do termostato, o usu\u00e1rio simplesmente desinstala seu termostato antigo, instala um inteligente e conecta os sensores que j\u00e1 possui a ele. Sem nenhuma a\u00e7\u00e3o adicional.<\/p>\n

Vamos considerar a integra\u00e7\u00e3o em nosso sistema como exemplo. <\/p>\n

Suponha que temos 8 m\u00f3dulos Sonoff na rede. Alguns usu\u00e1rios precisar\u00e3o apenas do controle via nuvem Sonoff (categoria 1). Outros come\u00e7ar\u00e3o a usar firmware de terceiros e migrar\u00e3o gradualmente para a categoria 2. A maioria dos firmwares de terceiros opera pelo mesmo princ\u00edpio: transmiss\u00e3o de dados para um servidor MQTT. OpenHub, Majordomo ou qualquer outro serve a um \u00fanico prop\u00f3sito \u2013 unir dispositivos dispersos em um \u00fanico espa\u00e7o informativo, localizado na Internet ou em uma rede local. Portanto, a presen\u00e7a de um Servidor \u00e9 obrigat\u00f3ria. Aqui surge o principal problema \u2013 se o Servidor falhar, todo o sistema deixa de funcionar de forma aut\u00f4noma. Para evitar isso, os sistemas se tornam mais complexos, adicionando maneiras manuais de controle, que duplicam a automa\u00e7\u00e3o em caso de falha do Servidor. <\/p>\n

N\u00f3s, por outro lado, seguimos um caminho diferente, onde cada dispositivo \u00e9 autossuficiente. Assim, o Servidor n\u00e3o desempenha um papel decisivo, apenas amplia a funcionalidade.<\/p>\n

Vamos voltar ao experimento mental. Novamente pegamos os mesmos 8 m\u00f3dulos Sonoff e instalamos neles o firmware Lytko. Todas as implementa\u00e7\u00f5es do firmware Lytko t\u00eam a fun\u00e7\u00e3o SSDP<\/a><\/noindex>. SSDP \u00e9 um protocolo de rede, baseado em um conjunto de protocolos da Internet, usado para anunciar e descobrir servi\u00e7os de rede. A resposta a uma solicita\u00e7\u00e3o pode ser tanto padr\u00e3o quanto estendida. Incorporamos a esse retorno, al\u00e9m das fun\u00e7\u00f5es padr\u00e3o, a cria\u00e7\u00e3o de uma lista de dispositivos na rede. Assim, os dispositivos se encontram e cada um deles ter\u00e1 essa lista. Exemplo de lista SSDP:<\/p>\n

\"ssdpList\": \n\t{\n\t\t\"id\": 94967291,  \n\t\t\"ip\": \"192.168.x.x\",\n                \"type\": \"term\u00f4metro\"\n\t}, \n\t{\n\t\t\"id\": 94967282,\n\t\t\"ip\": \"192.168.x.x\",\n                \"type\": \"term\u00f4metro\"\n\t}<\/code><\/pre>\n
\nComo mostrado no exemplo, a lista inclui os IDs dos dispositivos, o endere\u00e7o IP na rede, o tipo de bloco (neste caso, um termostato baseado em Sonoff). Esta lista \u00e9 atualizada a cada dois minutos (esse intervalo \u00e9 suficiente para responder \u00e0s mudan\u00e7as din\u00e2micas no n\u00famero de dispositivos na rede). Assim, monitoramos a adi\u00e7\u00e3o, altera\u00e7\u00e3o e desconex\u00e3o de dispositivos sem qualquer a\u00e7\u00e3o do usu\u00e1rio. Esta lista \u00e9 enviada para o navegador ou aplicativo m\u00f3vel, e o script gera automaticamente a p\u00e1gina com a quantidade especificada de blocos. Cada bloco corresponde a um dispositivo\/sensor\/controlador. Visualmente, a lista \u00e9 assim:<\/p>\n
\"Lytko
\n
\nMas e se outros sensores de r\u00e1dio estiverem conectados ao esp8266\/esp32 atrav\u00e9s do cc2530 (ZigBee) ou nrf24 (MySensors)? <\/p>\n
Sobre projetos<\/h3>\n
\nExistem diversos sistemas distribu\u00eddos no mercado. Nosso sistema permite integra\u00e7\u00e3o com os mais populares. <\/p>\n
Abaixo est\u00e3o projetos que, de uma forma ou de outra, tentam mudar a situa\u00e7\u00e3o de incompatibilidade entre diferentes fabricantes. Por exemplo, SLS Gateway<\/a><\/noindex>, MySensors <\/a><\/noindex> ou ZESP32<\/a><\/noindex>. ZigBee2MQTT <\/a><\/noindex> ligado a um servidor MQTT, portanto n\u00e3o \u00e9 adequado para este exemplo. <\/p>\n
Uma das op\u00e7\u00f5es para implementar MySensors \u00e9 um gateway baseado em ESP8266. Os outros exemplos s\u00e3o baseados em ESP32. Neles, podemos implementar nosso princ\u00edpio de opera\u00e7\u00e3o para detectar e criar uma lista de dispositivos. <\/p>\n
Vamos fazer mais um experimento mental. Temos o gateway ZESP32 ou SLS Gateway ou MySensors. Como podemos integr\u00e1-los em um \u00fanico espa\u00e7o de informa\u00e7\u00e3o? \u00c0s fun\u00e7\u00f5es padr\u00e3o desses gateways, adicionaremos a biblioteca do protocolo SSDP. Ao consultar este controlador via SSDP, ele adicionar\u00e1 \u00e0 resposta padr\u00e3o uma lista de dispositivos conectados a ele. Com base nessa informa\u00e7\u00e3o, o navegador gerar\u00e1 a p\u00e1gina. Em termos gerais, isso parecer\u00e1 assim:<\/p>\n
\"Lytko
\nInterface web<\/i><\/p>\n
\"Lytko
\nAplicativo PWA<\/i><\/p>\n
\"ssdpList\": \n{\n   \"id\": 94967291, \/\/ identificador \u00fanico do dispositivo\n   \"ip\": \"192.168.x.x\", \/\/ endere\u00e7o ip na rede\n   \"type\": \"term\u00f4metro\" \/\/ tipo de dispositivo\n},\n{\n   \"id\": 94967292,\n   \"ip\": \"192.168.x.x\",\n   \"type\": \"term\u00f4metro\"\n},\n{\n   \"id\": 94967293,\n   \"ip\": \"192.168.x.x\",\n   \"type\": \"term\u00f4metro\"\n},\n{  \n   \"id\": 13587532, \n   \"type\": \"interruptor\"  \n},\n{  \n   \"id\": 98412557, \n   \"type\": \"detector de fuma\u00e7a\"\n},\n{  \n   \"id\": 57995113, \n   \"type\": \"sensor de contato\"\n},\n{  \n   \"id\": 74123668,\n   \"type\": \"sensor de temperatura, umidade e press\u00e3o\"\n},\n{\n    \"id\": 74621883, \n    \"type\": \"sensor de temperatura e umidade\"\n}\n<\/code><\/pre>\n
\nA partir do exemplo, podemos ver que os dispositivos s\u00e3o adicionados de forma independente uns dos outros. Tr\u00eas termostatos est\u00e3o conectados com seus pr\u00f3prios endere\u00e7os IP e cinco sensores diferentes com IDs \u00fanicos. Se o sensor estiver conectado \u00e0 rede Wi-Fi, ter\u00e1 seu pr\u00f3prio IP; se estiver conectado ao gateway, o endere\u00e7o IP do dispositivo ser\u00e1 o endere\u00e7o IP do gateway.<\/p>\n
Para a comunica\u00e7\u00e3o com os dispositivos, utilizamos WebSocket. Isso permite minimizar o consumo de recursos em compara\u00e7\u00e3o com solicita\u00e7\u00f5es GET e obter informa\u00e7\u00f5es dinamicamente durante a conex\u00e3o ou altera\u00e7\u00e3o. <\/p>\n
Os dados s\u00e3o 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\u00e3o ser\u00e1 exibido. Mas o sinal de sua aus\u00eancia, se necess\u00e1rio, chegar\u00e1 como uma notifica\u00e7\u00e3o no aplicativo do usu\u00e1rio. <\/p>\n
A primeira tentativa de implementar essa abordagem foi um aplicativo PWA. Isso permite armazenar a base de blocos no dispositivo do usu\u00e1rio e solicitar apenas os dados necess\u00e1rios. No entanto, devido \u00e0s particularidades da estrutura, essa op\u00e7\u00e3o \u00e9 incompleta. E a \u00fanica sa\u00edda \u00e9 um aplicativo nativo para Android e iOS, que est\u00e1 atualmente em desenvolvimento ativo. Por padr\u00e3o, o aplicativo funcionar\u00e1 apenas na rede interna. Se necess\u00e1rio, pode-se mudar tudo para controle externo. Assim, quando o usu\u00e1rio sai da rede local, o aplicativo comutar\u00e1 automaticamente para a nuvem. <\/p>\n
O controle externo \u00e9 uma duplica\u00e7\u00e3o completa da p\u00e1gina. Ao ativar a p\u00e1gina, o usu\u00e1rio pode se conectar ao servidor e gerenciar os dispositivos atrav\u00e9s do painel pessoal. Assim, o servidor amplia a funcionalidade, permitindo gerenciar dispositivos estando fora de casa e sem estar preso \u00e0 configura\u00e7\u00e3o de encaminhamentos de portas ou a um IP dedicado.<\/p>\n
Assim, a op\u00e7\u00e3o descrita acima est\u00e1 desprovida das desvantagens da abordagem do servidor e possui v\u00e1rias vantagens, como a flexibilidade na conex\u00e3o de novos dispositivos.<\/p>\n
Sobre o termostato<\/h3>\n
\nVamos considerar o sistema de gerenciamento com base em nosso termostato.<\/p>\n
Previsto:<\/p>\n
    \n
  1. Regula\u00e7\u00e3o da temperatura de cada termostato (exibida como um bloco separado);<\/li>\n
  2. Configura\u00e7\u00e3o da programa\u00e7\u00e3o de opera\u00e7\u00e3o do termostato (manh\u00e3, dia, noite, madrugada);<\/li>\n
  3. Sele\u00e7\u00e3o da rede Wi-Fi e conex\u00e3o do dispositivo a ela;<\/li>\n
  4. Atualiza\u00e7\u00e3o do dispositivo \"over-the-air\";<\/li>\n
  5. Configura\u00e7\u00e3o do MQTT;<\/li>\n
  6. Configura\u00e7\u00e3o da rede \u00e0 qual o dispositivo est\u00e1 conectado.<\/li>\n<\/ol>\n
    \n\"Lytko
    \n
    \nAl\u00e9m do gerenciamento atrav\u00e9s da interface web, tamb\u00e9m \u00e9 poss\u00edvel usar o cl\u00e1ssico \u2014 toques na tela. A bordo est\u00e1 um monitor Nextion NX3224T024 de 2,4 polegadas. A escolha recaiu sobre ele devido \u00e0 facilidade de uso do dispositivo. No entanto, estamos desenvolvendo nosso pr\u00f3prio monitor baseado em STM32. Sua funcionalidade n\u00e3o \u00e9 inferior \u00e0 do Nextion, mas ter\u00e1 um custo menor, o que impactar\u00e1 positivamente no pre\u00e7o final do dispositivo.<\/p>\n
    \"Lytko
    \n
    \nComo qualquer tela de termostato respeit\u00e1vel, nosso Nextion pode:<\/p>\n