LOCODUINO
Parlons Arduino => Vos projets => Discussion démarrée par: Gorgio-arduino le juin 28, 2019, 10:05:14 am
-
Bonjour, à tous.
Il y a quelque temps, j'ai créé un post sur le BAL piloté par Arduino nano.
Je travaille sur ce projet depuis un an, et il est abouti et fonctionnel.
L’Arduino du canton N dépend de l’état de l’Arduino du canton N+1, le N+1 dépend du N+2, jusqu’à revenir à l’Arduino N (Réseau en Os)
3 à 4 câbles sont nécessaire pour ce fonctionnement entre Arduino, autant dire un paquet de spaghettis.
Je souhaiterai remplacer ces liaisons filaires par des liaisons wifi avec module ESP8266 peu chère
Ceci aura une conséquence immédiate : Il n’y aura plus que les GND, + alim marche réduite, + alim marche normale et 5V pour les Arduino, donc pour chaque canton.
De plus, cela permettra d’ajouter des tronçons au réseau sans modification de câblage.
Pour cela, il faut programmer les ESP8266 avec le bon code et c’est là que je bloque. (Je sais téléverser dans un ESP8266)
En fait, je veux envoyer de l’ARDUINO (IP 192.168.0.151) N+1 texte « Avertissement » vers l’Arduino (IP 192.168.0.150) N.
Si ARDUINO N reçoit « Avertissement » de ARDUINO N+1 (BAL rouge ou carré du N+1), alors mettre
BAL N au jaune (avert.).
Il faut aussi que l’ARDUINO N puisse envoyer à son N-1 son état (carré ou rouge etc.)
J’ai aussi imaginé pouvoir piloter depuis un Arduino Méga + ESP8266 les différents accessoires de voie (Arduino+ESP8266 + servo pour aiguillage) mais aussi envoyer les positions aiguille déviée au BAL pour l’affichage Rappel Ralentissement, commander les carrés.
Si quelqu’un sait, je suis preneur
Georges.
-
Bonjour
Cette démarche sans fil me semble tout à fait dans l'air du temps, on commence déjà à trouver des décodeurs de loco WIFI.
Oui je sais faire mais avec des ESP32, il me semble qu'il y a quelques petites différences entre l'ESP32 et ESP8266, mais cela ne devrait pas être un problème.
Comme il y a plusieurs ESP il va falloir un routeur et utiliser des adresses IP fixes, le routeur cela peut être une box ou un routeur dédié.
Un octet transmis d'un ESP à un autre ESP est largement suffisant dans ce cas.
L'ESP32 a des bibliothèques pour faire cela assez facilement, celles de ESP8266, doivent êtres semblables.
On peut discuter de tout cela.
Cordialement
Pierre
-
Bonjour,
Merci pour ce post
J'essaye bon grè malgrè de transmettre une variable d'un ESP à un autre.
Le soucis, c'est qu'un ESP doit être à la fois être envoyeur et receveur de données pour ensuite les communiquer à leur Arduino respectif par liaison série,
Je ne sais pas comment envoyer d'un ESP150 (IP x.x.x.150) une valeur "Z" vers un ESP151 (ip x.x.x.151) mais aussi recevoir sur ESP151 une valeur "Y" d'un ESP152 (ip x.x.x.152)
Tous les ESP sont connectés sur la même box WIFI en IP fixe.
Il y a pas mal de tuto , comment allumer une led depuis un smartphone au par HTTP, mais rien trouvé entre ESP.
Pour ce qui est de l'ESP32, la différence est sur le nombre de GPIO,
Possédant déjà un circuit avec 14 cantons donc 14 ARDUINO NANO, j'ai opté pour l'ESP8266 qui lui possède 2 GPIO, j'utilise une liaison série entre ESP et NANO , mais le principe d’échange WIFI doit rester le même que celui ESP32 , au code et librairy prés.
Je pense que si j'arrive à maitriser ces liaisons WIFI entre ESP, je serais en mesure de passer toute mes locos en WIFI pilotées par un ARDUINO MEGA qui se chargera de les contrôler.
Une chose à la fois.
Je programme beaucoup avec Blockly, étant nul en langage, mais bon en automatisme (Vieux souvenir du GRAFCET).
Je ne désepère pas.
Cdt
-
Si vous voulez vraiment utiliser du WiFi (sur ESP 8266 ou 32) donc du TCP, regardez la diffusion broadcast. Le mieux serait peut être d'ailleurs de UDP. Toujours en broadcast bien sûr.
Toujours si vous voulez vraiment faire du WiFi, il faut à mon avis utiliser un protocole UDP donc et s'inspirer du fonctionnement des satellites (SAM en particulier) et avoir une communication d'état et non événementielle. Cela va bien avec l'UDP qui est léger mais où il y a un risque de perte de données.
Travaillez directement en ESP32, pas plus cher et commence à supplanter définitivement l'ESP8266 (dont certaine biblio ne sont même plus maintenues).
A mon sens, vous ne pourrez pas vous dispenser d'une gestion centralisée. Vous ne raisonnerez donc pas en n+1 ou n+2... mais en identifiants fixes avec une base de données qui peut être un simple tableau ou plus complexe.
Mais franchement, regardez y à deux fois entre ce type d'infrastructure qui nécessitera de toutes façon du filaire et une architecture basée sur les satellites !
Bien cordialement
Christophe.
-
Les communications réseau donc celles en WIFI, se font généralement avec le protocole TCP/IP (mais il existe un autre protocole moins utilisé UDP/IP). Avec le protocole TCP/IP il faut fonctionner en mode client/serveur :
- le serveur est démarré avant le client et attend la connection d'un client. On peut aussi avoir plusieurs clients.
- le client se connecte à un serveur.
Une fois que le client est connecté au serveur le client peut envoyer des messages au serveur ou en recevoir, avec des read et des write, le serveur peut envoyer des messages au client ou en recevoir, avec des read et des write.
Dans le cas présent chaque ESP doit être a la fois serveur et client, c'est à dire que chaque ESP va démarrer un serveur (disons un serveur de signal) et va se connecter au serveur de signal d'un autre ESP, chaque ESP peut alors communiquer avec 2 ESP (ceux des cantons adjacents) en lecture et/ou en écriture.
Je vais rechercher, j'ai un petit programme de serveur de boutons sur ESP32.
Pierre
-
Je ne pense pas que de travailler en client/serveur sur chaque ESP soit la bone solution. Pour moi il est préférable de centraliser la gestion. J'ai oublié de dire tout à l'heure que tous ceci devrait bien sûr communiquer à l'aide de websockets (pour avoir une communication bi directionnelle client -> serveur, serveur -> client) sans pour autant créer autant de serveurs de d'ESP.
-
Bonjour
Quelques remarques :
Certes l'UDP est plus simple, mais il y a toujours des risques de pertes de paquets ! avec TCP pas de risques.
Dans le cas présent il n'y a pas vraiment besoin de diffusion.
La bibliothèque WIFI des ESP cache (presque) complètement les sockets, et on a pas besoin de sockets pour écrire des applications simples comme c'est le cas ici..
Pour une fois que l'on peut se passer de centralisation, il ne faut pas se priver. Le mot serveur sur chaque ESP est un bien grand mot, c'est juste pour se conformer au modèle client/serveur.
Cordialement
Pierre
-
Voici un exemple prévu pour un M5stack, c'est un ESP32 avec un affichage LCD couleur, 3 boutons et plein d'autre choses.
L'exemple est un serveur de boutons, chaque fois que l'on appuie sur un (ou plusieurs) bouton(s) l'état des boutons est envoyé au client connecté, on pourrait facilement le transformer en serveur de signal.
Comme l'ESP est doté d'un affichage celui ci est utilisé pour afficher l'état WIFI et l'état du client, tout ce qui concerne l'affichage est dans un onglet séparé (affichage.h). Il faut aussi gérer l'affichage et les boutons, toutes les méthodes nécessaires sont préfixées par "M5".
Le programme serveur.ino
// LCD 320x240
// 16 bit/pixel color order (R:5-bit, G:6-bit, B:5-bit), 65,536 colors
IPAddress ip; // adresse ip du serveur
#include <WiFi.h>
#include <M5Stack.h>
#include "Affichage.h"
char ssid[]="WIFI MAC"; // nom du reseau
char pass[]="Ma phrase de securite"; // mot de passe WPA
WiFiServer server(22); // serveur sur le port 22
int status=WL_IDLE_STATUS; // etat connexion wifi
void setup() {
M5.begin();
afficher(false,false);
while (status!=WL_CONNECTED) { // connexion wifi
status=WiFi.begin(ssid, pass);
delay(5000);
}
server.begin(); // demarrage du serveur (config)
ip=WiFi.localIP(); // obtention de l'adresse ip du serveur
afficher(true,false);
}
void loop() {
WiFiClient client=server.available(); // test si client connecte
if (client) { byte data; int color; // client connecte
afficher(true,true);
while (client.connected()) { // boucle de traitement
data=M5.BtnA.read()*4+M5.BtnB.read()*2+M5.BtnC.read(); // lecture des boutons
client.write(data); // envoi au client
boutons(data);
delay(100);
}
afficher(true,false);
client.stop(); // client deconnecte
}
}
Si on veut des adresses IP fixes il faut changer "server.begin()"; en "server.config(...);"
Accessoirement le fichier faisant les affichages :
void afficher(boolean b1,boolean b2) { // affichage des messages
M5.Lcd.setTextColor(BLACK);
M5.Lcd.setTextFont(4);
M5.Lcd.fillScreen(WHITE);
M5.Lcd.setCursor(25,50);
if (!b1) {
M5.Lcd.print("Connexion WIFI ...");
return;
}
else {
M5.Lcd.print("Serveur : ");
M5.Lcd.print(ip);
}
if (b2) {
M5.Lcd.setTextColor(RED);
M5.Lcd.setCursor(25,100);
M5.Lcd.print("Client connecte");
}
}
void boutons(byte data) { int color; // affichage des boutons
if ((data&4)!=0) color=BLACK; else color=WHITE;
M5.Lcd.fillRoundRect(35,165,60,40,4,color);
if ((data&2)!=0) color=BLACK; else color=WHITE;
M5.Lcd.fillRoundRect(35+35+60,165,60,40,4,color);
if ((data&1)!=0) color=BLACK; else color=WHITE;
M5.Lcd.fillRoundRect(35+35+35+60+60,165,60,40,4,color);
}
Pierre
-
houla, TCP UDP , ce que font les modules WIFI entre eux, je m'en cogne un peu :P.
J'ai juste besoin de faire passer l’état d'une variable d'un ESP à un autre.
Dans mon cas pour un BAL: Si le BAL et sémaphore ou carré alors envoyer au BAL précédent "un truc" qui lui dit de se mettre au jaune , c'est tout.
ce que j'aimerai faire, c'est de remplacer une liaison série TX RX qui véhicule les variables d’état entre 2 Arduino par une liaison wifi.
Cdt
PS j'ai chaud
-
J'ai juste besoin de faire passer l’état d'une variable d'un ESP à un autre.
Dans mon cas pour un BAL: Si le BAL et sémaphore ou carré alors envoyer au BAL précédent "un truc" qui lui dit de se mettre au jaune , c'est tout.
ce que j'aimerai faire, c'est de remplacer une liaison série TX RX qui véhicule les variables d’état entre 2 Arduino par une liaison wifi.
C'est bien dans ce sens que va le programme ci dessus, il faut lui enlever tout ce qui est propre au "M5", tous les affichages, et remplacer l'état des boutons par l'état du signal. On ne peut pas faire moins sur un ESP.
Pierre
PS j'ai chaud aussi
-
Oui, j'ai vu après mon dernier post
Je m’attelle à l'adapter avec pour mon module, car la structure semble y être
Je reviendra vers vous
Merci à vous tous en tout cas
Cdt
-
Bonsoir,
J'ai essayer d'avancer mais je deviens ou je suis déjà maboule
Je tombe toujours sur cette erreur de compilation
request for member 'indexOf' in 'request', which is of non-class type 'char'
La compilation bloque ici >:(
if (request.indexOf("client.read") != -1) {
ci joint le code
(http://)
#include <ESP8266WiFi.h>
IPAddress ip(192,168,0,150);
IPAddress gateway(192,168,0,1);
IPAddress subnet(255,255,255,0);
WiFiServer server(80);
void setup() {
WiFi.disconnect();
delay(2500);
WiFi.config(ip, gateway, subnet);
WiFi.begin("mabox","monmotdepasse");
while (WiFi.status() != WL_CONNECTED) { delay(250); };
server.begin();
}
void loop() {
WiFiClient client = server.available();
if (!client) return;
while (!client.available()) { delay(1); }
char request = client.read();
client.flush();
if (request.indexOf("client.read") != -1) {
client.println("HTTP/1.1 200 OK");
client.println("Content-Type: text/html");
client.println("");
client.println("<!DOCTYPE HTML>");
client.println("<html>");
client.println("Test Ok");
client.println("</html>");
}
}
-
Bonjour,
request est un char, il est déclaré deux lignes au dessus. Ce n'est donc pas un objet et par conséquent il n'a pas de méthode indexOf.
-
Bonjour,
Pour faire communiquer plusieurs modules, il est sûrement plus simple d'utiliser une communication basée sur le protocole UDP plutôt que TCP.
https://www.tala-informatique.fr/wiki/index.php/Esp8266_udp_server
-
Bonjour
Pour faire communiquer plusieurs modules, il est sûrement plus simple d'utiliser une communication basée sur le protocole UDP plutôt que TCP.
UDP est plus simple, cependant UDP est un protocole non fiable, certes sur un réseau local c'est très relatif, mais peut-on garantir qu'il n'y aura pas perte ou inversion de paquets. S'il faut mettre en oeuvre des contrôles alors autant utiliser TCP, d'autant plus que le débit ici sera très très faible.
Pierrre
-
UDP est plus simple, cependant UDP est un protocole non fiable, certes sur un réseau local c'est très relatif, mais peut-on garantir qu'il n'y aura pas perte ou inversion de paquets. S'il faut mettre en oeuvre des contrôles alors autant utiliser TCP, d'autant plus que le débit ici sera très très faible.
Il ne s'agit pas de contrôle mais simplement d'une répétition du message comme c'est le cas sur les satellites (avec SAM) ou encore en DCC où les commandes sont répétées une dizaine de fois si je ne m'abuse. A fortiori si le débit est très faible, cela ne pose pas de problèmes à répéter le message.
-
Bonjour,
J'ai fait des test longue durée sur une communication en UDP entre mon Mac et un Weimos Mini D1 (ESP8266) pour un truc qui n'a rien à voir avec le modélisme ferroviaire. Le Mac envoyait un message toutes les 10s avec un numéro d'ordre. Le Mini D1 incrémentait de son côté un compteur et le comparait avec le numéro d'ordre pour voir si un message était perdu. L'ensemble a tourné pendant 3 jours.
Résultat : 12% des messages sont perdus, ce qui est bien au dessus de ce qui est attribuable au fait que l'UDP ne fait pas d'acquittement. On va dire que la communication en UDP sur un ESP8266 marche jusqu'à un certain point mais que bon c'est très très loin d'être fiable.
Donc ne pas hésiter à répéter les messages.
Par ailleurs, j'avais aussi fait quelques tests, mais de manière plus informelle, avec un serveur http sur le même Weimos Mini D1. Le serveur répond un peu quand ça lui chante : des requêtes qui n'aboutissent pas ou qui aboutissent après un délai important. Je ne saurais dire la proportion d'échec mais c'est loin d'être négligeable. J'ai pas encore essayé les websocket.
-
Bonjour à tous,
Une application du protocole UDP est la diffusion d'un même message à plusieurs destinations (broadcast). Cela peut être utile pour détecter dynamiquement les systèmes connectés au réseau. Ensuite, une fois les systèmes connus, on peut établir des connexions TCP avec ces derniers. Dans l'IT, on voit souvent des applications à l'écoute en TCP et en UDP sur le même numéro de port.
Bonne journée et meilleures salutations.
-
Bonsoir,
J'ai du mal a avancer - Je rappele que ce systeme fonctionne parfaitement en filaire.
Je souhaite remplacer les fils par des liaisons WIFI
J'ai fait un petit schéma pour bien comprendre le fonctionnement attendu.
La seule chose que j'ai réussi à faire c'est ceci
Page WEB 192.168.0.150/R (simulant un ESP BAL'C' du schéma) l'ESP BAL'B' recoit R , envoi une variable Avertissementon à son arduino et retourne AV à la page WEB
Page WEB 192.168.0.150/JV (simulant un ESP BAL'C' du schéma) l'ESP BAL'B' recoit JV , envoi une variable Avertissementoff à son arduino et retourne VL (voie libre) à la page WEB
Le reste je sais pas par quel bout le prendre. un ESP peut-il recevoir depuis 2 IP différentes sans forcément demander une requête ?
C'est peut être pas possible de faire cela en WIFI.
Si quelqu'un à un début de solution de codage (fu fu fu fu !!!!)
Ou puis-je trouver des infos sur les fonctions type server.send server.on notamment ce que doit contenir les parenthèses, j'ai fouillé sans succès (Dans les librairies?)
Bonne soirée
#include <ESP8266WiFi.h>
#include <WiFiClient.h>
#include <ESP8266WebServer.h>
#include <ESP8266mDNS.h>
IPAddress ip(192,168,0,150);
IPAddress gateway(192,168,0,1);
IPAddress subnet(255,255,255,0);
const char* ssid = "******";
const char* password = "*****";
ESP8266WebServer server(80);
void setup(void){
Serial.begin(115200);
// on demande la connexion au WiFi
WiFi.config(ip, gateway, subnet);
WiFi.begin(ssid, password);
Serial.println("");
// on attend d'etre connecte au WiFi avant de continuer
while (WiFi.status() != WL_CONNECTED) {
delay(500);
Serial.print(".");
}
// on affiche l'adresse IP qui nous a ete attribuee QUE J'AI CHOISI (IP fixe)
Serial.println("");
Serial.print("IP address: ");
Serial.println(WiFi.localIP());
server.on("/R", [](){
server.send(200, "text/plain", "AV");
Serial.println("Signal ferme");
});
server.on("/JV", [](){
server.send(200, "text/plain", "VL");
Serial.println("Signal ouvert");
});
// on commence a ecouter les requetes venant de l'exterieur
server.begin();
}
void loop(void){
// a chaque iteration, on appelle handleClient pour que les requetes soient traitees
server.handleClient();
}
Le code n'est pas de moi, mais je l'ai adapté à mon besoin.
-
Bonjour Giorgio-arduino,
Ou puis-je trouver des infos sur les fonctions type server.send server.on notamment ce que doit contenir les parenthèses, j'ai fouillé sans succès (Dans les librairies?)
server.on("/R", [](){
server.send(200, "text/plain", "AV");
Serial.println("Signal ferme");
});
Pour bien comprendre ce qu'il faut écrire entre les parenthèses et plus précisément entre les crochets ou les accolades fait au préalable une recherche sur les fonctions lamda.
Ce qui est écrit ci-dessus, pourrais s'écrire ainsi en plus lisible (et fonctionnant aussi bien) sans lambda:
void handle_R();
...
setup()
{
...
server.on ("/R", handle_R); // handle_R pour "handle répondant à la commande /R" par exemple
...
}
void handle_R()
{
.... quelquechose à faire ici !! Allumer les led d'un signal...
server.send(200, "text/plain", "AV");
Serial.println("Signal fermé");
}
Ceci dit il ne se passe rien dans handle_R en dehors du fait que le server renvoie un "accusé de réception".
Pour avancer un peu va voir ce site (in english) https://tttapa.github.io/ESP8266/Chap01%20-%20ESP8266.html (https://tttapa.github.io/ESP8266/Chap01%20-%20ESP8266.html)
-
Merci pour cet info sur server.on et send
J'avais déjà compris que mes variables à traiter se trouveraient après serveur.on
Maintenant je sais qu'après la virgule du server.on("*", fonction), on peut y mettre un fonction qui exécute des lignes de code , comme mettre un GPIO à 1
et le /R c'est quoi? existe -il d'autres termes ?
Mes carences en codage me font défaut sur ce projet. Il est loin mon BASIC 2.0 du C64!
Je regarderai le lien sur l'ESP.
Merci
-
Bonjour,
le "/R" est le chemin après l'IP.
Par exemple si le serveur est à l'IP 192.168.1.1, accéder à http://192.168.1.1/R avec ton navigateur te renverra "AV"
Ceci dit, je ne pense pas que faire tourner un serveur web pour communiquer soit la bonne solution (à vrai dire ça n'est pas du tout comme ça qu'il faut faire), il vaudrait mieux communiquer directement avec les sockets. Cherche "ESP32 socket examples" tu trouveras des tutos, par exemple : https://techtutorialsx.com/2018/05/25/esp32-socket-server-controlling-a-relay-remotely/
-
Bonjour
Voila une ébauche de ce que pourrait être la communication entre ESP pour le BAL.
On est ici en TCP donc avec le modèle client serveur.
Chaque ESP est à la fois serveur (pour un autre ESP) sur le port 2222 et client (d'un autre ESP).
Le serveur reçoit un octet d'un ESP et le transmet à un autre ESP (trois ESP).
IPAddress ipLocal; // adresse ip du serveur local
#include <WiFi.h>
char ssid[]="WIFI MAC"; // nom du reseau
char pass[]="Ma phrase de securite"; // mot de passe WPA
WiFiServer serveur(2222); // serveur sur le port 2222
int status=WL_IDLE_STATUS; // etat connexion wifi
WiFiClient client;
IPAddress ipDistant(192,168,1,13); // adresse ip du serveur distant
void setup() {
Serial.begin(9600);
Serial.println("Essai de connexion wifi");
while (status!=WL_CONNECTED) { // connexion wifi
status=WiFi.begin(ssid, pass);
delay(5000);
}
Serial.println("Serveur connecte wifi");
serveur.begin(); // demarrage du, serveur
ipLocal=WiFi.localIP(); // obtention de l'adresse ip du serveur
serveur.begin(); // demarrage du serveur 2222
Serial.println(ipLocal);
while (!client.connect(ipDistant,2222)) { Serial.print("."); delay(100); }
Serial.println();
Serial.println("Client connecte au serveur distant 2222");
Serial.println(ipDistant);
Serial.println("Attente de connexion au serveur local 2222");
}
void loop() {
WiFiClient clientDuServeur=serveur.available(); // test si clientDuServeur connecte
if (clientDuServeur) { unsigned char data; int color; // clientDuServeur connecte
Serial.println("Client connecte au serveur local 2222");
while (clientDuServeur.connected()) { // boucle de traitement
if (client.available()>=1) {
data=client.read();
Serial.print((int)data); Serial.print(" ");
clientDuServeur.write(data);
}
delay(100);
}
Serial.println("Client deconnecte au serveur local 2222");
clientDuServeur.stop(); // clientDuServeur deconnecte
}
}
C'est assez difficile à comprendre, mais cela fonctionne bien (sur un ESP32), avec un Mac pour simuler les deux autre ESP (je n'ai qu'un ESP32).
Ce n'est pas complètement au point s'il y a des déconnections entre les clients et les serveurs.
Cordialement
Pierre
PS fait petite correction sur les n° de port 22 est devenu 2222 (le port 22 n'est pas utilisable sur Mac).
-
Bonjour,
Après plusieurs très longues soirées, le principe de fonctionnement est OK
Je suis tombé au grès de mes recherche sur le site easycoding.tn (et là c'est bingo pour moi)
Ce qui m'a permis de m'affranchir du codage
Le principe que je recherchai est en fait pas si complexe que je l'imaginai.
Si l'ESP reçoit BalR (venant du N+1), il affiche "Recu Rouge" et ici je pourrai envoyer un variable vers l'Arduino NANO via une liaison série pour mettre de BAL au Jaune
Comme le BAL N était au rouge et passe au jaune, il envoi à l'ESP N-1 (ip192.168.0.150) BalJ, qui mettra le BAL N-1 en Voie libre.
Voila, je ne clôture pas ce sujet car je communiquerai sur le passage de mon réseau du filaire vers le WIFI. puisque j'en ai à présent le principe.
Reste à mettre en vis à vis, les ARDUINO NANO de contrôle BAL avec les ESP qui leurs seront associés.
Je reste à votre écoute, bon gré , un départ en vacances imminent. 8)
Un grand merci à ceux qui ont participé à ce post, j'ai lu plein de choses intéressantes dans vos commentaires. ;)
Georges
-
Bonsoir,
C'est fait, le BAL en WIFI, ça marche, et ça ouvre des perspectives de réalisation de réseau modulaire avec très peu de câbles.
C'est idéal pour faire un réseau démontable. Il suffira d'amener sur chaque module du 5v et du 12V
Et je vous parle même pas des commandes d’aiguille avec servo , pareil du 5V un arduino wifi c'est tout
le pilotage des appareils de voies et de décor peuvent même se faire avec une tablette, puisque tout se pilote avec des variables.
Je ferais ce WE une vidéo du BAL WIFI qui m'a servi pour réaliser la mise au point.
Cout d'un BAL WIFI avec Feu imprimé 3D , environ 10 euros. (Nano + ESP-01)
Bonne nuit.
-
Bonjour Georges,
Peux tu publier le code arduino que tu as utilisé finalement pour les ESP ?
-
Bonsoir,
1- Comme expliquer auparavant, j'ai simulé le bal N+1 par envoi de commande depuis un navigateur Exemple http://192.168.0.151/ICr qui commande l'Arduino nano de passe au Carré "ICr"= Interrupteur cmd Carré On ; "Icr"= Interrupteur Carré Off.
Ce que fait l'ESP-01 c'est uniquement recevoir les cmd depuis HTTP est de les envoyer vers l'Arduino sous forme de txt via une liaison série, et en fonction des textes reçu le BAL se mets au rouge , au jaune ,Marche réduite , enfin tout ce qu'un feu SNCF peu signaler
2- Il faut que je m’attelle à présent à renvoyer des ordres d’état du BAL (Arduino Nano) vers son ESP qui enverra un texte type ("LRoV1" pour LED ROUGE on VOIE 1 'Allumer'), ce qui ordonnerra au BAL N-1 de se mettre au jaune. MAIS CA C'EST PAS ENCORE FAIT.
Ce ne sera qu'un texte lu sur le port série de l'ESP. Ce texte sera envoyé via un IP vers un autre BAL
Plutôt que du code , voici le logigramme établi sous TUNIOT (http://easycoding.tn/tuniot/demos/code/?lang=fr)
Vous pouvez le reproduire et visualiser ainsi le code que vous aurez copier dans l'IDE ARDUINO
En prime une petite photo du montage réaliser avec un BAL imprimer 3D mais cassé (Il me sert de BANC TEST)