Lytko une

Fai un tempo presentámosvos termostato intelixente. Este artigo foi orixinalmente pensado como unha demostración do seu firmware e sistema de control. Pero para explicar a lóxica do termostato e o que implementamos, é necesario esbozar todo o concepto no seu conxunto.

Sobre a automatización

Convencionalmente, toda a automatización pódese dividir en tres categorías:
Categoría 1 - Dispositivos "intelixentes" separados. Compras lámpadas, teteras, etc. de diferentes fabricantes. Pros: cada dispositivo amplía as capacidades e aumenta o confort. Contras: cada novo fabricante require a súa propia aplicación. Os protocolos de dispositivos de diferentes fabricantes adoitan non ser compatibles entre si.

Categoría 2 — instalación dun PC de placa única ou compatible con x86. Isto elimina as restricións á potencia de computación e nesta máquina está instalado MajorDoMo ou calquera outra distribución de servidor para xestionar unha casa intelixente. Así, os dispositivos da maioría dos fabricantes están conectados nun único espazo de información. Eses. aparece o teu propio servidor para unha casa intelixente. Pros: compatibilidade nun único centro, que proporciona capacidades de xestión melloradas. Contras: se o servidor falla, todo o sistema volve á fase 1, é dicir. tórnase fragmentado ou vólvese inútil.

Categoría 3 - a opción máis hardcore. Na fase de reparación, póñense todas as comunicacións e duplícanse todos os sistemas. Pros: todo é perfecto e entón a casa vólvese realmente intelixente. Desvantaxes: extremadamente caro en comparación coas categorías 1 e 2, a necesidade de pensar todo con antelación e ter en conta cada pequeno detalle.

A maioría dos usuarios elixen a opción un e despois pasan sen problemas á segunda. E entón os máis persistentes chegan á opción 3.

Pero hai unha opción que se pode chamar sistema distribuído: cada dispositivo individual será tanto un servidor como un cliente. Esencialmente, este é un intento de tomar e combinar a opción 1 e a opción 2. Tome todos os seus pros e elimine os contras, para atrapar a media dourada.

Quizais alguén dirá que xa se desenvolveu tal opción. Pero este tipo de decisións están moi centradas; para persoas expertas en programación. O noso obxectivo é reducir a barreira de entrada a estes sistemas distribuídos, tanto en forma de dispositivos finais como na forma de integración dos dispositivos existentes no noso sistema. No caso dun termostato, o usuario simplemente elimina o seu termostato antigo, instala un intelixente e conecta os seus sensores existentes a el. Sen pasos adicionais.

Vexamos a integración no noso sistema usando un exemplo.

Imaxinemos que temos 8 módulos Sonoff na nosa rede. Para algúns usuarios, o control a través da nube Sonoff (categoría 1) será suficiente. Algúns comezarán a usar firmware de terceiros e pasarán sen problemas á categoría 2. A maior parte do firmware de terceiros funciona co mesmo principio: transferir datos a un servidor MQTT. OpenHub, Majordomo ou calquera outro serven para un único propósito: unir dispositivos dispares nun único espazo de información situado en Internet ou nunha rede local. Polo tanto, a presenza dun Servidor é obrigatoria. Aquí é onde xorde o principal problema: se o servidor falla, todo o sistema deixa de funcionar de forma autónoma. Para evitalo, os sistemas vólvense máis complexos, engádense métodos de control manual que duplican a automatización en caso de fallo do servidor.

Tomamos un camiño diferente, onde cada dispositivo é autosuficiente. Así, o Servidor non xoga un papel decisivo, senón que só amplía a funcionalidade.

Volvamos ao experimento mental. Tomemos os mesmos 8 módulos Sonoff de novo e instalemos neles o firmware Lytko. Todos os firmwares de Lytko teñen a función SSDP. SSDP é un protocolo de rede baseado na suite de protocolos de Internet para a publicidade e o descubrimento de servizos de rede. A resposta a unha solicitude pode ser estándar ou ampliada. Ademais das funcións estándar, incluímos nesta resposta a creación dunha lista de dispositivos na rede. Así, os propios dispositivos atópanse entre si e cada un deles terá esa lista. Exemplo de folla SSDP:

