Hace algún tiempo le presentamos . El artículo actual se concibió inicialmente como una demostración de su firmware y sistema de control. Pero para explicar la lógica de funcionamiento del termostato y lo que hemos implementado, es necesario esbozar toda la concepción en general.
Sobre la automatización
Condicionalmente, toda la automatización se puede dividir en tres categorías:
Categoría 1 — dispositivos 'inteligentes' individuales. Adquiere bombillas, hervidores, etc. de diferentes fabricantes. Ventajas: cada dispositivo amplía las capacidades y aumenta la comodidad. Desventajas: se necesita una aplicación diferente para cada nuevo fabricante. Los protocolos de dispositivos de diferentes fabricantes a menudo no son compatibles entre sí.
Categoría 2 — la instalación de un PC de placa única o uno compatible con x86. Esto elimina las limitaciones de poder de cálculo, y en esta máquina se instala MajorDoMo o cualquier otra distribución de servidor para gestionar una casa inteligente. Así, la mayoría de los dispositivos de diferentes fabricantes se conectan en un único espacio informático. Es decir, se crea su propio servidor para la casa inteligente. Ventajas: compatibilidad bajo un único centro, lo que brinda amplias posibilidades de gestión. Desventajas: si el servidor falla, todo el sistema regresa a la fase 1, es decir, se vuelve fragmentado o inútil.
Categoría 3 — la opción más avanzada. En la etapa de renovación se instalan todas las comunicaciones y se duplican todos los sistemas. Ventajas: todo se lleva a la perfección y entonces la casa se vuelve realmente inteligente. Desventajas: extremo costo en comparación con las categorías 1 y 2, la necesidad de planificar todo con anticipación y considerar cada detalle.
La mayoría de los usuarios eligen la opción uno y luego pasan gradualmente a la opción dos. Y posteriormente, los más persistentes llegan a la opción 3.
Pero existe una opción que se puede denominar sistema distribuido: cada dispositivo individual será tanto servidor como cliente. En esencia, es un intento de combinar la opción 1 y la opción 2. Tomar todos sus beneficios y eliminar desventajas, encontrar un término medio.
Es posible que algunos digan que ya se ha desarrollado una opción así. Pero tales soluciones son muy específicas; para personas con conocimientos en programación. Nuestro objetivo es reducir la barrera de entrada a estos sistemas distribuidos tanto en forma de dispositivos finales como en la integración de dispositivos existentes en nuestro sistema. En el caso del termostato, el usuario simplemente retira su viejo termostato, instala uno inteligente y conecta los sensores que ya tiene. Sin ninguna acción adicional.
Veamos la integración en nuestro sistema como ejemplo.
Imaginemos que en nuestra red hay 8 módulos Sonoff. A algunos usuarios les bastará con el control a través de la nube de Sonoff (categoría 1). Otros comenzarán a usar firmware de terceros y progresivamente pasarán a la categoría 2. La mayoría de los firmwares de terceros funcionan bajo el mismo principio: la transmisión de datos al servidor MQTT. OpenHub, Majordomo u otros sirven a un mismo objetivo: unir dispositivos dispares en un único espacio informático, ya sea en Internet o en una red local. Por lo tanto, la existencia de un servidor es obligatoria. De aquí surge el principal problema: si el servidor falla, todo el sistema deja de funcionar de manera autónoma. Para evitar esto, los sistemas se complican, añadiendo métodos de control manual que duplican la automatización en caso de fallo del servidor.
Nosotros seguimos un camino diferente, donde cada dispositivo es autosuficiente. Así, el servidor no desempeña un papel crucial, sino que solo amplía la funcionalidad.
Regresemos al experimento mental. Tomemos nuevamente los mismos 8 módulos Sonoff y les instalemos el firmware Lytko. En todos los firmwares Lytko se ha implementado la función . SSDP es un protocolo de red basado en un conjunto de protocolos de Internet, utilizado para anunciar y descubrir servicios de red. La respuesta a la solicitud puede ser estándar o extendida. Hemos incorporado en esta respuesta, además de las funciones estándar, la creación de una lista de dispositivos en la red. De este modo, los dispositivos se encuentran entre sí, y cada uno de ellos tendrá tal lista. Ejemplo de la lista SSDP:
"ssdpList":
{
"id": 94967291,
"ip": "192.168.x.x",
"type": "thermostat"
},
{
"id": 94967282,
"ip": "192.168.x.x",
"type": "thermostat"
}Como se puede ver en el ejemplo, la lista incluye los id de los dispositivos, la dirección IP en la red, el tipo de bloque (en nuestro caso, un termostato basado en Sonoff). Esta lista se actualiza cada dos minutos (este intervalo es suficiente para reaccionar a cambios dinámicos en la cantidad de dispositivos en la red). De esta manera, podemos rastrear la adición, modificación y desconexión de dispositivos sin ninguna acción por parte del usuario. Esta lista se envía al navegador o a la aplicación móvil, y el script genera automáticamente la página con la cantidad especificada de bloques. Cada bloque corresponde a un dispositivo/sensor/controlador. Visualmente, la lista se ve así:
Pero, ¿qué sucede si a esp8266/esp32 se conectan otros sensores de radio a través de cc2530 (ZigBee) o nrf24 (MySensors)?
Sobre proyectos
Existen diversos sistemas distribuidos en el mercado. Nuestro sistema permite integrarse con los más populares.
A continuación se presentan proyectos que, de alguna manera, intentan cambiar la situación de incompatibilidad entre diferentes fabricantes. Por ejemplo, , o . está conectado a un servidor MQTT, por lo que no es adecuado para este ejemplo.
Una de las opciones de implementación de MySensors es un gateway basado en ESP8266. Los otros ejemplos son sobre ESP32. En ellos se puede aplicar nuestro principio de operación para la detección y creación de la lista de dispositivos.
Hagamos otro experimento mental. Tenemos un gateway ZESP32 o SLS Gateway o MySensors. ¿Cómo podemos unirlos en un único espacio informático? A las funciones estándar de estos gateways añadiremos la biblioteca del protocolo SSDP. Al hacer una consulta a este controlador a través de SSDP, él añadirá a la respuesta estándar la lista de dispositivos que están conectados a él. Con esta información, el navegador generará una página. En términos generales, se verá así:
Interfaz web
Aplicación PWA
"ssdpList":
{
"id": 94967291, // identificador único del dispositivo
"ip": "192.168.x.x", // dirección ip en la red
"type": "thermostat" // tipo de dispositivo
},
{
"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"
}
Del ejemplo se puede ver que los dispositivos se añaden de forma independiente. Se han conectado 3 termostatos con direcciones IP propias y 5 sensores diferentes con IDs únicos. Si un sensor se conecta a la red Wi-Fi, tendrá su propia IP; si está conectado a un gateway, la dirección IP del dispositivo será la misma que la del gateway.
Para comunicarnos con los dispositivos utilizamos WebSocket. Esto permite minimizar el uso de recursos en comparación con las solicitudes GET y recibir información dinámicamente al conectar o cambiar.
Los datos se obtienen directamente del dispositivo al que pertenece el bloque, evitando el servidor. De este modo, si cualquiera de los dispositivos falla, el sistema sigue funcionando. En la interfaz web, simplemente no se mostrará el dispositivo que ha caído de la lista. Sin embargo, la señal de pérdida, si es necesario, llegará como una notificación a la aplicación del usuario.
El primer intento de implementar este enfoque fue una aplicación PWA. Esto permite almacenar la base de bloques en el dispositivo del usuario y solicitar solo los datos necesarios. Pero debido a las particularidades de la estructura, esta opción es incompleta. Y la única salida es una aplicación nativa para Android e IOS, que actualmente se encuentra en desarrollo activo. Por defecto, la aplicación funcionará solo en la red interna. Si es necesario, se puede trasladar todo a un control externo. Así, cuando el usuario sale de la red local, la aplicación se cambia automáticamente a la nube.
El control externo es un duplicado completo de la página. Al activar la página, el usuario puede iniciar sesión en el servidor y gestionar los dispositivos a través de su cuenta personal. Así, el servidor amplía la funcionalidad, permitiendo gestionar dispositivos desde fuera de casa y no estar atado a la red de puertos o a una IP dedicada.
De este modo, la opción descrita anteriormente no tiene las desventajas del enfoque del servidor, además de contar con varias ventajas en forma de flexibilidad para conectar nuevos dispositivos.
Sobre el termostato
Consideremos el sistema de gestión a través de nuestro termostato como ejemplo.
Se prevé:
- Regulación de la temperatura de cada termostato (se muestra en forma de bloque separado);
- Configuración del horario de funcionamiento del termostato (mañana, día, tarde, noche);
- Selección de la red Wi-Fi y conexión del dispositivo a ella;
- Actualización del dispositivo 'por aire';
- Configuración de MQTT;
- Configuración de la red a la que está conectado el dispositivo.
Además del control a través de la interfaz web, también se ha previsto el clásico — mediante toques en la pantalla. A bordo se encuentra un monitor Nextion NX3224T024 de 2.4 pulgadas. Se eligió debido a la facilidad de uso con el dispositivo. Sin embargo, se está desarrollando un monitor propio basado en STM32. Su funcionalidad no es inferior a la del Nextion, pero costará menos, lo que influirá positivamente en el precio final del dispositivo.
Al igual que cualquier pantalla de termostato respetable, nuestro Nextion puede:
- establecer la temperatura necesaria para el usuario (con los botones de la derecha);
- activar y desactivar el modo de funcionamiento programado (botón H);
- mostrar el funcionamiento del relé (flecha a la izquierda);
- tiene protección infantil (se bloquean los toques físicos mientras el candado está puesto);
- muestra el nivel de señal WiFi.
Además, con el monitor se puede:
- elegir 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 puede conocer la información sobre la red conectada. Se utiliza un código QR para emparejar el dispositivo en el firmware de HomeKit.
Demostración del trabajo con la pantalla:
Hemos desarrollado con tres termostatos conectados.
Usted preguntará: “¿Cuál es la característica de su termostato?” Actualmente, en el mercado existen muchos termostatos con función Wi-Fi, trabajo programado y control táctil. Además, los entusiastas han escrito módulos para interactuar con la mayoría de los sistemas de casa inteligente populares (Majordomo, HomeAssistant, etc.).
Nuestro termostato es compatible con esos sistemas y tiene todas las características mencionadas anteriormente. 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 control del sistema (por programación), le añadiremos uno adaptativo. La aplicación permite obtener la geolocalización del usuario. Gracias a esto, el sistema cambiará dinámicamente los modos de funcionamiento según su ubicación. Y el módulo del clima permitirá adaptarse a las condiciones meteorológicas.
Y escalabilidad. Cualquier persona podrá reemplazar el termostato estándar que tenga por el nuestro. Con un esfuerzo mínimo. Hemos seleccionado los 5 sensores más populares disponibles en el mercado y hemos añadido su soporte. Pero incluso en el caso de características exclusivas del sensor, el usuario podrá conectarlo a nuestro termostato. Para ello, será necesario calibrar el termostato para trabajar con el sensor específico. Proporcionaremos las instrucciones.
Al conectar el termostato o cualquier otro dispositivo, este aparece simultáneamente en todas partes: tanto en la interfaz web como en la aplicación PWA. La adición de un dispositivo se realiza automáticamente: solo es necesario conectarlo a la red Wi-Fi.
Nuestro sistema no necesita un Servidor, y en caso de falla, no se convierte en calabaza. Incluso si uno de los componentes falla, el sistema no comienza a funcionar en modo de emergencia. Los controladores, sensores, dispositivos: cada elemento es tanto Servidor como cliente, por lo que es completamente autónomo.
Para los interesados, nuestras redes sociales: , , , , .
Correo: shop@lytko.com
P. S. no estamos pidiendo que se renuncie al Servidor. También contamos con soporte para un servidor MQTT y tenemos nuestra propia nube. Nuestro objetivo es llevar la estabilidad y confiabilidad del sistema a un nivel de calidad completamente nuevo. Para que el Servidor no sea un punto débil, sino que complemente la funcionalidad y haga el sistema más conveniente.
Fuente: habr.com
