Bonjour, 
Suite au constat que mon triac 24A de chez robotdyn est HS, je viens de changer sur la platine le composant BTA24-600B par un BTA40, néanmoins celà ne fonctionne toujours pas, toujours pas de led bleue indiquant que c'est sous tension...
du coup j'en déduis que c'est la platine robotdyn complète qui est HS.
Il y a-t-il moyen de s'en fabriquer une et si oui comment? ou bien dois-je nécessairement recommander la platine de robotdyn et remplacer le BTA d'origine par mon BTA40 à l'arrivée? ou il y a t-il une autre solution??
merci pour votre aide.

Bonjour,

Tout d’abord, merci pour ce développement. Je viens de finir le routeur avec capteur uxix2 sur un esp32 proche du tableau et un esp32 avec triac et capteur de température proche du chauffe-eau.

Dans la prochaine version serait-il possible de sélectionner si l’on veut voir les courbes du deuxième capteur de courant ? Dans mon cas, ce capteur n’étant pas utilisé, j’ai deux courbes toujours à zéro..

Voilà pour ma part le petit ajout

Bonjour, je n'arrive pas à installer la version 11.7 par USB, il ne m'est proposé que le COM 1 et l'installation échoue !.

Bonjour
Afin de faire dialoguer les ESP32 de façon très fiable ( le site sera au Sénégal) , est il possible de faire du fiilaire ou de la fibre optique entre les ESP.
La distance entre les 2 ESP serait de 300m environ.
Merci de vos idées. (ex F1OMD )

Bonjour à tous
je suis nouveau dans le monde du photovoltaïque et je me retrouve déjà dans la nécessité de fabriquer un routeur.
mon installation 3.2kwc de panneau + onduleur hybride DEYE 3.6kw + wifi LSW-3
J'en suis à l'étape du programmation du ESP32, avec quelques difficultés à me connecter à ma box pour le moment.
Quelqu'un a déjà t'il réussi à communiquer avec ce module wifi ?. 
J'arrive à me connecter dessus en wifi avec son adresse IP + utilisateur + MDP

merci de vos retours.

Charles

Bonjour Forum!,

j'ai en service, depuis un petit moment déjà ce magnifique produit !
cela fonctionne à merveille V8.06, U*I, triac

J'ai décidé de passer en V11.15 pour pouvoir activer plus de sorties
et voir comment je pourrais gérer des batteries pour la nuit ...

Mon Wifi est mis en veille entre 00H et 7H. Le probleme apparait donc le matin car l'ESP disparait des écrans radars
Il est comme "figé", pas d'activité des leds ... le boot de la carte ne permet pas une relance, seul une mise hors tension permet de corriger le pb, jusqu'au lendemain
je l'ai observé au moment ou le wifi se coupe , il passe comme "prevu" en recherche en faisant clignoter les leds , mais au bout d'un moment il fini pas ne plus rien faire

Par la même occasion, toutes les données se volatilisent à chaque fois.

Je précise que j'ai 2 ESP Wroom32 , un en V8.06 et l'autre en V11.15. avec l'ancienne version, jamais eu ce souci ni aucun autre d'ailleurs

Est ce tout simplement un ESP défectueux ? ou y a t'il une particularité que je n'ai pas trouvé ? quelqu’un a t'il connu ce désagrément ?

   


A très vite !

bonjour à toutes et à tous. L'autre  jour en parcourant le forum à la recherche d'info, je suis tombé sur les différents schéma de câblage du site F1ATB pour les cumulus et en particulier pour le tri sans neutre. Depuis hier impossible de retrouver le lien. Si quelqu'un avait l'info? merci

   
   
Bonjour,
Si cela intéresse des personnes.
J'ai changé l'afficheur LILYGO TTGO T-Display 1.14 pouces, par un afficheur TFT 2,8" ILI9341, car je ne voyais pas l'affichage.
J'y ai modifié quelques ligne de code pour l'adapter, rien de bien méchant. 
J'ai fais aussi le circuit imprimé et le boitiers. Pour ces pièces il vous faut juste les commander sur le site jlcpcb.com.
J'ai aussi pour ce que cela intéresse les circuit imprimé pour le routeur ainsi que les supports pour les leds, le routeur, le dimmer.
Je suis disponible si besoin.
Cordialement.

Pièces jointes

  Routeur Solaire.zip (Taille : 221.2 Ko / Téléchargements : 26)
  ESP32 Afficheur ILLI9341 - CADCAM.ZIP (Taille : 21.17 Ko / Téléchargements : 24)

bonjour
je suis interesse pour installer un routeur solaire  jai une installation avec 11 panneau de 400 w  et mon ballon eau chaude est tres loin de mon compteur linky et tableau general 
je voudrais pouvoir faire communiquer via 2 esp 32 en wifi pour router sur le ballon 
javais un routeur solaire precedement mais il a grillé 
et je voudrais un systeme moiins couteux de plus la pince amperometrique etant tres loin du routeur le routeur  avait beaucoup de difficulter a gerer le surplus
pouver vous maider 
evidement jai regarder sur le site il est tres fourni et je suis un peux confu  
je vous remercie pour votre temps 
nicolas

