En tant qu'amateur (plus ou moins éclairé !), j'ai réalisé des capteurs maison (Wemos D1 mini) et les ai mis en ligne en utilisant les services très agréables d'Adafruit IO. En l’occurrence il s'agit de thermomètres et du dashboard associé, mais peu importe.
Tout fonctionne bien. Mais je désire à présent me passer d'Adafruit IO et gérer la chaîne de A à Z. J'ai tâtonné 2 jours sans succès majeur. Il est temps de faire un pas de côté et de planifier la suite.
Il semble que le Broker MQTT Mosquitto ne puisse pas stocker les données pour alimenter un dashboard. C'est pourquoi J'imagine l'architecture suivante :
Wemos D1 mini (créer la mesure) ==> Broker MQTT Mosquitto (transporter la mesure) ==> Base de donnée style InfluxDB (stocker la mesure) ==> Grafana (mettre en forme la mesure)
Là où j'en suis :
Créer la mesure sur un ESP8266, c'est OK.
L'envoyer à Mosquitto, hébergé sur un NAS Synology grâce au paquet de la communauté, c'est OK.
La lire en live sur MQTT Explorer depuis mon ordi, c'est OK.
Héberger grâce à Docker sur le NAS Synology : Grafana et InfluxDB, les services démarrent et les interfaces Web sont disponibles.
Là où je peine :
Je n'y connais rien en bases de données
La liaison entre Mosquitto et InfluxDB n'est pas claire pour moi. Depuis InfluxDB, il semble y avoir un plugin "Telegraf" que je n'ai pas réussi à paramétrer.
Je vous sollicite donc pour me conseiller : mon "architecture" est-elle viable ? J'ai le sentiment que l'utilisation de Docker m'aide à mettre en place des services qui ne sont finalement pas complètement fonctionnels...
Ce n'est pas qu'il ne sont pas fonctionnel, c'est qu'il te manque un élément qui récupère les données publier par MQTT, pour les enregistrer dans InfluDB. @J-M-L te propose télégraphe pour être cet élément(appelé agent).
Il est aussi possible de faire un programme/agent en python par exemple pour faire l'enregistrement de ces données dans ta base InfluDB.
Vu que tu utilise les dockers, tu peux télécharger un docker avec Telegraph sur hub.docker.com
Oui, j'avais zappé, je pensais bien qu'il y avait un programme existant en Python.
Du coup la remarque du docker Telegraph est bien sûre tout aussi valable avec Python.
Même si, ca ne doit pas être beaucoup plus dure de l'intégrer dans le docker InfluDB.
Merci à tous les deux pour vos réponses ! Avant de creuser davantage, je me permets de reformuler.
Je comprends qu'il me manque donc une brique, par exemple le fameux Telegraf (ou un code Python). Cet élément, un agent, va récupérer le flux MQTT et l'inscrire dans la base de donnée InfluxDB.
Du coup, le schéma serait le suivant : Wemos D1 mini (créer la mesure) ==> Broker MQTT Mosquitto (transporter la mesure) ==> Telegraf (inscrire la mesure dans la base de données) ==> Base de donnée style InfluxDB (stocker la mesure) ==> Grafana (mettre en forme la mesure)
Bonjour terwal et J-M-L,
Bonjour à toutes et à tous,
Merci pour vos réponses.
J'ai bien installé trois containers Docker sur mon NAS pour Telegraf, InfluxDB et Grafana.
Clairement, j'ai écumé une dizaine (peut-être même deux dizaines..!) de tutos en français et anglais pour Telegraf et le stack "TIG" mais quelque chose doit m'échapper car je n'arrive pas à avancer depuis nos derniers échanges.
Dans l'interface web d'Influx DB, je me laisse guider par le wizard d'un "plugin Telegraf" : je renseigne mes paramètres.
Pour la petite histoire, si je laisse le fichier de config du wizard par défaut "pour voir", alors la réponse dans le terminal de Telegraf diffère et rien ne se passe.
Ma maîtrise de Python étant très faible, je n'ai pas réussi à comprendre comment intégrer ce script. Certaines étapes ne sont pas assez explicite pour moi
En revanche, j'ai trouvé un contournement en utilisant la library Arduino pour InfluxDB et cela shunte complètement le protocole MQTT, et donc Telegraf. J'arrive à écrire dans la base de donnée InfluxDB depuis un ESP8266 avec cette méthode.
Voici l'exemple que j'ai testé avec succès :
/**
* Basic Write Example code for InfluxDBClient library for Arduino
* Data can be immediately seen in a InfluxDB UI: wifi_status measurement
* Enter WiFi and InfluxDB parameters below
*
* Measures signal level of the actually connected WiFi network
* This example supports only InfluxDB running from unsecure (http://...)
* For secure (https://...) or Influx Cloud 2 use SecureWrite example
**/
#if defined(ESP32)
#include <WiFiMulti.h>
WiFiMulti wifiMulti;
#define DEVICE "ESP32"
#elif defined(ESP8266)
#include <ESP8266WiFiMulti.h>
ESP8266WiFiMulti wifiMulti;
#define DEVICE "ESP8266"
#endif
#include <InfluxDbClient.h>
// WiFi AP SSID
#define WIFI_SSID "ssid"
// WiFi password
#define WIFI_PASSWORD "password"
// InfluxDB server url. Don't use localhost, always server name or ip address.
// E.g. http://192.168.1.48:8086 (In InfluxDB 2 UI -> Load Data -> Client Libraries),
#define INFLUXDB_URL "influxdb-url"
// InfluxDB 2 server or cloud API authentication token (Use: InfluxDB UI -> Load Data -> Tokens -> <select token>)
#define INFLUXDB_TOKEN "toked-id"
// InfluxDB 2 organization id (Use: InfluxDB UI -> Settings -> Profile -> <name under tile> )
#define INFLUXDB_ORG "org"
// InfluxDB 2 bucket name (Use: InfluxDB UI -> Load Data -> Buckets)
#define INFLUXDB_BUCKET "bucket"
// InfluxDB v1 database name
//#define INFLUXDB_DB_NAME "database"
// InfluxDB client instance
InfluxDBClient client(INFLUXDB_URL, INFLUXDB_ORG, INFLUXDB_BUCKET, INFLUXDB_TOKEN);
// InfluxDB client instance for InfluxDB 1
//InfluxDBClient client(INFLUXDB_URL, INFLUXDB_DB_NAME);
// Data point
Point sensor("wifi_status");
void setup() {
Serial.begin(115200);
// Connect WiFi
Serial.println("Connecting to WiFi");
WiFi.mode(WIFI_STA);
wifiMulti.addAP(WIFI_SSID, WIFI_PASSWORD);
while (wifiMulti.run() != WL_CONNECTED) {
Serial.print(".");
delay(500);
}
Serial.println();
// Set InfluxDB 1 authentication params
//client.setConnectionParamsV1(INFLUXDB_URL, INFLUXDB_DB_NAME, INFLUXDB_USER, INFLUXDB_PASSWORD);
// Add constant tags - only once
sensor.addTag("device", DEVICE);
sensor.addTag("SSID", WiFi.SSID());
// Check server connection
if (client.validateConnection()) {
Serial.print("Connected to InfluxDB: ");
Serial.println(client.getServerUrl());
} else {
Serial.print("InfluxDB connection failed: ");
Serial.println(client.getLastErrorMessage());
}
}
void loop() {
// Store measured value into point
sensor.clearFields();
// Report RSSI of currently connected network
sensor.addField("rssi", WiFi.RSSI());
// Print what are we exactly writing
Serial.print("Writing: ");
Serial.println(client.pointToLineProtocol(sensor));
// If no Wifi signal, try to reconnect it
if (wifiMulti.run() != WL_CONNECTED) {
Serial.println("Wifi connection lost");
}
// Write point
if (!client.writePoint(sensor)) {
Serial.print("InfluxDB write failed: ");
Serial.println(client.getLastErrorMessage());
}
//Wait 10s
Serial.println("Wait 10s");
delay(10000);
}
Cela représente-t-il un problème ? J'ai le sentiment que l'autonomie des outils sur batterie pourraient pâtir de ce changement et que cela réduit l'évolutivité d'une installation. Mais bon, à l'instant t, je n'ai que cela qui fonctionne...
c'est également de cette manière (=sans MQTT) que j'ai utilisé InfluxDB+Grafana jusqu'à présent
(je pensais que tu tenais à passer par MQTTetn'ai donc pas évoqué la manière de s'en passer)
Pour augmenter l'autonimie le métais l'ESP en sommeil profond après envoi des données vers InfluxDB, C'était compatible avec mon usage étant donné que l'ESP n'avait pas d'autres tâches que faire de temps en temps des mesures et les envoyer vers la base de données
