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

Il y a quelque temps, nous vous avons pr\u00e9sent\u00e9 un thermostat intelligent<\/a><\/noindex>. Cet article \u00e9tait initialement pr\u00e9vu comme une d\u00e9monstration de son firmware et de son syst\u00e8me de gestion. Mais pour expliquer la logique de fonctionnement du thermostat et ce que nous avons mis en \u0153uvre, il est n\u00e9cessaire de d\u00e9crire l'ensemble du concept.<\/p>\n

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

Concernant l'automatisation<\/h3>\n

\nOn peut classer l'automatisation en trois cat\u00e9gories :
\nCat\u00e9gorie 1<\/u> \u2014 dispositifs \u00ab intelligents \u00bb individuels. Vous achetez des ampoules, des bouilloires, etc., aupr\u00e8s de diff\u00e9rents fabricants. Avantages : chaque appareil \u00e9tend les fonctionnalit\u00e9s et am\u00e9liore le confort. Inconv\u00e9nients : chaque nouveau fabricant n\u00e9cessite sa propre application. Les protocoles des appareils de diff\u00e9rents fabricants sont souvent incompatibles entre eux.<\/p>\n

Cat\u00e9gorie 2<\/u> \u2014 installation d'un PC monocarte ou compatible x86. Cela \u00e9limine les limites de puissance de calcul, et sur cette machine, on installe MajorDoMo ou toute autre distribution serveur pour la gestion de la maison intelligente. Ainsi, les dispositifs de la plupart des fabricants se connectent dans un espace d'information unique. C'est-\u00e0-dire qu'un serveur pour la maison intelligente est cr\u00e9\u00e9. Avantages : compatibilit\u00e9 sous un centre unique, ce qui offre des possibilit\u00e9s \u00e9tendues de gestion. Inconv\u00e9nients : en cas de panne du serveur, tout le syst\u00e8me revient \u00e0 l'\u00e9tat 1, c'est-\u00e0-dire qu'il devient disjoint ou inutilisable.<\/p>\n

Cat\u00e9gorie 3<\/u> \u2014 l'option la plus hardcore. Lors de la r\u00e9novation, toutes les communications sont int\u00e9gr\u00e9es et tous les syst\u00e8mes sont doubl\u00e9s. Avantages : tout est pouss\u00e9 \u00e0 la perfection et la maison devient v\u00e9ritablement intelligente. Inconv\u00e9nients : co\u00fbt extr\u00eame par rapport aux cat\u00e9gories 1 et 2, n\u00e9cessit\u00e9 de tout planifier \u00e0 l'avance et de prendre en compte chaque d\u00e9tail.<\/p>\n

La plupart des utilisateurs choisissent l'option un, puis passent progressivement \u00e0 l'option deux. Et finalement, les plus tenaces atteignent l'option 3. <\/p>\n

Mais il existe une option que l'on pourrait appeler un syst\u00e8me distribu\u00e9 : chaque appareil sera \u00e0 la fois un serveur et un client. En essence, c'est une tentative de combiner l'option 1 et l'option 2. Prendre tous leurs avantages et exclure les inconv\u00e9nients, trouver le juste milieu. <\/p>\n

Certaines personnes pourraient dire qu'une telle option a d\u00e9j\u00e0 \u00e9t\u00e9 d\u00e9velopp\u00e9e. Mais ces solutions sont \u00e9troites; elles s'adressent \u00e0 des personnes ayant des comp\u00e9tences en programmation. Notre objectif est d'abaisser le seuil d'entr\u00e9e dans de tels syst\u00e8mes distribu\u00e9s, tant en termes d'appareils finaux qu'en int\u00e9gration des dispositifs existants dans notre syst\u00e8me. Dans le cas d'un thermostat, l'utilisateur retire simplement son ancien thermostat, installe un intelligent et connecte les capteurs qu'il poss\u00e8de. Sans aucune action suppl\u00e9mentaire.<\/p>\n

