Hace algún tiempo, te presentamos un
termostato inteligente . Este artículo fue concebido originalmente como una demostración de su firmware y sistema de control. Pero para explicar la lógica del termostato y lo que hemos implementado, es necesario describir todo el concepto.
Acerca de la automatización
Convencionalmente, toda la automatización se puede dividir en tres categorías:
Categoría 1 : dispositivos "inteligentes" separados. Obtienes bombillas, teteras, etc. de diferentes fabricantes. Ventajas: cada dispositivo amplía las oportunidades y aumenta la comodidad. Contras: cada nuevo fabricante necesita su propia aplicación. Los protocolos de dispositivos de diferentes fabricantes a menudo no son compatibles entre sí.
Categoría 2 : instalación de una PC de placa única o compatible con x86. Esto elimina las limitaciones en el poder de cómputo, y MajorDoMo o cualquier otro servidor de distribución para administrar un hogar inteligente está instalado en esta máquina. Por lo tanto, los dispositivos de la mayoría de los fabricantes están conectados en un solo espacio de información. Es decir Aparece su servidor para el hogar inteligente. Pros: compatibilidad en un solo centro, que proporciona capacidades de gestión avanzadas. Contras: en caso de falla / falla del servidor, todo el sistema vuelve a la etapa 1, es decir se fragmenta o se vuelve inútil.
La categoría 3 es la versión más hardcore. En la etapa de reparación, todas las comunicaciones se establecen y todos los sistemas se duplican. Pros: todo se lleva al ideal y luego la casa se vuelve realmente inteligente. Contras: costo extremo en comparación con las categorías 1 y 2, la necesidad de pensar antes de todo y tener en cuenta cada pequeña cosa.
La mayoría de los usuarios seleccionan la opción uno y luego cambian sin problemas a la opción dos. Y en el futuro, la opción de alcance más persistente 3.
Pero hay una opción que se puede llamar un sistema distribuido: cada dispositivo individual será un servidor y un cliente. De hecho, este es un intento de tomar y combinar la opción 1 y la opción 2. Tome todas sus ventajas y elimine las desventajas, tome el término medio.
Quizás alguien dirá que tal opción ya se ha desarrollado. Pero tales decisiones están estrechamente dirigidas; para personas con conocimientos de programación. Nuestro objetivo es reducir el umbral de entrada a dichos sistemas distribuidos tanto en forma de dispositivos finales como en forma de integración de dispositivos existentes en nuestro sistema. En el caso del termostato, el usuario simplemente retira su antiguo termostato, instala uno inteligente y conecta sus sensores al mismo. Sin ninguna acción adicional.
Consideremos la integración en nuestro sistema usando un ejemplo.
Imagine que tenemos 8 módulos Sonoff en nuestra red. Algunos usuarios pueden tener suficiente control sobre la nube de Sonoff (categoría 1). Algunos utilizarán firmware de terceros y pasarán sin problemas a la categoría 2. La mayor parte del firmware de terceros funciona con el mismo principio: transferencia de datos al servidor MQTT. OpenHub, Majordomo o cualquier otro tienen el mismo propósito: combinar dispositivos dispares en un solo espacio de información ubicado en Internet o en una red local. Por lo tanto, la presencia del servidor es obligatoria. A partir de aquí surge el problema principal: cuando el servidor falla, todo el sistema deja de funcionar de forma autónoma. Para evitar esto, los sistemas se vuelven más complicados, se agregan métodos de control manual que duplican la automatización en caso de una falla del servidor.
Tomamos un camino diferente, donde cada dispositivo es autosuficiente. Por lo tanto, el servidor no juega un papel decisivo, sino que solo amplía la funcionalidad.
De vuelta al experimento mental. Nuevamente, tome los mismos 8 módulos Sonoff e instale el firmware de Lytko en ellos. En todo el firmware de Lytko, se implementa la función
SSDP . SSDP es un protocolo de red basado en un conjunto de protocolos de Internet utilizados para anunciar y descubrir servicios de red. La respuesta a la solicitud puede ser estándar o avanzada. Además de las funciones estándar, incluimos en esta respuesta la creación de una lista de dispositivos en la red. Por lo tanto, los dispositivos se encuentran entre sí, y cada uno de ellos tendrá dicha lista. Ejemplo de hoja SSDP:
"ssdpList": { "id": 94967291, "ip": "192.168.xx", "type": "thermostat" }, { "id": 94967282, "ip": "192.168.xx", "type": "thermostat" }
Como puede ver en el ejemplo, la lista incluye la identificación del dispositivo, la dirección IP de la red, el tipo de bloque (en nuestro caso, un termostato basado en Sonoff). Esta lista se actualiza una vez cada dos minutos (este intervalo es suficiente para responder a un cambio dinámico en la cantidad de dispositivos en la red). Por lo tanto, rastreamos la adición, modificación y desconexión de dispositivos sin ninguna acción por parte del usuario. Esta lista se envía a un navegador o aplicación móvil, y el script mismo forma una página con un número determinado de bloques. Cada bloque corresponde a un dispositivo / sensor / controlador. Visualmente, la lista se ve así:
Pero si otros sensores de radio están conectados a esp8266 / esp32 a través de cc2530 (ZigBee) o nrf24 (MySensors)?
Sobre proyectos
Existen varios sistemas distribuidos en el mercado. Nuestro sistema le permite integrarse con los más populares.
A continuación se presentan los proyectos que de alguna manera intentan cambiar la situación con la incompatibilidad de diferentes fabricantes entre sí. Esto, por ejemplo,
SLS Gateway ,
MySensors o
ZESP32 .
ZigBee2MQTT está vinculado a un servidor MQTT, por lo que no es adecuado, por ejemplo.
Una opción de implementación para MySensors es una puerta de enlace basada en ESP8266. Otros ejemplos están en ESP32. Y en ellos puede implementar nuestro principio de detección y creación de una lista de dispositivos.
Hagamos otro experimento mental. Tenemos una puerta de enlace ZESP32 o SLS Gateway, o MySensors. ¿Cómo se pueden combinar en un solo espacio de información? Agregaremos la biblioteca de protocolos SSDP a las funciones estándar de estas puertas de enlace. Al acceder a este controlador a través de SSDP, agregará a la respuesta estándar una lista de dispositivos que están conectados a él. Según esta información, el navegador formará una página. En términos generales, se verá así:
Interfaz web
Aplicación 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" }
El ejemplo muestra que los dispositivos se agregan independientemente uno del otro. Se conectan 3 termostatos con sus propias direcciones IP y 5 sensores diferentes con identificación única. Si el sensor está conectado a una red Wi-Fi, tendrá su propia ip, si está conectado a la puerta de enlace, la dirección IP del dispositivo será la dirección IP de la puerta de enlace.
Para comunicarnos con dispositivos, utilizamos WebSocket. Esto le permite minimizar el costo de los recursos en comparación con las solicitudes de obtención y recibir información dinámicamente al conectarse o cambiar.
Los datos se toman directamente del dispositivo al que pertenece la unidad, sin pasar por el servidor. Por lo tanto, si alguno de los dispositivos falla, el sistema continúa funcionando. La interfaz web no solo muestra el dispositivo que falta en la lista. Pero la señal de la pérdida, si es necesario, vendrá en forma de notificación en la aplicación del usuario.
El primer intento de implementar este enfoque fue una aplicación PWA. Esto le permite almacenar la base de bloques en el dispositivo del usuario y solicitar solo los datos necesarios. Pero debido a las peculiaridades de la estructura, dicha opción es inferior. Y solo hay una salida: una aplicación nativa para Android e IOS, que actualmente se encuentra en desarrollo activo. Por defecto, la aplicación solo funcionará en la red interna. Si es necesario, puede transferir todo a control externo. Entonces, cuando el usuario abandona la red local, la aplicación cambia automáticamente a la nube.
Gestión externa: duplicación completa de la página. Cuando se activa la página, el usuario puede iniciar sesión en el servidor y administrar dispositivos a través de una cuenta personal. Por lo tanto, el servidor amplía la funcionalidad, permitiéndole administrar dispositivos mientras está fuera de casa, y no estar vinculado al reenvío de puertos o una IP dedicada.
Por lo tanto, la opción anterior está libre de los inconvenientes del enfoque del servidor, y también tiene varias ventajas en forma de flexibilidad para conectar nuevos dispositivos.
Sobre el termostato
Considere un sistema de control que utilice nuestro termostato como ejemplo.
Proporcionado por:
- Control de temperatura de cada termostato (se muestra como una unidad separada);
- Establecer el horario del termostato (mañana, día, tarde, noche);
- Elegir una red Wi-Fi y conectar un dispositivo a ella;
- Actualización del dispositivo "por aire";
- Configurar MQTT;
- Configure la red a la que está conectado el dispositivo.
Además de administrar a través de la interfaz web, proporcionaron la clásica, tocando la pantalla. A bordo está el monitor Nextion NX3224T024 de 2.4 pulgadas. La elección recayó en él debido a la simplicidad de trabajar con el dispositivo. Pero en desarrollo está su propio monitor basado en STM32. Su funcionalidad no es peor que la de Nextion, pero costará menos, lo que afectará positivamente el precio final del dispositivo.
Al igual que cualquier pantalla de termostato respetuosa, nuestra Nextion puede:
- establecer la temperatura necesaria para el usuario (usando los botones a la derecha);
- enciende y apaga el modo de operación programado (botón H);
- visualización del funcionamiento del relé (flecha a la izquierda);
- tiene protección contra los niños (los clics físicos se bloquean hasta que se elimina el bloqueo);
- Muestra la intensidad de la señal WiFi.
Además, usando el monitor puedes:
- seleccione el tipo de sensor instalado por el usuario;
- gestionar la función de protección infantil;
- actualizar el firmware
Al hacer clic en la barra de WiFi, el usuario encontrará información sobre la red conectada. El código QR se usa para emparejar el dispositivo en el firmware de HomeKit.
Demostración de trabajo con la pantalla:
Desarrollamos una
página de demostración con tres termostatos conectados.
Usted pregunta: "¿Cuál es la peculiaridad de su termostato?" Ahora hay muchos termostatos en el mercado con función de Wi-Fi, trabajo programado, control táctil. Y los entusiastas han escrito módulos para interactuar con los sistemas domésticos inteligentes más populares (Majordomo, HomeAssistant, etc.).
Nuestro termostato es compatible con dichos sistemas y tiene todo lo anterior. Pero la característica distintiva es que el termostato se mejora constantemente, gracias a la flexibilidad del sistema. Con cada actualización, la funcionalidad se expandirá. A la forma estándar de administrar el sistema (de acuerdo con el cronograma), agregaremos uno adaptativo. La aplicación le permite obtener la geolocalización del usuario. Debido a esto, el sistema cambiará dinámicamente los modos operativos dependiendo de su ubicación. Y el módulo meteorológico le permitirá adaptarse a las condiciones climáticas.
Y extensibilidad. Cualquiera puede reemplazar el termostato habitual instalado con él por el nuestro. Con un mínimo esfuerzo. Seleccionamos los 5 sensores más populares del mercado y agregamos su soporte. Pero incluso en el caso de las características exclusivas del sensor, el usuario podrá conectarlo a nuestro termostato. Para hacer esto, debe calibrar el termostato para que funcione con un sensor específico. Le daremos instrucciones.
Al conectar un termostato o cualquier otro dispositivo, aparece simultáneamente en todas partes: tanto en la interfaz web como en la aplicación PWA. Agregar un dispositivo es automático: solo conéctelo a una red Wi-Fi.
Nuestro sistema no necesita un servidor, y en caso de falla no se convierte en una calabaza. Incluso si uno de los componentes falla, el sistema no se inicia de acuerdo con el escenario de emergencia. Controladores, sensores, dispositivos: cada elemento es un servidor y un cliente, por lo tanto, es completamente autónomo.
Para aquellos interesados, nuestras redes sociales:
Telegram ,
Instagram ,
Telegram News ,
VK ,
Facebook .
Correo electrónico: shop@lytko.com
PD: no instamos a abandonar el servidor. También tenemos soporte para el servidor MQTT y tenemos nuestra propia nube. Nuestro objetivo es llevar la estabilidad y confiabilidad del sistema a un nivel completamente nuevo. De modo que el servidor no es un punto débil, sino que complementa la funcionalidad y hace que el sistema sea más conveniente.