tdouez / TeleinfoMySensors

Interface Téléinfo pour compteur Linky avec MySensors
14 stars 5 forks source link

Compatibilité v2.0.0 et "vieux" hardware / Plus de comm après inclusion #8

Closed Marc-- closed 2 years ago

Marc-- commented 2 years ago

Bonjour !

J'utilise depuis quelques années ton projet, et ça fonctionnait pas trop mal. Mais quelques erreurs de communication et le fait qu'il y ait une version "2.0" a suffit à me faire mettre à jour.

J'ai donc mis à jour la GW et déployé la version 2.0 sur les modules TIC. Ils utilisent le PCB daté du 10/2019, avec le NRF24 monté sur un connecteur.

Je n'ai pas de soucis à les inclure dans Jeedom, mais bizarrement une fois inclus, plus aucune communication.

Je doute que le problème soit côté Jeedom, penses tu qu'il puisse y avoir une incompatibilité HW / SW ?? Ca me parait fou car l'inclusion est niquel, le log ne montre plus de caractères inconnus. Mais on dirait qu'une fois inclu, le module TIC n'a plus rien à dire.

Peux tu me guider sur le debug ?

mySensors.log mySensors_node (1).log

Marc-- commented 2 years ago

Re,

J'ai flashé une v1.1.5 pour vérifier sans modifier la passerelle et j'ai bien une remontée d'infos régulière.

Je vais essayer de debug un peu en comparant, mais la v2 apporte beaucoup de changement je ne suis pas sur d'aller loin.

tdouez commented 2 years ago

Bonjour Marc, non pas de changement HW à part le changement de format du module NRF24L01. as tu la possibilité de te connecter au node directement pour récupérer les infos de la sortie série ? Tu es dans quel mode TIC, historique ou standard ?

Quand tu branches le module sur le compteur Linky, la led clignote 3 ou 5 fois ?

Marc-- commented 2 years ago

Je vais me connecter dessus cet aprem. En gros tu veux que je pique la sortie du mosfet BS170 et que je lise sur un terminal pour voir ce qu'il raconte ?

Je suis en mode standard, un compteur "consommation" et l'autre "producteur". J'ai testé sur les deux avec le même résultat.

tdouez commented 2 years ago

Non il faudrait que tu te connectes sur l'arduino avec le module de programmation FDTI pour lire la sortie série de l'arduino.

Marc-- commented 2 years ago

Bon, c'était instructif. Je note tout au cas ou ça te donne une piste.

Quand je log l'arduino avec le module FTDI, tout semble parfaitement normal. J'ai des updates des valeurs, c'est magique. Si je le débranche le FTDI, le module continue de fonctionner.

Par contre si je le branche SANS le FTDI, il y a une première communication avec Jeedom, puis plus rien. La "onboard LED" de l'arduino clignote de manière légère, j'ai comme l'impression qu'il manque de puissance pour démarrer.

Au multimètre j'ai 6v au point de mesure "4". image

Sur l'arduino, j'ai un 3,3 / 3,2V. Sachant qu'ils sont flashés pour un BOD à 1,8V comme conseillé.


Autre test

Sur le Linky j'ai connecté uniquement I1 et I2. Pas A. J'alimente donc par le FTDI. Juste après le boot "MySensors 2.3.2", j'ai une suite de caractères blanc. Pas de communication. Je ne peux pas fournir le log car il n'est pas reconnu comme fichier texte. Linky_ko

Si je débranche I2 (ou I1), je boot le module (toujours alim FTDI), il démarre puis m'affiche "TIC Mode Standard", et ensuite le boot classique "Fumée Bleue V2.0.0" et ca roule. conso-OK.log

Je décide de supprimer le FTDI. J'alimente le module avec I1 / A, et je laisse I2 débranché. Je lui laisse quelques secondes, je branche I2 : ca marche.

Ma conclusion: si les bornes I1 et I2 sont connectées au moment du boot du programme, ca plante.

tdouez commented 2 years ago