Consid\u00e9rons l'int\u00e9gration dans notre syst\u00e8me \u00e0 titre d'exemple. <\/p>\n

Imaginons que notre r\u00e9seau comporte 8 modules Sonoff. Certains utilisateurs se contenteront d\u2019un contr\u00f4le via le cloud Sonoff (cat\u00e9gorie 1). D'autres utiliseront un firmware tiers et passeront progressivement \u00e0 la cat\u00e9gorie 2. La majorit\u00e9 des firmwares tiers fonctionnent selon le m\u00eame principe : transmission des donn\u00e9es \u00e0 un serveur MQTT. OpenHub, Majordomo ou tout autre service ont un objectif commun : regrouper des appareils disparates dans un espace d'information unifi\u00e9, situ\u00e9 soit sur Internet, soit sur un r\u00e9seau local. Par cons\u00e9quent, la pr\u00e9sence d'un serveur est indispensable. D'o\u00f9 d\u00e9coule le principal probl\u00e8me \u2013 en cas de panne du serveur, tout le syst\u00e8me cesse de fonctionner de mani\u00e8re autonome. Pour \u00e9viter cela, les syst\u00e8mes se complexifient, des m\u00e9thodes de contr\u00f4le manuelles sont ajout\u00e9es pour dupliquer l'automatisation en cas de d\u00e9faillance du serveur. <\/p>\n

Nous avons opt\u00e9 pour une autre voie, o\u00f9 chaque appareil est autonome. Ainsi, le serveur ne joue pas un r\u00f4le crucial, mais sert seulement \u00e0 \u00e9largir les fonctionnalit\u00e9s.<\/p>\n

Revenons \u00e0 l'exp\u00e9rience de pens\u00e9e. Prenons \u00e0 nouveau ces m\u00eames 8 modules Sonoff et installons-y le firmware Lytko. Toutes les firmwares Lytko comportent la fonction SSDP<\/a><\/noindex>. SSDP est un protocole r\u00e9seau bas\u00e9 sur un ensemble de protocoles Internet, servant \u00e0 annoncer et \u00e0 d\u00e9couvrir des services r\u00e9seau. La r\u00e9ponse \u00e0 une requ\u00eate peut \u00eatre standard ou \u00e9tendue. Nous avons int\u00e9gr\u00e9 dans cette r\u00e9ponse, en plus des fonctions standard, la cr\u00e9ation d'une liste des appareils sur le r\u00e9seau. De cette fa\u00e7on, les appareils se d\u00e9couvrent mutuellement, et chacun d'eux disposera d'une telle liste. Exemple de liste SSDP :<\/p>\n