"ssdpList": 
	{
		"id": 94967291,  
		"ip": "192.168.x.x",
                "type": "thermostat"
	}, 
	{
		"id": 94967282,
		"ip": "192.168.x.x",
                "type": "thermostat"
	}

Como se pode ver no exemplo, a lista inclúe ID do dispositivo, enderezo IP na rede e tipo de unidade (no noso caso, un termostato baseado en Sonoff). Esta lista actualízase unha vez cada dous minutos (este período é suficiente para responder aos cambios dinámicos no número de dispositivos na rede). Deste xeito, rastrexamos os dispositivos engadidos, cambiados e desactivados sen ningunha acción do usuario. Esta lista envíase ao navegador ou á aplicación móbil, e o propio script xera unha páxina cun número determinado de bloques. Cada bloque corresponde a un dispositivo/sensor/controlador. Visualmente a lista é así:

Pero que pasa se outros sensores de radio están conectados ao esp8266/esp32 a través de cc2530 (ZigBee) ou nrf24 (MySensors)?

Sobre proxectos

Existen varios sistemas distribuídos no mercado. O noso sistema permíteche integrar cos máis populares.

A continuación móstranse proxectos que, dun xeito ou doutro, intentan cambiar a situación coa incompatibilidade de diferentes fabricantes entre si. Este é, por exemplo, Pasarela SLS, Os meus sensores ou ZESP32. ZigBee2MQTT está ligado a un servidor MQTT, polo que non é axeitado para o exemplo.

Unha opción para implementar MySensors é unha pasarela baseada no ESP8266. O resto dos exemplos están en ESP32. E neles pode implementar o noso principio de funcionamento de detectar e crear unha lista de dispositivos.

Imos facer outro experimento mental. Temos unha pasarela ZESP32 ou SLS ou MySensors. Como se poden combinar nun único espazo de información? Engadiremos a biblioteca de protocolos SSDP ás funcións estándar destas pasarelas. Ao acceder a este controlador a través de SSDP, engadirá unha lista de dispositivos que están conectados a el á resposta estándar. En base a esta información, o navegador xerará unha páxina. En xeral, quedará así:

Interface web

Aplicación 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 engádense independentemente uns dos outros. Están conectados 3 termostatos cos seus propios enderezos IP e 5 sensores diferentes con ID únicos. Se o sensor está conectado a unha rede Wi-Fi, terá a súa propia IP; se está conectado a unha pasarela, entón o enderezo IP do dispositivo será o enderezo IP da pasarela.

Usamos WebSocket para comunicarnos con dispositivos. Isto permítelle minimizar os custos dos recursos en comparación con obter solicitudes e obter información de forma dinámica ao conectar ou cambiar.

Os datos tómanse directamente do dispositivo ao que pertence o bloque, evitando o servidor. Así, se algún dos dispositivos falla, o sistema segue funcionando. A interface web simplemente non mostra o dispositivo que falta na lista. Pero un sinal sobre a perda, se é necesario, chegará en forma de notificación na aplicación do usuario.

O primeiro intento de implementar este enfoque foi unha aplicación PWA. Isto permítelle almacenar unha base de bloques no dispositivo do usuario e solicitar só os datos necesarios. Pero debido ás peculiaridades da estrutura, esta opción é incompleta. E só hai unha saída: unha aplicación nativa para Android e iOS, que está actualmente en desenvolvemento activo. Por defecto, a aplicación só funcionará na rede interna. Se é necesario, pode transferir todo ao control externo. Así, cando o usuario abandona a rede local, a aplicación cambia automaticamente á nube.

Control externo: duplicación completa da páxina. Cando a páxina está activada, o usuario pode iniciar sesión no servidor e xestionar os dispositivos a través da súa conta persoal. Así, o servidor amplía a súa funcionalidade, o que lle permite xestionar dispositivos mentres está fóra da casa, e non estar ligado ao reenvío de portos ou a unha IP dedicada.

Así, a opción anterior non ten as desvantaxes do enfoque do servidor e tamén ten unha serie de vantaxes en forma de flexibilidade para conectar novos dispositivos.

