Capteur de température et d'humidité WiFi IoT. Partie : 8 IoT, Domotique : 9 étapes

2024 Auteur: John Day | [email protected]. Dernière modifié: 2024-01-30 09:09

Préambule

Cet article documente la robustesse pratique et le développement ultérieur d'un Instructable antérieur: « Pimping » de votre premier appareil WiFi IoT. Partie 4: IoT, Domotique incluant toutes les fonctionnalités logicielles nécessaires pour permettre le déploiement réussi dans un environnement domestique domestique.

introduction

Comme mentionné ci-dessus, cet Instructable décrit le rapprochement d'un exemple IoT antérieur avec une conception de systèmes fiable permettant la gestion réussie de cas d'utilisation pratiques tels que; Perte de puissance catastrophique, panne du courtier MQTT, panne WiFi N/W, reconfiguration du capteur à distance, stratégie de rapport configurable pour réduire le trafic réseau et étalonnage du capteur sur mesure.

Un total de 6 appareils off ont été créés (voir photo 1 ci-dessus) et distribués dans ma maison pour former mon premier réseau de capteurs IoT.

L'Instructable voit également un examen de la convention de dénomination MQTT telle qu'elle est utilisée dans la série initiale IoT Home Automation, cédant la place à une structure plus équilibrée et pratique permettant un débogage plus simple du trafic IoT dans un environnement d'appareils IoT multiples.

Ce qui suit sont les détails de conception complets du capteur IoT, y compris: construction, code source, stratégie de test et configurations OpenHAB.

De quelles pièces ai-je besoin ?

1. 1 sur ESP8266-01,
2. 2 condensateurs électrolytiques 1uF,
3. 3 résistances 10K,
4. 1 résistance 330R,
5. 1 sur 3 mm de diamètre. LED,
6. 1 sur LD1117-33v, 3v3 LDO VReg. (Farnell ici),
7. 1 capteur de température/humidité DHT22,
8. 1 connecteur double 4 voies 0,1 ",
9. 1 boîtier en plastique CAMDENBOSS RX2008/S-5, boîte de rempotage, ABS, 38 mm, 23 mm (Farnell ici),
10. 1 connecteur d'alimentation CC, Fiche, 1 A, 2 mm, Montage sur panneau (Farnell ici),
11. 1 dissipateur thermique TO-220 24,4 °C/W (ici Farnell),
12. Divers gaines thermorétractables (jaune, Ebay ici),
13. Câble plat IDC de différentes longueurs,
14. Composé de dissipateur thermique,
15. Veroboard,
16. Appareil de programmation ESP8266-01. Vois ici; Construction de circuit pratique avec carte à bande, à partir de l'étape 9.

De quel logiciel ai-je besoin ?

1. IDE Arduino 1.6.9
2. Arduino IDE configuré pour programmer l'ESP8266-01. Vois ici; Configuration de l'IDE Arduino pour programmer l'ESP8266-01

De quels outils ai-je besoin ?

1. Fer à souder,
2. Perceuse & mèches diverses,
3. Des dossiers,
4. Scie à métaux,
5. Etau robuste,
6. Pistolet thermique,
7. DMM.

De quelles compétences ai-je besoin ?

1. Une connaissance minimale de l'électronique,
2. Connaissance d'Arduino et de son IDE,
3. Compétences rudimentaires de fabrication (soudage, sciage, limage, perçage etc.),
4. Un peu de patience,
5. Une certaine compréhension de votre réseau domestique.

Sujets couverts

1. Aperçu du circuit
2. Présentation du système logiciel
3. Présentation du logiciel
4. Étalonnage du capteur
5. Convention de nommage des rubriques MQTT
6. Configuration OpenHAB
7. Tester la conception
8. Conclusion
9. Références utilisées

Liens de séries

Vers la partie 7: Study Lights Controller (retravaillé). Partie 7: IoT, Domotique

Vers la partie 9: Contrôleur secteur IoT. Partie 9: IoT, Domotique

Étape 1: Présentation du circuit

L'image 1 ci-dessus montre la conception complète du circuit pour le capteur IoT.

Au cœur de l'appareil IoT se trouve l'ESP8266-01 qui est connecté à un capteur de température/humidité DHT22 via une résistance de rappel de 10K vers GPIO2. Un 5v externe provient d'une alimentation à découpage et alimente l'appareil via une prise de montage sur panneau CC de 2 mm et régulé localement avec un régulateur de tension LDO LD1117-33v, 3v3 monté sur un dissipateur de chaleur externe avec une vis à tête cylindrique bombée BZP M3 et un écrou.