Pour la sortie FDTI, le module commence à mette sa vitesse à 1200 bauds et cherche à recevoir des trames en mode "historique". Si au bout de 10 secondes, les trames ne sont pas reçues il passe en vitesse 9600 bauds qui correspond au mode "standard". Tu es à quelle vitesse sur ton terminal série ? Il faut se mettre à 9600 dans ton cas. Je pense que dans ton cas l'alimentation du Linky est un peu faible et dans le code le NRF est en mode max (#define MY_RF24_PA_LEVEL RF24_PA_MAX). Tu peux essayer de passer ne mode HIGH pour avoir une consommation moindre (#define MY_RF24_PA_LEVEL RF24_PA_HIGH).

Marc-- commented 2 years ago

Je suis bien en 9600 bauds.

Côté puissance, j'ai le même comportement que ce soit alimenté par un moyen externe ou le Linky.

Je suis déja en "RF24_PA_LOW" car j'ai que 5m en champ libre entre la GW et le Linky. J'ai aussi switché "MY_RF24_CHANNEL 1" car c'est le plus loin des mes autres réseaux 2,4Ghz.

Je vais refaire quelques tests, car en V1.1.5 aucun soucis et une fois "bootés" aucun problème non plus. Il n'y a que ce moment au tout début du code (la bascule historique / standard ?) ou ça foire.

Marc-- commented 2 years ago

Alors je précise de suite, je suis pas dev. Je comprend "à peu près".

J'avais dans l'idée que c'était le choix du baud rate qui plantait le programme (les carrés blancs... suspect). Donc sachant que je suis en mode standard, j'ai décidé de ne pas lui laisser le choix. J'ai donc viré la bouche while qui vérifie les trames historiques et forcé le "flag_timeout" à TRUE.

Et ça fonctionne bien. Alors bizarrerie de chez moi ou il y a quelque chose ? Car j'ai le même comportement sur 2 Linky différents (et de marques différentes).

`// ---------------------------------------------------------------- // init_speed_TIC // ---------------------------------------------------------------- _Mode_e init_speed_TIC() { boolean flag_timeout = true; boolean flag_found_speed = false; boolean flag_debut_trame = false; boolean flag_milieu_trame = false; boolean flag_fin_trame = false; uint32_t currentTime = millis(); _Mode_e mode;

digitalWrite(MY_DEFAULT_ERR_LED_PIN, LOW); digitalWrite(MY_DEFAULT_RX_LED_PIN, LOW);

// Test en mode historique // Recherche des éléments de début, milieu et fin de trame Serial.begin(1200); // mode historique /* while (!flag_timeout && !flag_found_speed) { if (Serial.available()>0) { char in = (char)Serial.read() & 127; // seulement sur 7 bits if (in == 0x0A) flag_debut_trame = true; // début trame if (in == 0x20) flag_milieu_trame = true; // milieu trame if (in == 0x0D) flag_fin_trame = true; // fin trame

  if (flag_debut_trame && flag_milieu_trame && flag_fin_trame) flag_found_speed = true;
}
if (currentTime + 10000 <  millis()) flag_timeout = true; // 10s de timeout

} */ if (flag_timeout) { // trame avec vistesse histo non trouvée donc passage en mode standard mode = TINFO_MODE_STANDARD; Serial.end(); Serial.begin(9600); // mode standard Serial.println(F("TIC mode standard")); clignote_led(MY_DEFAULT_RX_LED_PIN, 3, 500); } else { mode = TINFO_MODE_HISTORIQUE; Serial.println(F("TIC mode historique")); clignote_led(MY_DEFAULT_RX_LED_PIN, 5, 500); }

digitalWrite(MY_DEFAULT_ERR_LED_PIN, HIGH);

return mode; }

`

tdouez commented 2 years ago

ok merci pour ce test. Je vais vérifier cela de mon côté avec un compteur en mode standard.

tdouez commented 2 years ago

Après quelques recherches, le problème est peut-être lié à la tentative de lecture du serial en 1200 bauds et ensuite le passage en 9600 bauds. Il y aurait une augmentation de la consommation de l'arduino dans ce cas; ce qui peut poser problème avec le module. Je ferai un test dès que j'ai accès à un compteur en mode standard (je suis en histo chez moi) .

tdouez commented 2 years ago

C'est bon le problème est normalement résolu avec la version v2.0.1