Plus d'accès aux données de la passerelle Enphase Envoy

[Serge19]

Le pb c'est que même en redirection de port se sera très compliqué, en tout cas pour moi, car on fait planter la passerelle et pas sûr qu'à un moment elle ne se brique pas. Et le pire pour moi c'est que je n'arrive pas à forcer la maj en 5528, c'est Enphase qui décide à quel moment.

[michy]

Bonjour,

  Juste pour aider à trouver une solution si c'est un problème qui vient du routeur (autre sujet si ça vient d'un bug du dernier firmware de chez enphase)

  pour ceux qui ont une passerelle et la patience de compiler, tester, debugger (Je ne peux pas m'y coller, je n'ai pas de passerelle)

  j'ai relevé quelques bug 'mineurs' et d'autre un peu plus 'tordu' dans le code pour la Source Enphase

  * l'usage de String fragmente énormément la mémoire disponible, dans certaine situation, il est possible qu'il n'y ait plus de bloc suffisamment grand pour traiter certaine demande [regarder la valeur de Mémoire RAM libre minimum sur votre page "données brutes", je suppose que ça descend très bas]
  * Il y a une requête POST (vers enlighten.enphaseenergy.com) qui est traitée comme un GET, le serveur chez Enphase a parfaitement le droit de ne pas répondre considérant une erreur dans la requête [soit c'est GET et les paramètres sont dans l'URL, soit c'est un POST et les paramètres devrait être dans le body)
  * il y a des readStringUntil ...  qui attendent de trouver le caractère \n, alors qu'il n'est pas du tout garantie que ce caractère soit à la fin du Json donné par la passerelle, la fonction se termine sur un timeout de 1 seconde, malgré cela sur le core 0, la fonction pour interroger à nouveau la passerelle est déclenchée, on entre certainement dans un succession d'interrogation avec des réponses tardives qui peuvent saturer la mémoire
  * Certaines fonctions peuvent retourner une erreur ou pour d'autre il faut attendre qu'il y ait des données disponibles pour les lires, comme ce n'est pas géré dans le code [surtout pour V7, ou il n'y a aucune sortie de code sur erreur] , on poursuit le traitement sur quelque chose de 'pas attendue' ... 
  * compte tenu qu'on interroge en permanence la passerelle (toutes les 600ms), il serait judicieux de laisser la connexion ouverte pour éviter les séquences de 'connect' à chaque fois, juste de l'optimisation, ce n'est pas une erreur
  * Comme on a un #include "ArduinoJson.h", il n'est plus nécessaire de faire le parsing à la main des chaines (qui peuvent évoluer un peu d'une version de firmware a une autre de la part de Enphase : tel que c'est fait, un espace en plus suffit à 'casser' le routeur) [Autre avantage, on ne gère plus la réception des octets, on passe le stream réseau a ArduinoJson qui traite en direct la réception et le parsing]
  * Espressif a sérieusement retoucher les fonctions réseau dans les dernières version de son code, ce qui était traité avant par des fonction WiFi est maintenant traité par NetWork, bien plus cohérent car certain utilise le routeur en Ethernet


J'attache logigramme de +/- ce qui est programmé pour la lecture des données, de la version evo que je propose et le module SourceEnphase associé [pas tester, à vous de jouer]

[Luc1]

Apparemment, nouvelle politique d'authentification et d'autorisation pour accéder aux API en V4 concernant les développeurs avec nb connections limitées (pour le plan gratuit) à 10/minute et/ou 1000/mois.
voir ici: https://developer-v4.enphase.com/docs/qu...tml#step_1
Serait ce l'explication ?

Lorsque j'ai eu l'assistance enphase il y a qqs jours pour dire mes soucis de perte de connexion à ma passerelle avec un logiciel routeur tiers, il m'a été répondu: "Vous savez chez enphase on a aussi un routeur, et là on assume la maintenance !"  
Evidemment avec le routeur qui va bien , le chauffe eau adéquat et qqs billets de mille ....

[wolff231]

Ça paraît cohérent car le routeur au démarrage se connecte a enphase , puis il plante plus tard.

Du côté passerelle quand on consulte les évènements dans l'application enlighten, moi ça indique que l'installation a été arrêtée car il y a un disfonctionnement dans la mesure de la consommation.

Forcément enphase devra réagir de son côté si toutes les passerelles se mettent en default.

[Luc1]

Ça paraît cohérent car le routeur au démarrage se connecte a enphase , puis il plante plus tard.