La conception comprend une LED rouge de 3 mm connectée à GPIO0 qui est utilisée pour donner une indication locale de l'état de l'appareil IoT lors du démarrage ou de toute condition d'erreur ultérieure. Il peut également être utilisé pour identifier l'appareil par activation manuelle via l'interface openHAB.

La conception complète s'intègre parfaitement dans une boîte d'empotage en ABS, comme indiqué ci-dessus dans l'image 2, et a été spécialement conçue pour garantir que le capteur est aussi loin que possible du régulateur afin d'éviter toute polarisation due aux effets de chaleur locaux (image 7 ci-dessus).

Le circuit imprimé est une seule pièce de veroboard, découpée en forme et conçue pour s'adapter à l'enceinte (image 3 ci-dessus). Cette carte est fixée en position avec une vis en nylon à tête fraisée M3 et deux écrous qui affleurent le dessous du capteur, lui permettant ainsi de reposer sur une surface plane.

Les photos 4 … 6 montrent différents états de construction.

Étape 2: Présentation du système logiciel

Ce dispositif de détection de température et d'humidité IoT contient six composants logiciels clés, comme illustré à la photo 1 ci-dessus.

SPIFFS

Il s'agit du système de classement Flash SPI intégré et est utilisé pour contenir les informations suivantes (voir photo 2 ci-dessus);

• Icônes et html de la « page d'accueil de la configuration du capteur »: servis par l'appareil IoT lorsqu'il ne parvient pas à se connecter à votre réseau WiFi IoT (généralement en raison d'informations de sécurité incorrectes) et fournit à l'utilisateur un moyen de configurer le capteur à distance sans avoir besoin pour reprogrammer ou télécharger de nouveaux contenus SPIFFS.
• Informations de sécurité: elles contiennent les informations utilisées à la mise sous tension par l'appareil IoT pour se connecter à votre réseau WiFi IoT et à MQTT Broker. Les informations soumises via la 'Page d'accueil de la configuration du capteur' sont écrites dans ce fichier ('secvals.txt').
• Informations d'étalonnage: les informations contenues dans ce fichier (« calvals.txt ») sont utilisées pour étalonner le capteur de température/humidité embarqué si cela s'avère nécessaire. Les constantes d'étalonnage ne peuvent être écrites sur l'appareil IoT que via les commandes MQTT d'un courtier MQTT.

Remarque: Pour configurer initialement l'appareil, voir ici pour plus de détails sur l'utilisation de SPIFFS avec l'IDE Arduino.

Serveur mDNS

Cette fonctionnalité est invoquée lorsque l'appareil IoT n'a pas réussi à se connecter à votre réseau WiFi en tant que station WiFi et est devenu à la place un point d'accès WiFi semblable à un routeur WiFi domestique. Dans le cas d'un tel routeur, vous vous y connectez généralement en saisissant l'adresse IP de quelque chose comme 192.168.1.1 (généralement imprimée sur une étiquette apposée sur la boîte) directement dans la barre d'URL de votre navigateur, après quoi vous recevrez une page de connexion à saisir. le nom d'utilisateur et le mot de passe pour vous permettre de configurer l'appareil.

Pour l'ESP8266 en mode AP (mode point d'accès), l'appareil utilise par défaut l'adresse IP 192.168.4.1, mais avec le serveur mDNS en cours d'exécution, vous n'avez qu'à entrer le nom convivial « SENSORSVR.local » dans la barre d'URL du navigateur pour voir le 'Page d'accueil de la configuration du capteur'.

Client MQTT

Le client MQTT fournit toutes les fonctionnalités nécessaires pour: connectez-vous à votre courtier MQTT de réseau IoT, abonnez-vous aux sujets de votre choix et publiez des charges utiles sur un sujet donné. En bref, il fournit les fonctionnalités de base de l'IoT.

Serveur Web

Comme mentionné ci-dessus, si l'appareil IoT ne parvient pas à se connecter au réseau WiFi dont le SSID, le P/W, etc. est défini dans le fichier d'informations de sécurité contenu dans SPIFFS, l'appareil deviendra un point d'accès. Une fois connecté au réseau WiFi fourni par le point d'accès, la présence d'un serveur Web HTTP vous permet de vous connecter directement à l'appareil et de modifier sa configuration via l'utilisation d'un navigateur Web HTTP. Page' page Web qui est également conservée dans SPIFFS.

Station Wi-Fi