Sobre o termostato

Vexamos o sistema de control usando o noso termostato como exemplo.

Fornecido:

1. Control de temperatura para cada termostato (mostrado como un bloque separado);
2. Establecer o horario de funcionamento do termostato (mañá, tarde, noite, noite);
3. Seleccionar unha rede Wi-Fi e conectar un dispositivo a ela;
4. Actualizando o dispositivo "polo aire";
5. Configurar MQTT;
6. Configure a rede á que está conectado o dispositivo.

Ademais do control a través da interface web, proporcionamos o clásico, facendo clic na pantalla. Hai un monitor Nextion NX3224T024 de 2.4 polgadas a bordo. A elección recaeu sobre el debido á facilidade de traballar co dispositivo. Pero estamos a desenvolver o noso propio monitor baseado en STM32. A súa funcionalidade non é peor que a de Nextion, pero custará menos, o que repercutirá positivamente no prezo final do dispositivo.

Como calquera pantalla de termostato que se precie, o noso Nextion pode:

• establecer a temperatura requirida polo usuario (utilizando os botóns da dereita);
• activar e desactivar o modo de operación programado (botón H);
• Mostrar o funcionamento do relé (frecha á esquerda);
• ten protección para nenos (os clics físicos están bloqueados ata que se retira o bloqueo);
• mostra a intensidade do sinal WiFi.

Ademais, usando o monitor podes:

• seleccionar o tipo de sensor instalado polo usuario;
• xestionar a función de bloqueo infantil;
• actualizar o firmware.

Ao facer clic na barra WiFi, o usuario atopará información sobre a rede conectada. O código QR úsase para emparellar o dispositivo no firmware HomeKit.

Demostración do traballo coa pantalla:

Temos desenvolvido páxina de demostración con tres termostatos conectados.

Podes preguntar: "Que ten de especial o teu termostato?" Agora no mercado hai moitos termostatos con función Wi-Fi, funcionamento programado e control táctil. E os entusiastas escribiron módulos para interactuar cos sistemas domésticos intelixentes máis populares (Majordomo, HomeAssistant, etc.).

O noso termostato é compatible con estes sistemas e ten todo o anterior. Pero a característica distintiva é que o termostato está en constante mellora, grazas á flexibilidade do sistema. Con cada actualización a funcionalidade ampliarase. Ao método estándar de xestión do sistema (segundo unha programación), engadirémoslle un adaptativo. A aplicación permite obter a xeolocalización do usuario. Grazas a isto, o sistema cambiará dinámicamente os modos de funcionamento dependendo da súa localización. E o módulo meteorolóxico permitirá adaptarse ás condicións meteorolóxicas.

E ampliabilidade. Calquera pode substituír o seu termostato convencional existente polo noso. Cun mínimo esforzo. Seleccionamos 5 dos sensores máis populares do mercado e engadimos soporte para eles. Pero aínda que o sensor teña características exclusivas, o usuario poderá conectalo ao noso termostato. Para iso, terás que calibrar o termostato para que funcione cun sensor específico. Proporcionaremos instrucións.

Ao conectar un termostato ou calquera outro dispositivo, aparece simultáneamente en todas partes: tanto na interface web como na aplicación PWA. Engadir un dispositivo prodúcese automaticamente: só tes que conectalo á rede Wi-Fi.

O noso sistema non necesita un Servidor, e se falla, non se transforma nunha cabaza. Aínda que falle un dos compoñentes, o sistema non comeza a funcionar nun escenario de emerxencia. Controladores, sensores, dispositivos: cada elemento é tanto un servidor como un cliente, polo tanto, completamente autónomo.

Para os interesados, as nosas redes sociais: Telegrama, Instagram, Noticias de Telegram, VK, Facebook.

Correo: [protexido por correo electrónico]

PS Non te animamos a abandonar o servidor. Tamén admitimos un servidor MQTT e temos a nosa propia nube. O noso obxectivo é levar a estabilidade e fiabilidade do sistema a un nivel totalmente novo. Para que o Servidor non sexa un punto débil, senón que complemente a funcionalidade e faga máis cómodo o sistema.

Fonte: www.habr.com