Remora V1.3 NodeMCU Nouvelle Version Logicielle + API Locale

Charles

Oui sur ESP8266 un truc dans le genre dans la fonction WifiHandleConn()

    Serial.print(F("========== SDK Saved parameters Start")); 
    WiFi.printDiag(Serial);
    Serial.println(F("========== SDK Saved parameters End")); 

    IPAddress ip(192,168,1,111);
    IPAddress gateway(192,168,1,1);
    IPAddress subnet(255,255,255,0);
    WiFi.config(ip, gateway, subnet);

D'ailleurs pour toutes questions sur les API/fonctions de l'ESP8266 je vous conseille vivement la documentation de référence ici

Dany21000

Merci Charles.

Je vais la potasser car j'ai un projet que je présenterai ici aussi pour lequel, il me faudra maitriser la bete.

Concernant le réglage ip fixe, config s'écrit sans majuscule au C.
Remora installée et câblée à la sauvage, fonctionnelle avec 4 FP d'utilisé (6 sont câblés) mais par de radiateurs au bout.

Teleinfo désactivée et non gérée par remora mais par jeedom qui dispose d'un modem téléinfo dédié.

La gestion du relais sera utilisée différement dans un premier temps :
Un contact J/N est en place, le relais remora sera mis en série (COM et NF) avec le relais du compteur EDF.
L'objectif n'est pas d'utiliser le relais remora pour activer le contact J/N.
Il sera utilisé ici pour couper le contact J/N dans un cas précis : période creuse ET atteinte l'intensité maximale moins 10A (résistance cumule de 2400W).

Voilà.

Je vais travailler avec lunarok pour avancer sur le plugin jeedom avec cet esp8266.

alban

@Charles

Merci pour ton complément.
J'ai mis ce code, et j'ai pu récupérer l'adresse MAC et l'inscrire dans ma liste blanche, et coller ainsi au nodeMCU un bail statique

Cependant, au moment du téléversement, j'ai l'erreur vue plus haut :

warning: espcomm_sync failed
error: espcomm_open failed

J'ai pas mal galeré, et finalement j'ai changé mon cable USB, et appuyé une fois sur reset pour effectuer le téléversement ... coup de chance ?

Concernant l'adresse MAC, lorsque regarde la console série (Merci coolTerm au passage), 2 adresses MAC apparaissent, très proche l'une de l'autre :

la première est liée au réseau AP
la seconde est liée à notre réseau Wifi

Enfin pour terminer sur ce point, l'outil esptool.py vous fournit une troisième adresse MAC (sans doute constructeur) avec la commande :

$ esptool.py --port XX --baud XX read_mac

Il ne me reste plus qu'à mettre le nodeMCU à la place du Core et attendre la mise à jour du plugin dans jeedom

Domheesy

Bonsoir!

J'ai monté ce jour mon REMORA et je bloque pour la programmation de l'ESP.
Dans l'IDE Arduino je ne vois pas le port COM pour dialoguer avec l'ESP.
Pour info je suis sous OSX El Capitan. L'ESP fonctionne bien car il me créé un réseau WIFI du type AI-THINKER_xxxxx.
De plus dans les préférences système, je vois bien apparaitre CP2102 USB to UART Bridge Contrôler dans l'arborescence USB et l'emplacement est 4.
L'ESP est relié uniquement par un câble USB/micro-USB au MAC.

Si quelqu'un a un début de solution, je suis preneur. Merci

Charles

Tu as regardé sur le forum silabs pour des driver el capitan ?
http://community.silabs.com/t5/Interface/OS-X-10-10-CP210x-VCP-Driver-Release-Candidate/td-p/138472/page/2
En fin de page tu as une release candidate, peut-être à essayer ?

Domheesy

Merci de l'info Charles, ça marche beaucoup mieux effectivement.

Je vais pouvoir tester toutes les fonctionnalités et développer d'autres choses (xPL, ajout horloge I2C, ...)

alban

@Charles

Dans le retour d'info de la téléinfo, à quoi correspond les 2 derniers paramètres MOTDETAT et MAT ?

"_UPTIME":5251,"ADCO":xxxxxxxxxxx,"OPTARIF":"HC..","ISOUSC":60,"HCHC":58316761,"HCHP":78312403,"PTEC":"HP..","IINST":11,"IMAX":47,"PAPP":2450,"HHPHC":"D","MOTDETAT":400000,"MAT":400000

EDIT : après une bonne heure de fonctionnement j'ai ça :

{
"_UPTIME":14523,"ADCO":xxxxxxxxxxx,"OPTARIF":"HC..","ISOUSC":60,"HCHC":58316761,"HCHP":78316938,"IINST":2,"IMAX":47,"PAPP":480,"HHPHC":"D","MOTDETAT":400000,"MAT":400000,"IMAHHPHC":"D","PTEC":"HP..X","OF":"HC.."
}

Les derniers élements semblent étranges.

EDIT 2 : Il y a un vrai souci. Le rendu n'est pas un json, et les données se mélangent au bout d'un moment.

francky50

@Dany21000 , un grand merci a toi pour ton partage qui m'a permis de finir mon flashage du nodeMCU.
Et ne pas oublier de sortir le nodeMCU de la carte Remora avant de flasher sinon çà fonctionne pas.