Cette fonctionnalité donne à l'appareil IoT la possibilité de se connecter à un réseau WiFi domestique à l'aide des paramètres du fichier d'informations de sécurité, sans cela, votre appareil IoT ne pourra pas s'abonner/publier sur le courtier MQTT.

Point d'accès Wi-Fi

La possibilité de devenir un point d'accès WiFi est un moyen par lequel l'appareil IoT vous permet de vous y connecter et d'effectuer des modifications de configuration via une station WiFi et un navigateur (comme Safari sur l'iPad d'Apple).

Ce point d'accès diffuse un SSID = "SENSOR" + les 6 derniers chiffres de l'adresse MAC de l'appareil IoT. Le mot de passe de ce réseau fermé est nommé de manière imaginative « MOT DE PASSE »

Étape 3: Présentation du logiciel

PréambulePour compiler avec succès ce code source, vous aurez besoin des bibliothèques supplémentaires suivantes;

PubSubClient.h

• Par: Nick O'Leary
• Objectif: Permet à l'appareil de publier ou de s'abonner à des sujets MQTT avec un courtier donné
• De:

DHT.h

• Par: Adafruit
• Objectif: Bibliothèque pour capteur de température/humidité DHT
• De:

Présentation des codes

Le logiciel utilise la machine à états comme indiqué sur la photo 1 ci-dessus (copie complète de la source ci-dessous). Il y a 5 états principaux comme ci-dessous;

• INIT

  Cet état d'initialisation est le premier état entré après la mise sous tension

• NONCONFIG

  Cet état est entré si après la mise sous tension un fichier secvals.txt invalide ou manquant est détecté

• EN ATTENTE NO

  Cet état est transitoire, entré alors qu'il n'existe pas de connexion réseau WiFi

• EN ATTENTE MQTT

  Cet état est transitoire, entré après qu'une connexion au réseau WiFi a été établie et tant qu'il n'existe aucune connexion à un courtier MQTT sur ce réseau

• ACTIF

  Il s'agit de l'état de fonctionnement normal entré une fois qu'une connexion réseau WiFi et une connexion MQTT Broker ont été établies. C'est pendant cet état que la fonctionnalité de température et d'humidité du capteur est publiée sur le courtier MQTT

Les événements contrôlant les transitions entre les états sont décrits dans la photo 1 ci-dessus. Les transitions entre les états sont également régies par les paramètres SecVals suivants;

• 1ère adresse IP du courtier MQTT. Sous forme décimale pointée AAA. BBB. CCC. DDD
• 2e port de courtier MQTT. Sous forme d'entier.
• La troisième connexion MQTT Broker tente d'être établie avant de passer du mode STA au mode AP. Sous forme d'entier.
• 4e SSID du réseau Wi-Fi. Sous forme de texte libre.
• 5e mot de passe du réseau Wi-Fi. Sous forme de texte libre.

Comme mentionné ci-dessus, si l'appareil IoT ne parvient pas à se connecter en tant que station WiFi au réseau WiFi dont le SSID et le P/W sont définis dans secvals.txt contenu dans SPIFFS, l'appareil IoT deviendra un point d'accès. Une fois connecté à ce point d'accès, il affichera la "Page d'accueil de configuration du capteur" comme indiqué ci-dessus dans l'image 2 (en entrant soit "SENSORSVR.local" ou 192.168.4.1 dans la barre d'adresse URL de votre navigateur). Cette page d'accueil permet la reconfiguration du capteur via un navigateur

Accès à distance dans l'état ACTIF

Une fois connecté au courtier MQTT, il est également possible de recalibrer et de reconfigurer l'appareil via les publications thématiques MQTT. Le fichier calvals.txt a un accès R/W et secvals.txt a un accès en écriture uniquement exposé.

Débogage utilisateur

Pendant la séquence de démarrage, le voyant de l'appareil IoT donne le retour de débogage suivant

• 1 Flash court: Aucun fichier de configuration situé dans SPIFFS (secvals.txt)
• 2 clignotements courts: l'appareil IoT tente de se connecter au réseau WiFi
• Éclairage continu: l'appareil IoT tente de se connecter à MQTT Broker
• Éteint: l'appareil est actif
• Remarque 1: La 'Page d'accueil de la configuration du capteur' n'utilise pas de sockets sécurisés et dépend donc de la sécurité de votre réseau.
• Remarque 2: Afin de programmer chaque appareil IoT, la chaîne MQTT devra être modifiée avant le téléchargement. Cela est dû au fait que le numéro du capteur a été intégré dans la chaîne de rubrique MQTT. c'est à dire. 'WFD/THSen/100/HumdStatus/1' pour mes 6 appareils, ils sont respectivement numérotés de 1 à 6.

