même soucis, perte de data dans home assistant depuis la gateway enphase. puis je me suis rendu compte ce matin que plus d'eau chaude non plus car le routeur f1atb etait en carafe car plus de data depuis la gateway.
ce que j'ai remarqué, c'est qu'en faisant un reboot de ma gateway enphase avec le routeur f1atb éteint, elle reboot et repart correctement. mes remontées dans home assistant fonctionne bien. mais des que je rallume le routeur f1atb, dans les 5min la gateway s'effondre et se met à clignoter rouge à nouveau.
j'etais sur une vieille version du routeur. j'ai upgrade en 17.21 et meme resultat.
pour le moment j'ai shunté le routeur pour gérer à nouveau mon chauffe eau en mode hp/hc :'(
(Hier, 06:20 PM)Pliz72 a écrit : Idem pour moi, testé a l'instant
Token OK mais pas de mesure
Merci pour les tests.
Supprimer le mDNS ne suffit donc pas pour tout le monde pour que cela fonctionne à nouveau.
Il doit y avoir une subtilité qui fait que cela fonctionne chez Luc1 mais pas chez d'autres utilisateurs.
oui et concernant mDNS en décochant la case " Adresse IP auto par résolution mDNS" on le bypasse (v17.18) sans avoir à modifier le code (et on utilise dans ce cas l"adresse IP manuelle " Adresse IP Enphase-Envoy externe"). Mais ça ne résout pas la suite.
Sinon dans mon cas j'ai un raspberry/homeAssistant/mosquitto qui voit bien les sensors envoy ... Donc pour l'instant je renvoie par MQTT le sensor envoy à l'esp32 tout en essayant de comprendre ce qui empeche l'esp d'interroger le envoy ... à suivre.
(Hier, 06:20 PM)Pliz72 a écrit : Idem pour moi, testé a l'instant
Token OK mais pas de mesure
Merci pour les tests.
Supprimer le mDNS ne suffit donc pas pour tout le monde pour que cela fonctionne à nouveau.
Il doit y avoir une subtilité qui fait que cela fonctionne chez Luc1 mais pas chez d'autres utilisateurs.
oui et concernant mDNS en décochant la case " Adresse IP auto par résolution mDNS" on le bypasse (v17.18) sans avoir à modifier le code (et on utilise dans ce cas l"adresse IP manuelle " Adresse IP Enphase-Envoy externe"). Mais ça ne résout pas la suite.
Sinon dans mon cas j'ai un raspberry/homeAssistant/mosquitto qui voit bien les sensors envoy ... Donc pour l'instant je renvoie par MQTT le sensor envoy à l'esp32 tout en essayant de comprendre ce qui empeche l'esp d'interroger le envoy ... à suivre.
Idem mais ce n'est pas magique en terme de réactivité ca fait grossièrement le boulot,
effectivement que ca soit jeedom ou HA il n'y as pas eut de maj sur les intégrations et pourtant cela fonctionne, je ne veux pas faire de la théorie de comptoir mais ca semble cibler, il existe des afficheurs diy pour la enphase il faudrais se renseigner savoir si de leurs côtés ils ont les mêmes probleme que nous
D'ailleurs enphase n'as jamais répondu a mon mail
S'il manque effectivement l'API /ivp/meters/reports/consumption, c'est un second problème qui se greffe en plus
Dans la version 17.20 du routeur, On doit obtenir 6 informations de la passerelle
PactConso_M => Puisance en Watt en cours dans la maison (couvert par apport solaire et soutirage réseau Enedis ... dispo dans ivp/meter/reading reste a identifier l'item
PactReseau => Puissance en Watt échangée avec le réseau Enedis, dispo dans ivp/meter/reading sous le nom "activePower" doc[0]["activePower"]
PvaReseau => Puissance en VA échangée avec le réseau Enedis, dispo dans ivp/meter/reading sous le nom "apparentPower" doc[0]["apparentPower"]
whDlvdCum => Cumul wattHeure délivré dispo dans ivp/meter/reading sous le nom "actEnergyDlvd" doc[0]["actEnergyDlvd"]
Tension_M => tension dispo dans ivp/meter/reading sous le nom "voltage" doc[0]["voltage"]
Intensite_M => intensité dispo dans ivp/meter/reading sous le nom "current" doc[0]["current"]
Bonjour à tous,
Merci Michy pour ces détails. Pour infos je suis en <software>D8.3.5528</software> et RMS 17.20 (j'ai désactivé la résolution mDNS car j'ai une IP fixe pour l'IQ + le mDNS ne fonctionne pas chez moi)
Même remarque que la majorité des personnes: le routeur solaire tente de se connecter à l'IQ meter qui se met en 'rideau' (4 led rouge) => pour solutionner dans les parametres du RMS j'ai sélectionné "Non définie" pour la "Source" dans l'onglet Mesures de puissance". Puis j'ai redémarré l'IQ meter et depuis il fonctionne (pour info: j'ai testé de remettre la source Enphase dans le RMS et de nouveau 4 leds rouges sur IQ meter au bout de quelques minutes).
Pour faire avancer sur le pb je partage les infos ci-dessous. (Note pour faire ces tests il faut que l'IQ meter soit bien sure avec les leds vertes)
pour générer un token: https://enlighten.enphaseenergy.com/entr...erial_num="Numéro série passerelle IQ Enphase à 12 chiffre"
Lecture du Json: ivp/meters via la commande: (je suis sur Linux)
curl -k -H "Authorization: Bearer MON_TOKEN_TROUVE_PRECEDEMENT" \ https://MON_IP_IQ_METER/ivp/meters/readings
test via navigateur https://MON_IP_IQ_METER/login.html
=> Attention votre navigateur va indiquer url "Non sécurisé" il faut donc accepter la "Connexion non sécurisé" (le message dépend de votre navigateur)
J'ai joint le résulat de "ivp/meters/readings" dans meters_readings.txt => on retrouve bien les valeurs pour activePower/apparentPower/actEnergyDlvd/voltage/current (il manquerais la correspondance vers PactConso_M si quelqu'un la connait ?), je n'ai pas le code source sous la main ;-)
J'espère que cela pourra aider, désoler je dois me déconnecter, demain je serais en déplacement pour le boulot, j'ai la possibilité de pousser cela plus en détail mercredi soir ;-) si quelqu'un n'a pas résolut le pb d'ici là ;-)
Bien à vous
Hier, 08:43 PM (Modification du message : Hier, 09:18 PM par Serge19.)
(Hier, 07:36 PM)olivier38 a écrit :
(Hier, 06:57 PM)Mike a écrit :
(Hier, 06:20 PM)Pliz72 a écrit : Idem pour moi, testé a l'instant
Token OK mais pas de mesure
Merci pour les tests.
Supprimer le mDNS ne suffit donc pas pour tout le monde pour que cela fonctionne à nouveau.
Il doit y avoir une subtilité qui fait que cela fonctionne chez Luc1 mais pas chez d'autres utilisateurs.
oui et concernant mDNS en décochant la case " Adresse IP auto par résolution mDNS" on le bypasse (v17.18) sans avoir à modifier le code (et on utilise dans ce cas l"adresse IP manuelle " Adresse IP Enphase-Envoy externe"). Mais ça ne résout pas la suite.
Sinon dans mon cas j'ai un raspberry/homeAssistant/mosquitto qui voit bien les sensors envoy ... Donc pour l'instant je renvoie par MQTT le sensor envoy à l'esp32 tout en essayant de comprendre ce qui empeche l'esp d'interroger le envoy ... à suivre.
S'il manque effectivement l'API /ivp/meters/reports/consumption, c'est un second problème qui se greffe en plus
Dans la version 17.20 du routeur, On doit obtenir 6 informations de la passerelle
PactConso_M => Puisance en Watt en cours dans la maison (couvert par apport solaire et soutirage réseau Enedis ... dispo dans ivp/meter/reading reste a identifier l'item
PactReseau => Puissance en Watt échangée avec le réseau Enedis, dispo dans ivp/meter/reading sous le nom "activePower" doc[0]["activePower"]
PvaReseau => Puissance en VA échangée avec le réseau Enedis, dispo dans ivp/meter/reading sous le nom "apparentPower" doc[0]["apparentPower"]
whDlvdCum => Cumul wattHeure délivré dispo dans ivp/meter/reading sous le nom "actEnergyDlvd" doc[0]["actEnergyDlvd"]
Tension_M => tension dispo dans ivp/meter/reading sous le nom "voltage" doc[0]["voltage"]
Intensite_M => intensité dispo dans ivp/meter/reading sous le nom "current" doc[0]["current"]
Bonjour à tous,
Merci Michy pour ces détails. Pour infos je suis en <software>D8.3.5528</software> et RMS 17.20 (j'ai désactivé la résolution mDNS car j'ai une IP fixe pour l'IQ + le mDNS ne fonctionne pas chez moi)
Même remarque que la majorité des personnes: le routeur solaire tente de se connecter à l'IQ meter qui se met en 'rideau' (4 led rouge) => pour solutionner dans les parametres du RMS j'ai sélectionné "Non définie" pour la "Source" dans l'onglet Mesures de puissance". Puis j'ai redémarré l'IQ meter et depuis il fonctionne (pour info: j'ai testé de remettre la source Enphase dans le RMS et de nouveau 4 leds rouges sur IQ meter au bout de quelques minutes).
Pour faire avancer sur le pb je partage les infos ci-dessous. (Note pour faire ces tests il faut que l'IQ meter soit bien sure avec les leds vertes)
pour générer un token: https://enlighten.enphaseenergy.com/entr...erial_num="Numéro série passerelle IQ Enphase à 12 chiffre"
Lecture du Json: ivp/meters via la commande: (je suis sur Linux)
curl -k -H "Authorization: Bearer MON_TOKEN_TROUVE_PRECEDEMENT" \ https://MON_IP_IQ_METER/ivp/meters/readings
test via navigateur https://MON_IP_IQ_METER/login.html
=> Attention votre navigateur va indiquer url "Non sécurisé" il faut donc accepter la "Connexion non sécurisé" (le message dépend de votre navigateur)
J'ai joint le résulat de "ivp/meters/readings" dans meters_readings.txt => on retrouve bien les valeurs pour activePower/apparentPower/actEnergyDlvd/voltage/current (il manquerais la correspondance vers PactConso_M si quelqu'un la connait ?), je n'ai pas le code source sous la main ;-)
J'espère que cela pourra aider, désoler je dois me déconnecter, demain je serais en déplacement pour le boulot, j'ai la possibilité de pousser cela plus en détail mercredi soir ;-) si quelqu'un n'a pas résolut le pb d'ici là ;-)
Bien à vous
(Hier, 06:20 PM)Pliz72 a écrit : Idem pour moi, testé a l'instant
Token OK mais pas de mesure
Merci pour les tests.
Supprimer le mDNS ne suffit donc pas pour tout le monde pour que cela fonctionne à nouveau.
Il doit y avoir une subtilité qui fait que cela fonctionne chez Luc1 mais pas chez d'autres utilisateurs.
Bonsoir Mike,
Je résume :
Comme Luc1 est en 5289 seul le mDNS causait pb mais pour les autres en 5528 c'est le mDNS + le flux des remontées consos.
La modif que j'ai faite de génération Token n'y change rien.
En 5167 tout marche comme avant en version 17.20 modifiée ou pas. C'est ce que j'ai testé et perso toujours bloqué en 5167.
Hier, 10:04 PM (Modification du message : Hier, 10:19 PM par Mike.)
(Hier, 09:45 PM)Serge19 a écrit : Bonsoir Mike,
Je résume :
Comme Luc1 est en 5289 seul le mDNS causait pb mais pour les autres en 5528 c'est le mDNS + le flux des remontées consos.
La modif que j'ai faite de génération Token n'y change rien.
En 5167 tout marche comme avant en version 17.20 modifiée ou pas. C'est ce que j'ai testé et perso toujours bloqué en 5167.
Merci Serge pour ce résumé.
Je pensais à tort que Luc1 utilisait la meme version du firmware que les autres utilisateurs rencontrant le problème. Au moins maintenant tout est clair.
J'aimerai pouvoir aider mais n'ayant pas le système Enphase, ce n'est pas evident.
De ce que je comprends, l’intégration Home Assistant continue de fonctionner quelque soit le firmware vu que certains l'utilisent comme contournement. Le code de cette integration doit être disponible quelque part et peut-être qu'on pourrait l'utiliser pour effectuer les mêmes requêtes.
Les sources de l’intégration HA sont ici : https://github.com/home-assistant/core/t...hase_envoy
Un coup d’œil rapide indique qu'elles sont basées sur la lib pyenphase : https://github.com/pyenphase/pyenphase
Avec la version 8.3.5289.....
Un ESP a repris le routage parfaitement avec la version 16.10 sans mDNS fournie par Mike depuis cet après midi.
Une tentative d'install de V 17.21 sur un autre ESP en echec ce soir:
Serveur Telnet actif sur le port 23
Source : Enphase
Échec! passerelle Enphase envoy déconnectée
connection to client clientFirmV5 failed (call to Envoy-S)
connection to client clientFirmV5 failed (call to Envoy-S)
connection to client clientFirmV5 failed (call to Envoy-S)
connection to client clientFirmV5 failed (call to Envoy-S)
Alors que pendant ce temps là, l'autre ESP en 16.10 tourne parfaitement, interroge les API et recoit les données !!!!
et toujours token recuperé manuellement via chrome "installer" = 12h alors que celui lu sur le port serie lors du demarrage de 16.10 "owner" = 12 mois
un premier jet de code pour ceux qui pourrait compiler tester
ça compile mais rien n'a été testé, je n'ai pas de passerelle ...,
J'ai fait en sorte de pouvoir tester des choses en jouant sur le nom du routeur (un reboot est nécessaire pour l'obtention du token)
* le premier caractère impact le setup pour obtenir le Token
un $ utilise la méthode POST en mettant les données dans la body
un # utilise la méthode POST avec paramètres sur la ligne URL mais ajout du header x-www-form-urlencoded
tout autre caractère au début du nom de routeur utilise le code tel que distribué par André
* le deuxième caractère impact la lecture des données sur la passerelle
un $ utilise la Lecture utilisant l'API ivp/meter/reading, basé sur code/décode André (pas de ArduinoJSON)
un # utilise la Lecture utilisant l'API ivp/meter/reading, basé sur extraction/filtrage par ArduinoJSON
tout autre caractère en 2ieme place du nom de routeur utilise le code tel que distribué par André
Si les réponses que je propose bénévolement sur ce forum ne vous plaisent pas, ignorez-les simplement sans me jeter la pierre ! (Ou ne posez pas de question)
Hier, 11:18 PM (Modification du message : Aujourd’hui, 10:23 AM par Mike.)
J'ai demandé à une IA de comparer le code existant du routeur avec celui de pyenphase et d'adapter le code du routeur en fonction.
Il y a des petites modifications, je ne sais pas si cela aura un impact ou pas. Le code compile mais je ne peux pas le tester moi même. Si quelqu'un veut tenter le coup, voici un .bin de la 16.10 qui contient les changements en question : https://transfert.free.fr/QNwpEeo
Attention: Ce .bin ne peut pas être installé en OTA depuis une version 17.
J'attache également le fichier source pour ceux qui voudraient compiler.
,