Bonjour @all,
de mon coté le routeur n'a pas enclenché sur les heures de nuit !
je le ferais en 1° temps à la main, sinon je recâblerais mon horloge Hager qui mettait les HC et mettait en service l'été entre 14 et 17h > plein soleil !
A l'ancienne Quoi !
a+

Bonjour,
j'ai carrément décâbler mon routeur et laisser comme ça pendant 1 heure ,mais cela n'a rien fait de plus...
Mon routeur n'arrive pas à ce connecter à la passerelle Emphase, les leds rouge et verte clignotent 3 fois puis s'éteignes.

(12-06-2026, 12:22 PM)lahuchette a écrit : Bonjour,
j'ai carrément décâbler mon routeur et laisser comme ça pendant 1 heure ,mais cela n'a rien fait de plus...
Mon routeur n'arrive pas à ce connecter à la passerelle Emphase,  les leds rouge et verte clignotent 3 fois puis s'éteignes.

Hello, même probleme à la suite de la MAJ du firmware de la passerelle hier matin.

La bonne nouvelle c'est que cela refonctionne avec HA ce matin après avoir spécifié que les communications avec l'envoy devaient se faire en HHTPS et pas en HTTP.

Pour F1ATB ca ne fonctionne toujours pas mais je suis en v17.07

A suivre

Bonjour ,
tu peux expliquer "avec HA" et ou tu règle le Https ( HHtps !,)

Bonjour,

Visiblement je ne suis pas le seul...
Une solution en vue, je suis en version 15.12

Merci

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

(12-06-2026, 05:38 PM)berserk14 a écrit : 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

Bonsoir les Enphaseurs perdus...
Comme vous tous, j'étais en 16.09 qui marchait nickel et depuis le 29 Mai alors que j'étais en vacances, plus rien . Déconnection entre routeur et passerelle Envoy S Metered ( D8.3.5289.260415 (d3c300))  Freebox Revolution (4.12.1)

J'ai trouvé une solution provisoire: downgrader en version 15.01 et je retrouve la communication entre routeur et passerelle Enphase fonctionnelle .... A partir de la 15.12, plus rien ne marche. Enfin si : certes toutes les valeurs sont à 0, les courbes plates et nulles MAIS, la marche forcée (qui ne fait pourtant pas bouger les courbes du routeur), commande bien le triac ( ce que je vérifie en voyant ma conso instantanée monter de 3000w dans le statut en direct de l'appli Enphase).

Quand j'observe le moniteur serie avec la V17.20 par ex, je vois:
Version : 17.20
Heure Defaut:
idxFuseau: 0
CODE: CET-1CEST,M3.5.0,M10.5.0/3
ssid:Lexxxxxxxxfreebox
password:quexxxxxxxxxxxxxxxxxxxorale
Wifi Begin : Lexxxxxxxxxxfreebox
.6.6.6.6.6.6.6.6.6
Connecté par WiFi, addresse IP : 192.168.1.195 or <a href='http://RMS-ESP32-9777696.local' >RMS-ESP32-9777696.local</a>
Serveur Telnet actif sur le port 23
Source : Enphase
Essai connexion Enlighten server 1 pour obtention session_id!
Notification de l'heure ( time synchronization event )
Sync time in ms : 10800000
12/06/2026 22:31:08 : Réception de l'heure Internet
Connected to Enlighten server:enlighten.enphaseenergy.com
headers 1 Enlighten received
session_id :
12/06/2026 22:31:08 : connection to client clientFirmV5 failed (call to Envoy-S)
12/06/2026 22:31:08 : connection to client clientFirmV5 failed (call to Envoy-S) .....
and so on, jusqu'à un rebboot de l'ESP après les 3 minutes de timeout  et qui reboucle à nouveau sur des tentatives de connection ....
Mais je ne suis pas en V5 !!!!

En resumé: connecté à Enlighten, headers recus, mais pas d'obtention de Session ID, pas de récupération du Token en V7 (Je ne suis pas en V5 !!!)

Sauf que, de facon aléatoire, lors de l'enregistrement du monitoring de certains reboot, je lis: 
Source : Enphase
Essai connexion Enlighten server 1 pour obtention session_id!

