Quick App - Enphase Envoy

[stipower 8]

Merci, c'est super.

Je vais regarder cela et poster mon code au cas ou ca intéresse quelqu'un sur HD2.

Même si ca sera beaucoup moins pro que toi ...

[TitiXsi 66]

Hello, chez moi plus rien ne fonctionne depuis une petite heure. ni le live enlighten, je pense que enphase a encore crashé des serveurs... ca donne quoi chez vous ?

[Lazer 8 477]

Chez moi tout fonctionne.
Le QuickApp en accès local, le site Web d'Enphase, et la remonté des infos dans le cloud :

 

 

EDIT : pas testé le Live Enlighten, de toute façon ça n'a jamais fonctionné chez moi, je n'ai pas contacté Enphase pour qu'ils réparent le bug, donc ça attendra la mise à jour globale.

 

Modifié 7 août 2023 par Lazer

[TitiXsi 66]

Ça vient de revenir.

[TitiXsi 66]

Bonjour à Tous,

 

Voici une version 2.08 basée sur la 2.00 de @Lazer. Encore Merci pour la v2.00

 

 

Les Modifs :

• Ordonnancement et Création des Childs avec leur noms "plus parlants".
  • Child-Balance Solaire Live (en positif si vous produisez (en W) plus que ce que vous consommez à cet instant)
  • Child-Voltage (il est utilisé pour détecter les sous-tensions (207v) et sur-tensions (253v) du réseau)
  • Child-Prod Live (votre puissance de production (en W) à cet instant)
  • Child-Conso Live (votre puissance de consommation (en W) à cet instant)
  • Child-Balance Solaire Moy 5 Min (en positif si vous produisez (en W) plus que ce que vous consommez sur une moyenne de 5Min, c'est très utile si vous lancez des appareils suivants votre surplus pour s'affranchir des nuages passants ... )
  • Child-Prod ToDay (votre production en Kwh aujourd'hui)
  • Child-Conso ToDay (votre consommation en Kwh aujourd'hui)
  • Child-Prod LifeTime (votre production en Mwh depuis l'installation)
  • Child-Conso LifeTime (votre consommation en Mwh depuis l'installation)
  • Child-Balance Solaire LifeTime (en positif si votre production (en Mwh) depuis l'installation est supérieure à votre consommation (en Mwh) depuis l'installation)
     
• Le Child Inverter a été commenté dans la QA, vous pouvez le remettre si besoin, il est sensé indiquer la production des Micro-onduleur depuis l'installation mais cette valeur à été remise à zero par enphase (surement durant le passage D5/D7), du coup, il ne sert pas à grand chose...
   
• Child-Voltage permet :
  • de stocker les min et max tensions détectés avec leurs dates dans les Variables Locales, ca peut être utile
  • de détecter les sous-tensions (207v) et sur-tensions (253v) du réseau et d'envoyer un Push à tous les devices de type Ios déclarés (J'ai longtemps essayé, c'est enfin dispo ).
    
     
• Child-Balance Solaire Moy 5 Min permet :
  • de stocker 6 Variables Locales permettant de calculer le Moyenne sur 5 échantillonnages (soit 5min, si on échantillonne toutes les minutes) -> c'est très utile si vous lancez des appareils suivants votre surplus pour s'affranchir des nuages passants ...
     
• Tous les Childs sont :
  • paramétrés en PowerSensor sauf Child-Prod Live, Child-Conso Live, Child-Prod ToDay et Child-Conso ToDay qui sont en PowerMeter.
  • désactivés dans le panneau d'energie (includeInEnergyPanel = false / saveToEnergyPanel = false), sauf Child-Prod Live et Child-Conso Live.
    
     
• Les Childs Child-Prod Live, Child-Conso Live, Child-Prod ToDay et Child-Conso ToDay permettent :
  • d'être définis dans le compteur d'energie et donc de comptabiliser votre production/consommation instantanée (en W) et d'energie en Wh pour (par heure, journée, semaine, mois, année...)
  • 1 seul choix possible par type de compteur lors du parametrage du compteur d'energie.
    
    
     
• Les rapports d'énergie sont conforme au site enphase (mise à par le gap de 15min pour le refresh de conso et prod sur le site enphase)
  • Exemple Jour J
    • Site Enphase :
      
       
    • Fibaro :
      
      
       
  • Exemple Jour J-1
    • Site Enphase : Prod 34,2Kwh / Conso 14,4Kwh
      
       
    • Fibaro : Prod 34,19Kwh / Conso 14,55Kwh (J'ai 0.15Kwh de diférence, surement un Wallplug qui est pris en compte, je dois vérifier)
      

 

Si j'ai du temps pendant l'automne, je rajouterai un Child par micro-onduleur détectés. On pourra récupérer la puissance instantannée produite.

 

En espérant que ce Fork puisse vous servir
@Lazer, je te laisse voir si tu veux créer un nouveau Topic ou pas

 

 

 

 

 

Modifié 20 août 2023 par TitiXsi

[Lazer 8 477]

Bravo

 

Oui il vaut mieux que tu fasses un topic dédié pour maintenir cette version, qui je pense évoluera en parallèle de la mienne.

Tu as ajouté des choses intéressantes, et d'autres que je ne reprendrai clairement pas.
Idéalement il faudrait faire un fichier de config pour permettre à l'utilisateur de paramétrer ça comme il veut, mais ça fait usine à gaz à maintenir... du coup je pense que 2 versions distinctes c'est plus facile.

[TitiXsi 66]

Bouh que j'en ai marre de cet accès à la passerelle qui ne marche jamais ou du moi très rarement... comme si il fallait des plombe pour répondre à la requête et qu'elle s'accumulaient... plantage toutes les 1h puis toutes les 15min, puis tout le temps ...

J'ai contacté le support Enphase qui au début a été bien sympa, mais là visiblement, ils bottent en touche... ca vient de l'api et pas de la passerelle, merci de contacter le support api. et de l'autre côté, ca vient de la passerelle et pas de l'api ...

 

Je viens d'être fibré et je pensais que ceci arrangerai peut-être les choses ... Que Nenni !
Du coup je vais essayer de la relier en RJ45, même si avant le déploiement D7, je n'avais aucun problème à taper l'api toutes les 500ms ...

 

c'est dommage, j'avais un chouette truc pour vous .. le nombre Qrelay UP et le nombre de micro-onduleurs qui produisent...

En codage la puissance par micro-onduleurs... mais là je suis bloqué dans le dev ... :'(

 

Il existe quoi en device zwave afin de trouver un woraround fiable pour mesurer 2 puissances (j'ai vu quelques pinces, mais lesquelles sont fiable et jusqu'à quelle puissance) ?

 

Modifié 12 septembre 2023 par TitiXsi

[Lazer 8 477]

En Z-Wave, je dirais Aeotec ou Qubino.

Enfin, Qubino, attention, ils ne sont plus fabriqués, depuis le rachat par Shelly ils sont en train de resortir les modèles remis au gout du jour... seulement 3 pour l'instant, et pas encore de pince de mesure.... sinon pour rester chez Shelly le fameux 1 PM qui est si populaire, mais il faudra l'interroger via l'API en Wi-Fi.

 

Sinon pour ta passerelle Envoy.... depuis le début tu étais en Wi-Fi ?
Cherche pas plus loin, le problème est là, ça ira mieux en RJ45.

 

La fibre n'a aucun impact, puisque tu l'interroge en local, donc sans passer par Internet. Tout au plus un accès Interner trop lent et saturé pourrait retarder l'envoi des données vers le cloud Enphase, m'enfin ça ne doit pas représenter une grosse quantité d'info.

[TitiXsi 66]

oui, j'ai toujours eté en wifi 2.4ghz, j'ai essayé en 5ghz. j'ai même tenté de passer en RJ45, ça n'avait pas été folichon non plus, mais j'avais un câble très vieux un cat 4e je crois

Bref, je vais profiter du cat5e qui passe à proximité de la passerelle et qui alimentait ma box free en adsl. Je vais lui mettre une prise et on verra déjà ce que ça donne.

 

Je te rejoins sur le fait qu'il n'y a pas de grosses à transiter, mais il y a toujours un check du token qui à mon avis prends du temps, je ne sais pas comment c'est géré cette histoire en local...

 

J'ai édité mon précédent message entre temps, et rajouté un snapshot sur mon état de codage

 

Merci pour les devices zwave, je regarderai ça quand j'aurais abandonné l'api enphase ...

[Lazer 8 477]

J'ai vu, mais ça te sert à quoi de savoir combien de QRelay et de MO fonctionnement ?

Normalement il fait jour et ils fonctionnent tous, sinon il fait nuit et tous les MO arrêtés, ou bien le courant est coupé et dans ce cas ce sont tous les MO + les QRelays qui sont arrêtés.

 

En ce qui concerne le token, je pense qu'il est vérifié en local, je doute fort qu'il soit vérifié en ligne à chaque connexion sur l'API locale.
C'est facile à savoir, il suffit de couper l'accès Internet pendant qu'on fait les essais... ce qui ne m'est pas arrivé récemment (pas de coupure fibre depuis que je suis passé à l'auth avec le token... enfin j'ai pas souvenir)

 

Modifié 12 septembre 2023 par Lazer

[TitiXsi 66]

Justement, depuis des mises à jour des passerelles post D7, certains micro onduleurs on du mal à retrouver le nord par moment, je suis sur le groupe facebook Enphase france et c'est au minimum 2,3 personnes par semaine qui ont des perte de mo, et comme l'application n'envoie pas de notification en cas de problème... bref, si ca intéresse que moi, c'est pas grave :p

 

Edit : J'ai rajouté mon 3eme Qrelay avec mes nouveaux panneaux et j'ai pu les voir passer via la QA (le seul moment ou elle a marché d'ailleurs)

Modifié 12 septembre 2023 par TitiXsi

[Lazer 8 477]

C"est tout de même très étrange tous les problèmes que tu as.... si tu n'es pas le seul sur Facebook, ce n'est pas vraiment rassurant cela dit...

De mon coté, Enphase, ça fonctionnement tellement bien, aucun souci à déclarer (si on met de coté la politique de gestion des firmwares / cloud...)

Je n'en dirais pas autant d'APsystems dont la passerelle est une grosse bouse fumante, et j'ai aussi quelques doutes sur les micro-onduleurs... pas sûr, mais je soupçonne quelques micro-coupures, sans incidence sur l'énergie produite quotidiennement cela dit.

[TitiXsi 66]

Tous les problèmes reportés date d'après le token. Comme disait l'autre... c'était mieux avant... je soupçonne qu'ils aient mal anticipé les besoins de gestion de token et qu'ils soient un poil sous l'eau niveau serveur. D'ailleurs hier ça pedalait sous l'application... bref. J'adore enphase mais son api, beaucoup moins ...

[Lazer 8 477]

Le week-end dernier c'est leur cloud qui avait des souci, ils ont même mis une bannière sur leur site... résultat plusieurs heures de retard dans la mise à jour des stats.
Forcément ça se répercute sur l'appli vu qu'elle va chercher les données au même endroit.

 

C'est "marrant", il y a quelques temps je disais que ce firmware D7 avait été poussé à la va vite chez les clients sans prendre le temps de le tester à fond, Nico n'était pas d'accord et disait que tout était maitrisé. Visiblement pas, avec du recul.

[TitiXsi 66]

Je ne comprends même pas la légalité de cette mise à jour forcée. Si cela rend obsolète certaines fonctionnalités du système...

[Lazer 8 477]

Les API locales, c'était une fonctionnalité qui n'était même pas documentées, donc bon courage... j'espère que tu as une armée de très bons avocats

[TitiXsi 66]

J'ai simplement une Doc qui explique que l'API la passerelle est accessible via IP/home et déjà, là, ça fonctionne pas..  donc bon... parlon de la base des choses... au ping j'ai rien.

[TitiXsi 66]

20 ième appel au support enphase :

• Oui monsieur c'est un problème connu, même pour nous, ça prends très longtemps d'avoir les infos et parfois les requêtes n'aboutissent pas... et ceci depuis la version D7
• On ne sais pas vraiment d’où ça vient... on cherche toujours, on est entrain de développer un autre système d'authentification, le système va changer.
• Peut-être qu'il n'y aura plus de token en local, je ne sais pas mais on travail dessus.
• Malheureusement, je ne peux pas downgrader la passerelle en D5, ca serait trop simple pour nous.
• ceci n'a rien avoir avec votre Connexion Wifi ou autre
• on va vider le cache de la passerelle et vous allez ré-essayer
  

 

A suivre !

 

Sinon Aeotec Gen 5 avec 3 pinces et j'en utiliserai que 2...

[TitiXsi 66]

@Lazer, je me rends compte que la QA quand elle rencontre un "can't get (production/inventory...) recommence immédiatement sauf que ma passerelle a un temps de réponse au ping aléatoire ... quelques ms à plusieurs secondes. Je parlais dans mes messages précédent de saturation progressive, ne serais pas lié au setTimeOut qui n'attends pas forcément la fin de la réponse précédente (ce n'est pas son rôle, on est en asynchrone) pour envoyer une nouvelle requête et rajouter de la latence de traitement à la passerelle jusqu'à ce qu'elle mouline complet et ne soit plus accessible ?

 

Merci pour ton expertise

[Lazer 8 477]

Ah ben oui tient, bien vu

Je n'avais pas percuté quand tu as parlé de Wi-Fi, mais effectivement, clairement les requêtes trop rapprochées sollicitent trop ta passerelle, surtout si tu as mis 5 ou 10 secondes d'intervalle.
Repasse à 60s et ça ira mieux je pense.

[TitiXsi 66]

il y a 27 minutes, Lazer a dit :

Ah ben oui tient, bien vu

Je n'avais pas percuté quand tu as parlé de Wi-Fi, mais effectivement, clairement les requêtes trop rapprochées sollicitent trop ta passerelle, surtout si tu as mis 5 ou 10 secondes d'intervalle.
Repasse à 60s et ça ira mieux je pense.

je suis déjà à 60sd, mais quand on regarde le log. on est à plusieurs tentatives par seconde (en cas d'echec)

 

Modifié 13 septembre 2023 par TitiXsi

[Lazer 8 477]

Ouh là là, c'est bizarre ça.

C'est bien le paramètre RefreshInterval que tu as mis à 60 ?

Sinon il faut relancer le QA avec la variable debug à true pour voir le détail de ce qui se passe.

 

(il faut l'ajouter au QA si elle n'existe pas déjà dans l'onglet dédié)

 

Modifié 13 septembre 2023 par Lazer

[TitiXsi 66]

il y a 8 minutes, Lazer a dit :

Ouh là là, c'est bizarre ça.

C'est bien le paramètre RefreshInterval que tu as mis à 60 ?

Sinon il faut relancer le QA avec la variable debug à true pour voir le détail de ce qui se passe.

 

(il faut l'ajouter au QA si elle n'existe pas déjà dans l'onglet dédié)

 

J'ai passé le settimeout général à 15sd au lieu de 1sd... à voir, ca semble être plus stable même si il y a des déco.
J'ai tourné en mode debug je vais suivre ...

 

 

[TitiXsi 66]

Tiens une question de pur curiosité sur les variables

Pourquoi j'en ai qui ne sont pas éditables ?

[Lazer 8 477]

Nom de variable trop long je pense.

Sinon, 1s, tu m'étonnes que la passerelle saturait