Remora V1.3 NodeMCU Nouvelle Version Logicielle + API Locale
-
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 -
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.
-
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 :
-
@Dany21000
Ah oui pas idiot ça de pouvoir l'avoir tout le temps, je viens de l'implémenter vite fait dans lesetup(), repo à jour// handler for uptime server.on("/uptime", [&](){ String response = ""; response += FPSTR("{\r\n"); response += F("\"uptime\":"); response += uptime; response += FPSTR("\r\n}\r\n") ; server.send ( 200, "text/json", response ); });Et voilà
-
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.
-
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); #endifEDIT 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);
^ -
Bonjour,
Dans le même ordre d'esprit, j'ai modifié la ligne 96 du fichier webserver.cpp comme suit :response += F(",\"") ;devient
response += F(",\r\n\"") ;afin d'avoir un affichage JSON cohérent avec les autres variables.
Par contre, je n'ai toujours rien trouvé pour le problème des redondances de variables dans la téléinfo -
Salut Thibault, j'utilise la commande http://192.168.1.98/tinfo
Pour la liaison série il faut que je fasse des tests.
-
Bojour @aherben
As-tu activé la teleinfo ligne 30 dans le fichier remora.h et la bonne version de board (lignes 22 à 25) ?
Autre possibilité, il se peut que tu n'aies pas la téléinfo activée chez toi, mais de nos jours c'est très rare.
Après il se peut que ce soit un souci dans les soudures, et @Charles et les autres seront à même de t'aiguiller.
