Hello,
Je vais changer mon mode de chauffage. Combien peut se revendre une remora 1.3 nodemcu ?
@+
Hello,
Je vais changer mon mode de chauffage. Combien peut se revendre une remora 1.3 nodemcu ?
@+
Je n'ai pas encore eux le temps d'apprivoiser ces modifications.
En tout cas, je viens de connecter la téléinfo sur la remora... enfin depuis 2 jours elle y est.
Aie, elle me fait du délestage en plus de jeedom...
Demain je lui retire sa teleinfo tant que je n'ai pas ajouté un petit booleen quelque part pour autoriser ou non le delestage par la remora.
Je vais certainement ouvrir un nouveau sujet dès que j'ai un peu de temps et tu aura la réponse du pourquoi du DHT22.
Merci Charles de ta réponse.
Je dispose de 3 autres nodemcu (pas de lua mais du c) que j'exploite comme sondes à base de DHT22. Pour le moment, ce projet de sonde est en standby car j'attends les DHT22.
C'est en travaillant sur ce projet, qui sera partagé, que j'ai été confronté à ce problème de non-reconnexion au réseau wifi.
Je me suis basé sur un mix de code du remora et d'un exemple de lecture du DHT22 pour réaliser mon système.
Et du coup, au départ, je pensais que c'était mon code des sondes qui n'était pas bon.
Alors j'ai flashé mes 3 nodemcu avec le code remora 1.3.1.
Chacun avec une IP Fixe.
Le PC en client DHCP est connecté en filaire sur un commutateur lui même relié au routeur, qui fait aussi point d'accès wifi.
Tests effectués :
1 - lancer un ping sur les 3 nodemcu
2 - renommer le nom du réseau Wifi...
3 - les nodemcu ne pingent plus, tout va bien.
4 - apres quelques minutes, des réseaux Wifi Remora220, 221 et 222 (hostname = 4eme octet de l'IP fixe) apparaissent
5 - 5 minutes apres, je remet le nom initial du réseau Wifi
6 - ... rien ne se passe, les remora restent en mode AP autonome
7 - inutile, mais je redémarra le routeur/ap wifi ... idem, rien ne se passe
8 - redemarrage d'une des remora (la 220) ... et elle se reconnecte bien et reping bien
9 - je redemarre le routeur, et pendant qu'il redémarrage, un nouveau réseau Wifi apparait Remora220
10 - malgrès quelques minutes après le routeur du réseau Wifi du routeur ... retour au point N°6
Donc j'en au conclus qu'une fois basculé en mode softAP... ils y restent.
D'ailleurs pendant ces tests, ma vraie remora elle est aussi revenue en mode softAP et j'ai été contraint de la redémarrer manuellement aussi.
Voici pourquoi j'ai effectué les modifications que je vous présente ci-dessous :
**
Fonction WifiHandleConn : **
int WifiHandleConn(boolean setup = false)
{
int ret = WiFi.status();
uint8_t timeout ;
if (setup) {
Serial.print(F("========== SDK Saved parameters Start"));
WiFi.printDiag(Serial);
Serial.println(F("========== SDK Saved parameters End"));
///////////////////////// AJOUT DANY
IPAddress ip(192,168,50,251);
IPAddress gateway(192,168,50,254);
IPAddress subnet(255,255,255,0);
WiFi.config(ip, gateway, subnet);
///////////////////////// AJOUT DANY
#if defined (DEFAULT_WIFI_SSID) && defined (DEFAULT_WIFI_PASS)
Serial.print(F("Connection au Wifi : "));
Serial.print(DEFAULT_WIFI_SSID);
Serial.print(F(" avec la clé '"));
Serial.print(DEFAULT_WIFI_PASS);
Serial.print(F("'..."));
Serial.flush();
WiFi.begin(DEFAULT_WIFI_SSID, DEFAULT_WIFI_PASS);
#else
Serial.print(F("Connection Wifi avec les parametres sauvegardes "));
#endif
timeout = 25; // 25 * 200 ms = 5 sec time out
// 200 ms loop
while ( ((ret = WiFi.status()) != WL_CONNECTED) && timeout )
{
// Orange LED
LedRGBON(COLOR_ORANGE);
delay(50);
LedRGBOFF();
delay(150);
--timeout;
}
// connected ? disable AP, client mode only
if (ret == WL_CONNECTED)
{
Serial.println(F("connecte!"));
WiFi.mode(WIFI_STA);
Serial.print(F("IP address : ")); Serial.println(WiFi.localIP());
Serial.print(F("MAC address : ")); Serial.println(WiFi.macAddress());
// not connected ? start AP
} else {
///////////////////////// AJOUT DANY
Serial.println("");
Serial.println("Connexion Wifi impossible, Redemarrage automatque");
ESP.wdtDisable();
ESP.restart();
///////////////////////// AJOUT DANY
///////////////////////// SUPPRESSION DANY
/*
char ap_ssid[32];
Serial.print(F("Erreur, passage en point d'acces "));
Serial.println(DEFAULT_HOSTNAME);
// protected network
Serial.print(F(" avec la clé '"));
Serial.print(DEFAULT_WIFI_AP_PASS);
Serial.println("'");
Serial.flush();
WiFi.softAP(DEFAULT_HOSTNAME, DEFAULT_WIFI_AP_PASS);
WiFi.mode(WIFI_AP_STA);
Serial.print(F("IP address : ")); Serial.println(WiFi.softAPIP());
Serial.print(F("MAC address : ")); Serial.println(WiFi.softAPmacAddress());
*/
///////////////////////// SUPPRESSION DANY
}
// Set OTA parameters
ArduinoOTA.setPort(DEFAULT_OTA_PORT);
ArduinoOTA.setHostname(DEFAULT_HOSTNAME);
ArduinoOTA.setPassword(DEFAULT_OTA_PASS);
ArduinoOTA.begin();
// just in case your sketch sucks, keep update OTA Available
// Trust me, when coding and testing it happens, this could save
// the need to connect FTDI to reflash
// Usefull just after 1st connexion when called from setup() before
// launching potentially buggy main()
for (uint8_t i=0; i<= 10; i++) {
LedRGBON(COLOR_MAGENTA);
delay(100);
LedRGBOFF();
delay(200);
ArduinoOTA.handle();
}
} // if setup
return WiFi.status();
}
Fonction loop
/* ======================================================================
Function: loop
Purpose : boucle principale du programme
Input : -
Output : -
Comments: -
====================================================================== */
void loop()
{
static bool refreshDisplay = false;
static bool lastcloudstate;
static unsigned long previousMillis = 0; // last time update
unsigned long currentMillis = millis();
bool currentcloudstate ;
// our own setup
if (first_setup) {
mysetup();
first_setup = false;
}
// Gérer notre compteur de secondes
if ( millis()-previousMillis > 1000) {
// Ceci arrive toute les secondes écoulées
previousMillis = currentMillis;
uptime++;
refreshDisplay = true ;
}
#ifdef MOD_TELEINFO
// Vérification de la reception d'une 1ere trame téléinfo
tinfo_loop();
_yield();
#endif
#ifdef MOD_RF69
// Vérification de la reception d'une trame RF
if (status & STATUS_RFM)
rfm_loop();
_yield();
#endif
#ifdef MOD_OLED
// pour le moment on se contente d'afficher la téléinfo
screen_state = screen_teleinfo;
// Modification d'affichage et afficheur présent ?
if (refreshDisplay && (status & STATUS_OLED))
display_loop();
_yield();
#endif
// çà c'est fait
refreshDisplay = false;
#if defined (SPARK)
// recupération de l'état de connexion au cloud SPARK
currentcloudstate = Spark.connected();
#elif defined (ESP8266)
// recupération de l'état de connexion au Wifi
currentcloudstate = WiFi.status()==WL_CONNECTED ? true:false;
#endif
// La connexion cloud vient de chager d'état ?
if (lastcloudstate != currentcloudstate)
{
// Mise à jour de l'état
lastcloudstate=currentcloudstate;
// on vient de se reconnecter ?
if (currentcloudstate)
{
// on pubie à nouveau nos affaires
// Plus necessaire
#ifdef SPARK
// spark_expose_cloud();
#endif
// led verte
LedRGBON(COLOR_GREEN);
}
else
{
// on compte la deconnexion led rouge
my_cloud_disconnect++;
Serial.print("Perte de conexion au cloud #");
Serial.println(my_cloud_disconnect);
LedRGBON(COLOR_RED);
///////////////////////// AJOUT DANY
Serial.println("");
Serial.println("Redemarrage automatque");
ESP.wdtDisable();
ESP.restart();
///////////////////////// AJOUT DANY
}
}
//#ifdef SPARK
//char buff[64];
//int len = 64;
// process incoming connections one at a time forever
//server.processConnection(buff, &len);
//#endif
// Connection au Wifi ou Vérification
#ifdef ESP8266
// Webserver
server.handleClient();
ArduinoOTA.handle();
if (task_emoncms) {
emoncmsPost();
task_emoncms=false;
} else if (task_jeedom) {
jeedomPost();
task_jeedom=false;
}
#endif
}
J'utilise l'Arduino IDE 1.6.7, je vais essayer et étudier ta nouvelle version du WifiHandleConn ce soir.
Pour passer les optos en 3V3, j'ai suivi la documentation de Charles :
https://community.hallard.me/topic/103/problème-de-fils-pilotes-passer-les-optos-en-3-3v
Dans ce cas, il s'agit du régulateur interne au nodemcu qui assure la régulation 3V3. Ce qui n'est pas forcement optimal. Je fournis légèrement plus que 5V sur l'alimentation, je dois être a 5.1V mais pas plus.
Depuis, je n'ai pas de soucis. J'ai aussi pour essayer, alimenté au cul du raspberry d'USB à USB du nodemcu... et je n'ai pas eu de soucis.
Enfin pour récupérer l'uptime, au début je lisais la réponse json "_UPTIME" de la requête /tinfo.
Puis, j'ai soumis une idées d'avoir une requête /uptime dédié qui retourne seulement et directement cette valeur (en json toujours), idée mise en oeuvre par Charles.
Aujourd'hui, le seul problème que j'ai c'est la non reconnexion au wifi automatique en cas de perte de la box/routeur/ap.
J'ai alimenté les optocoupleurs en 3v3 ou lieu de 5v.
L'alimentation est assurée par les bornier... J'ai eu 13j d'ultimes pour le moment.
Les ordres envoyés par jeedom ne sont pas répétés et tout fonctionne très bien.
Je suis d'accord que répéter les ordres, c'est du bricolage. Je les repetes quand je lis un uptime de moins de 2 minutes uniquement, ce qui n'est pas encore arrivé.
Quelle tension a tu sur ton 5v ?
Il y a une évolution que j'essaye d'apporter à remora.
Je souhaite que la remora se reconnecte automatiquement quand le reseau wifi n'est pas disponible, reboot du point d'accès, demarrage du remora avant le point d'accès, etc ...
Dans la boucle de loop, je rajoute ceci qui fonctionne :
// Si perte de la connection au reseau wifi, redemarrage automatique
if (WiFi.status() != WL_CONNECTED) {
Serial.println("Perte de la connection au reseau Wifi");
Serial.println("Redemarrage automatique");
ESP.wdtDisable();
ESP.restart();
}
Parce que je voulais aussi essayer de ne pas rebooter la remora mais mon code ici ne fonctionne pas ... :
IPAddress ip(192,168,50,251);
IPAddress gateway(192,168,50,254);
IPAddress subnet(255,255,255,0);
WiFi.config(ip, gateway, subnet);
WiFi.begin(DEFAULT_WIFI_SSID, DEFAULT_WIFI_PASS);
Serial.print("Reconnexion au reseau Wifi en cours");
while (WiFi.status() != WL_CONNECTED) { // Attente de la connexion au reseau Wifi, redemarrage automatique
delay(500);
Serial.print(".");
}
Note, je test en redémarrant le point d'accès logicielement.
@Fab_33 said:
D’où l'avantage de pouvoir désactiver le délestage (une option)
Dans mon cas, la teleinfo n'est pas connectée sur la remora donc la mécanique de délestage du remora ne se mettra jamais en oeuvre.
Mais effectivement, les zones a délester doivent pouvoir être choisie, ainsi que la durée avant un nouvel état des lieux afin de savoir si on réactive ou pas.
Il faudrait faire une mécanique en lot sur lesquelles on assigne ou non des zones.
Au premier besoin de délester, on désactive un lot de x zone(s)
Au second, on attaque le second lot, etc ...
Sans forcément avoir 50 lots ... déjà 3, c'est déjà suffisant.
Ce que je fais en fait, c'est d'utiliser jeedom pour gérer le délestage.
Si je détecte que j'approche des 6kVA, je déleste manuellement en ordonnant aux thermostats de Jeedom qui pilote la chauffe des radiateurs de les passer en mode H.
Je ne me sert de la remora que pour envoyer le signal sur les fils-pilotes.
Version logicielle 1.3.1 dans la remora
Version beta du plugin jeedom
Les ordres fonctionnent mais les status ne remontent pas.
Heu... je crois avoir vu un message la première fois avec Arduino IDE qu'il fallait que le dossier se nomme remora_soft et pas remora_soft_master..
Dans le fichier remora.h, juste en dessous des parametres Wifi, j'ajoute ceci :
// Définir ici les parametres IP
// de connexion à votre réseau Wifi
// =====================================
#define DEFAULT_WIFI_IP_FIXE // commenter cette ligne pour rester en adresse IP dynamique
IPAddress ip(192,168,50,251);
IPAddress masque(255,255,255,0);
IPAddress passerelle(192,168,50,254);
IPAddress dns1(192,168,50,254);
Dans le fichier remora_soft.ino, dans la fonction "WifiHandleConn", ajout :
Serial.println(F("========== SDK Saved parameters End"));
APRES LA LIGNE CI DESSUS , AJOUT DE :
#ifdef DEFAULT_WIFI_IP_FIXE
WiFi.config(ip, dns1, passerelle, masque);
#endif
EDIT et j'obtiens des erreurs de compilation sur un type non défini :
remora.h:80: error: 'IPAddress' does not name a type
IPAddress ip(192,168,50,251);
^
Merci Charles,
J'aurai aussi une autre modification mais je galère un peu pour le moment.
En fait, je voudrais que dans le remora.h, fichier qui contient les variables initiales, on puisse spécifier le mode d'IP réseau dhcp ou fixe (avec les parametres associés).
Mais je ne désespère pas y arriver et proposer ici cette modification.
J'ai fais une modification du code afin d'avoir l'uptime via /tinfo même si la télé information est désactivée (fonction tinfoJSON) :
J'ai essayé de modifier le code du webserver (fonction handleNotFound) pour qu'il réponde sur /uptime :
J'ai alimenté en 3.3v les optocoupleurs, via le régulateur du nodeMCU.
Le remora est alimenté via l'USB du nodeMCU lui même alimenté par le Raspberry Pi 2 de jeedom.
L'uptime est plutôt bon, plusieurs jours déjà.
Je pense tester des résistances de 1k, il faut juste que j'aille les chercher au magasin électronique à 300m.
Je me demande si on aurait pas meilleur temps de remplacer l'alimentation 5 par une 3.3...
Je vais essayer dans la soirée, j'ai récupéré un pc de bureau avec un bloc qui fournit les 2 tensions.
Je couperai la piste des optocoupleurs, une soudure et jalimente en 3.3 depuis le bornier.
C'est ce à quoi je pense. Ce qui nécessite un travail côté logiciel.
Regarde coté alimentation, essaye de le faire fonctionner avec une alimentation de smartphone, sans celle du tableau.
Soit le régulateur qui alimente la puce esp est fatigué, soit c'est ton alimentation en rail din,est elle a 5v en charge ?
Sinon c'est une instabilité logicielle...
J'utilise l'alimentation en rail din qui alimente une batterie avec deux ports usb, un pour Remora, l'autre pour jeedom.
Aucun problème. Remora alimenté par le port usb du nodemcu et pas par le bornier.
C'est une installation temporaire pour le moment.
H est l'état post boot.
Donc ton remora à redémarré.
Quand ceci arrive, que seul le remora pilote tu peux te retrouver mal (froid alors que tu demande de chauffer) . Quand remora n'est utilisé que comme interface fil pilote, le problème est limité.
Charles, Est-ce que remora (nodemcu) dispose d'un stockage persistant après arrêt/reboot ?
Je finierai ça début d'année. Pour le moment c'est Noël.
J'ai aussi fait des mesures hors phase, avec une simple pile de 9v pour le moment.
Je soupçonne aussi les optocoupleur de dysfonctionnes.
Je finierai les tests semaine prochaine.
Tu peux m'indiquer ce que tu as effectué comme modification ?
Oula, j'ai deux radiateurs qui sont en mode confort sur lesquels les relais n'arrêtent pas de commuter.
La cause : la remora ne bloque pas le courant en sortie (confort = aucun signal).
J'ai parfois 10 50 120 et 230V... Les valeurs changent en permanence
En mode H A et E pas de soucis... D'ailleurs je me demande si en E le radiateur affiche un comportement particulier.
Ce qui est étrange c'est que ce n'est pas le jeedom qui envoi des ordre, ce que j'ai commencé par croire, je l'ai donc déconnecté du réseau pour qu'il ne donne plus d'ordre au remora.