Du côté passerelle quand on consulte les évènements dans l'application enlighten, moi ça indique que l'installation a été arrêtée car il y a un disfonctionnement dans la mesure de la consommation.

Forcément enphase devra réagir de son côté si toutes les passerelles se mettent en default.

Je crois que ça dit simplement que ta passerelle a redémarré (sans présumer de la cause)  et que la production est seulement réduite (  chez moi, j’ai limité l'exportation à 3Kw en appliquant une PEL (Production Export Limit ?) dans les paramètres et je reçois ce type de messages (particulièrement en cette période ! ) lorsqu'il y a écretage/bridage de l’export.

[GhostOfMajin]

Bonjour,

  Juste pour aider à trouver une solution si c'est un problème qui vient du routeur (autre sujet si ça vient d'un bug du dernier firmware de chez enphase)

  pour ceux qui ont une passerelle et la patience de compiler, tester, debugger (Je ne peux pas m'y coller, je n'ai pas de passerelle)

  j'ai relevé quelques bug 'mineurs' et d'autre un peu plus 'tordu' dans le code pour la Source Enphase

  * l'usage de String fragmente énormément la mémoire disponible, dans certaine situation, il est possible qu'il n'y ait plus de bloc suffisamment grand pour traiter certaine demande [regarder la valeur de Mémoire RAM libre minimum sur votre page "données brutes", je suppose que ça descend très bas]
  * Il y a une requête POST (vers enlighten.enphaseenergy.com) qui est traitée comme un GET, le serveur chez Enphase a parfaitement le droit de ne pas répondre considérant une erreur dans la requête [soit c'est GET et les paramètres sont dans l'URL, soit c'est un POST et les paramètres devrait être dans le body)
  * il y a des readStringUntil ...  qui attendent de trouver le caractère \n, alors qu'il n'est pas du tout garantie que ce caractère soit à la fin du Json donné par la passerelle, la fonction se termine sur un timeout de 1 seconde, malgré cela sur le core 0, la fonction pour interroger à nouveau la passerelle est déclenchée, on entre certainement dans un succession d'interrogation avec des réponses tardives qui peuvent saturer la mémoire
  * Certaines fonctions peuvent retourner une erreur ou pour d'autre il faut attendre qu'il y ait des données disponibles pour les lires, comme ce n'est pas géré dans le code [surtout pour V7, ou il n'y a aucune sortie de code sur erreur] , on poursuit le traitement sur quelque chose de 'pas attendue' ... 
  * compte tenu qu'on interroge en permanence la passerelle (toutes les 600ms), il serait judicieux de laisser la connexion ouverte pour éviter les séquences de 'connect' à chaque fois, juste de l'optimisation, ce n'est pas une erreur
  * Comme on a un #include "ArduinoJson.h", il n'est plus nécessaire de faire le parsing à la main des chaines (qui peuvent évoluer un peu d'une version de firmware a une autre de la part de Enphase : tel que c'est fait, un espace en plus suffit à 'casser' le routeur) [Autre avantage, on ne gère plus la réception des octets, on passe le stream réseau a ArduinoJson qui traite en direct la réception et le parsing]
  * Espressif a sérieusement retoucher les fonctions réseau dans les dernières version de son code, ce qui était traité avant par des fonction WiFi est maintenant traité par NetWork, bien plus cohérent car certain utilise le routeur en Ethernet


J'attache logigramme de +/- ce qui est programmé pour la lecture des données, de la version evo que je propose et le module SourceEnphase associé [pas tester, à vous de jouer]

Bonjour, je veux bien tester mais tu pourrais me compiler la version 17.20 (avec ton patch) en .bin pour que je puisse l'injecter en OTA stp ?

[Serge19]

