Et ça le RaZ comme un v4 factory le ferait ?

Car je pensais que lefirmware "nonrmal" donc pas factory le permettait aussi.

@Arnaud-R said:

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

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 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 :

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é.

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

1. 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

2. 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

3. 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 faible

Cause 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 10

Note : 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

4. 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.

5. 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

6. 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

7. 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

Oui les 2 cases sont cochées, c'est d'ailleurs grace à la seconde qu'il parvient à se reconnecter.

J'ai désactivé le wifi6 (AX) sur le 2.4Ghz, je suis passé en sleep 0, j'ai meme tenté le SetOption57 0 pour eviter la bascule mais même problème.

Mais c'est vraiment avec la Freebox que j'ai des problème, avec le répéteur 0 issue.

Vérifiez que vous ayez ces 2 options cochées (à minima la 1ère) et redémarrez.

Est-ce que la réception wifi est meilleure ?