"ssdpList": \n\t{\n\t\t"id": 94967291,  \n\t\t"ip": "192.168.x.x",\n                "type": "thermostat"\n\t}, \n\t{\n\t\t"id": 94967282,\n\t\t"ip": "192.168.x.x",\n                "type": "thermostat"\n\t}<\/code><\/pre>\n
\nComme indiqu\u00e9 dans l'exemple, la liste comprend les identifiants des appareils, l'adresse IP dans le r\u00e9seau, le type de module (dans notre cas, un thermostat bas\u00e9 sur Sonoff). Cette liste est mise \u00e0 jour toutes les deux minutes (ce d\u00e9lai est suffisant pour r\u00e9agir aux changements dynamiques du nombre d'appareils dans le r\u00e9seau). Ainsi, nous suivons l'ajout, la modification et la d\u00e9sactivation des appareils sans aucune action de l'utilisateur. Cette liste est envoy\u00e9e au navigateur ou \u00e0 l'application mobile, et le script g\u00e9n\u00e8re lui-m\u00eame la page avec le nombre de blocs sp\u00e9cifi\u00e9. Chaque bloc correspond \u00e0 un appareil\/senseur\/contr\u00f4leur. Visuellement, la liste ressemble \u00e0 ceci :<\/p>\n
\"Lytko
\n
\nMais si des capteurs radio suppl\u00e9mentaires sont connect\u00e9s au esp8266\/esp32 via cc2530 (ZigBee) ou nrf24 (MySensors) ? <\/p>\n
\u00c0 propos des projets<\/h3>\n
\nDivers syst\u00e8mes distribu\u00e9s sont pr\u00e9sents sur le march\u00e9. Notre syst\u00e8me permet de s'int\u00e9grer avec les plus populaires. <\/p>\n
Voici quelques projets qui essaient d'am\u00e9liorer la situation d'incompatibilit\u00e9 entre diff\u00e9rents fabricants. Par exemple, SLS Gateway<\/a><\/noindex>, MySensors <\/a><\/noindex> ou ZESP32<\/a><\/noindex>. ZigBee2MQTT <\/a><\/noindex> li\u00e9 \u00e0 un serveur MQTT, il ne convient donc pas comme exemple. <\/p>\n
Une des impl\u00e9mentations de MySensors est une passerelle bas\u00e9e sur l'ESP8266. Les autres exemples sont bas\u00e9s sur l'ESP32. Dans ceux-ci, nous pouvons int\u00e9grer notre principe de d\u00e9tection et de cr\u00e9ation de la liste des appareils. <\/p>\n
Faisons une autre exp\u00e9rience mentale. Nous avons une passerelle ZESP32 ou SLS Gateway ou MySensors. Comment peut-on les unir dans un espace d'information commun ? Aux fonctions standard de ces passerelles, nous ajouterons une biblioth\u00e8que pour le protocole SSDP. Lorsqu'on interroge ce contr\u00f4leur par SSDP, il ajoutera \u00e0 la r\u00e9ponse standard la liste des appareils qui lui sont connect\u00e9s. Sur la base de ces informations, le navigateur g\u00e9n\u00e9rera la page. En g\u00e9n\u00e9ral, cela ressemblera \u00e0 ceci :<\/p>\n
\"Lytko
\nInterface web<\/i><\/p>\n
\"Lytko
\nApplication PWA<\/i><\/p>\n
"ssdpList": \n{\n   "id": 94967291, \/\/ identifiant unique de l'appareil\n   "ip": "192.168.x.x", \/\/ adresse IP dans le r\u00e9seau\n   "type": "thermostat" \/\/ type d'appareil\n},\n{\n   "id": 94967292,\n   "ip": "192.168.x.x",\n   "type": "thermostat"\n},\n{\n   "id": 94967293,\n   "ip": "192.168.x.x",\n   "type": "thermostat"\n},\n{  \n   "id": 13587532, \n   "type": "switch"  \n},\n{  \n   "id": 98412557, \n   "type": "smoke"\n},\n{  \n   "id": 57995113, \n   "type": "contact_sensor"\n},\n{  \n   "id": 74123668,\n   "type": "temperature_humidity_pressure_sensor"\n},\n{\n    "id": 74621883, \n    "type": "temperature_humidity_sensor"\n}\n<\/code><\/pre>\n
\nL'exemple montre que les appareils sont ajout\u00e9s ind\u00e9pendamment les uns des autres. Trois thermostats sont connect\u00e9s avec leurs propres adresses IP et cinq capteurs diff\u00e9rents avec des ID uniques. Si un capteur est connect\u00e9 au r\u00e9seau Wi-Fi, il aura sa propre adresse IP ; s'il est connect\u00e9 \u00e0 une passerelle, l'adresse IP de l'appareil sera celle de la passerelle.<\/p>\n
Nous utilisons WebSocket pour communiquer avec les appareils. Cela permet de r\u00e9duire au minimum l'utilisation des ressources par rapport aux requ\u00eates GET et d'obtenir des informations dynamiquement lors d'une connexion ou d'un changement. <\/p>\n
Les donn\u00e9es sont directement prises de l'appareil auquel appartient le bloc, sans passer par le serveur. Ainsi, en cas de d\u00e9faillance de l'un des appareils, le syst\u00e8me continue de fonctionner. Sur l'interface web, seul l'appareil manquant n'est pas affich\u00e9. Toutefois, un signal de disparition sera envoy\u00e9 sous forme de notification dans l'application de l'utilisateur, si n\u00e9cessaire. <\/p>\n
La premi\u00e8re tentative de mise en \u0153uvre de cette approche fut une application PWA. Cela permet de stocker la base des blocs sur l'appareil de l'utilisateur et de ne demander que les donn\u00e9es n\u00e9cessaires. Cependant, en raison des particularit\u00e9s de la structure, cette option est incompl\u00e8te. Il ne reste donc qu'une solution : une application native pour Android et iOS, qui est actuellement en d\u00e9veloppement actif. Par d\u00e9faut, l'application fonctionnera uniquement sur le r\u00e9seau interne. Si n\u00e9cessaire, tout peut \u00eatre transf\u00e9r\u00e9 vers un contr\u00f4le externe. Ainsi, lorsque l'utilisateur quitte le r\u00e9seau local, l'application passe automatiquement au cloud. <\/p>\n
Le contr\u00f4le externe consiste en une duplication compl\u00e8te de la page. Lors de l'activation de la page, l'utilisateur peut se connecter au serveur et g\u00e9rer les appareils via son tableau de bord. Ainsi, le serveur \u00e9largit les fonctionnalit\u00e9s, permettant de g\u00e9rer les appareils depuis l'ext\u00e9rieur de la maison et de ne pas \u00eatre li\u00e9 \u00e0 la redirection de ports ou \u00e0 une adresse IP d\u00e9di\u00e9e.<\/p>\n
Ainsi, l'option d\u00e9crite ci-dessus est d\u00e9pourvue des inconv\u00e9nients de l'approche serveur et pr\u00e9sente plusieurs avantages en termes de flexibilit\u00e9 pour connecter de nouveaux appareils.<\/p>\n
\u00c0 propos du thermostat<\/h3>\n
\nExaminons le syst\u00e8me de gestion \u00e0 travers l'exemple de notre thermostat.<\/p>\n
Il est pr\u00e9vu :<\/p>\n
    \n
  1. R\u00e9gulation de la temp\u00e9rature de chaque thermostat (affich\u00e9e sous la forme d'un bloc s\u00e9par\u00e9) ;<\/li>\n
  2. Configuration d'un emploi du temps de fonctionnement du thermostat (matin, jour, soir, nuit) ;<\/li>\n
  3. Choix du r\u00e9seau Wi-Fi et connexion de l'appareil \u00e0 celui-ci ;<\/li>\n
  4. Mise \u00e0 jour de l'appareil 'par voie a\u00e9rienne' ;<\/li>\n
  5. Configuration de MQTT ;<\/li>\n
  6. Configuration du r\u00e9seau auquel l'appareil est connect\u00e9.<\/li>\n<\/ol>\n
    \n\"Lytko
    \n
    \nEn plus de la gestion via une interface web, nous avons pr\u00e9vu un contr\u00f4le classique \u2014 par des pressions sur l'\u00e9cran. Il est \u00e9quip\u00e9 d'un \u00e9cran Nextion NX3224T024 de 2,4 pouces. Nous avons choisi celui-ci en raison de la facilit\u00e9 d'utilisation de l'appareil. Cependant, un \u00e9cran bas\u00e9 sur STM32 est en cours de d\u00e9veloppement. Ses fonctionnalit\u00e9s ne sont pas inf\u00e9rieures \u00e0 celles du Nextion, mais son co\u00fbt sera moins \u00e9lev\u00e9, ce qui aura un impact positif sur le prix final de l'appareil.<\/p>\n
    \"Lytko
    \n
    \nComme tout \u00e9cran de thermostat respectueux, notre Nextion sait :<\/p>\n