assert failed: udp_new_ip_type /IDF/components/lwip/lwip/src/core/udp.c:1278 (Required to lock TCPIP core functionality!) 

Backtrace: 0x4008ec3c:0x3ffb1b30 0x4008ec01:0x3ffb1b50 0x4009536d:0x3ffb1b70 0x4013f52a:0x3ffb1cb0 0x401379fc:0x3ffb1cd0 0x40137a5d:0x3ffb1d10 0x40136592:0x3ffb1d30 0x40136651:0x3ffb1d70 0x401366cc:0x3ffb1d90 0x40136b0e:0x3ffb1db0 0x40137605:0x3ffb1dd0 0x40105b7e:0x3ffb1df0 0x40106a2f:0x3ffb1e70 0x40106b2a:0x3ffb1ef0 0x401e2de1:0x3ffb1f10 0x400fa32f:0x3ffb1f30 0x400fe9c2:0x3ffb1fe0 0x401209d6:0x3ffb2270 0x4008fa85:0x3ffb2290

Alors comme un rookie de la programmation que je suis, j'ai demandé à Mistral Vibe qui me fait la réponse suivante que je soumet à la sagacité d'André e de nos collègues "pointus" :

L'erreur que vous rencontrez ( assertfailed: udp_new_ip_type) n'est pas directement liée à votre code de connexion HTTPS ( clientSecu.connect() ), mais elle peut être déclenchée par une mauvaise gestion du contexte réseau dans votre application ESP32/ESP-IDF, surtout si vous utilisez à la fois des sockets UDP et HTTPS (TLS) dans le même programme.
Voici une analyse ciblée sur votre extrait de code et des pistes pour résoudre le problème :

---

1. Contexte de votre code

clientSecu.setInsecure();  // Désactive la vérification du certificat SSL/TLS
if (!clientSecu.connect(server1Enphase, 443, 3000))
StockMessage("Connection failed to Enlighten server :" + Host);

• Vous utilisez probablement une bibliothèque comme WiFiClientSecure (ESP32) ou HTTPClient pour une connexion HTTPS.setInsecure()      permet de contourner la vérification du certificat (utile pour le développement, mais à éviter en production).
• Le timeout de 3000 ms est raisonnable pour une connexion HTTPS.
  

---

2. Pourquoi l'assertion lwIP peut-elle se déclencher ?
L'erreur      udp_new_ip_type
suggère que quelque part dans votre code (ou une bibliothèque utilisée), une fonction lwIP est appelée sans verrouiller le cœur TCPIP.
Cela peut arriver si :

• Vous utilisez à la fois UDP et HTTPS dans votre programme, et qu'une bibliothèque (ou votre code) appelle directement des fonctions lwIP bas niveau sans protection.
  
• Vous avez désactivé le verrouillage TCPIP dans la configuration ESP-IDF (CONFIG_LWIP_TCPIP_CORE_LOCKING ).
  
• Vous utilisez une version obsolète de ESP-IDF ou de la bibliothèque WiFiClientSecure.
  

---

                        Merci de vos commentaires, 
                               Très cordialement à  tous
                                       Francis

C est vrai que c est la misère car l'un fait planter l'autre.
Alors que séparateur le routeur ou la passerelle marchent bien.

Il n' y a pas moyen de couper la prise de musure enphase dans f1atb et de mettre une marche forcée dans les actions de 1500w de chauffe eau de 10h du mat a 16h le soir.

Je n ai pas d autres sources de mesure et il faut très beau donc on ne profite pas de la production.

---

J ai mi mon routeur sur source de données non définie, ce qui lui permet de ne plus communiquer avec enphase, pour l' instant ça ne plante plus ni côté routeur, ni côté passerelle.

J ai mi une action de 10h a 18h avec une puissance de routage de 50% et un seuil PV de 3000w , du coup mon chauffe eau fonctionne a mi puissance durant la journée.

Si jamais ça peut dépanner quelqu un en attendant un retour positif de chez enphase.

Bonjour,
Même constat chez moi.
L'un fait planter l'autre...
Faute de temps et d'autres moyens de mesure, j'ai dû couper le routeur.
En espérant qu'une solution soit trouvée