J'ai de nouveau analysé le code UxIx3, qui pose problème depuis l'adoption de la bibliothèque "cartes" V3.01 et suivantes au lieu de feu la V2.17 qui marchait parfaitement.

Le problème tourne en partie autour du WIFI (mais pas uniquement je pense) et semble avoir été résolu pour ceux qui ont peu d'ESP32, ou n'utilisent pas le module UxIx3 (tri-phasé).

Le code UxIx3 tel qu'il est écrit actuellement consomme inutilement des ressources, et il n'est pas impossible qu'il y ait depuis la V3.01 des interactions entre les deux cores, possiblement avec les "mutex hardware" ou autres.

Actuellement, le code UxIx3 envoie une requête de données au module JSY-MK-333, puis lit la réponse caractère par caractère jusqu'à les avoir tous lus. C'est une perte de temps inutile, car, en supposant que le module réponde 'dans l'instant', cela prend au minimum  141 données x 10 bits / 9600 = 150 ms.

J'ai donc simplement "dissocié" la requête de la lecture, pour être sûr que lorsque le core viendra lire la réponse, tout le message sera déjà dans le buffer et sera donc lu "à grande vitesse". J'aurais pu aussi venir vérifier si toutes les données avaient été reçues, avec un timeout, avant de les lire toutes, mais sans bloquer.

Le code actuel marche simplement parce que le serial.read() est en partie "bloquant", c'est à dire qu'il attend avec un timeout, dont j'ai lu qu'il était par défaut de 1 seconde. C'est curieux quand on veut faire du temps réel d'avoir des read avec timeout. Mais c'est comme çà.

Pour résoudre le problème, j'ai simplement sorti la requête elle-même de la "lecture", et lancé une première requête à la fin de l'init du port série (voir plus loin).

Et j'ai modifié le code principal en lisant, puis en relançant une requête, sachant que je ne viendrai lire la réponse que 800ms plus tard (lors de l'extinction du timer), donc en étant sûr qu'elle sera dans le buffer de réception dans son intégralité.

if (Source == "UxIx3") {
          Lecture_JSY333();
          PeriodeProgMillis = 800;
          Request_data_JSY333();
        }

Sans doute parce que dans le code V3.0x il y a de nouvelles inter-actions 'parasites' entre le temps réel des deux cores, le simple fait d'utiliser moins longtemps l'UART libère de la ressource qui améliore grandement les choses (pour le WIFI ?? j'en doute).

Très curieux, mais c'est comme ça. Donc je prends puique ainsi cela tombe en marche.

La prochaine étape sera pour moi de passer la comm série à 19200 comme cela a été si bien fait par un autre d'entre nous, pour gagner un facteur 2 sur la vitesse de transmission et réduire encore le temps de lecture et d'occupation de l'UART. Et je testerai en continu le buffer de réception pour ne pas en retarder la lecture comme je le fais actuellement ( comme c'est très bien fait pour le Linky).

En tout cas, je n'ai plus de plantage de mon serveur UxIx3, ce qui est déjà très bien.


// *************************************************
// * Client lecture JSY-MK-333 * Triphasé          *
// * Développement initial de Pierre F (Mars 2024) *
// * update PhDV61 Juin 2024 et Août 2024          *
// *************************************************

void Setup_JSY333() {
  MySerial.setRxBufferSize(SER_BUF_SIZE);
  MySerial.begin(9600, SERIAL_8N1, RXD2, TXD2);  //PORT DE CONNEXION AVEC LE CAPTEUR JSY-MK-333
  delay(10);
  Request_data_JSY333();
}

void Request_data_JSY333() {
int i;
  byte msg_send[] = { 0x01, 0x03, 0x01, 0x00, 0x00, 0x44, 0x44, 0x05 };
  for (i = 0; i < 8; i++) {
    MySerial.write(msg_send[i]);
  }
}  

void Lecture_JSY333() {

  float Tension_M1, Tension_M2, Tension_M3;
  float Intensite_M1, Intensite_M2, Intensite_M3;
  float PVA_M_inst1, PVA_M_inst2, PVA_M_inst3;
  float PW_inst1, PW_inst2, PW_inst3;
  byte Lecture333[200];
  bool injection;
  bool sens1, sens2, sens3;
  long delta_temps = 0;
  int a = 0;

  while (MySerial.available()) {
    Lecture333[a] = MySerial.read();
    a++;
  }
...

Voilà.

Edit : je viens de lire que les tâches WIFI tournaient par défaut (arrrrghhh) sur ... le core 0. Ceci expliquant peut-être cela...