Problème API

[Dany21000]

Je crois avoir compris.
Voici les modifications que je fais sur le code :
remora.h :
-les identiifiants infrastructure Wifi
-L'identifiant Wifi hotspot
-Je désactive le support du téléinfo

Fichier remora_soft.ino
-Modification de la fonction WifiHandleConn pour disposer d'une IP statique

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")); 

    IPAddress ip(192,168,50,252);
    IPAddress gateway(192,168,50,254);
    IPAddress subnet(255,255,255,0);
    WiFi.config(ip, gateway, subnet);

    #if defined (DEFAULT_WIFI_SSID) && defined (DEFAULT_WIFI_PASS)
      Serial.print(F("Connection au Wifi : ")); .......

Mes conclusions après tests avec mon second nodemcu "nu" :
Support téléinfo actif = pas de problème code http 200 et réponse en json
Support téléinfo non-actif = problème code http 404 sans réponse fiable

[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.

[Charles]

@alban,

Merci du retour, ah vrai dire je l'attendais en peu celle-ci, c'est un vilain bug présent aussi sur WifInfo (normal le code est copier/coller) je voulais voir il il était aussi présent sur rémora.
Le truc c'est que ce code fonctionne parfaitement avec un Particle et le problème se produit uniquement avec l'ESP8266. Il faut que j'arrive à le reproduire et le "choper" au moment ou il ajoute la mauvaise donnée. C'est dans ma top priority, je vais ajouter des contrôles supplémentaires pour éviter le soucis mais ça ne va pas m'expliquer pourquoi çà déconne.
En fait j'ajoute dans la liste des valeurs uniquement les étiquettes non présentes ou différentes, mais elles sont ajoutées uniquement si la checksum est correcte. donc je comprends pas comment on peu se retrouver avec des valeurs incorrectes
Si quelqu'un veux aller voir le code ici, peut-être que je suis passé a coté d'un truc simple. Mais ce code marche parfaitement avec le programme teleinfo.c et avec cette librairie sur un particle donc j'ai un gros doute. Peut être une mauvaise utilisation du SDK

[alban]

@Charles ,
J'ai beau être développeur, je ne suis pas sûr de bien lire ton code.

Au niveau du checksum, celui-ce ne se fait peut-être pas à chaque appel. S'il n'est fait qu'au démarrage, sur le premier appel, et que le checksum est bon, alors d'autres variables peuvent faire leur apparition. C'est assez bizarre puisque ça rajoute des noms de variable fabriqués à partir des autres.

Cela dit, un contournement serait de balancer en variable un tableau des noms de variables que l'on attend. Ensuite ta fonction regarde si la variable qu'elle récupère est bien contenue dans le tableau des noms de variables attendues. Dans le cas présent, avec la version 1.3, on attend pour la téléfinfo : _UPTIME, ....etc ...MODETAT et rien d'autre.

[Charles]

La checksum est vérifié systématiquement à l'entrée de la fonction valueAdd donc c'est le 1er check, si elle n'est pas bonne, on ne fait rien et on retourne NULL (pas de nouvelle valeur). Le problème se produit donc entre les 2 et c'est la ou j'ai des doutes sur la partie concernée (le malloc et les memcpy)

Pour contourner je vais la revérifier à la sortie , c'est à dire si la checksum n'est pas bonne je ne sors pas la valeur (même si elle est présente)

[alban]

Tu sais, moi sorti de php, html, css, js et un peu de java, je suis bon à rien ... pour le moment

le checksum est fait sur un name et une value. Tu aurais un exemple à décrire pour que je comprenne ?

Pour info, à la ligne 193 :

TI_Debug((char) cheksum);

il manque un "c" à checksum

[bsheep]

Un correctif rapide peut être de ne renseigner que des étiquettes valides (PAPP, IINST).
Bien évidemment, il faut connaitre toutes les possibilités (compteur monophasé, triphasé) etc...

[Charles]

@bsheep
Yes c'est exact mais c'est exactement ce que je voulais éviter, mettre les étiquettes en dur dans le code. Mais comme j'ai publié la release candidate hier soir, je vais pouvoir me pencher sur le problème, si je récupère mon internet chez moi, la l'ADSL vient de tomber ça va pas être simple.

[alban]

@Charles,

Je reviens sur ce sujet car après 24 heures de fonctionnement, en plus de la création de variables farfelues, maintenant les bonnes variables ont des valeurs complètement folles - en gros les valeurs sont des concaténations des autres éléments ...
Comme dirait la princesse Leia :

Au secours Obi-Wan Kenobi, vous êtes mon seul espoir.

Du coup, je reboote le nodemcu (en téléversant par OTA) et ça repart.

[Charles]

@alban
Quel est la version du SDK dans les log série ?
Je n'ai plus constaté le soucis sur WifInfo depuis que j'ai passé le CPU à 160HMz et avec le dernier repo git arduino/esp8266 qui compile avec le SDK 1.5.0 ce serait intéressant de voir si tu as le SDK 1.3.0 de ton coté.

Pour info je viens de pousser une nouvelle version tu peux maintenant faire un reset depuis l'interface Web ou avec ipremora/reset

[alban]

@Charles,
Sur tes conseils, je suis passé sur le dernier git arduino/esp8266.
Pour le SDK je ne sais pas où trouver cette information.
Par contre les compils et téléversements se font avec le CPU à 80 MHz.

EDIT : j'ai vu pour le SDK : 1.50 ... par contre ça reboote sans cesse.
EDIT 2 : j'ai recompilé avec le CPU à 160 MHz et le nodemcu reboote toutes les minutes ou toutes les 2 minutes

[alban]

@Charles,
Je complète mon précédent post. En fait, en plus du reboot, il me crée toujours des variables farfelues ... actuellement DCO, MAT, SC, TEC.
Je ne comprends pas.

EDIT : je me demande si cela ne vient pas de la carte remora. Je m'explique. Lorsque Remora tournait avec le Core, pour moi tout allait bien. Cela dit, dans jeedom, j'avais des messages d'erreur comme si jeedom n'avait pas pu récupérer les données. A l'époque, je m'étais ça sur le compte de Spark en me disant qu'il pouvait y avoir sans doute des pertes de connexion avec leur serveur.

Mais maintenant, je me dis que déjà le Remora devait booter déjà sans cesse. Du coup, as-tu une idée d'où cela pourrait provenir sur la carte (v1.2c de mémoire) ?

[Charles]

Alban je fais des tests sur une 1.2 et visiblement j'arrive maintenant à de bons uptime (depuis ce matin là, 12H), tu peux avoir toutes les infos sur l'onglet système :
d'ailleurs erreur, c'est une 1.2 compilé pour 1.3 mais comme j'ai pas branché les fils pilotes pour tester çà fonctionne

[alban]

Merci @Charles
Donc je recompile avec l'option version version 1.3 et je reviens vers toi.
Pour information comme mon chauffage est piloté par la vera pour le moment, j'attends que tout soit bien stable avec de brancher les fils pilotes.

[alban]

L'uptime max que j'obtiens 145 ...

Voici le contenu du menu système :

Uptime	23
Version Logiciel	1.3.1
Compilé le	Jan 9 2016 15:10:05
Version Matériel	V1.3 avec MCP23017
Modules activés	OLED TELEINFO
SDK Version	1.5.0
Chip ID	0xA184D
Boot Version	0x1F
Flash Real Size	4.00 MB
Firmware Size	357.33 KB
Free Size	664.00 KB
Analog	0 mV
SPIFFS Total	2.81 MB
SPIFFS Used	128.20 KB
SPIFFS Occupation	4%
Fil Pilote #1	
Fil Pilote #2	Hors Gel
Fil Pilote #3	Hors Gel
Fil Pilote #4	Hors Gel
Fil Pilote #5	Hors Gel
Fil Pilote #6	Hors Gel
Fil Pilote #7	Hors Gel
Etat Relais	Ouvert
Delestage	Niveau 1 Zone 1
Free Ram	20.45 KB

Donc la grosse différence, c'est le champ "analog" qui est à 0 chez moi. Le SPIFFS aussi n'est pas pareil.

[alban]

Après remise au propre du firmware et du spiffs, j'obtiens (compilé remora 1.3, sdk 1.50, cpu 160MHz, module OLED et TELEINFO activés) :

• uptime > 1000 avec le nodemcu branché en usb sur l'ordi , teleinfo non branchée,
• uptime < 500 avec le remora alimenté par un chargeur 5V / 0,7A, téléinfo branchée.

Donc le problème vient soit de l'alimentation, soit de la téléinfo ...

[alban]

Suite.
Malgré les reboots muliples, de nouvelles variables farfelues sont apparues ... Je vais faire le test du remora dans le boitier électrique mais sans la téléinfo activée pour éliminer l'alimentation du champ des possibles.
Idem uptime < 200.

EDIT 2 : changement d'alimentation. Pas de reboot (uptime > 2000).

EDIT 3 : activation module téléinfo, mais téléinfo non branchée, avec la nouvelle alimentation (5V / 1A) : uptime > 5000

EDIT 4 : branchement de la téléfino => reboot direct puis uptime > 100 + variables bizarre ...

Conclusion, il y a un souci sur le circuit de téléinfo ou sur l'interprétation des trames qui fait rebooter.

[Charles]

@alban
tu peux activer le debug de la téléinfo (attention ça va cracher et à 1200bps ça pourrait foirer)
Enlever le commentaire de LibLibTeleinfo.h (voir ici)

// Define this if you want library to be verbose
#define TI_DEBUG

[francky50]

@alban
As-tu essayé de changer le protocol Wifi de ta box ? j'avais le même problème de reset constant dès que je me connectait sur ma freebox v6 et c'était stable dans d'autres lieux ou le nodemcu n'arrivait pas à se connecter ou sur mon mac. J'ai mis une réponse dans l'autre post "Remora V1.3 NodeMCU Nouvelle Version Logicielle + API Locale"
PS : j'ai mis un historique sur mon uptime dans Jeedom pour voir si çà reset mais depuis hier 22h quand je l'ai activé il y a eu aucun reset.

[alban]

@francky50

Oui j'ai vu ton post et en fait j'ai déjà ces mêmes paramètres.
Par contre, quelle est ta config avancée (canal, version de protocole et autres ...) ?
Pas mal l'idée d'historiser l'uptime