Remora V1.3 NodeMCU Nouvelle Version Logicielle + API Locale
-
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":400000EDIT : 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 }; #endifJe 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. -
-
@omyxcol
Pas bête, l'idée du 4.5V, tant mieux si ça fonctionne.Sinon, à tester mais je reste persuadé qu'avec les optos blancs, les laisser en 5V (pour ne pas tirer sur le régul du NodeMCU) et changer la 390 Ohm de pilotage de l'opto par une 1K (ou 1.2K) devrait régler le problème.
@Dany21000
Oui tout alimenter en 3V3 va effectivement régler le soucis. en revanche pas sur du résultat quand tu vas brancher l'USB sur le nodeMCU (5V), le 5V était aussi pour la compatibilité avec Spark. -
Vous avez raison, je changerai les resistances par des 1k, mais je ne les ai pas sous la main (en commande) mais ça ou le chauffage en hors gel au mois de décembre... Si un autre remoriste est dans mon cas il peut faire ça en attendant.
Prochaine étape la teleinfo.
A bientôt
