Il y a quelque temps nous vous avons présenté . Cet article était initialement destiné à une démonstration de son micrologiciel 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 dans son ensemble.
À propos de l'automatisation
Classiquement, toute automatisation peut être divisée en trois catégories :
Catégorie 1 — des appareils « intelligents » séparés. Vous achetez des ampoules, des théières, etc. auprès de différents fabricants. Avantages : Chaque appareil étend les capacités et augmente le confort. Inconvénients : Chaque nouveau fabricant nécessite sa propre application. Les protocoles des appareils de différents fabricants ne sont souvent pas compatibles entre eux.
Catégorie 2 — installation d'un PC monocarte ou compatible x86. Cela supprime les restrictions sur la puissance de calcul, et MajorDoMo ou toute autre distribution de serveur pour gérer 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'informations. Ceux. votre propre serveur pour une maison intelligente apparaît. Avantages : compatibilité sous un centre unique, qui offre des capacités de gestion améliorées. Inconvénients : si le serveur tombe en panne, tout le système revient à l'étape 1, c'est-à-dire se fragmente ou devient inutile.
Catégorie 3 - l'option 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 perfectionné et la maison devient alors vraiment intelligente. Inconvénients : extrêmement cher par rapport aux catégories 1 et 2, nécessité de tout réfléchir à l'avance et de prendre en compte chaque petit détail.
La plupart des utilisateurs choisissent la première option, puis passent facilement à la deuxième option. Et puis les plus persistants atteignent l’option 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. Il s’agit essentiellement d’une tentative de prendre et de combiner l’option 1 et l’option 2. Prendre tous leurs avantages et éliminer les inconvénients, pour trouver 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 personnes averties en programmation. Notre objectif est de réduire les barrières à l'entrée dans de tels systèmes distribués, à la fois sous la forme de dispositifs finaux et sous la forme de l'intégration de dispositifs existants dans notre système. Dans le cas d'un thermostat, l'utilisateur retire simplement son ancien thermostat, en installe un intelligent et y connecte ses capteurs existants. Sans aucune étape supplémentaire.
Examinons l'intégration dans notre système à l'aide d'un exemple.
Imaginons que nous ayons 8 modules Sonoff sur notre réseau. Pour certains utilisateurs, le contrôle via le cloud Sonoff (catégorie 1) sera suffisant. Certains commenceront à utiliser des firmwares tiers et passeront progressivement en catégorie 2. La majeure partie des firmwares tiers fonctionne sur le même principe : transférer des données vers un serveur MQTT. OpenHub, Majordomo ou tout autre n'ont qu'un seul objectif : réunir des appareils disparates en un seul espace d'informations situé soit sur Internet, soit sur un réseau local. La présence d’un Serveur est donc obligatoire. C'est là que surgit le principal problème : si le serveur tombe en panne, l'ensemble du système cesse de fonctionner de manière autonome. Pour éviter cela, les systèmes deviennent plus complexes, des méthodes de contrôle manuel sont ajoutées qui dupliquent l'automatisation en cas de panne du serveur.
Nous avons emprunté une voie différente, où chaque appareil est autonome. Ainsi, le serveur ne joue pas un rôle décisif, mais étend uniquement les fonctionnalités.
Revenons à l'expérience de pensée. Reprenons les mêmes 8 modules Sonoff et installons-y le firmware Lytko. Tous les firmwares Lytko ont la fonction . SSDP est un protocole réseau basé sur la suite de protocoles Internet pour la publicité et la découverte des services réseau. La réponse à une demande peut être soit standard, soit étendue. En plus des fonctions standards, 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 fiche SSDP :
"ssdpList":
{
"id": 94967291,
"ip": "192.168.x.x",
"type": "thermostat"
},
{
"id": 94967282,
"ip": "192.168.x.x",
"type": "thermostat"
}Comme vous pouvez le voir dans l'exemple, la liste comprend les identifiants des appareils, l'adresse IP sur le réseau, le type d'unité (dans notre cas, un thermostat basé sur Sonoff). Cette liste est mise à jour toutes les deux minutes (cette période est suffisante pour répondre aux changements dynamiques du nombre d'appareils sur le réseau). De cette façon, nous suivons les appareils ajoutés, modifiés et désactivés sans aucune action de l'utilisateur. Cette liste est envoyée au navigateur ou à l'application mobile, et le script lui-même génère une page avec un nombre de blocs donné. Chaque bloc correspond à un appareil/capteur/contrôleur. Visuellement, la liste ressemble à ceci :
Mais que se passe-t-il si d'autres capteurs radio sont connectés à l'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.
Vous trouverez ci-dessous des projets qui tentent d'une manière ou d'une autre de changer la situation en raison de l'incompatibilité des différents fabricants entre eux. Il s'agit par exemple de , ou . est lié à un serveur MQTT, il ne convient donc pas à l'exemple.
Une option pour implémenter MySensors est une passerelle basée sur l'ESP8266. Le reste des exemples sont sur ESP32. Et vous pouvez y mettre en œuvre notre principe de fonctionnement 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 une passerelle SLS, ou MySensors. Comment les combiner dans un seul espace d’information ? Nous ajouterons la bibliothèque de protocoles SSDP aux fonctions standards de ces passerelles. Lors de l'accès à ce contrôleur via SSDP, il ajoutera une liste des appareils qui y sont connectés à la réponse standard. Sur la base de ces informations, le navigateur générera une page. En général, cela ressemblera à ceci :
interface Web
Application 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 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 des identifiants uniques sont connectés. Si le capteur est connecté à un réseau Wi-Fi, il aura sa propre IP ; s’il est connecté à une passerelle, alors l’adresse IP de l’appareil sera l’adresse IP de la passerelle.
Nous utilisons WebSocket pour communiquer avec les appareils. Cela vous permet de minimiser les coûts de ressources par rapport à l'obtention de demandes et d'obtenir des informations de manière dynamique lors de la connexion ou du changement.
Les données sont extraites directement de l'appareil auquel appartient le bloc, en contournant le serveur. Ainsi, si l'un des appareils tombe en panne, le système continue de fonctionner. L'interface Web n'affiche tout simplement pas le périphérique manquant dans la liste. Mais un signal de perte, si nécessaire, viendra sous la forme d’une notification dans l’application de l’utilisateur.
La première tentative de mise en œuvre de cette approche était une application PWA. Cela vous permet de stocker une 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, cette option est incomplète. Et il n'y a qu'une seule issue : une application native pour Android et IOS, 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.
Contrôle 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 son compte personnel. Ainsi, le serveur étend ses fonctionnalités, vous permettant de gérer des 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 ne présente pas les inconvénients de l'approche serveur et présente également un certain nombre d'avantages sous forme de flexibilité dans la connexion de nouveaux appareils.
À propos du thermostat
Regardons le système de contrôle en utilisant notre thermostat comme exemple.
Fourni:
- Contrôle de la température pour chaque thermostat (affiché sous forme de bloc séparé) ;
- Réglage de l'horaire de fonctionnement du thermostat (matin, après-midi, soir, nuit) ;
- Sélectionner un réseau Wi-Fi et y connecter un appareil ;
- Mettre à jour l'appareil « par liaison radio » ;
- Configuration de MQTT ;
- Configurez le réseau auquel l'appareil est connecté.
En plus du contrôle via l'interface Web, nous avons fourni le contrôle classique - en cliquant sur l'écran. Il y a un moniteur Nextion NX3224T024 de 2.4 pouces à bord. Le choix s'est porté sur lui en raison de la facilité de travail avec l'appareil. Mais nous développons notre propre moniteur basé sur STM32. Sa fonctionnalité n'est pas pire que celle de Nextion, mais elle coûtera moins cher, ce qui aura un impact positif sur le prix final de l'appareil.
Comme tout écran de thermostat qui se respecte, notre Nextion peut :
- régler la température souhaitée par l'utilisateur (à l'aide des boutons de droite) ;
- activer et désactiver le mode de fonctionnement programmé (bouton H) ;
- afficher le fonctionnement du relais (flèche à gauche) ;
- dispose d'une protection enfants (les clics physiques sont bloqués jusqu'à ce que le verrou soit retiré) ;
- affiche la force du signal WiFi.
De plus, à l'aide du moniteur, vous pouvez :
- sélectionner le type de capteur installé par l'utilisateur ;
- gérer la fonction de verrouillage enfant ;
- mettre à jour le firmware.
En cliquant sur la barre WiFi, l'utilisateur découvrira 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é avec trois thermostats connectés.
Vous pourriez demander : « Quelle est la particularité de votre thermostat ? » Il existe désormais sur le marché de nombreux thermostats dotés d'une fonction Wi-Fi, d'un fonctionnement programmé et d'une commande 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'étendra. A la méthode standard de gestion du système (selon un planning), nous en ajouterons une adaptative. L'application permet d'obtenir la géolocalisation de l'utilisateur. Grâce à cela, le système changera dynamiquement de mode 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é. Tout le monde peut remplacer son thermostat conventionnel existant par le nôtre. Avec un minimum d'effort. Nous avons sélectionné 5 des capteurs les plus populaires du marché et ajouté leur prise en charge. Mais même si le capteur possède des caractéristiques exclusives, l'utilisateur pourra le connecter à notre thermostat. Pour ce faire, vous devrez calibrer le thermostat pour qu'il fonctionne avec un capteur spécifique. Nous fournirons des instructions.
Lors de la connexion d'un thermostat ou de tout autre appareil, il apparaît simultanément partout : aussi bien dans l'interface web que dans l'application PWA. L'ajout d'un appareil s'effectue automatiquement : il vous suffit de le connecter au réseau Wi-Fi.
Notre système n'a pas besoin de serveur, et s'il tombe en panne, il ne se transforme pas en citrouille. Même si l'un des composants tombe en panne, le système ne commence pas à fonctionner en cas d'urgence. Contrôleurs, capteurs, appareils, chaque élément est à la fois serveur et client, donc totalement autonome.
Pour les personnes intéressées, nos réseaux sociaux : , , , , .
E-mail: [email protected]
PS Nous ne vous encourageons pas à abandonner le serveur. Nous prenons également en charge un serveur MQTT et disposons de 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 la fonctionnalité et rend le système plus pratique.
Source: habr.com