Problèmes connexion wifi Freebox Ultra
-
@Arnaud-R A priori le problème wifi de la Freebox semble connu et touche différents IOT.
https://dev.freebox.fr/bugs/task/39906@Nicolas-Bernaerts je pense avoir trouvé une solution paliative (une rustine plutot).
En plus de la désactivation de l'AX sur le 2.4Ghz, j'ai effectué quelques modifications. Voici le rapport généré par Hermes :
DENKY D4 - RAPPORT TECHNIQUE
Date : 12 juin 2026
Firmware : Tasmota 15.2.0 (teleinfo-denkyd4)
Matériel : ESP32-PICO-V3-02 v3.0 @ 240 MHz
- IDENTIFICATION
Appareil : Denky D4 (compteur téléinformation)
MAC : 4C:75:XX:XX:BC:B0
IP : 192.168.1.52
Hostname : denky-7344
Module : ID 0 (Denky D4)
MQTT : Connecté à HA 192.168.1.111:1883, topic "denky", client "denkyd4"
OTA URL : NicolasBernaerts/tasmota/.../tasmota32-teleinfo-denkyd4.bin- PROBLÈME 1 : CORRUPTION DE LA CLÉ RÉSEAU ZIGBEE
Symptôme : Après reboot de la VM HAOS, Zigbee2MQTT (v2.12.0) crash au démarrage.
Message : "Network key must be a 16 digits long array, got 15 values"Cause : Le fichier zigbee2mqtt/configuration.yaml avait une network_key incomplète
(15 valeurs au lieu de 16). La version 2.12.0 a ajouté une validation stricte absente
des versions précédentes.Solution : Récupération de la clé complète depuis coordinator_backup.json.
Clé hexadécimale : 96af96ec5916xxxxxxx4d36c8a671fdc
network_key:
- 150 - 175 - 150 - 236
- 89 - 22 - 32 - 198
- 2 - 228 - 211 - 108
- 138 - 103 - 31 - 220 <-- 16eme valeur ajoutée
Problème secondaire : PAN ID et Extended PAN ID non synchronisés.
Solution : Ajout dans advanced:advanced:
pan_id: 0xb232
ext_pan_id:
- 0x15 - 0xc9 - 0xfa - 0x64
- 0xe5 - 0x4a - 0x06 - 0x2a- PROBLÈME 2 : DÉCONNEXIONS WIFI SUR RÉSEAU MESH FREEBOX
Symptôme : Le Denky D4 se déconnecte périodiquement quand il est physiquement proche
de la Freebox Ultra, mais reste stable sur le répéteur WiFi.Timeline (monitoring ping toutes les 2 secondes) :
Départ : Connecté répéteur -64 dBm (BSSID repeteur)
Switch Freebox : Reconnexion repeteur -78 dBm (BSSID repeteur)
+47 minutes : Déconnexion complete signal trop faibleCause racine : L'ESP32 ne fait PAS de roaming actif entre les BSSID d'un réseau mesh.
Il reste accroché au BSSID du répéteur même avec un signal très faible (-82 dBm).
La connexion finit par lâcher sans parvenir à rescanner un meilleur AP.Topologie identifiée :
Freebox Ultra (gateway 192.168.1.254)
MAC WAN : 38:07:XX:XX:4D:A7
WiFi 2.4GHz BSSID : 3A:07:XX:XXB2:90
WiFi 5GHz BSSID : 3A:07:XX:XX:B2:94
SSID : "WiFi-du-voisin"Repeteur Freebox (192.168.1.2)
MAC : 38:07:XX:XX:B1:16
WiFi BSSID : 3A:XX:XX:68:8D:A0
SSID : "WiFi-du-voisin" (mesh)Solution - Forcer un rescan WiFi avec sélection du meilleur AP :
1. Mode scan complet au démarrage
curl http://192.168.1.52/cm?cmnd=WifiConfig 5
2. Réduire la puissance pour éviter le repeteur lointain
curl http://192.168.1.52/cm?cmnd=WifiPower 2
3. Redémarrer (le scan choisira le meilleur BSSID)
curl http://192.168.1.52/cm?cmnd=Restart 1
4. Revenir en mode normal
curl http://192.168.1.52/cm?cmnd=WifiConfig 4
curl http://192.168.1.52/cm?cmnd=WifiPower 10Note : La commande BSSId n'est PAS supportée dans Tasmota 15.2.0.
On ne peut pas forcer un BSSID spécifique. La solution passe par
la manipulation de WifiPower + WifiConfig pour forcer un rescan.État final stable :
BSSID : 3A:07:XX:XX:B2:90 (Freebox Ultra)
Signal : -29 dBm
RSSI : 100%
WifiPower : 10 dBm- PROBLÈME 3 : CRASH ANTÉRIEUR (IllegalInstruction)
Symptôme : Tasmota status12 montre un crash dans le call stack.
{
"StatusSTK": {
"Exception": 0,
"Reason": "IllegalInstruction",
"EPC": "4000d00f",
"CallChain": [
"4000d00c", "40155491", "4014ded2", "40150491",
"40129cb2", "400e5fc2", "4011ccca", "400debf0",
"400d9cb4", "4015929b"
]
}
}Température ESP32 mesurée : 58 a 62°C.
Cause exacte non déterminée (conflit serie teleinfo ? surchauffe ?).Recommandation : Surveiller StatusSNS.ESP32.Temperature.
Si > 70°C, ajouter un dissipateur thermique.- CONFIGURATION FINALE
WifiConfig: 4 (Retry mode avec scan initial)
WifiPower: 10 dBm
SSID1: WiFi-du-voisin
BSSID: 3A:07:XX:XX:B2:90 (Freebox Ultra)
Signal: -29 dBm (RSSI 100%)
IP: 192.168.1.52 (bail statique Freebox)
Gateway: 192.168.1.254
DNS: 192.168.1.253 (AdGuard)
MQTT: 192.168.1.111:1883- OUTILS DE MONITORING
- Script ping permanent (toutes les 2 secondes)
- Détection de changements d'état ARP (REACHABLE/PROBE/FAILED)
- Collecte automatique des logs Tasmota à chaque (re)connexion
- 25 fichiers de télémétrie sauvegardés (status0 a status13, WiFi, MQTT, etc.)
- Fichier d'événements avec timestamps pour chaque transition UP/DOWN
- COMMANDES UTILES TASMOTA
http://192.168.1.52/cm?cmnd=status 0 -> Status complet
http://192.168.1.52/cm?cmnd=status 5 -> Status réseau
http://192.168.1.52/cm?cmnd=status 11 -> Status instantané (WiFi + énergie)
http://192.168.1.52/cm?cmnd=WifiPower -> Puissance WiFi
http://192.168.1.52/cm?cmnd=WifiConfig -> Mode WiFi
http://192.168.1.52/cm?cmnd=Restart 1 -> Redémarrer================================
Document généré le 12 juin 2026 -
@Nicolas-Bernaerts je pense avoir trouvé une solution paliative (une rustine plutot).
En plus de la désactivation de l'AX sur le 2.4Ghz, j'ai effectué quelques modifications. Voici le rapport généré par Hermes :
DENKY D4 - RAPPORT TECHNIQUE
Date : 12 juin 2026
Firmware : Tasmota 15.2.0 (teleinfo-denkyd4)
Matériel : ESP32-PICO-V3-02 v3.0 @ 240 MHz
- IDENTIFICATION
Appareil : Denky D4 (compteur téléinformation)
MAC : 4C:75:XX:XX:BC:B0
IP : 192.168.1.52
Hostname : denky-7344
Module : ID 0 (Denky D4)
MQTT : Connecté à HA 192.168.1.111:1883, topic "denky", client "denkyd4"
OTA URL : NicolasBernaerts/tasmota/.../tasmota32-teleinfo-denkyd4.bin- PROBLÈME 1 : CORRUPTION DE LA CLÉ RÉSEAU ZIGBEE
Symptôme : Après reboot de la VM HAOS, Zigbee2MQTT (v2.12.0) crash au démarrage.
Message : "Network key must be a 16 digits long array, got 15 values"Cause : Le fichier zigbee2mqtt/configuration.yaml avait une network_key incomplète
(15 valeurs au lieu de 16). La version 2.12.0 a ajouté une validation stricte absente
des versions précédentes.Solution : Récupération de la clé complète depuis coordinator_backup.json.
Clé hexadécimale : 96af96ec5916xxxxxxx4d36c8a671fdc
network_key:
- 150 - 175 - 150 - 236
- 89 - 22 - 32 - 198
- 2 - 228 - 211 - 108
- 138 - 103 - 31 - 220 <-- 16eme valeur ajoutée
Problème secondaire : PAN ID et Extended PAN ID non synchronisés.
Solution : Ajout dans advanced:advanced:
pan_id: 0xb232
ext_pan_id:
- 0x15 - 0xc9 - 0xfa - 0x64
- 0xe5 - 0x4a - 0x06 - 0x2a- PROBLÈME 2 : DÉCONNEXIONS WIFI SUR RÉSEAU MESH FREEBOX
Symptôme : Le Denky D4 se déconnecte périodiquement quand il est physiquement proche
de la Freebox Ultra, mais reste stable sur le répéteur WiFi.Timeline (monitoring ping toutes les 2 secondes) :
Départ : Connecté répéteur -64 dBm (BSSID repeteur)
Switch Freebox : Reconnexion repeteur -78 dBm (BSSID repeteur)
+47 minutes : Déconnexion complete signal trop faibleCause racine : L'ESP32 ne fait PAS de roaming actif entre les BSSID d'un réseau mesh.
Il reste accroché au BSSID du répéteur même avec un signal très faible (-82 dBm).
La connexion finit par lâcher sans parvenir à rescanner un meilleur AP.Topologie identifiée :
Freebox Ultra (gateway 192.168.1.254)
MAC WAN : 38:07:XX:XX:4D:A7
WiFi 2.4GHz BSSID : 3A:07:XX:XXB2:90
WiFi 5GHz BSSID : 3A:07:XX:XX:B2:94
SSID : "WiFi-du-voisin"Repeteur Freebox (192.168.1.2)
MAC : 38:07:XX:XX:B1:16
WiFi BSSID : 3A:XX:XX:68:8D:A0
SSID : "WiFi-du-voisin" (mesh)Solution - Forcer un rescan WiFi avec sélection du meilleur AP :
1. Mode scan complet au démarrage
curl http://192.168.1.52/cm?cmnd=WifiConfig 5
2. Réduire la puissance pour éviter le repeteur lointain
curl http://192.168.1.52/cm?cmnd=WifiPower 2
3. Redémarrer (le scan choisira le meilleur BSSID)
curl http://192.168.1.52/cm?cmnd=Restart 1
4. Revenir en mode normal
curl http://192.168.1.52/cm?cmnd=WifiConfig 4
curl http://192.168.1.52/cm?cmnd=WifiPower 10Note : La commande BSSId n'est PAS supportée dans Tasmota 15.2.0.
On ne peut pas forcer un BSSID spécifique. La solution passe par
la manipulation de WifiPower + WifiConfig pour forcer un rescan.État final stable :
BSSID : 3A:07:XX:XX:B2:90 (Freebox Ultra)
Signal : -29 dBm
RSSI : 100%
WifiPower : 10 dBm- PROBLÈME 3 : CRASH ANTÉRIEUR (IllegalInstruction)
Symptôme : Tasmota status12 montre un crash dans le call stack.
{
"StatusSTK": {
"Exception": 0,
"Reason": "IllegalInstruction",
"EPC": "4000d00f",
"CallChain": [
"4000d00c", "40155491", "4014ded2", "40150491",
"40129cb2", "400e5fc2", "4011ccca", "400debf0",
"400d9cb4", "4015929b"
]
}
}Température ESP32 mesurée : 58 a 62°C.
Cause exacte non déterminée (conflit serie teleinfo ? surchauffe ?).Recommandation : Surveiller StatusSNS.ESP32.Temperature.
Si > 70°C, ajouter un dissipateur thermique.- CONFIGURATION FINALE
WifiConfig: 4 (Retry mode avec scan initial)
WifiPower: 10 dBm
SSID1: WiFi-du-voisin
BSSID: 3A:07:XX:XX:B2:90 (Freebox Ultra)
Signal: -29 dBm (RSSI 100%)
IP: 192.168.1.52 (bail statique Freebox)
Gateway: 192.168.1.254
DNS: 192.168.1.253 (AdGuard)
MQTT: 192.168.1.111:1883- OUTILS DE MONITORING
- Script ping permanent (toutes les 2 secondes)
- Détection de changements d'état ARP (REACHABLE/PROBE/FAILED)
- Collecte automatique des logs Tasmota à chaque (re)connexion
- 25 fichiers de télémétrie sauvegardés (status0 a status13, WiFi, MQTT, etc.)
- Fichier d'événements avec timestamps pour chaque transition UP/DOWN
- COMMANDES UTILES TASMOTA
http://192.168.1.52/cm?cmnd=status 0 -> Status complet
http://192.168.1.52/cm?cmnd=status 5 -> Status réseau
http://192.168.1.52/cm?cmnd=status 11 -> Status instantané (WiFi + énergie)
http://192.168.1.52/cm?cmnd=WifiPower -> Puissance WiFi
http://192.168.1.52/cm?cmnd=WifiConfig -> Mode WiFi
http://192.168.1.52/cm?cmnd=Restart 1 -> Redémarrer================================
Document généré le 12 juin 2026@Arnaud-R
Concernant le wifi. ,j'utilise également un réseau mesh Linksys Vélo, avec 3 répéteur. Il est à noter que j'ai désactivé le wifi de ma box pour éviter tout conflit. Avec les 2 options cochées mes esp32 sont très stables, quelque soit la borne utilisée.Concernant le plantage, le plupart du temps cela provient de l'alimentation. Trop de chargeur USB sont de très très mauvaise qualité. Essayez de changer pour une alimentation USB de qualité.
-
@Arnaud-R
Concernant le wifi. ,j'utilise également un réseau mesh Linksys Vélo, avec 3 répéteur. Il est à noter que j'ai désactivé le wifi de ma box pour éviter tout conflit. Avec les 2 options cochées mes esp32 sont très stables, quelque soit la borne utilisée.Concernant le plantage, le plupart du temps cela provient de l'alimentation. Trop de chargeur USB sont de très très mauvaise qualité. Essayez de changer pour une alimentation USB de qualité.
@Nicolas-Bernaerts Merci pour cette réponse éclairée.
Mais afin de limiter les variables je fais les tests avec la même configuration physique, càd le même chargeur (Samsung 1A) et les mêmes cables. Et je n'avais pas de problème avant le changement de box (les anciennes étaient une Freebox Pop ou Livebox S) ou de la dernière MàJ.
Quant à désactiver le wifi de ma box, cela serait pénalisant car je suis dans une implantation des 2 AP couvrant l'intégralité de mon domicile.
Quant au screen suivant, il m'étonne car je suis configurer en 100W. Mais avant je vais deconnecter le TIC pour voir si j'ai toujours des resets.
Essai sans branchement à la TIC. Etonnant car je l'ai déjà repassé en factory suite aux premiers crashs :
-
@Nicolas-Bernaerts Merci pour cette réponse éclairée.
Mais afin de limiter les variables je fais les tests avec la même configuration physique, càd le même chargeur (Samsung 1A) et les mêmes cables. Et je n'avais pas de problème avant le changement de box (les anciennes étaient une Freebox Pop ou Livebox S) ou de la dernière MàJ.
Quant à désactiver le wifi de ma box, cela serait pénalisant car je suis dans une implantation des 2 AP couvrant l'intégralité de mon domicile.Quant au screen suivant, il m'étonne car je suis configurer en 100W. Mais avant je vais deconnecter le TIC pour voir si j'ai toujours des resets.
Essai sans branchement à la TIC. Etonnant car je l'ai déjà repassé en factory suite aux premiers crashs :
Mais quand je veux flasher en factory il me dit ça :
-
@Arnaud-R
Avez vous fait un répartitionement total de l'esp au moment de la bascule du Tasmota teleinfo classique vers mon fork ?
Les plantages sont quasi systématiquement liés à un pb de partitionnement. J'ai des versions esp32 qui tournent depuis plus de 8 mois en mode standard sans aucune fuite mémoire. C'est pour cela que je doute de l'analyse IA. -
@Arnaud-R
Avez vous fait un répartitionement total de l'esp au moment de la bascule du Tasmota teleinfo classique vers mon fork ?
Les plantages sont quasi systématiquement liés à un pb de partitionnement. J'ai des versions esp32 qui tournent depuis plus de 8 mois en mode standard sans aucune fuite mémoire. C'est pour cela que je doute de l'analyse IA.@Nicolas-Bernaerts Il fonctionnait a merveille depuis des mois. Les seules variables sont le passage à la Freebox ultra et la MàJ OTA.
Ca semble fonctionner avec quelques modifs. Il ne tient pas sur le BSSID de la Freebox, même en désactivant l'AX et le steering, verrouillant le canal, une BW à 20MHz. Donc j'ai passé le WifiConfig à 4 et le WifiPower à 16DBm pour qu'il garde le BSSID du répéteur qui est assez pres pour garder un RSSI à 40% environ. Surtout pas coché Scan wifi on reboot ni Scan every 44min pour ne pas qu'il raccroche la box.
Je reste étonné de l'erreur de flash en factory alors que le flash denky (normal) fonctionne. Je penserais à un pb de mémoire flash SPI défectueuse. Ce que j'ai formulé à Tindie, où j'ai acheté le Denky mais qui me renvoie vers cette communauté pour trouver une solution ...Il doit inéluctablement avoir un souci de communication xifi 2.4GHz avec la box qui n'existe pas sur le répéteur. Pour l'instant cette rustine tient.
En attendant je vais créer un nouveau topic pour d'autres questions
-
Mais quand je veux flasher en factory il me dit ça :
@arnaud-r oui le flasher en V4 j'ai parfois le même soucis, je ne sais pas trop pourquoi, quand j'ai ce soucis j'utilise le V3.3.1
http://github.com/Jason2866/ESP_Flasher/releases/tag/v3.3.1 qui marche à tous les coups -
Mais quand je veux flasher en factory il me dit ça :
@arnaud-r oui le flasher en V4 j'ai parfois le même soucis, je ne sais pas trop pourquoi, quand j'ai ce soucis j'utilise le V3.3.1
http://github.com/Jason2866/ESP_Flasher/releases/tag/v3.3.1 qui marche à tous les coups -
@Charles merci pour la réponse..
Et ça le RaZ comme un v4 factory le ferait ?
Car je pensais que lefirmware "nonrmal" donc pas factory le permettait aussi.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login