Hace un tiempo os presentamos . Este artículo fue pensado originalmente como una demostración de su firmware y sistema de control. Pero para explicar la lógica del termostato y lo que implementamos, es necesario delinear el concepto en su conjunto.
Acerca de la automatización
Convencionalmente, toda la automatización se puede dividir en tres categorías:
Categoría 1 — dispositivos “inteligentes” separados. Compras bombillas, teteras, etc. de diferentes fabricantes. Ventajas: Cada dispositivo amplía las capacidades y aumenta la comodidad. Contras: Cada nuevo fabricante requiere su propia aplicación. Los protocolos de dispositivos de diferentes fabricantes a menudo no son compatibles entre sí.
Categoría 2 — instalación de un PC monoplaca o compatible con x86. Esto elimina las restricciones en la potencia informática y en esta máquina se instala MajorDoMo o cualquier otra distribución de servidor para administrar una casa inteligente. Así, los dispositivos de la mayoría de fabricantes están conectados en un único espacio de información. Aquellos. Aparece tu propio servidor para una casa inteligente. Ventajas: compatibilidad en un solo centro, lo que proporciona capacidades de gestión mejoradas. Contras: si el servidor falla, todo el sistema vuelve a la etapa 1, es decir. se fragmenta o se vuelve inútil.
Categoría 3 - la opción más dura. En la etapa de reparación, se instalan todas las comunicaciones y se duplican todos los sistemas. Ventajas: todo se lleva a la perfección y luego la casa se vuelve verdaderamente inteligente. Desventajas: extremadamente caro en comparación con las categorías 1 y 2, la necesidad de pensar todo de antemano y tener en cuenta cada pequeño detalle.
La mayoría de los usuarios eligen la opción uno y luego pasan sin problemas a la opción dos. Y luego los más persistentes llegan a la opción 3.
Pero existe una opción que se puede llamar sistema distribuido: cada dispositivo individual será a la vez servidor y cliente. Esencialmente, este es un intento de tomar y combinar la opción 1 y la opción 2. Tome todas las ventajas y elimine las desventajas para alcanzar el punto medio.
Quizás alguien diga que ya se ha desarrollado esa opción. Pero tales decisiones tienen un enfoque muy limitado; para personas con conocimientos de programación. Nuestro objetivo es reducir la barrera 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 de un termostato, el usuario simplemente retira su termostato antiguo, instala uno inteligente y le conecta los sensores existentes. Sin ningún paso adicional.
Veamos la integración en nuestro sistema usando un ejemplo.
Imaginemos que tenemos 8 módulos Sonoff en nuestra red. Para algunos usuarios, el control a través de la nube de Sonoff (categoría 1) será suficiente. Algunos comenzarán a usar firmware de terceros y pasarán sin problemas a la categoría 2. La mayor parte del firmware de terceros funciona según el mismo principio: transferir datos a un servidor MQTT. OpenHub, Majordomo o cualquier otro tienen un propósito: unir dispositivos dispares en un único espacio de información ubicado en Internet o en una red local. Por tanto, la presencia de un Servidor es obligatoria. Aquí es donde surge el principal problema: si el servidor falla, todo el sistema deja de funcionar de forma autónoma. Para evitar esto, los sistemas se vuelven más complejos, se agregan métodos de control manual que duplican la automatización en caso de falla del Servidor.
Tomamos un camino diferente, donde cada dispositivo es autosuficiente. Por lo tanto, el servidor no juega un papel decisivo, sino que sólo amplía la funcionalidad.
Volvamos al experimento mental. Tomemos nuevamente los mismos 8 módulos Sonoff e instalemos el firmware Lytko en ellos. Todos los firmwares Lytko tienen la función . SSDP es un protocolo de red basado en el conjunto de protocolos de Internet para publicidad y descubrimiento de servicios de red. La respuesta a una solicitud puede ser estándar o ampliada. 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 propios dispositivos se encuentran entre sí y cada uno de ellos tendrá esa lista. Ejemplo de hoja SSDP:
"ssdpList":
{
"id": 94967291,
"ip": "192.168.x.x",
"type": "thermostat"
},
{
"id": 94967282,
"ip": "192.168.x.x",
"type": "thermostat"
}Como puede ver en el ejemplo, la lista incluye ID de dispositivos, dirección IP en la red, tipo de unidad (en nuestro caso, un termostato basado en Sonoff). Esta lista se actualiza una vez cada dos minutos (este período es suficiente para responder a cambios dinámicos en la cantidad de dispositivos en la red). De esta manera, rastreamos los dispositivos agregados, modificados y deshabilitados sin ninguna acción del usuario. Esta lista se envía al navegador o a la aplicación móvil y el propio script genera 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, ¿qué pasa si otros sensores de radio están conectados al esp8266/esp32 a través de cc2530 (ZigBee) o nrf24 (MySensors)?
Acerca de los proyectos
Existen varios sistemas distribuidos en el mercado. Nuestro sistema le permite integrarse con los más populares.
A continuación se muestran proyectos que de una forma u otra intentan cambiar la situación de incompatibilidad de diferentes fabricantes entre sí. Esto es, por ejemplo, , o . está vinculado a un servidor MQTT, por lo que no es adecuado para el ejemplo.
Una opción para implementar MySensors es una puerta de enlace basada en ESP8266. El resto de ejemplos están en ESP32. Y en ellos podrás implementar nuestro principio operativo de detectar y crear una lista de dispositivos.
Hagamos otro experimento mental. Disponemos de gateway ZESP32 o Gateway SLS, o MySensors. ¿Cómo se pueden combinar en un único 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á una lista de dispositivos que están conectados a él a la respuesta estándar. Basándose en esta información, el navegador generará una página. En general se verá así:
interfaz web
Solicitud de 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"
}
El ejemplo muestra que los dispositivos se agregan independientemente unos de otros. Se conectan 3 termostatos con sus propias direcciones IP y 5 sensores diferentes con ID únicos. Si el sensor está conectado a una red Wi-Fi, tendrá su propia IP; si está conectado a una puerta de enlace, entonces la dirección IP del dispositivo será la dirección IP de la puerta de enlace.
Usamos WebSocket para comunicarnos con dispositivos. Esto le permite minimizar los costos de recursos en comparación con recibir solicitudes y obtener información dinámicamente al conectarse o cambiar.
Los datos se toman directamente del dispositivo al que pertenece el bloque, sin pasar por el servidor. Así, si alguno de los dispositivos falla, el sistema continúa funcionando. La interfaz web simplemente no muestra el dispositivo que falta en la lista. Pero la señal de pérdida, si es necesario, llegará 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 una base de bloques en el dispositivo del usuario y solicitar solo los datos necesarios. Pero debido a las peculiaridades de la estructura, esta opción está incompleta. Y solo hay una salida: una aplicación nativa para Android e IOS, que actualmente se encuentra en desarrollo activo. De forma predeterminada, la aplicación sólo funcionará en la red interna. Si es necesario, puedes transferir todo al control externo. Entonces, cuando el usuario abandona la red local, la aplicación cambia automáticamente a la nube.
Control externo: 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 su cuenta personal. De esta manera, el Servidor amplía su funcionalidad, permitiéndole administrar dispositivos mientras está fuera de casa, y no estar atado al reenvío de puertos o una IP dedicada.
Por lo tanto, la opción anterior no tiene las desventajas del enfoque del servidor y también tiene una serie de ventajas en forma de flexibilidad para conectar nuevos dispositivos.
Sobre el termostato
Veamos el sistema de control usando nuestro termostato como ejemplo.
Proporcionó:
- Control de temperatura para cada termostato (se muestra como un bloque separado);
- Configuración del horario de funcionamiento del termostato (mañana, tarde, tarde, noche);
- Seleccionar una red Wi-Fi y conectarle un dispositivo;
- Actualización del dispositivo "por aire";
- Configurar MQTT;
- Configure la red a la que está conectado el dispositivo.
Además del control a través de la interfaz web, proporcionamos el clásico: haciendo clic en la pantalla. Hay un monitor Nextion NX3224T024 de 2.4 pulgadas a bordo. La elección recayó en él debido a la facilidad de trabajar con el dispositivo. Pero estamos desarrollando nuestro propio monitor basado en STM32. Su funcionalidad no es peor que la de Nextion, pero costará menos, lo que repercutirá positivamente en el precio final del dispositivo.
Como cualquier pantalla de termostato que se precie, nuestra Nextion puede:
- configurar la temperatura requerida por el usuario (usando los botones de la derecha);
- encender y apagar el modo de operación programado (botón H);
- funcionamiento del relé de visualización (flecha de la izquierda);
- tiene protección infantil (los clics físicos se bloquean hasta que se quita el bloqueo);
- muestra la intensidad de la señal WiFi.
Además, utilizando el monitor podrás:
- seleccionar el tipo de sensor instalado por el usuario;
- administrar la función de bloqueo para niños;
- actualizar el firmware.
Al hacer clic en la barra WiFi, el usuario encontrará información sobre la red conectada. El código QR se utiliza para emparejar el dispositivo en el firmware de HomeKit.
Demostración de cómo trabajar con la pantalla:
hemos desarrollado con tres termostatos conectados.
Quizás pregunte: "¿Qué tiene de especial su termostato?" Ahora en el mercado existen muchos termostatos con función Wi-Fi, funcionamiento programado y 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 ampliará. Al método estándar de gestión del sistema (según un cronograma), agregaremos uno adaptativo. La aplicación permite obtener la geolocalización del usuario. Gracias a esto, el sistema cambiará dinámicamente los modos de funcionamiento dependiendo de su ubicación. Y el módulo meteorológico te permitirá adaptarte a las condiciones climáticas.
Y capacidad de ampliación. Cualquiera puede reemplazar su termostato convencional existente por el nuestro. Con el mínimo esfuerzo. Hemos seleccionado 5 de los sensores más populares del mercado y les hemos agregado soporte. Pero aunque el sensor tenga unas características exclusivas, el usuario podrá conectarlo a nuestro termostato. Para hacer esto, necesitará 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. La adición de un dispositivo se produce automáticamente: solo necesita conectarlo a la red Wi-Fi.
Nuestro sistema no necesita Servidor, y si falla no se convierte en una calabaza. Incluso si uno de los componentes falla, el sistema no comienza a funcionar en un escenario de emergencia. Controladores, sensores, dispositivos: cada elemento es a la vez un servidor y un cliente y, por tanto, completamente autónomo.
Para los interesados, nuestras redes sociales: , , , , .
E-mail: [email protected]
PS No le recomendamos que abandone el servidor. También admitimos un servidor MQTT y tenemos nuestra propia nube. Nuestro objetivo es llevar la estabilidad y confiabilidad del sistema a un nivel completamente nuevo. Para que el Servidor no sea un punto débil, sino que complemente la funcionalidad y haga más conveniente el sistema.
Fuente: habr.com