LE CARNET TECHNIQUE / DONNÉES
Une courbe commence par un point vérifiable.
Le projet Quiet Bee utilise une XIAO ESP32-C3, une passerelle HTTPS, InfluxDB 3 et un tableau de bord. Voici comment vérifier les frontières entre ces composants.
1. Définir la chaîne et les responsabilités
La carte prépare le message. Le Wi-Fi fournit l’accès réseau. Le serveur HTTPS authentifie et limite les écritures. InfluxDB stocke les points. Une API de lecture sélectionne les données utiles aux courbes. Le navigateur n’a jamais besoin de connaître le jeton administrateur de la base.
Sur le VPS du projet, InfluxDB écoute en local et la route d’écriture du sous-domaine IoT est gérée côté serveur. Cette architecture évite d’exposer directement le port de la base. Le tutoriel ne vous autorise pas à écrire sur cette installation : créez une base, un domaine et une clé propres à votre projet.
2. Définir un message sans ambiguïté
Commencez avec un point de diagnostic, puis ajoutez une mesure réelle après validation du capteur. Voici un message fictif de test au format line protocol, sans timestamp explicite :
diagnostic,device=atelier01 wifi_rssi=-65i,uptime_s=120idiagnostic est le nom de mesure ; device est un tag pour sélectionner la source ; les champs wifi_rssi et uptime_s sont des entiers grâce au suffixe i. Le serveur attribue l’heure de réception si vous n’envoyez pas de timestamp. Cette heure ne correspond pas forcément à l’acquisition, surtout après une coupure réseau.
Pour un capteur différé, conservez séparément l’heure d’acquisition et la qualité de l’horloge. Fixez les unités dans le nom ou le schéma de données. Ne placez pas une séquence unique dans un tag : les tags sont utiles aux dimensions stables, pas à tous les détails d’un échantillon.
3. Vérifier HTTPS avant le firmware complet
Sur une destination que vous contrôlez, configurez une route d’écriture, une limite de taille et une clé à droits restreints. Injectez la clé via une configuration privée ; ne la placez pas dans une page Web, un dépôt public ou une capture d’écran. Renouvelez-la si elle est exposée.
POST /api/esp32/write HTTP/1.1
Host: votre-domaine.example
Authorization: Bearer CLE_DE_VOTRE_PROJET
Content-Type: text/plain
diagnostic,device=atelier01 wifi_rssi=-65i,uptime_s=120iCe bloc décrit une requête, pas un serveur prêt à l’emploi. Le contrat de la passerelle doit fixer la base et la précision du timestamp ; un ESP32 ne doit pas pouvoir sélectionner une base arbitraire. Un statut 204 est le résultat attendu de la route du projet, tandis que d’autres API peuvent avoir un contrat différent.
4. Préparer l’envoi Arduino sans affaiblir TLS
Sur l’ESP32, établissez le Wi-Fi avec un délai maximal, synchronisez l’horloge et configurez la chaîne de confiance du certificat avant d’émettre. N’utilisez pas setInsecure() comme solution définitive à une erreur TLS. Le certificat racine, le nom DNS, l’heure et la chaîne serveur doivent être cohérents.
Le programme doit borner le temps de connexion et le temps de lecture, fermer la session, puis attendre avant une nouvelle tentative. Ne bouclez pas immédiatement sur une erreur 401 : elle demande une correction de clé. En cas d’erreur réseau, une reprise avec délai croissant limite la charge et la dépense énergétique.
Les sources complètes du projet de référence restent présentées dans le parcours XIAO ESP32-C3 existant. Vérifiez les versions de carte et de bibliothèque avant d’adapter son firmware ; ce texte ne prétend pas fournir un programme universel compatible avec toute carte ESP32.
5. Relire le point dans InfluxDB 3
Une écriture acceptée doit être relue dans la base cible. Depuis un client autorisé, une requête SQL bornée permet d’inspecter le diagnostic. L’exemple ci-dessous ne contient aucun secret et nécessite une table alimentée :
SELECT time, device, wifi_rssi, uptime_s
FROM diagnostic
WHERE time >= now() - INTERVAL '1 hour'
AND device = 'atelier01'
ORDER BY time DESC
LIMIT 20;Vérifiez le nom de la source, les unités et l’ordre des dates. InfluxDB 3 utilise notamment SQL ; ne reprenez pas une procédure Flux écrite pour InfluxDB 2 sans vérifier sa compatibilité. Consultez les limites de votre édition pour choisir des fenêtres de lecture et une conservation adaptées.
6. Diagnostiquer au bon niveau
| Résultat | Piste de diagnostic |
|---|---|
| Pas d’adresse Wi-Fi | Réseau 2,4 GHz, identifiants, signal et délai de connexion. |
| Échec TLS avant HTTP | Horloge, autorité racine, DNS et chaîne du certificat. |
| 401 / 403 | Clé absente, expirée ou droit insuffisant ; ne pas afficher la clé dans les journaux. |
| 400 | Syntaxe du message, type des champs, timestamp et précision. |
| 413 / 429 | Taille ou fréquence excessive ; réduire le lot et temporiser. |
| 204, puis aucun point visible | Base/table cible, filtre temporel, identifiant et droit de lecture. |
| Courbe figée malgré les points | Réponse de l’API de lecture, fuseau, cache et erreurs JavaScript. |
7. Passer de la démonstration au capteur
Un graphique public doit annoncer la provenance de ses valeurs. Remplacez la simulation seulement après vérification indépendante de la sonde. Pour une valeur invalide, conservez un état d’erreur ou une absence de point au lieu de générer une température raisonnable. Distinguez une interruption de transmission d’une variation physique.
La précision dépend aussi de l’abri, du rayonnement, du temps de réponse et de la position du capteur. Avant toute interprétation environnementale, archivez les conditions de pose et confrontez les données à une référence adaptée. La plateforme transmet des nombres ; elle ne valide pas, à elle seule, la qualité d’une mesure.
Sources et références
- InfluxDB 3 : écriture de données ↗
- InfluxDB 3 : requêtes SQL ↗
- Seeed : démarrer avec la XIAO ESP32-C3 ↗
Les schémas de votre référence matérielle et la documentation de votre version de logiciel priment sur un exemple générique.