Étape 4: Étalonnage du capteur

Lors de la mise sous tension de l'appareil IoT, dans le cadre de la séquence de démarrage, un fichier nommé "cavals.txt" est lu à partir de SPIFFS. Le contenu de ce fichier sont des constantes d'étalonnage comme indiqué ci-dessus dans la photo 1. Ces constantes d'étalonnage sont utilisées pour ajuster les lectures acquises par le capteur pour les aligner sur un appareil de référence. Il existe une autre valeur qui définit une stratégie de rapport pour l'appareil et est décrite ci-dessous avec la procédure suivie pour étalonner les capteurs.

Stratégie de rapportCe paramètre détermine la manière dont le capteur à distance signale tout changement paramétrique ambiant local. Si une valeur de 0 est sélectionnée, le capteur à distance publiera tout changement constaté dans les valeurs de température ou d'humidité à chaque lecture du capteur (environ toutes les 10 secondes). Toute autre valeur retardera la publication d'un changement de 1…60 minutes. La modification de ce paramètre permet d'optimiser le trafic réseau MQTT.

Étalonnage de la température

Pour calibrer les capteurs, ils ont été placés à proximité physique les uns des autres, comme indiqué ci-dessus sur la photo 2. À côté d'eux, j'ai placé un multimètre numérique avec un thermocouple calibré attaché (Fluke 87 V), puis j'ai surveillé les sorties de chaque appareil via la température OpenHAB. page des tendances au cours d'une journée pour obtenir une bonne variation de température. J'ai noté à la fois le décalage statique (zéro élevé 'C') et le taux de variation de chaque appareil (gain, ou pente du graphique 'M') par rapport à celui de la valeur provenant du thermocouple calibré. J'ai ensuite calculé la relation simple y=mx+c (j'ai trouvé qu'elle était suffisamment linéaire pour être une approximation proche d'un graphique en ligne droite) et programmé toutes les corrections nécessaires dans les constantes d'étalonnage via MQTTSpy.

Les appareils ont ensuite été surveillés pendant 24 heures supplémentaires pour s'assurer que l'étalonnage était réussi. Une indication était que les traces de température sur la page de tendance de température OpenHAB étaient toutes à peu près les unes sur les autres.

Bien sûr, si vous n'êtes intéressé que par une approximation de la température, vous pouvez laisser toutes les valeurs d'étalonnage par défaut.

Étalonnage de l'humidité

Comme je ne possède aucun moyen d'enregistrer avec précision ou même de contrôler l'humidité ambiante locale, pour calibrer les capteurs, j'ai utilisé une approche similaire à celle ci-dessus, en plaçant tous les appareils à proximité physique (photo 2) et en surveillant simplement leur sortie via l'OpenHAB Page de tendance d'humidité. J'ai ensuite choisi l'appareil n°1 comme référence d'étalonnage et étalonné tous les appareils par rapport à cela.

Étape 5: Convention de nommage des rubriques MQTT

Après beaucoup d'essais et d'erreurs, j'ai opté pour la convention de nommage des sujets décrite dans la photo 1 ci-dessus.

À savoir, 'AccessMethod/DeviceType/WhichDevice/Action/SubDevice'

Ce n'est pas parfait, mais cela permet d'appliquer des filtres utiles pour voir toutes les sorties de capteur pour une valeur paramétrique donnée, permettant ainsi une comparaison facile comme sur la photo 2 ci-dessus avec MQTTSpy. Il prend également en charge des groupements logiques de fonctionnalités raisonnablement extensibles au sein d'un appareil IoT donné.

Lors de la mise en œuvre de ces sujets dans le logiciel, j'ai utilisé des chaînes de sujets codées en dur avec des identifiants numériques fixes et intégrés pour chaque périphérique, au lieu de générer dynamiquement les sujets au moment de l'exécution afin d'économiser de la RAM et de maintenir des performances élevées.

Remarque: si vous ne savez pas comment utiliser MQTTSpy, consultez ici « Configuration d'un courtier MQTT ». Partie 2: IoT, Domotique'

Étape 6: Configuration d'OpenHAB

J'ai modifié la configuration OpenHAB donnée dans mon précédent Instructable (ici) et ajouté des entrées individuelles pour;

• Garage,
• Salle,
• Salon,
• Cuisine
• Chambre d'invité
• Chambre des maîtres

Dans le plan du site, voir photo 1 ci-dessus.

Pour chacune de ces entrées, j'ai ajouté des plans de site individuels exposant les valeurs ambiantes locales (voir photo 2 ci-dessus);

• Température
• Humidité
• Indice de chaleur

J'ai également inclus un interrupteur pour contrôler la led locale montée dans le capteur.

Les images 3 à 5 montrent des traces individuelles en direct sur une période de 24 heures pour la température, l'humidité et le RSSI (indication de la force du signal reçu, essentiellement une mesure de la capacité du capteur à voir le réseau WiFi).

L'image 6 donne un exemple d'une tendance d'humidité à long terme sur une période d'une semaine.

Remarque 1: Si vous ne savez pas comment utiliser OpenHAB, consultez ici 'Configuration et configuration d'OpenHAB. Partie 6: IoT, Domotique'

Remarque 2: Une copie du plan du site modifié, des fichiers de règles et d'éléments, des icônes, etc. est fournie ci-dessous.

Étape 7: Tester la conception

Pour la plupart, j'ai testé l'appareil IoT sur la connexion MQTT avec MQTT Spy, en surveillant la sortie des LED et le trafic de débogage sur l'interface série. Cela m'a permis d'exercer tous les sujets abonnés disponibles et de vérifier les réponses publiées. Bien que cela ait été réalisé manuellement et devienne parfois un peu fastidieux, cela a permis une couverture à 100%.

Cependant, la machine d'état principale s'est avérée un peu délicate à tester car elle reposait sur la présence ou l'absence d'un réseau WiFi, dont l'accès nécessite des jeux de paramètres spécifiques. Il n'était tout simplement pas pratique d'utiliser le réseau domestique pour cela.

Pour contourner ce problème, j'ai créé mon propre ensemble de réseaux factices à l'aide d'ESP8266-01 configurés en tant que points d'accès (photo 1) avec les SSID de 'DummyNet1' et 'DummyNet2' respectivement. L'utilisation du circuit de la photo 2 au-dessus de la led a indiqué si un appareil IoT s'y était connecté. Bien que ce n'était pas une solution de test parfaite (c'est-à-dire que chacun de ces réseaux WiFi factices ne contenait pas de serveur MQTT), il était possible de tester complètement la machine d'état.

