Remora V1.3 NodeMCU Nouvelle Version Logicielle + API Locale
-
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
-
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 ? -
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, ...)
-
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.
-
@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. -
Je finierai ça début d'année. Pour le moment c'est Noël.
-
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? -
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 ?
-
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.
-
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. -
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.
-
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!
-
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. -
@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
-
@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 ? -
@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
-
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.
-
Bonjour à tous,
J'ai monté mon kit, tout fonctionne à l'exception de tinfo :
Je ne récupère que le UPTIME :
{
"_UPTIME":684532
}Si quelqu'un à une idée je suis preneur
-
Bonsoir à tous
J'ai remis les optos en 5v. J'ai réglé le régulateur 5v rail din au min à 4,5v. Les fp fonctionnent et pour l instant pas de reset. -