Bonjour,

  Juste pour aider à trouver une solution si c'est un problème qui vient du routeur (autre sujet si ça vient d'un bug du dernier firmware de chez enphase)

  pour ceux qui ont une passerelle et la patience de compiler, tester, debugger (Je ne peux pas m'y coller, je n'ai pas de passerelle)

  j'ai relevé quelques bug 'mineurs' et d'autre un peu plus 'tordu' dans le code pour la Source Enphase

  * l'usage de String fragmente énormément la mémoire disponible, dans certaine situation, il est possible qu'il n'y ait plus de bloc suffisamment grand pour traiter certaine demande [regarder la valeur de Mémoire RAM libre minimum sur votre page "données brutes", je suppose que ça descend très bas]
  * Il y a une requête POST (vers enlighten.enphaseenergy.com) qui est traitée comme un GET, le serveur chez Enphase a parfaitement le droit de ne pas répondre considérant une erreur dans la requête [soit c'est GET et les paramètres sont dans l'URL, soit c'est un POST et les paramètres devrait être dans le body)
  * il y a des readStringUntil ...  qui attendent de trouver le caractère \n, alors qu'il n'est pas du tout garantie que ce caractère soit à la fin du Json donné par la passerelle, la fonction se termine sur un timeout de 1 seconde, malgré cela sur le core 0, la fonction pour interroger à nouveau la passerelle est déclenchée, on entre certainement dans un succession d'interrogation avec des réponses tardives qui peuvent saturer la mémoire
  * Certaines fonctions peuvent retourner une erreur ou pour d'autre il faut attendre qu'il y ait des données disponibles pour les lires, comme ce n'est pas géré dans le code [surtout pour V7, ou il n'y a aucune sortie de code sur erreur] , on poursuit le traitement sur quelque chose de 'pas attendue' ... 
  * compte tenu qu'on interroge en permanence la passerelle (toutes les 600ms), il serait judicieux de laisser la connexion ouverte pour éviter les séquences de 'connect' à chaque fois, juste de l'optimisation, ce n'est pas une erreur
  * Comme on a un #include "ArduinoJson.h", il n'est plus nécessaire de faire le parsing à la main des chaines (qui peuvent évoluer un peu d'une version de firmware a une autre de la part de Enphase : tel que c'est fait, un espace en plus suffit à 'casser' le routeur) [Autre avantage, on ne gère plus la réception des octets, on passe le stream réseau a ArduinoJson qui traite en direct la réception et le parsing]
  * Espressif a sérieusement retoucher les fonctions réseau dans les dernières version de son code, ce qui était traité avant par des fonction WiFi est maintenant traité par NetWork, bien plus cohérent car certain utilise le routeur en Ethernet


J'attache logigramme de +/- ce qui est programmé pour la lecture des données, de la version evo que je propose et le module SourceEnphase associé [pas tester, à vous de jouer]

Bonjour Michy,

Pas moyen de compiler en 3.3.10 ou 3.3.8. Y a t'il d'autre changement que dans Source_EnphaseEnvoy.ino?
-> j'ai ce message : Compilation error: 'ValJson' was not declared in this scope; did you mean 'ValJsonSG'?

[MikrRF7]

Salut à tous. Moi depuis quatre jours, routeur F1ATB , chargeur V2C ne communiquent Plus et la passerelle enphase est soit rouge soit tous ce que vous citez plus haut . Une fois le F1atb éteint, la passerelle se reconnecte. Le chargeur V2C, j’ai dû enlever la gestion puissance avec la passerelle enphase car il déconnait complètement (déconnection reconnection). Pour le chargeur, apparemment il est possible de leur demander ( à V2C)une mise à jour 2.4.6.26.
Je pense, surtout qu’enphase commence à brider les systèmes tiers, pour privilégier ses propres systèmes. Si des Systèmes DIY ne fonctionnent plus, ça ne les concerne pas…

[michy]

Bonjour,

  je n'ai mis que les 2 fonctions setup et lecture du module,
  à la fin il y a une série de fonctions pour décoder le Json 'à la main' (qui sont encore utilisées dans d'autres modules), il faut donc les reprendre

  en PJ, version complète qui remplace integralement le fichier Source_EnphaseEnvoy.ino actuel de la V17.20 et qui compile en Espressif 3.3.10
  (+ quelques ajustement pour voir la situation dans le pavé "Messages")

[MikrRF7]

Salut à tous. Moi depuis quatre jours, routeur F1ATB , chargeur V2C ne communiquent Plus et la passerelle enphase est soit rouge soit tous ce que vous citez plus haut . Une fois le F1atb éteint, la passerelle se reconnecte. Le chargeur V2C, j’ai dû enlever la gestion puissance avec la passerelle enphase car il déconnait complètement (déconnection reconnection). Pour le chargeur, apparemment il est possible de leur demander ( à V2C)une mise à jour 2.4.6.26.
Je pense, surtout qu’enphase commence à brider les systèmes tiers, pour privilégier ses propres systèmes. Si des Systèmes DIY ne fonctionnent plus, ça ne les concerne pas…