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

[seb.digeos@sfr.fr]

SR19

Bonjour

Vous qui avez l'expérience du développement du code pour EnPhase, que pensez-vous de ces problèmes soulevés par certains.
N'ayant chez moi pas de système Enphase, je ne peux investiguer. A l'époque du développement, je m'étais connecté à distance à un système Enphase dont la personne avait rerouté temporairement les ports.

Cordialement
André / F1ATB

Bonjour, si ça peut aider pour identifier le problème je peux ouvrir temporairement les ports de ma passerelle 

Cordialement

[Gub]

La solution temporaire est de repasser par vos domotique jeedom home assistant etc et publier votre conso en mqtt

Merci berserk14, c'est ce que j'ai fait grâce à vous: 
Voici mon yaml avec l'intégration enphase :

alias: Envoy vers MQTT
description: ""
triggers:
  - trigger: state
    entity_id:
      - sensor.envoy_122323128582_current_net_power_consumption
actions:
  - action: mqtt.publish
    data:
      topic: envoy/net_power_consumption
      payload: >-
        {"Pw":{{
        states("sensor.envoy_122323128582_current_net_power_consumption") | float * 1000
        }}}
      retain: true
mode: single

Merci pour le partage.
Je suis en train de tester et j'ai une actualisation des données Envoy seulement toutes les 60 secondes (environ) dans HA.
C'est pareil pour vous ?

[Luc1]

Bonjour à tous,
Le problème n'est pas particulier avec le routeur F1ATB, mais pour tous les utilisateurs des API Enphase... (ex:  https://forum-photovoltaique.fr/viewtopic.php?t=82076 )

J'ai trouvé ça : nouvelle tech brief d'Enphase juin 2025 décrivant les modalités de connexion actualisées pour acceder aux API :
 teb-00060-en-us-iq-gateway-local-api-or-ui-access-using-token-2025-06-18
in https://enphase.com/download/iq-gateway-...sing-token

Avec pas mal de changements par rapport à la version diffusée partout de 
 Tech Brief-IQ Gateway Local API or UI Access using Token-EN-US-12-14-2022 
qu'elle annule et remplace. 

J'y note  également un passage obligé de htttp à https
NOTE: When the token retrieval URL is accessed through the web browser, the browser does an HTTPS GET on the URL. The content of the response can be seen in the browser. This content contains the token, expected expiry date, and time in UNIX epoch time stamp format. The duration for which the token is valid can be verified using this information.
L'ancienne version accédait en HTTTP

ancienne version:
curl -f -k -H 'Accept: application/json' -H 'Authorization: Bearer eyJraWQiOi…’ -X GET http://<IQ Gateway-ip>/api/v1/production/inverters
et maintenant:
curl -f -k -H 'Accept: application/json' -H 'Authorization: Bearer eyJraWQiOi…’ -X GET https://<IQ Gateway-ip>/api/v1/production/inverters


A explorer par des bidouilleurs plus doués en anglais et en programmation que moi !!!

[michy]

ça utilise déjà https sur le port 443

Code :

clientSecu.println("GET https://" + host + "/ivp/meters/reports/consumption HTTP/1.0");

par contre on utilise une autre API :  /ivp/meters/reports/consumption  et pas /api/v1/production/inverters

Cette API  /ivp/meters/reports/consumption existe encore dans la doc de 2025 (je ne sais pas si c'est un bug dans les docs, il est écrit que les informations sont rafraichi toutes les 5 minutes, ce qui est incompatible avec le fonctionnement du routeur)  

voir s'il ne faudrait pas utiliser l'API /ivp/livedata/status qui est plus cohérente pour le routeur



Si quelqu'un peut faire une capture (texte) de ce qui est retourner dans la navigateur dans chacune des situations quand on fait les appels suivant (remplacer {IQ_Gateway_ip} par l'IP de votre passerelle):

https://{IQ_Gateway_ip}/ivp/meters/readings

https://{IQ Gateway_ip}/ivp/pdm/energy

https://{IQ_Gateway_ip}/api/v1/production/inverters

https://{IQ_Gateway_ip}/ivp/meters/reports/consumption

https://{IQ_Gateway_ip}/ivp/livedata/status