[RESOLU] Création d'un sketch ARDUINO pour intégrer un LIDAR TFmini sur un ESP 8266

ok ça c’est fait, et dedans j’ai collé le _P129 , tel que proposé par @seb821 dans ce fil.
Capture
Le dossier « _P129 » est celui créé quand j’ai compilé le ino de seb821.

Ok c’est fait (plus tôt que prévu :wink:), par contre les données du LIDAR, je suis censé les voir dans ce serial monitor? parce que là le monitor est vide

ok je l’ai ouvert, je l’ai téléversé (uploadé), mais j’ai une erreur

C:\Users\#####\AppData\Local\Arduino15\packages\esp8266\tools\xtensa-lx106-elf-gcc\2.5.0-4-b40a506/bin/xtensa-lx106-elf-ar: core\core.a: No such file or directory

j’ai lu ailleurs qu’au lieu de mettre la carte LOLIN(WEMOS) D1 R2&mini, il faut mettre la carte générique ESP 8266, ça peut venir de ça?

merci

1 « J'aime »

Juste pour être sûr : toutes les dernières manips que j’ai cité, c’est sous Arduino IDE et indépendamment de ESP Easy. Le code que j’ai mis est un sketch indépendant qu’il faut compiler et uploader sur la D1 mini avec Arduino IDE.

Pour le dossier, oui en effet il faut que le fichier .ino soit dans un dossier du même nom, sinon Arduino IDE ne marche pas.

Oui. Tu peux ajouter dans la fonction setup une ligne

Serial.println("Hello World");

Cela doit apparaître. Mais commence vraiment par le plus simple pour te familiariser, le sketch Blink.

Je ne sais pas trop là. Tu peux essayer Generic ESP8266, ça doit marcher aussi. Ou sinon Tools > Board > Boards Manager > Taper « esp » et pour esp8266 essayer d’installer une autre version.

Bref, il faut arriver à se faire la main sur des sketchs très simples, compiler, uploader, et lire sur le port série. Il y doit y avoir des tutoriels aussi sur le web qui sont plus parlants.

Salut,

Peut-être un peu plus simple, je viens de voir qu’il y avait une librairie tfmini. Le principe des librairies, c’est du code écrit pour un capteur par exemple qui peut être utilisé juste en appelant une simple fonction. Cela simplifie souvent les choses.

Du coup, cela donnerait :

  • Récupérer le fichier BasicReading.ino et le mettre dans un dossier BasicReading
  • Récupérer les deux fichiers de la librairie ici (.cpp et .h) et les mettre dans le même dossier
  • Ouvrir le fichier .ino avec Arduino IDE
  • Changer SoftwareSerial mySerial(10, 11); par SoftwareSerial mySerial(D1, D2); (ou SoftwareSerial mySerial(5,4); pour pouvoir compiler avec Generic ESP8266 - voir l’équivalence des pins )
  • Compiler et updloader