Dany21000

Je finierai ça début d'année. Pour le moment c'est Noël.

omyxcol

Bonjour à tous.
Petit retour sur les derniers essais
Apres avoir configuré mon réseau pour acceder depuis l'extérieure à mon super kit 1.3, je peux via des raccourcis basiques organisés sur une page de mon téléphone piloter mon remora evrywere. Cependant lorsque je lance une requête de type "arret total http....aaaaaaa" dans les minutes suivantes, je verifie avec "fp" tout est à "A". Mais le lendemain les fp sont "H" et idem pour le relais qui repasse à "0". Y a t il dans le code une condition pour remettre des valeurs par défaut?

Dany21000

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 ?

omyxcol

Merci il reboot souvent alors, je viens de regarder il est encore en mode post boot (7 fp à H et relais 0). Il y a environ 8h j avais envoyé une toute autre commande et j'avais vérifié que l'ordre était bien passé. Je ne connais pas bien cette puce mais il y a peut être un peu de flash dispo pour mettre un fichier conf.ini à jour à chaque ordre envoyé. Puis on le lit post boot. J'ai déjà fait ce genre de truc pour une puce mbed.

Dany21000

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.

bsheep

Bonsoir, pour savoir si remora à rebooté il y a l étiquette virtuelle _UPTIME qui est disponible dans l url /tinfo.

Elle correspond au nombre de secondes depuis que remora est démarrée.

Pour info, je suis à 3j d' UPTIME.

omyxcol

Merci pour cette info précieuse. Je viens de lancer une requête sur ce label et bingo à peine 2h depuis le dernier reboot. Des mon retour je vérifierai le 5v sous charge de l alimentation rail din et le reste???. Je ne manquerai pas de vous tenir informé sur la cause de ces resets. Si ça marche chez vous ça marchera chez moi!

omyxcol

Hello
Je pense avoir trouvé à distance la cause de mes resets... je me suis dit passons les fp en confort histoire de ne plus alimenter les optos. Comme par hasard le compteur est à plus de 10h. Donc ça veux dire que je ne vais pas être le seul, potentiellement ceux qui comme moi ont les optos blancs sur le 3.3v (cf le post sur les problèmes de fp) vont avoir le problème. Ça sent le changement des optos pour à nouveau les alimenter en 5v, ou un bon vieux régulateur 3.3v à souder avec des fils au niveau du jumper opto (il y a du 5v, le départ de l alimentation des optos il ne reste plus qu'à prendre une masse et certainement souder un condo sur le 3.3)
Avant de prendre mon fer à souder je testerai une diminution de la tension d'alimentation. Si a 4.5v le nodemcu fonctionne le relais aussi et si ça résout la sensibilité des optos en mode 5v. Ce sera gagné... je ne peux malheureusement pas tester tout de suite pour vous donner la solution.

bsheep

@Charles
Bonjour,

J'utilise la version 1.3 de la carte et la dernière version du logiciel (rev 1ae2a85). Cependant, je n'arrive pas à piloter le fp7, je n'ai pas d'erreur (je sors toujours du 230V quelque soit le mode.)
Quand je regarde le code source du fichier https://github.com/hallard/remora_soft/blob/master/pilotes.cpp (ligne 15)

#if defined (REMORA_BOARD_V10)
  int SortiesFP[NB_FILS_PILOTES*2] = { FP1,FP2,FP3,FP4,FP5,FP6,FP7 };
#else
  int SortiesFP[NB_FILS_PILOTES*2] = { FP1,FP2,FP3,FP4,FP5,FP6 };
#endif

Je vois qu'il manque le dernier fil pilote (FP7) dans la condition #else.
Est-ce qu'il s'agit d'un oublie ? d'une limitation de la version 1.3 (du genre ne pas cabler a cause d'une limitation matérielle?).

Merci

Charles

@omyxcol
l'idée de départ était d'alimenter les optos en 5V justement pour ne pas tirer sur le régulateur du NodeMCU (qui semble être un clone de piètre qualité du réel AMS117 3.3V)
Si en plus il provoque des reset quand on tire un peu dessus c'est pas cool.
Ceci dit, peut être changer le régulateur par un vrai ASM1117 sur le node MCU peut être un bon test.
Sinon une autre idée, laisser en 5V mais augmenter la résistance de déclenchement de 390 Ohm car actuellement on a 5V-3.3V-1.2V/390 = 1.2mA et comme ça semble déclencher les optos blancs, Peut être mette une 1K (0.5mA) ne déclencherait pas les optos, même pousser à 1.2K ?

Charles

@bsheep
tu as parfaitement raison, c'est du à un vieil historique. Je viens de corriger, le repo est à jour!

#if (NB_FILS_PILOTES==7)
  int SortiesFP[NB_FILS_PILOTES*2] = { FP1,FP2,FP3,FP4,FP5,FP6,FP7 };
#elif (NB_FILS_PILOTES==6)
  int SortiesFP[NB_FILS_PILOTES*2] = { FP1,FP2,FP3,FP4,FP5,FP6 };
#else
  #error "Définition du nombre de fils pilotes inccorect"
#endif

Dany21000

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.

Remora V1.3 NodeMCU Nouvelle Version Logicielle + API Locale

3

5.7k

534

5.0k

Top Topics

Popular Tags