Il y a quelque temps, nous vous avons présenté . Cet article était initialement prévu comme une démonstration de son firmware et de son système de gestion. Mais pour expliquer la logique de fonctionnement du thermostat et ce que nous avons mis en œuvre, il est nécessaire de décrire l'ensemble du concept.
Concernant l'automatisation
On peut classer l'automatisation en trois catégories :
Catégorie 1 — dispositifs « intelligents » individuels. Vous achetez des ampoules, des bouilloires, etc., auprès de différents fabricants. Avantages : chaque appareil étend les fonctionnalités et améliore le confort. Inconvénients : chaque nouveau fabricant nécessite sa propre application. Les protocoles des appareils de différents fabricants sont souvent incompatibles entre eux.
Catégorie 2 — installation d'un PC monocarte ou compatible x86. Cela élimine 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-à-dire qu'un serveur pour la maison intelligente est créé. Avantages : compatibilité sous un centre unique, ce qui offre des possibilités étendues de gestion. Inconvénients : en cas de panne du serveur, tout le système revient à l'état 1, c'est-à-dire qu'il devient disjoint ou inutilisable.
Catégorie 3 — l'option la plus hardcore. Lors de la rénovation, toutes les communications sont intégrées et tous les systèmes sont doublés. Avantages : tout est poussé à la perfection et la maison devient véritablement intelligente. Inconvénients : coût extrême par rapport aux catégories 1 et 2, nécessité de tout planifier à l'avance et de prendre en compte chaque détail.
La plupart des utilisateurs choisissent l'option un, puis passent progressivement à l'option deux. Et finalement, les plus tenaces atteignent l'option 3.
Mais il existe une option que l'on pourrait appeler un système distribué : chaque appareil sera à 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énients, trouver le juste milieu.
Certaines personnes pourraient dire qu'une telle option a déjà été développée. Mais ces solutions sont étroites; elles s'adressent à des personnes ayant des compétences en programmation. Notre objectif est d'abaisser le seuil d'entrée dans de tels systèmes distribués, tant en termes d'appareils finaux qu'en intégration des dispositifs existants dans notre système. Dans le cas d'un thermostat, l'utilisateur retire simplement son ancien thermostat, installe un intelligent et connecte les capteurs qu'il possède. Sans aucune action supplémentaire.
Considérons l'intégration dans notre système à titre d'exemple.
Imaginons que notre réseau comporte 8 modules Sonoff. Certains utilisateurs se contenteront d’un contrôle via le cloud Sonoff (catégorie 1). D'autres utiliseront un firmware tiers et passeront progressivement à la catégorie 2. La majorité des firmwares tiers fonctionnent selon le même principe : transmission des données à un serveur MQTT. OpenHub, Majordomo ou tout autre service ont un objectif commun : regrouper des appareils disparates dans un espace d'information unifié, situé soit sur Internet, soit sur un réseau local. Par conséquent, la présence d'un serveur est indispensable. D'où découle le principal problème – en cas de panne du serveur, tout le système cesse de fonctionner de manière autonome. Pour éviter cela, les systèmes se complexifient, des méthodes de contrôle manuelles sont ajoutées pour dupliquer l'automatisation en cas de défaillance du serveur.
Nous avons opté pour une autre voie, où chaque appareil est autonome. Ainsi, le serveur ne joue pas un rôle crucial, mais sert seulement à élargir les fonctionnalités.
Revenons à l'expérience de pensée. Prenons à nouveau ces mêmes 8 modules Sonoff et installons-y le firmware Lytko. Toutes les firmwares Lytko comportent la fonction . SSDP est un protocole réseau basé sur un ensemble de protocoles Internet, servant à annoncer et à découvrir des services réseau. La réponse à une requête peut être standard ou étendue. Nous avons intégré dans cette réponse, en plus des fonctions standard, la création d'une liste des appareils sur le réseau. De cette façon, les appareils se découvrent mutuellement, et chacun d'eux disposera d'une telle liste. Exemple de liste SSDP :
"ssdpList":
{
"id": 94967291,
"ip": "192.168.x.x",
"type": "thermostat"
},
{
"id": 94967282,
"ip": "192.168.x.x",
"type": "thermostat"
}Comme indiqué dans l'exemple, la liste comprend les identifiants des appareils, l'adresse IP dans le réseau, le type de module (dans notre cas, un thermostat basé sur Sonoff). Cette liste est mise à jour toutes les deux minutes (ce délai est suffisant pour réagir aux changements dynamiques du nombre d'appareils dans le réseau). Ainsi, nous suivons l'ajout, la modification et la désactivation des appareils sans aucune action de l'utilisateur. Cette liste est envoyée au navigateur ou à l'application mobile, et le script génère lui-même la page avec le nombre de blocs spécifié. Chaque bloc correspond à un appareil/senseur/contrôleur. Visuellement, la liste ressemble à ceci :
Mais si des capteurs radio supplémentaires sont connectés au esp8266/esp32 via cc2530 (ZigBee) ou nrf24 (MySensors) ?
À propos des projets
Divers systèmes distribués sont présents sur le marché. Notre système permet de s'intégrer avec les plus populaires.
Voici quelques projets qui essaient d'améliorer la situation d'incompatibilité entre différents fabricants. Par exemple, , ou . lié à un serveur MQTT, il ne convient donc pas comme exemple.
Une des implémentations de MySensors est une passerelle basée sur l'ESP8266. Les autres exemples sont basés sur l'ESP32. Dans ceux-ci, nous pouvons intégrer notre principe de détection et de création de la liste des appareils.
Faisons une autre expérience 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èque pour le protocole SSDP. Lorsqu'on interroge ce contrôleur par SSDP, il ajoutera à la réponse standard la liste des appareils qui lui sont connectés. Sur la base de ces informations, le navigateur générera la page. En général, cela ressemblera à ceci :
Interface web
Application PWA
"ssdpList":
{
"id": 94967291, // identifiant unique de l'appareil
"ip": "192.168.x.x", // adresse IP dans le réseau
"type": "thermostat" // type d'appareil
},
{
"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. Trois thermostats sont connectés avec leurs propres adresses IP et cinq capteurs différents avec des ID uniques. Si un capteur est connecté au réseau Wi-Fi, il aura sa propre adresse IP ; s'il est connecté à une passerelle, l'adresse IP de l'appareil sera celle de la passerelle.
Nous utilisons WebSocket pour communiquer avec les appareils. Cela permet de réduire au minimum l'utilisation des ressources par rapport aux requêtes GET et d'obtenir des informations dynamiquement lors d'une connexion ou d'un changement.
Les données sont directement prises de l'appareil auquel appartient le bloc, sans passer par le serveur. Ainsi, en cas de défaillance de l'un des appareils, le système continue de fonctionner. Sur l'interface web, seul l'appareil manquant n'est pas affiché. Toutefois, un signal de disparition sera envoyé sous forme de notification dans l'application de l'utilisateur, si nécessaire.
La première tentative de mise en œuvre 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ées nécessaires. Cependant, en raison des particularités de la structure, cette option est incomplète. Il ne reste donc qu'une solution : une application native pour Android et iOS, qui est actuellement en développement actif. Par défaut, l'application fonctionnera uniquement sur le réseau interne. Si nécessaire, tout peut être transféré vers un contrôle externe. Ainsi, lorsque l'utilisateur quitte le réseau local, l'application passe automatiquement au cloud.
Le contrôle externe consiste en une duplication complète de la page. Lors de l'activation de la page, l'utilisateur peut se connecter au serveur et gérer les appareils via son tableau de bord. Ainsi, le serveur élargit les fonctionnalités, permettant de gérer les appareils depuis l'extérieur de la maison et de ne pas être lié à la redirection de ports ou à une adresse IP dédiée.
Ainsi, l'option décrite ci-dessus est dépourvue des inconvénients de l'approche serveur et présente plusieurs avantages en termes de flexibilité pour connecter de nouveaux appareils.
À propos du thermostat
Examinons le système de gestion à travers l'exemple de notre thermostat.
Il est prévu :
- Régulation de la température de chaque thermostat (affichée sous la forme d'un bloc séparé) ;
- Configuration d'un emploi du temps de fonctionnement du thermostat (matin, jour, soir, nuit) ;
- Choix du réseau Wi-Fi et connexion de l'appareil à celui-ci ;
- Mise à jour de l'appareil 'par voie aérienne' ;
- Configuration de MQTT ;
- Configuration du réseau auquel l'appareil est connecté.
En plus de la gestion via une interface web, nous avons prévu un contrôle classique — par des pressions sur l'écran. Il est équipé d'un écran Nextion NX3224T024 de 2,4 pouces. Nous avons choisi celui-ci en raison de la facilité d'utilisation de l'appareil. Cependant, un écran basé sur STM32 est en cours de développement. Ses fonctionnalités ne sont pas inférieures à celles du Nextion, mais son coût sera moins élevé, ce qui aura un impact positif sur le prix final de l'appareil.
Comme tout écran de thermostat respectueux, notre Nextion sait :
- régler la température souhaitée par l'utilisateur (avec les boutons de droite);
- activer et désactiver le mode de fonctionnement selon un emploi du temps (bouton N);
- afficher le fonctionnement du relais (flèche à gauche);
- avoir une protection pour enfants (les pressions physiques sont bloquées tant que le verrou n'est pas désactivé);
- afficher le niveau du signal WiFi.
De plus, grâce à l'écran, on peut :
- choisir le type de capteur installé par l'utilisateur;
- gérer la fonction de protection pour enfants;
- mettre à jour le firmware.
En cliquant sur la barre WiFi, l'utilisateur peut obtenir des informations sur le réseau connecté. Le code QR est utilisé pour appairer l'appareil dans le firmware HomeKit.
Démonstration de fonctionnement avec l'écran :
Nous avons développé avec trois thermostats connectés.
Vous vous demandez : « Quelle est la particularité de votre thermostat ? » Actuellement, il existe de nombreux thermostats sur le marché avec fonction Wi-Fi, fonctionnement selon un emploi du temps, et contrôle tactile. Et des passionnés ont développé des modules pour interagir avec la plupart des systèmes de maison intelligente populaires (Majordomo, HomeAssistant, etc.).
Notre thermostat est compatible avec ces systèmes et possède toutes les fonctionnalités énoncées ci-dessus. Mais la particularité est que le thermostat est constamment amélioré, grâce à la flexibilité du système. Avec chaque mise à jour, les fonctionnalités seront élargies. Au mode de contrôle standard (selon un emploi du temps), nous ajouterons un mode adaptatif. L'application permet d'obtenir la géolocalisation de l'utilisateur. Grâce à cela, le système changera dynamiquement les modes de fonctionnement en fonction de sa position. Et le module météo permettra de s'adapter aux conditions météorologiques.
Et l'évolutivité. Quiconque peut remplacer le thermostat standard qu'il a par le nôtre, avec un minimum d'efforts. Nous avons sélectionné 5 capteurs parmi les plus populaires sur le marché et ajouté leur prise en charge. Mais même en cas de caractéristiques exclusives du capteur, l'utilisateur peut le connecter à notre thermostat. Pour cela, il sera nécessaire de calibrer le thermostat pour fonctionner avec le capteur spécifique. Nous fournirons les instructions.
En connectant le thermostat ou tout autre appareil, il apparaît simultanément partout : dans l'interface web et dans l'application PWA. L'ajout de l'appareil se fait automatiquement : il suffit de le connecter au réseau Wi-Fi.
Notre système n'a pas besoin de serveur, et en cas de défaillance, il ne se transforme pas en citrouille. Même en cas de défaillance d'un des composants, le système ne commence pas à fonctionner en mode d'urgence. Les contrôleurs, capteurs, dispositifs — chaque élément est à la fois un serveur et un client, et par conséquent complètement autonome.
Pour ceux qui s'intéressent — nos réseaux sociaux : , , , , .
Email : shop@lytko.com
P. S. Nous n'encourageons pas à renoncer au serveur. Nous avons également un support pour un serveur MQTT et un cloud propre. Notre objectif est d'élever la stabilité et la fiabilité du système à un niveau qualitativement supérieur. Pour que le serveur ne soit pas le point faible, mais complète les fonctionnalités et rende le système plus pratique.
Source : habr.com
