{"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\/es\/blog\/news\/lytko-obedinyaet","title":{"rendered":"Lytko une","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hace alg\u00fan tiempo le presentamos un termostato inteligente<\/a><\/noindex>. El art\u00edculo actual se concibi\u00f3 inicialmente como una demostraci\u00f3n de su firmware y sistema de control. Pero para explicar la l\u00f3gica de funcionamiento del termostato y lo que hemos implementado, es necesario esbozar toda la concepci\u00f3n en general.<\/p>\n

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

Sobre la automatizaci\u00f3n<\/h3>\n

\nCondicionalmente, toda la automatizaci\u00f3n se puede dividir en tres categor\u00edas:
\nCategor\u00eda 1<\/u> \u2014 dispositivos 'inteligentes' individuales. Adquiere bombillas, hervidores, etc. de diferentes fabricantes. Ventajas: cada dispositivo ampl\u00eda las capacidades y aumenta la comodidad. Desventajas: se necesita una aplicaci\u00f3n diferente para cada nuevo fabricante. Los protocolos de dispositivos de diferentes fabricantes a menudo no son compatibles entre s\u00ed.<\/p>\n

Categor\u00eda 2<\/u> \u2014 la instalaci\u00f3n de un PC de placa \u00fanica o uno compatible con x86. Esto elimina las limitaciones de poder de c\u00e1lculo, y en esta m\u00e1quina se instala MajorDoMo o cualquier otra distribuci\u00f3n de servidor para gestionar una casa inteligente. As\u00ed, la mayor\u00eda de los dispositivos de diferentes fabricantes se conectan en un \u00fanico espacio inform\u00e1tico. Es decir, se crea su propio servidor para la casa inteligente. Ventajas: compatibilidad bajo un \u00fanico centro, lo que brinda amplias posibilidades de gesti\u00f3n. Desventajas: si el servidor falla, todo el sistema regresa a la fase 1, es decir, se vuelve fragmentado o in\u00fatil.<\/p>\n

Categor\u00eda 3<\/u> \u2014 la opci\u00f3n m\u00e1s avanzada. En la etapa de renovaci\u00f3n se instalan todas las comunicaciones y se duplican todos los sistemas. Ventajas: todo se lleva a la perfecci\u00f3n y entonces la casa se vuelve realmente inteligente. Desventajas: extremo costo en comparaci\u00f3n con las categor\u00edas 1 y 2, la necesidad de planificar todo con anticipaci\u00f3n y considerar cada detalle.<\/p>\n

La mayor\u00eda de los usuarios eligen la opci\u00f3n uno y luego pasan gradualmente a la opci\u00f3n dos. Y posteriormente, los m\u00e1s persistentes llegan a la opci\u00f3n 3. <\/p>\n

Pero existe una opci\u00f3n que se puede denominar sistema distribuido: cada dispositivo individual ser\u00e1 tanto servidor como cliente. En esencia, es un intento de combinar la opci\u00f3n 1 y la opci\u00f3n 2. Tomar todos sus beneficios y eliminar desventajas, encontrar un t\u00e9rmino medio. <\/p>\n

Es posible que algunos digan que ya se ha desarrollado una opci\u00f3n as\u00ed. Pero tales soluciones son muy espec\u00edficas; para personas con conocimientos en programaci\u00f3n. Nuestro objetivo es reducir la barrera de entrada a estos sistemas distribuidos tanto en forma de dispositivos finales como en la integraci\u00f3n 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\u00f3n adicional.<\/p>\n

Veamos la integraci\u00f3n en nuestro sistema como ejemplo. <\/p>\n

Imaginemos que en nuestra red hay 8 m\u00f3dulos Sonoff. A algunos usuarios les bastar\u00e1 con el control a trav\u00e9s de la nube de Sonoff (categor\u00eda 1). Otros comenzar\u00e1n a usar firmware de terceros y progresivamente pasar\u00e1n a la categor\u00eda 2. La mayor\u00eda de los firmwares de terceros funcionan bajo el mismo principio: la transmisi\u00f3n de datos al servidor MQTT. OpenHub, Majordomo u otros sirven a un mismo objetivo: unir dispositivos dispares en un \u00fanico espacio inform\u00e1tico, ya sea en Internet o en una red local. Por lo tanto, la existencia de un servidor es obligatoria. De aqu\u00ed surge el principal problema: si el servidor falla, todo el sistema deja de funcionar de manera aut\u00f3noma. Para evitar esto, los sistemas se complican, a\u00f1adiendo m\u00e9todos de control manual que duplican la automatizaci\u00f3n en caso de fallo del servidor. <\/p>\n

Nosotros seguimos un camino diferente, donde cada dispositivo es autosuficiente. As\u00ed, el servidor no desempe\u00f1a un papel crucial, sino que solo ampl\u00eda la funcionalidad.<\/p>\n

Regresemos al experimento mental. Tomemos nuevamente los mismos 8 m\u00f3dulos Sonoff y les instalemos el firmware Lytko. En todos los firmwares Lytko se ha implementado la funci\u00f3n SSDP<\/a><\/noindex>. 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\u00e1ndar o extendida. Hemos incorporado en esta respuesta, adem\u00e1s de las funciones est\u00e1ndar, la creaci\u00f3n de una lista de dispositivos en la red. De este modo, los dispositivos se encuentran entre s\u00ed, y cada uno de ellos tendr\u00e1 tal lista. Ejemplo de la lista SSDP:<\/p>\n

\"ssdpList\": \n\t{\n\t\t\"id\": 94967291,  \n\t\t\"ip\": \"192.168.x.x\",\n                \"type\": \"termostato\"\n\t}, \n\t{\n\t\t\"id\": 94967282,\n\t\t\"ip\": \"192.168.x.x\",\n                \"type\": \"termostato\"\n\t}<\/code><\/pre>\n
\nComo se puede ver en el ejemplo, la lista incluye los id de los dispositivos, la direcci\u00f3n 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\u00e1micos en la cantidad de dispositivos en la red). De esta manera, podemos rastrear la adici\u00f3n, modificaci\u00f3n y desconexi\u00f3n de dispositivos sin ninguna acci\u00f3n por parte del usuario. Esta lista se env\u00eda al navegador o a la aplicaci\u00f3n m\u00f3vil, y el script genera autom\u00e1ticamente la p\u00e1gina con la cantidad especificada de bloques. Cada bloque corresponde a un dispositivo\/sensor\/controlador. Visualmente, la lista se ve as\u00ed:<\/p>\n
\"Lytko
\n
\nPero, \u00bfqu\u00e9 sucede si a esp8266\/esp32 se conectan otros sensores de radio a trav\u00e9s de cc2530 (ZigBee) o nrf24 (MySensors)? <\/p>\n
Sobre proyectos<\/h3>\n
\nExisten diversos sistemas distribuidos en el mercado. Nuestro sistema permite integrarse con los m\u00e1s populares. <\/p>\n
A continuaci\u00f3n se presentan proyectos que, de alguna manera, intentan cambiar la situaci\u00f3n de incompatibilidad entre diferentes fabricantes. Por ejemplo, SLS Gateway<\/a><\/noindex>, MySensors <\/a><\/noindex> o ZESP32<\/a><\/noindex>. ZigBee2MQTT <\/a><\/noindex> est\u00e1 conectado a un servidor MQTT, por lo que no es adecuado para este ejemplo. <\/p>\n
Una de las opciones de implementaci\u00f3n de MySensors es un gateway basado en ESP8266. Los otros ejemplos son sobre ESP32. En ellos se puede aplicar nuestro principio de operaci\u00f3n para la detecci\u00f3n y creaci\u00f3n de la lista de dispositivos. <\/p>\n
Hagamos otro experimento mental. Tenemos un gateway ZESP32 o SLS Gateway o MySensors. \u00bfC\u00f3mo podemos unirlos en un \u00fanico espacio inform\u00e1tico? A las funciones est\u00e1ndar de estos gateways a\u00f1adiremos la biblioteca del protocolo SSDP. Al hacer una consulta a este controlador a trav\u00e9s de SSDP, \u00e9l a\u00f1adir\u00e1 a la respuesta est\u00e1ndar la lista de dispositivos que est\u00e1n conectados a \u00e9l. Con esta informaci\u00f3n, el navegador generar\u00e1 una p\u00e1gina. En t\u00e9rminos generales, se ver\u00e1 as\u00ed:<\/p>\n
\"Lytko
\nInterfaz web<\/i><\/p>\n
\"Lytko
\nAplicaci\u00f3n PWA<\/i><\/p>\n
\"ssdpList\": \n{\n   \"id\": 94967291, \/\/ identificador \u00fanico del dispositivo\n   \"ip\": \"192.168.x.x\", \/\/ direcci\u00f3n ip en la red\n   \"type\": \"termostato\" \/\/ tipo de dispositivo\n},\n{\n   \"id\": 94967292,\n   \"ip\": \"192.168.x.x\",\n   \"type\": \"termostato\"\n},\n{\n   \"id\": 94967293,\n   \"ip\": \"192.168.x.x\",\n   \"type\": \"termostato\"\n},\n{  \n   \"id\": 13587532, \n   \"type\": \"interruptor\"  \n},\n{  \n   \"id\": 98412557, \n   \"type\": \"humo\"\n},\n{  \n   \"id\": 57995113, \n   \"type\": \"sensor_de_contacto\"\n},\n{  \n   \"id\": 74123668,\n   \"type\": \"sensor_de_temperatura_humedad_presi\u00f3n\"\n},\n{\n    \"id\": 74621883, \n    \"type\": \"sensor_de_temperatura_humedad\"\n}\n<\/code><\/pre>\n
\nDel ejemplo se puede ver que los dispositivos se a\u00f1aden de forma independiente. Se han conectado 3 termostatos con direcciones IP propias y 5 sensores diferentes con IDs \u00fanicos. Si un sensor se conecta a la red Wi-Fi, tendr\u00e1 su propia IP; si est\u00e1 conectado a un gateway, la direcci\u00f3n IP del dispositivo ser\u00e1 la misma que la del gateway.<\/p>\n
Para comunicarnos con los dispositivos utilizamos WebSocket. Esto permite minimizar el uso de recursos en comparaci\u00f3n con las solicitudes GET y recibir informaci\u00f3n din\u00e1micamente al conectar o cambiar. <\/p>\n
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\u00e1 el dispositivo que ha ca\u00eddo de la lista. Sin embargo, la se\u00f1al de p\u00e9rdida, si es necesario, llegar\u00e1 como una notificaci\u00f3n a la aplicaci\u00f3n del usuario. <\/p>\n
El primer intento de implementar este enfoque fue una aplicaci\u00f3n 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\u00f3n es incompleta. Y la \u00fanica salida es una aplicaci\u00f3n nativa para Android e IOS, que actualmente se encuentra en desarrollo activo. Por defecto, la aplicaci\u00f3n funcionar\u00e1 solo en la red interna. Si es necesario, se puede trasladar todo a un control externo. As\u00ed, cuando el usuario sale de la red local, la aplicaci\u00f3n se cambia autom\u00e1ticamente a la nube. <\/p>\n
El control externo es un duplicado completo de la p\u00e1gina. Al activar la p\u00e1gina, el usuario puede iniciar sesi\u00f3n en el servidor y gestionar los dispositivos a trav\u00e9s de su cuenta personal. As\u00ed, el servidor ampl\u00eda la funcionalidad, permitiendo gestionar dispositivos desde fuera de casa y no estar atado a la red de puertos o a una IP dedicada.<\/p>\n
De este modo, la opci\u00f3n descrita anteriormente no tiene las desventajas del enfoque del servidor, adem\u00e1s de contar con varias ventajas en forma de flexibilidad para conectar nuevos dispositivos.<\/p>\n
Sobre el termostato<\/h3>\n
\nConsideremos el sistema de gesti\u00f3n a trav\u00e9s de nuestro termostato como ejemplo.<\/p>\n
Se prev\u00e9:<\/p>\n
    \n
  1. Regulaci\u00f3n de la temperatura de cada termostato (se muestra en forma de bloque separado);<\/li>\n
  2. Configuraci\u00f3n del horario de funcionamiento del termostato (ma\u00f1ana, d\u00eda, tarde, noche);<\/li>\n
  3. Selecci\u00f3n de la red Wi-Fi y conexi\u00f3n del dispositivo a ella;<\/li>\n
  4. Actualizaci\u00f3n del dispositivo 'por aire';<\/li>\n
  5. Configuraci\u00f3n de MQTT;<\/li>\n
  6. Configuraci\u00f3n de la red a la que est\u00e1 conectado el dispositivo.<\/li>\n<\/ol>\n
    \n\"Lytko
    \n
    \nAdem\u00e1s del control a trav\u00e9s de la interfaz web, tambi\u00e9n se ha previsto el cl\u00e1sico \u2014 mediante toques en la pantalla. A bordo se encuentra un monitor Nextion NX3224T024 de 2.4 pulgadas. Se eligi\u00f3 debido a la facilidad de uso con el dispositivo. Sin embargo, se est\u00e1 desarrollando un monitor propio basado en STM32. Su funcionalidad no es inferior a la del Nextion, pero costar\u00e1 menos, lo que influir\u00e1 positivamente en el precio final del dispositivo.<\/p>\n
    \"Lytko
    \n
    \nAl igual que cualquier pantalla de termostato respetable, nuestro Nextion puede:<\/p>\n