Il faudra connecter le TX du TFMini sur D1 et le RX sur D2. Et les données devraient apparaître dans le serial monitor. Et si ça fonctionne, on pourra voir pour ESP Easy (ce sera nettement plus simple de faire un plugin avec le librairie .

Note : apparemment, en regardant dans les issues le code ne fonctionne pas directement. Mais un utilisateur (speedymk1) fournit un code qui doit fonctionner sur NodeMCU (et donc sur D1 mini) : TFMini not compatible with ESP8266 / NodeMCU 12E

si tu dialogue avec un périphérique sur les lignes TX/RX tu condamne la visu sérial sauf si même vitesse et protocol Text …
et tu devra déconnecté TX RX au moment de téléversé …

Oui c’est vrai, mais ici le code utilise D1/D2 sur l’ESP (en SoftwareSerial) et pas le RX/TX de l’ESP. Du coup, il n’y a pas de problème et c’est pour cela que j’indique de connecter TX/RX du TFMini sur les pins D1/D2 de l’ESP.

Pffffffffff je crois que vous avez l’argué Seb54 !
du coup un petit stage chez Babbel pour apprendre le MicroPython en express et suivre l’excellent tuto d’olive !

1 « J'aime »

:sunglasses: :sunglasses: :pray: :pray: ça clignote! Oui c’est pas grand chose mais ça me fait plaisir. Par contre je ne vois pas « hello world » dans le moniteur série (j’ai bien mis la ligne en setup).

:star_struck: :fist_right: :fist_left: ça mesure!!!
Capture

Oui oui, exit easy pour le moment. Par contre juste pour être sûr à mon tour, je suis bien censé mettre les dossiers directement dans Arduino, pas dans ArduinoData?
Capture

Mais du coup ça ne clignote plus, si un sketch écrase le précédent, je vais devoir trouver le moyen de fusionner des sketches (en mettant les codes à la queleuleu avant de compiler?)
Et note pour plus tard, les 79cm sont mesurés avec ma main devant à 10cm…je vais essayer de décortiquer le code

Et le graal : envoyer tout ça sur jeedom (jeedouino?)

en tout cas, un grand merci, ou plutôt 1000, j’ai fait en 48h grâce à vous ce que j’essayais de faire depuis 6 mois…

Complètement! Et c’est d’autant plus excitant de voir le bidule clignoter! :rofl: :rofl:

Edit : @seb821, ton avis stp, j’ai trouvé ce tuto qui semble correspondre à mes attentes :
https://projetsdiy.fr/envoyer-donnees-jeedom-api-json-http-esp8266/
ton avis stp : vaut-il mieux passer par ESP easy ou par ce tuto? Et si c’est par ce tuto, comment fusionner le sketch du tuto avec le sketch du TFmini que tu as suggéré?
merci

Rigolo ce lien c’est la réplique arduino de ce que je décrit en MicroPython dans mon tuto en ce moment.

Bon pour ce qui est de l’idée libère toi le plus possible des plugins

écrit ton code le plus possible ce sera beaucoup plus intéressant que de galérer avec esayesp

envoyer ou recevoir une donnée à jeedom est en fait assez simple et ne nécessite pas de plugin…

ou juste un virtuel.

ok ça marche merci, et juste pour me mettre le pied à l’étrier, quelle est la meilleure façon de concilier le sketch créer les données du LIDAR et celui pour les envoyer à jeedom? merci

Mettre les pieds dans le code, te servir des exemples d’envoi a jeedom et y inclure l’exemple du lidar.

Avec micropython tu a aussi des librairies et des exemples fournis

1 « J'aime »

Autant je trouve que ESP Easy c’est une super solution pour les personnes qui ne codent pas, mais à partir du moment où il faut mettre le nez dans le code pour créer un plugin (dont la structure n’est pas forcément évidente), c’est une autre histoire et ce sera sûrement plus simple de faire du code séparé.

Le tuto a l’air bien. Dans tous les cas, Projets DIY c’est un super site qui fait des articles de qualité depuis des années. Je suis d’ailleurs ravi de voir qu’il republie des articles après quelques mois sans trop de mise à jour.

Pour fusionner le sketch, il va falloir comprendre mieux le code en question et qu’est ce qui fait quoi. Et pour cela, pas trop le choix il faut y passer du temps. Je ne suis pas programmeur de formation, j’ai commencé comme toi avec des tutos et des exemples en adaptant.

Ce que je ferais, c’est partir du code du tuto et valider l’envoi des données à Jeedom. Par exemple, en remplaçant float t = dht.readTemperature(); par float t = 1234;, on doit arriver à faire remonter cette valeur à Jeedom. Ensuite, je supprimerais tout ce qui ne sert à rien dans le code en validant que la valeur remonte toujours (en la changeant à chaque fois). Et enfin, je rajouterais les bouts de code de l’autre sketch de lecture de la D1 mini.

A faire peut-être avant, lire deux trois articles qui expliquent la base du langage Arduino, ça aidera à comprendre. Par exemple celui là a l’air pas mal.

Ou alors tu changes de langage et bascule sur du mycropython comme le suggère olive. Mais difficile de donner un conseil vu que je n’ai pas (encore) essayé. A l’époque je suis parti sur langage arduino vu que la plupart des tutos et librairies étaient codé avec, mais il faut avouer que c’est un langage contraignant et pas forcément facile à appréhender.

1 « J'aime »

Je ne comprenais pas bien pourquoi ils parlaient d’I2C dans cette librairie, mais après recherche il semble que le capteur fonctionne soit en I2C (SDA/SCL), soit en UART (RX/TX) Voir ce manuel.

L’UART semble être le mode par défaut mais la librairie en python existe aussi pour ce mode a priori :

Ben oui et c’est pas plus mal en I2C ca évite de bouffer l’UART si l’on en a besoin pour autre chose.
tfmini
Tout le protocole est la : https://cdn.sparkfun.com/assets/d/9/e/c/d/TFmini-I__C-Product_Manual_V1.1_EN.pdf

C’est pareil puisqu’il est possible d’utiliser autres pin pour faire du port série « software ». D’ailleurs, c’est ce qui est fait par le script testé qui utilise les pins D1 et D2 en port série.

C’est top de pouvoir faire de l’I2C, je suis d’accord, mais cela rajoute une étape puisqu’il faut changer le mode du capteur. Je préfère juste le signaler.

Edit : si on a d’autres capteurs I2C à intégrer, effectivement il y a vrai intérêt à passer en I2C vu qu’on pourra les mettre en parallèle.

Tadaaaaaaaa !!! Il est pas beau mon virtuel??? :star_struck: :star_struck:
Capture

Par tâtonnements j’ai réussi à sortir un sketch qui fonctionne, avec cepandant un rafraîchissement à revoir (les distances ont plusieurs données de retard sur le moniteur série, quand je passe la main, la distance n’apparaît que quelques loop plus tard).

Pour la postérité, voici le code. Je le remplacerai en edit avec une version épurée des lignes désactivées et corrigée de ce pb de retard :

/*source : 
 * HTTP communication between ESP8266 and Jeedom Smart Home Server
 * Communication HTTP (TCP/IP) entre ESP8266 et le serveur domotique Jeedom
 * Copyright (C) 2017 https://www.projetsdiy.fr - http://www.diyprojects.io
 *   
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program.  If not, see <http://www.gnu.org/licenses/>.
 */
#include <ESP8266WebServer.h>
#include <ESP8266WiFi.h>
#include <ESP8266HTTPClient.h>
#include <WiFiClientSecure.h>
//---incorpo code BasicReading (Test TFmini)---
#include <Arduino.h>
#include <SoftwareSerial.h>
#include "TFMini.h"
//\\

const char* ssid     = "######";
const char* password = "######";
const char* host     = "192.168.86.236";
const int   port     = 80;
const char* apiKey   = "#####"; //(api du plugin Virtuel, pas de Jeedom)
const char* idDist     = "9272";    //numéro ID de l'info virtuelle
const char* idStren     = "9273";   //numéro ID de l'info virtuelle
const int   watchdog = 10000; // Fréquence d'envoi des données à Jeedom
const long interval = 10;           // interval at which to measure (milliseconds) (au delà, une latence est observée entre mesure et affichage serial.print)
unsigned long previousMillisLIDAR = 0;      // d'origine : millis()
unsigned long previousMillisJEEDOM = 0;  

ESP8266WebServer server ( 80 );
HTTPClient http;


//---incorpo code BasicReading (Test TFmini)---
// Setup software serial port
SoftwareSerial mySerial(5, 4);      // connection to TFMini
TFMini         tfmini;              // tfmini access
//\\

void setup() {
  Serial.begin(115200);
  delay(10);
  
  Serial.setDebugOutput(true);  
  Serial.println("Connecting Wifi...");

  WiFi.begin(ssid, password);
  while (WiFi.status() != WL_CONNECTED) {
    delay(500);
    Serial.print(".");
  }
  
  Serial.println("");
  Serial.println("WiFi connected");
  Serial.println("IP address: ");
  Serial.print(WiFi.localIP()); 
  
  server.begin();

  //---incorpo code BasicReading (Test TFmini)---
  // Step 1: Initialize hardware serial port (serial debug port)
  // wait for serial port to connect. Needed for native USB port only
  while (!Serial);
  // Step 2: Initialize the data rate for the SoftwareSerial port
  mySerial.begin(TFMINI_BAUDRATE);  // default boudrate is 115200
  delay(10);
  // Step 3: Initialize the TF Mini sensor
  tfmini.begin(&mySerial);
  Serial.println ("Initializing Serial and mySerial finished");
  //\\

  int value = 0;

  pinMode(LED_BUILTIN, OUTPUT);

}

void loop() {
  unsigned long currentMillis = millis();
  server.handleClient();
    
  if ( currentMillis - previousMillisLIDAR >= interval ) {     //*remplacement > par >=
  previousMillisLIDAR = currentMillis;
  //---incorpo code BasicReading (Test TFmini)---
  // Take one TF Mini distance measurement
  uint16_t dist = tfmini.getDistance();
  uint16_t strength = tfmini.getRecentSignalStrength();
  // Display the measurement
  Serial.print(dist);
  Serial.print(" cm   Signal: ");
  Serial.println(strength);
  //\\
  } else {
    if ( currentMillis - previousMillisJEEDOM >= watchdog ) {     //*remplacement > par >=
      previousMillisJEEDOM = currentMillis;
      if(WiFi.status() != WL_CONNECTED) {
        Serial.println("WiFi not connected !");
      } else {
          Serial.print("Distance envoyée à Jeedom : ");
          Serial.println(dist);
    
          String baseurl = "/core/api/jeeApi.php?apikey="; 
          baseurl += apiKey;
          baseurl += "&type=virtual&id="; 
          String url = baseurl + idDist;
          url += url + "&value="; url += dist;   //String(t); 
          sendToJeedom(url);
          delay(1000); //d'origine : 1000
          digitalWrite(LED_BUILTIN, HIGH);   // turn the LED on (HIGH is the voltage level)
          
          url = baseurl + idStren;
          url += url + "&value="; url += strength;    //String(h);
          sendToJeedom(url);
          Serial.println("données envoyées");
          digitalWrite(LED_BUILTIN, LOW);    // turn the LED off by making the voltage LOW
          delay(1000); //d'origine : 1000
      }
    }
  }
}

boolean sendToJeedom(String url) {
  //Serial.print("connecting to ");
  //Serial.println(host);
  //Serial.print("Requesting URL: ");
  //Serial.println(url);
  http.begin(host,port,url);
  int httpCode = http.GET();
  //Serial.println("données envoyées");
  http.end();
}

en tout cas, merci @seb821 @olive @rol-rider pour vos encouragements et vos pistes, ça fait plusieurs mois que je cherchais un moyen de capter si qqn se gare devant chez moi avant que je n’arrive à la maison.

On m’a plusieurs fois conseillé de mettre les mains dans le cambouis, mais j’arrivais pas à ouvrir le capot. C’est chose faite :love_you_gesture:

PS : par contre je vois pas bien d’où peut venir ce problème de retard

Edit : code remplacé par le code final

Bravo :+1: :+1: :+1:

bon je me rappel plus en arduino mais un delay(1000) ca fait une seconde
entre chaque tour il faut bien laisser un peut de temps a ta requette http de s’exécuter …
moi j’esserai 10 000 toutes les 10 secondes c’est déjà pas mal.

C’est top, super.

Pour le code, je pense que tu as compris que tout le début c’est des définitions (variables, fonctions, etc.), puis la fonction setup() est exécutée une unique fois au démarrage.
Ensuite, c’est la fonction loop() qui boucle sur elle-même.

Le point à comprendre, c’est que l’esp ne peut faire qu’une tâche à la fois. Si veut « temporiser », soit on utilise delay(), mais cela bloque l’exécution (pas gênant si on n’a qu’une chose à faire), soit on utiliser les formules du type : if ( currentMillis - previousMillis > watchdog ) { } => l’idée c’est que si on est pas dans le « timing » que l’on souhaite, on sort du if pour exécuter ce qu’il y après. Bon là, on a rien d’autres du coup ça change rien.

La fonction millis(), c’est comme un chronomètre en ms dès que l’esp est allumé. previousMillis sert à mémoriser une valeur. Du coup, le if précédent est exécuté toutes les 5000 ms qui est la valeur de watchdog. Ensuite, si on déroule un peu le code, après sendToJeedom(url); on voit un delay(1000) qui fait une pause d’une seconde avant d’envoyer la seconde valeur à Jeedom. A la limite pourquoi pas, mais ça peut se réduire je pense sans problème (à essayer), voire même s’enlever. Ensuite, il y a deux autres delay(1000) => ceux-là ne servent à rien puisque de toutes façons on va attendre 5 secondes derrière avant de relancer une mesure.

Avec le code actuel, il doit y avoir une mesure toutes les 8s environ. En enlevant les delay, cela va descendre à 5s. Et en réduisant watchdog, on peut aller encore plus loin. Mais cela va charger de plus en plus Jeedom pour rien, avec des requêtes en permanence pour mettre à jour les valeurs. Surtout pour une voiture garée :grinning:

Donc pour la partie test, c’est très bien de vouloir réduire les temps, mais dans les faits c’est inutile. L’astuce pour réagir immédiatement, c’est d’envoyer la valeur à Jeedom que toutes les 10 minutes par exemple, mais de continuer à mesurer fréquemment avec le capteur. Et on teste à chaque fois cette valeur pour voir si cela descend en dessous d’une certaine constante, puis dans ce cas déclencher un envoi immédiat à Jeedom (mais une seule fois, c’est à dire qu’il faut mémoriser avec une variable qu’on est passé en dessous, sinon cela continuera à envoyer tant que la distance mesurée est basse).

Bon je voudrait pas noyer le poisson tu oublie les thread … je ne sais pas si cela fonctionne sur esp8266 mais sur ESP32 c’est sur …

edit: j’ai fait une petite recherche sur 8266 c’est non …

Salut Seb, oui effectivement ce serait l’idéal. Mais je préfère pouvoir changer les constantes en scenario jeedom plutôt que de devoir faire un téléchargement à chaque fois que la constante doit être changée. Et 10 secondes c’est parfait, le mec se gare et bim, simulation d’ouverture de garage avec lumière orange pour qu’il se casse.

Ou alors on pourrait coder une plage horaire de fonctionnement? J’avoue que c’est assez chiant de devoir compiler/téléverser pour tester chaque nouvelle modification. Mais voilà une bonne piste de réflexion je pense, faut que je trouve un truc avant d’installer mon capteur sur ma façade.

Salut Olive, en fait le décalage entre mesure et affichage serial.print est constaté même sans requête http, juste en montant le délai de 10ms entre 2 mesures…Du coup j’ai fait une variable interval mesure et une variable interval requête, ça marche au poil.

Alors c’est la que tu va devoir faire des exercices en MicroPhyton :slight_smile:
Ce n’est pas un langage compilé tu peut donc modifier ton code source en live et a distance.

1 « J'aime »