J'ai inclus une copie du code source ci-dessous.

Étape 8: Conclusion

Général

Le logiciel des appareils IoT a fonctionné de manière fiable pendant de nombreux mois et se remet maintenant de pannes de courant dans les ménages (principalement causées par moi-même). Dans l'ensemble, ce sont des appareils assez robustes donnant des données cohérentes et précises.

Améliorations

En développant des routines logicielles pour lire et écrire dans SPIFFS, j'ai écrit du code qui, avec le recul, peut être un peu plus avancé que prévu, en utilisant des pointeurs vides, une refonte et des pointeurs vers des pointeurs. Bien qu'il soit très flexible et qu'il fasse bien le travail, la prochaine fois, j'utiliserai peut-être JSON comme ConfigFile.ino pour le simplifier un peu.

• Noyau Arduino GIT HUB

  https://github.com/esp8266/Arduino

• Source ConfigFile.ino

  https://github.com/esp8266/Arduino/tree/master/libraries/esp8266/examples/ConfigFile

Liste de souhaits

J'avais l'intention d'utiliser un client mDNS pour me connecter au courtier, mais la bibliothèque était trop floue. C'est pourquoi il est nécessaire de spécifier l'adresse IP du Broker MQTT par opposition à 'MQTTSVR.local'. Si la bibliothèque mDNS devenait plus stable à l'avenir, j'ajouterais cette capacité à l'appareil.

Il aurait été bien d'avoir un moyen de surveiller et de contrôler avec précision l'humidité ambiante pour étalonner les capteurs. Cependant, cela dit, la méthode d'étalonnage choisie donne de bonnes lectures relatives et semble raisonnablement précise conformément aux spécifications de la fiche technique du DHT22.

Enfin, étant donné la complexité du logiciel, j'ai trouvé que tester complètement le code après un changement majeur devenait chronophage. Je pourrais envisager des tests automatisés à une date ultérieure.

Étape 9: Références utilisées

J'ai utilisé les sources suivantes pour assembler ce Instructable;

PubSubClient.h

• Par: Nick O'Leary
• De:

DHT.h

• Par: Adafruit
• De:

Fiche technique DHT22