Il y a quelque temps, nous vous avons présenté un
thermostat intelligent . Cet article a été initialement conçu comme une démonstration de son firmware et de son système de contrôle. Mais afin d'expliquer la logique du thermostat et ce que nous avons mis en œuvre, il est nécessaire de décrire l'ensemble du concept.
À propos de l'automatisation
Classiquement, toute l'automatisation peut être divisée en trois catégories:
Catégorie 1 - appareils «intelligents» séparés. Vous obtenez des ampoules, des théières, etc. de différents fabricants. Avantages: chaque appareil élargit les opportunités et augmente le confort. Inconvénients: chaque nouveau fabricant a besoin de sa propre application. Les protocoles d'appareils de différents fabricants ne sont souvent pas compatibles les uns avec les autres.
Catégorie 2 - installation d'un PC à carte unique ou compatible x86. Cela supprime les limitations de la puissance de calcul et MajorDoMo ou toute autre distribution de serveur pour la gestion d'une maison intelligente est installée sur cette machine. Ainsi, les appareils de la plupart des fabricants sont connectés dans un seul espace d'information. C'est-à-dire apparaît votre serveur pour la maison intelligente. Avantages: compatibilité sous un seul centre, qui offre des capacités de gestion avancées. Inconvénients: en cas de panne / panne du serveur, l'ensemble du système revient à l'étape 1, c'est-à-dire se fragmente ou devient inutile.
La catégorie 3 est la version la plus hardcore. Au stade de la réparation, toutes les communications sont établies et tous les systèmes sont dupliqués. Avantages: tout est amené à l'idéal, puis la maison devient vraiment intelligente. Inconvénients: coût extrême par rapport aux catégories 1 et 2, la nécessité de penser avant tout et de prendre en compte chaque petite chose.
La plupart des utilisateurs sélectionnent l'option un, puis passent en toute transparence à l'option deux. Et à l'avenir, l'option de portée la plus persistante 3.
Mais il existe une option que l'on peut appeler un système distribué: chaque appareil individuel sera à la fois un serveur et un client. En fait, c'est une tentative de prendre et de combiner l'option 1 et l'option 2. Prendre tous leurs avantages et éliminer les inconvénients, rattraper le juste milieu.
Peut-être que quelqu'un dira qu'une telle option a déjà été développée. Mais ces décisions sont étroitement ciblées; pour les gens avertis en programmation. Notre objectif est d'abaisser le seuil d'entrée dans de tels systèmes distribués à la fois sous forme d'appareils terminaux et sous forme d'intégration d'appareils existants dans notre système. Dans le cas du thermostat, l'utilisateur retire simplement son ancien thermostat, installe un intelligent et y connecte ses capteurs. Sans aucune action supplémentaire.
Considérons l'intégration dans notre système à l'aide d'un exemple.
Imaginez que nous avons 8 modules Sonoff dans notre réseau. Certains utilisateurs peuvent avoir un contrôle suffisant sur le cloud Sonoff (catégorie 1). Certains utiliseront un firmware tiers et passeront en douceur à la catégorie 2. La majeure partie du firmware tiers fonctionne sur le même principe: le transfert de données vers le serveur MQTT. OpenHub, Majordomo ou tout autre servent le même objectif - pour combiner des appareils disparates dans un seul espace d'informations situé soit sur Internet soit sur un réseau local. Par conséquent, la présence du serveur est obligatoire. De là, le problème principal se pose - lorsque le serveur tombe en panne, le système entier cesse de fonctionner de manière autonome. Pour éviter cela, les systèmes deviennent plus compliqués, des méthodes de contrôle manuel sont ajoutées pour dupliquer l'automatisation en cas de défaillance du serveur.
Nous avons pris un chemin différent, où chaque appareil est autosuffisant. Ainsi, le serveur ne joue pas un rôle décisif, mais étend seulement la fonctionnalité.
Revenons à l'expérience de la pensée. Encore une fois, prenez les mêmes 8 modules Sonoff et installez-y le firmware Lytko. Dans tous les micrologiciels Lytko, la fonction
SSDP est implémentée. SSDP est un protocole réseau basé sur un ensemble de protocoles Internet utilisés pour annoncer et découvrir des services réseau. La réponse à la demande peut être standard ou avancée. En plus des fonctions standard, nous avons inclus dans cette réponse la création d'une liste d'appareils sur le réseau. Ainsi, les appareils eux-mêmes se retrouvent et chacun d'eux aura une telle liste. Exemple de feuille SSDP:
"ssdpList": { "id": 94967291, "ip": "192.168.xx", "type": "thermostat" }, { "id": 94967282, "ip": "192.168.xx", "type": "thermostat" }
Comme vous pouvez le voir dans l'exemple, la liste comprend l'ID de l'appareil, l'adresse IP du réseau, le type de bloc (dans notre cas, un thermostat basé sur Sonoff). Cette liste est mise à jour toutes les deux minutes (cet intervalle est suffisant pour répondre à un changement dynamique du nombre d'appareils sur le réseau). Ainsi, nous suivons l'ajout, la modification et la déconnexion des appareils sans aucune action de l'utilisateur. Cette liste est envoyée à un navigateur ou à une application mobile, et le script lui-même forme une page avec un nombre donné de blocs. Chaque bloc correspond à un appareil / capteur / contrôleur. Visuellement, la liste ressemble à ceci:
Mais si d'autres capteurs radio sont connectés à esp8266 / esp32 via cc2530 (ZigBee) ou nrf24 (MySensors)?
À propos des projets
Il existe différents systèmes distribués sur le marché. Notre système vous permet de vous intégrer aux plus populaires.
Voici les projets qui tentent en quelque sorte de changer la situation avec l'incompatibilité des différents fabricants entre eux. Cela, par exemple,
SLS Gateway ,
MySensors ou
ZESP32 .
ZigBee2MQTT est lié à un serveur MQTT, il ne convient donc pas par exemple.
Une option d'implémentation pour MySensors est une passerelle basée sur ESP8266. D'autres exemples sont sur ESP32. Et en eux, vous pouvez mettre en œuvre notre principe de détection et de création d'une liste d'appareils.
Faisons une autre expérience de pensée. Nous avons une passerelle ZESP32 ou SLS Gateway, ou MySensors. Comment peuvent-ils être combinés dans un seul espace d'information? Nous ajouterons la bibliothèque de protocoles SSDP aux fonctions standard de ces passerelles. Lorsque vous accédez à ce contrôleur via SSDP, il ajoutera à la réponse standard une liste de périphériques qui y sont connectés. Sur la base de ces informations, le navigateur formera une page. En termes généraux, cela ressemblera à ceci:
Interface Web
Application PWA "ssdpList": { "id": 94967291, // "ip": "192.168.xx", // ip "type": "thermostat" // }, { "id": 94967292, "ip": "192.168.xx", "type": "thermostat" }, { "id": 94967293, "ip": "192.168.xx", "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 montre que les appareils sont ajoutés indépendamment les uns des autres. 3 thermostats avec leurs propres adresses IP et 5 capteurs différents avec un identifiant unique sont connectés. Si le capteur est connecté à un réseau Wi-Fi, il aura sa propre adresse IP, s'il est connecté à la passerelle, alors l'adresse IP de l'appareil sera l'adresse IP de la passerelle.
Pour communiquer avec les appareils, nous utilisons WebSocket. Cela vous permet de minimiser le coût des ressources par rapport aux requêtes get et de recevoir des informations de manière dynamique lors de la connexion ou de la modification.
Les données sont prises directement à partir de l'appareil auquel l'unité appartient, sans passer par le serveur. Ainsi, si l'un des périphériques tombe en panne, le système continue de fonctionner. L'interface Web n'affiche pas seulement le périphérique manquant dans la liste. Mais le signal de la perte, si nécessaire, se présentera sous la forme d'une notification dans l'application de l'utilisateur.
La première tentative de mise en œuvre de cette approche a été une application PWA. Cela vous permet de stocker la base de blocs sur l'appareil de l'utilisateur et de demander uniquement les données nécessaires. Mais en raison des particularités de la structure, une telle option est inférieure. Et il n'y a qu'une seule issue: une application native pour Android et IOS, qui est actuellement en développement actif. Par défaut, l'application ne fonctionnera que sur le réseau interne. Si nécessaire, vous pouvez tout transférer vers un contrôle externe. Ainsi, lorsque l'utilisateur quitte le réseau local, l'application bascule automatiquement vers le cloud.
Gestion externe - duplication complète de la page. Lorsque la page est activée, l'utilisateur peut se connecter au serveur et gérer les appareils via un compte personnel. Ainsi, le serveur étend les fonctionnalités, vous permettant de gérer les appareils en dehors de la maison et de ne pas être lié à la redirection de port ou à une adresse IP dédiée.
Ainsi, l'option ci-dessus est exempte des inconvénients de l'approche serveur, et présente également plusieurs avantages sous la forme de la flexibilité de connexion de nouveaux appareils.
À propos du thermostat
Prenons l'exemple d'un système de contrôle utilisant notre thermostat.
Fourni par:
- Contrôle de la température de chaque thermostat (affiché comme une unité distincte);
- Réglage de l'horaire du thermostat (matin, jour, soir, nuit);
- Choisir un réseau Wi-Fi et y connecter un appareil;
- Mise à jour de l'appareil "over the air";
- Configurer MQTT;
- Configurez le réseau auquel l'appareil est connecté.
En plus de la gestion via l'interface Web, ils ont prévu la classique - en appuyant sur l'écran. À bord se trouve le moniteur 2,4 pouces Nextion NX3224T024. Le choix est tombé sur lui en raison de la simplicité de travail avec l'appareil. Mais en cours de développement est son propre moniteur basé sur STM32. Sa fonctionnalité n'est pas pire que celle de Nextion, mais elle coûtera moins, ce qui affectera positivement le prix final de l'appareil.
Comme tout écran de thermostat qui se respecte, notre Nextion peut:
- régler la température nécessaire à l'utilisateur (à l'aide des boutons à droite);
- activer et désactiver le mode de fonctionnement programmé (bouton H);
- affichage du fonctionnement du relais (flèche à gauche);
- a une protection contre les enfants (les clics physiques sont bloqués jusqu'à ce que le verrou soit retiré);
- affiche la force du signal WiFi.
De plus, en utilisant le moniteur, vous pouvez:
- sélectionner le type de capteur installé par l'utilisateur;
- gérer la fonction de protection de l'enfance;
- mettre à jour le firmware.
En cliquant sur la barre WiFi, l'utilisateur trouvera des informations sur le réseau connecté. Le code QR est utilisé pour coupler l'appareil dans le firmware HomeKit.
Démo de travail avec l'écran:
Nous avons développé une
page de démonstration avec trois thermostats connectés.
Vous demandez: «Quelle est la particularité de votre thermostat?» Il existe maintenant de nombreux thermostats sur le marché avec fonction Wi-Fi, travail programmé, contrôle tactile. Et les passionnés ont écrit des modules pour interagir avec les systèmes de maison intelligente les plus populaires (Majordomo, HomeAssistant, etc.).
Notre thermostat est compatible avec de tels systèmes et possède tout ce qui précède. Mais la particularité est que le thermostat est constamment amélioré, grâce à la flexibilité du système. Avec chaque mise à jour, la fonctionnalité s'élargit. À la façon standard de gérer le système (selon le calendrier), nous ajouterons un système adaptatif. L'application vous permet d'obtenir la géolocalisation de l'utilisateur. Pour cette raison, le système changera dynamiquement les modes de fonctionnement en fonction de son emplacement. Et le module météo vous permettra de vous adapter aux conditions météorologiques.
Et l'extensibilité. N'importe qui peut remplacer le thermostat habituel installé avec lui par le nôtre. Avec un effort minimal. Nous avons sélectionné les 5 capteurs les plus populaires du marché et ajouté leur support. Mais même dans le cas de caractéristiques de capteur exclusives, l'utilisateur pourra le connecter à notre thermostat. Pour ce faire, vous devez calibrer le thermostat pour qu'il fonctionne avec un capteur spécifique. Nous vous fournirons des instructions.
Lors de la connexion d'un thermostat ou de tout autre appareil, il apparaît simultanément partout: à la fois dans l'interface Web et dans l'application PWA. L'ajout d'un appareil est automatique: il suffit de le connecter à un réseau Wi-Fi.
Notre système n'a pas besoin de serveur, et en cas de panne il ne se transforme pas en citrouille. Même si l'un des composants tombe en panne, le système ne démarre pas selon le scénario d'urgence. Contrôleurs, capteurs, appareils - chaque élément est à la fois un serveur et un client, il est donc complètement autonome.
Pour les intéressés, nos réseaux sociaux:
Telegram ,
Instagram ,
Telegram News ,
VK ,
Facebook .
Courriel: shop@lytko.com
PS, nous ne recommandons pas d'abandonner le serveur. Nous prenons également en charge le serveur MQTT et avons notre propre cloud. Notre objectif est d'amener la stabilité et la fiabilité du système à un tout nouveau niveau. Pour que le serveur ne soit pas un point faible, mais complète les fonctionnalités et rend le système plus pratique.