Fa un temps us vam presentar . Aquest article estava pensat originalment com una demostració del seu firmware i sistema de control. Però per explicar la lògica del termòstat i què hem implementat, cal esbossar tot el concepte en conjunt.
Sobre l'automatització
Convencionalment, tota l'automatització es pot dividir en tres categories:
Categoria 1 — Dispositius “intel·ligents” separats. Compres bombetes, teteres, etc. de diferents fabricants. Avantatges: cada dispositiu amplia les capacitats i augmenta la comoditat. Contres: cada nou fabricant requereix la seva pròpia aplicació. Els protocols de dispositius de diferents fabricants sovint no són compatibles entre si.
Categoria 2 — instal·lació d'un ordinador d'una sola placa o compatible amb x86. Això elimina les restriccions a la potència de càlcul i MajorDoMo o qualsevol altra distribució de servidors per gestionar una llar intel·ligent està instal·lat en aquesta màquina. Així, els dispositius de la majoria de fabricants estan connectats en un únic espai d'informació. Aquells. apareix el vostre propi servidor per a una casa intel·ligent. Avantatges: compatibilitat en un únic centre, que proporciona capacitats de gestió millorades. Contres: si el servidor falla, tot el sistema torna a l'etapa 1, és a dir. es fragmenta o es torna inútil.
Categoria 3 - l'opció més hardcore. En l'etapa de reparació, es posen totes les comunicacions i es dupliquen tots els sistemes. Avantatges: tot es porta a la perfecció i després la casa esdevé realment intel·ligent. Inconvenients: extremadament car en comparació amb les categories 1 i 2, la necessitat de pensar-ho tot per endavant i tenir en compte cada petit detall.
La majoria dels usuaris trien l'opció 3 i després passen sense problemes a l'opció dos. I llavors els més persistents arriben a l'opció XNUMX.
Però hi ha una opció que es pot anomenar sistema distribuït: cada dispositiu individual serà alhora un servidor i un client. Essencialment, es tracta d'un intent d'agafar i combinar l'opció 1 i l'opció 2. Agafeu tots els seus pros i elimineu els contres, per agafar la mitjana daurada.
Potser algú dirà que aquesta opció ja s'ha desenvolupat. Però aquestes decisions estan molt focalitzades; per a gent experta en programació. El nostre objectiu és reduir la barrera d'entrada a aquests sistemes distribuïts, tant en forma de dispositius finals com en forma d'integració de dispositius existents al nostre sistema. En el cas d'un termòstat, l'usuari simplement elimina el seu antic termòstat, n'instal·la un d'intel·ligent i hi connecta els seus sensors existents. Sense cap pas addicional.
Vegem la integració al nostre sistema amb un exemple.
Imaginem que tenim 8 mòduls Sonoff a la nostra xarxa. Per a alguns usuaris, el control mitjançant el núvol Sonoff (categoria 1) serà suficient. Alguns començaran a utilitzar el microprogramari de tercers i passaran sense problemes a la categoria 2. La major part del microprogramari de tercers funciona amb el mateix principi: transferir dades a un servidor MQTT. OpenHub, Majordomo o qualsevol altre tenen un propòsit: unir dispositius diferents en un únic espai d'informació situat a Internet o en una xarxa local. Per tant, la presència d'un Servidor és obligatòria. Aquí és on sorgeix el problema principal: si el servidor falla, tot el sistema deixa de funcionar de manera autònoma. Per evitar-ho, els sistemes es tornen més complexos, s'afegeixen mètodes de control manual que dupliquen l'automatització en cas d'error del servidor.
Hem pres un camí diferent, on cada dispositiu és autosuficient. Així, el servidor no juga un paper decisiu, sinó que només amplia la funcionalitat.
Tornem a l'experiment mental. Tornem a prendre els mateixos 8 mòduls Sonoff i instal·lem-hi el firmware Lytko. Tots els firmwares de Lytko tenen la funció . SSDP és un protocol de xarxa basat en la suite de protocols d'Internet per a la publicitat i el descobriment de serveis de xarxa. La resposta a una sol·licitud pot ser estàndard o ampliada. A més de les funcions estàndard, hem inclòs en aquesta resposta la creació d'una llista de dispositius a la xarxa. Així, els propis dispositius es troben entre ells i cadascun d'ells tindrà una llista d'aquest tipus. Exemple de full SSDP:
"ssdpList":
{
"id": 94967291,
"ip": "192.168.x.x",
"type": "thermostat"
},
{
"id": 94967282,
"ip": "192.168.x.x",
"type": "thermostat"
}Com podeu veure a l'exemple, la llista inclou identificadors del dispositiu, adreça IP a la xarxa, tipus d'unitat (en el nostre cas, un termòstat basat en Sonoff). Aquesta llista s'actualitza cada dos minuts (aquest període és suficient per respondre als canvis dinàmics en el nombre de dispositius de la xarxa). D'aquesta manera, fem un seguiment dels dispositius afegits, canviats i desactivats sense cap acció de l'usuari. Aquesta llista s'envia al navegador o a l'aplicació mòbil, i el propi script genera una pàgina amb un nombre determinat de blocs. Cada bloc correspon a un dispositiu/sensor/controlador. Visualment la llista es veu així:
Però, què passa si altres sensors de ràdio estan connectats a l'esp8266/esp32 mitjançant cc2530 (ZigBee) o nrf24 (MySensors)?
Sobre projectes
Hi ha diversos sistemes distribuïts al mercat. El nostre sistema us permet integrar-vos amb els més populars.
A continuació es mostren projectes que d'una manera o altra intenten canviar la situació amb la incompatibilitat de diferents fabricants entre si. Això és, per exemple, , o . està lligat a un servidor MQTT, de manera que no és adequat per a l'exemple.
Una opció per implementar MySensors és una passarel·la basada en l'ESP8266. La resta d'exemples estan a ESP32. I en ells podeu implementar el nostre principi de funcionament de detectar i crear una llista de dispositius.
Fem un altre experiment de pensament. Tenim una passarel·la ZESP32 o una passarel·la SLS, o MySensors. Com es poden combinar en un únic espai d'informació? Afegirem la biblioteca de protocols SSDP a les funcions estàndard d'aquestes passarel·les. En accedir a aquest controlador mitjançant SSDP, afegirà una llista de dispositius que hi estan connectats a la resposta estàndard. A partir d'aquesta informació, el navegador generarà una pàgina. En general es veurà així:
Interfície web
Aplicació 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"
}
L'exemple mostra que els dispositius s'afegeixen independentment els uns dels altres. Es connecten 3 termòstats amb les seves pròpies adreces IP i 5 sensors diferents amb identificadors únics. Si el sensor està connectat a una xarxa Wi-Fi, tindrà la seva pròpia IP; si està connectat a una passarel·la, l'adreça IP del dispositiu serà l'adreça IP de la passarel·la.
Utilitzem WebSocket per comunicar-nos amb dispositius. Això us permet minimitzar els costos de recursos en comparació amb obtenir sol·licituds i obtenir informació de forma dinàmica quan es connecta o es modifica.
Les dades es prenen directament del dispositiu al qual pertany el bloc, sense passar per alt el servidor. Així, si algun dels dispositius falla, el sistema continua funcionant. La interfície web simplement no mostra el dispositiu que falta de la llista. Però un senyal sobre la pèrdua, si cal, arribarà en forma d'una notificació a l'aplicació de l'usuari.
El primer intent d'implementar aquest enfocament va ser una aplicació PWA. Això us permet emmagatzemar una base de blocs al dispositiu de l'usuari i sol·licitar només les dades necessàries. Però a causa de les peculiaritats de l'estructura, aquesta opció és incompleta. I només hi ha una sortida: una aplicació nativa per a Android i iOS, que actualment està en desenvolupament actiu. Per defecte, l'aplicació només funcionarà a la xarxa interna. Si cal, podeu transferir-ho tot al control extern. Així, quan l'usuari abandona la xarxa local, l'aplicació canvia automàticament al núvol.
Control extern: duplicació completa de la pàgina. Quan la pàgina està activada, l'usuari pot iniciar sessió al servidor i gestionar els dispositius mitjançant el seu compte personal. Així, el servidor amplia la seva funcionalitat, permetent gestionar els dispositius fora de casa i no estar lligat al reenviament de ports o a una IP dedicada.
Per tant, l'opció anterior no té els inconvenients de l'enfocament del servidor, i també té una sèrie d'avantatges en forma de flexibilitat en la connexió de nous dispositius.
Sobre el termòstat
Vegem el sistema de control amb el nostre termòstat com a exemple.
Proporcionat:
- Control de temperatura per a cada termòstat (que es mostra com a bloc separat);
- Configuració del programa de funcionament del termòstat (matí, tarda, vespre, nit);
- Seleccionar una xarxa Wi-Fi i connectar-hi un dispositiu;
- Actualització del dispositiu "a l'aire";
- Configuració de MQTT;
- Configureu la xarxa a la qual està connectat el dispositiu.
A més del control mitjançant la interfície web, vam proporcionar el clàssic: fent clic a la pantalla. Hi ha un monitor Nextion NX3224T024 de 2.4 polzades a bord. L'elecció va recaure en ell per la facilitat de treballar amb el dispositiu. Però estem desenvolupant el nostre propi monitor basat en STM32. La seva funcionalitat no és pitjor que la de Nextion, però costarà menys, cosa que repercutirà positivament en el preu final del dispositiu.
Com qualsevol pantalla de termòstat que es precie, el nostre Nextion pot:
- establir la temperatura requerida per l'usuari (amb els botons de la dreta);
- activar i desactivar el mode de funcionament programat (botó H);
- funcionament del relé de visualització (fletxa a l'esquerra);
- té protecció infantil (els clics físics es bloquegen fins que s'elimina el pany);
- mostra la força del senyal WiFi.
A més, amb el monitor podeu:
- seleccionar el tipus de sensor instal·lat per l'usuari;
- gestionar la funció de bloqueig infantil;
- actualitzar el firmware.
En fer clic a la barra WiFi, l'usuari trobarà informació sobre la xarxa connectada. El codi QR s'utilitza per vincular el dispositiu al microprogramari HomeKit.
Demostració del treball amb la pantalla:
Hem desenvolupat amb tres termòstats connectats.
Podeu preguntar: "Què té d'especial el termòstat?" Ara al mercat hi ha molts termòstats amb funció Wi-Fi, funcionament programat i control tàctil. I els entusiastes han escrit mòduls per interactuar amb els sistemes domèstics intel·ligents més populars (Majordomo, HomeAssistant, etc.).
El nostre termòstat és compatible amb aquests sistemes i té tot l'anterior. Però la característica distintiva és que el termòstat es millora constantment, gràcies a la flexibilitat del sistema. Amb cada actualització, la funcionalitat s'ampliarà. Al mètode estàndard de gestió del sistema (segons una programació), n'afegirem un d'adaptatiu. L'aplicació permet obtenir la geolocalització de l'usuari. Gràcies a això, el sistema canviarà dinàmicament els modes de funcionament en funció de la seva ubicació. I el mòdul meteorològic us permetrà adaptar-vos a les condicions meteorològiques.
I l'expansió. Qualsevol pot substituir el seu termòstat convencional existent pel nostre. Amb el mínim esforç. Hem seleccionat 5 dels sensors més populars del mercat i hem afegit suport per a ells. Però encara que el sensor tingui característiques exclusives, l'usuari el podrà connectar al nostre termòstat. Per fer-ho, caldrà calibrar el termòstat perquè funcioni amb un sensor específic. Donarem instruccions.
En connectar un termòstat o qualsevol altre dispositiu, apareix simultàniament a tot arreu: tant a la interfície web com a l'aplicació PWA. L'addició d'un dispositiu es fa automàticament: només cal connectar-lo a la xarxa Wi-Fi.
El nostre sistema no necessita un Servidor, i si falla, no es converteix en una carbassa. Fins i tot si un dels components falla, el sistema no comença a funcionar en un escenari d'emergència. Controladors, sensors, dispositius: cada element és alhora un servidor i un client, per tant, completament autònom.
Per als interessats, les nostres xarxes socials: , , , , .
Oficina de correus: [protegit per correu electrònic]
PS No us animem a abandonar el servidor. També admetem un servidor MQTT i tenim el nostre propi núvol. El nostre objectiu és portar l'estabilitat i la fiabilitat del sistema a un nivell totalment nou. Perquè el Servidor no sigui un punt feble, sinó que complementi la funcionalitat i fa que el sistema sigui més còmode.
Font: www.habr.com