Retour à RTM

Liste des changements RTM

Retrouvez les nouveautés de votre version de RTM. Ces notes restent consultables sans connexion à RTM Cloud.

4.6.0-0130

Le panneau Bases Radxa et passerelles remplace les commandes USB. Il déclare les bases et affiche les observations fraîches de la passerelle, de la source de corrections et du GNSS de référence, avec un motif explicite en cas d'indisponibilité.
Chaque base possède sa propre clé API, distincte des clés trackers. Elle est révélée une seule fois puis stockée sous forme d'empreinte, avec copie, masquage, renouvellement et révocation. L'affichage est lié au compte et à la visibilité de la fiche ; les lectures périodiques conservent les contrôles de saisie.
Les observations de base ont un schéma fermé et sont acquittées après commit DATA. Doublons et reprises ne rafraîchissent pas l'état ; la fraîcheur d'affichage vient de la réception serveur. RTM n'envoie aucun ordre radio, USB ou de provisionnement.
Le parcours T3-S3 propose une identité stable disponible et un nom lisible à vérifier sur le matériel. Le nom RTM, le nom OLED et l'identité restent distincts ; changer un nom ne change pas les clés.
La couverture utilise les vraies captures HTTP fraîches et durables du tracker choisi, avec son identité boot/séquence. Aucun uptime, RSSI, base_id de livraison ou point GNSS manquant n'est inventé. Le RSSI reste indisponible pour les nouveaux essais ; les anciens historiques restent lisibles.
Les anciens drivers, routes, commandes, widget et passerelle USB/IP sub-GHz sont retirés. Les déclarations anciennes identifiées sont désactivées et signalées comme retirées, sans effacer identités, mesures, archives privées ou empreintes de clés. Leur remplacement demande un profil pris en charge explicite.
Le registre des bases et ses reçus sont ajoutés aux sauvegardes DATA. La mise à jour préserve la configuration GNSS privée existante. Le paquet0130 exact doit être qualifié sur PC et sur le Pi principal par Hermès ; aucune promotion à Mirecourt n'est incluse.
Les sauvegardes0129 complètes restent reconnues et ne suppriment pas les bases déjà présentes ; une paire de tables de base incomplète est refusée. Un renommage conserve une désactivation concurrente. Le retrait des anciennes déclarations précède le démarrage des consommateurs et conserve leurs reçus en historique.
Les tests de qualification ont été alignés sur les métadonnées de transport et les captures T3-S3. Leurs contrôles de persistance et de collision sont conservés ; ces corrections de recette ne changent pas le comportement fonctionnel de cette édition.
Un fix ou un flux de corrections de la base ne prouve aucun fix rover, correction utile, portée ou EIRP. Sans GNSS rover connecté, aucune position réelle n'est attendue.

4.6.0-0129

Configuration des périphériques : un bouton permet de déclarer un tracker T3-S3 / SX1280 utilisant la passerelle HTTP externe. Sa fiche explique l'association de l'identifiant firmware à l'identifiant RTM, l'URL serveur et la clé API privée propre à chaque tracker.
La clé API peut être générée, copiée, masquée, renouvelée ou révoquée sans QR ni instructions Android. Elle reste affichée une seule fois pour le compte autorisé. Son renouvellement invalide l'ancienne clé et exige sa mise à jour dans la passerelle.
Le profil de connexion choisi est conservé séparément du transport observé dans les captures traitées. Les trackers T3-S3 ne sont plus dirigés vers les réglages HaLow ; le matériel non identifié conserve une fiche générique. Une différence entre profil et transport observé est signalée sans changer la configuration.
Modifier le nom, le véhicule ou la catégorie GNSS/transpondeur conserve le type physique du périphérique. Les colonnes de connexion sont ajoutées sans remplacer les données existantes ; le parcours Android et le menu USB / HaLow restent disponibles.
La configuration des périphériques attend les activations réelles du serveur avant ses lectures. Avec Track actif et Timing désactivé, l'entrée directe dans la page permet de configurer les trackers sans requête Timing fondée sur les valeurs initiales du navigateur.
L'identifiant technique du tracker accepte jusqu'à 64 caractères, comme la base DATA. La saisie et les validations serveur refusent proprement une valeur plus longue avant son écriture.
Ces changements ne pilotent pas le provisionnement radio, le port USB ou NTRIP de la passerelle et ne prouvent pas une liaison physique ou un fix RTK. Le candidat doit être qualifié sur PC puis sur le Pi principal par Hermès ; aucune promotion à Mirecourt n'est effectuée.

4.6.0-0128

BUG-000033 et BUG-000034 : les commandes « Tout le circuit » et par secteur conservent leurs boutons pendant les mises à jour live. Un clic reste utilisable lorsque les trackers émettent, sans perte du survol ou du focus au rythme des données reçues.
La palette garde ses boutons et le grand aperçu du drapeau dans la barre inférieure reste en place pendant les actualisations. La sélection du drapeau et de son texte est conservée ; les changements de secteurs, d'état des panneaux, de langue, d'activation du module et d'autorisation restent pris en compte.
Les commandes conservent leurs routes et contrôles de droits. Le simple appui de la souris et le survol ne provoquent aucun envoi supplémentaire ; les animations prévues des drapeaux clignotants restent disponibles.
Le nouvel artefact doit être qualifié sur PC puis sur le Pi par Hermès. La release et la sauvegarde précédentes sont conservées pour le retour arrière, sans écraser les écritures ultérieures. Aucune migration de données ni intervention à Mirecourt n'accompagne cette correction.

4.6.0-0127

Le rapport PDF du journal Piste conserve le titre complet de la session. Les noms longs passent à la ligne ; un titre exceptionnellement long dispose de pages d'identification au début du rapport. Seule sa partie dans le nom du fichier est limitée, avec l'identifiant de session conservé ; les noms de fichiers usuels ne changent pas.
Les messages de session, dont la validation manuelle, apparaissent intégralement dans la colonne Message au lieu d'être raccourcis sous Signal. Les messages enregistrés des autres événements restent également complets.
Les cellules et annotations passent à la ligne. Un même événement peut continuer sur plusieurs pages, avec une indication de suite, sans perdre ni répéter son texte et sans toucher le pied de page. Le nombre de lignes reste celui des événements enregistrés.
Le titre et le journal utilisent la police fournie avec RTM pour conserver les accents, ligatures et ponctuations françaises. Les caractères absents de cette police affichent leur code ; le texte original reste disponible aux lecteurs PDF compatibles pour l'extraction. La copie et la recherche dépendent du lecteur ; tous les alphabets et compositions typographiques ne sont pas garantis.
Les rapports déjà générés sont conservés. La correction ne modifie ni les journaux enregistrés, ni les droits, ni la validation des sessions ; les exports PDF Timing gardent leur générateur et leurs limites propres.
Ce nouveau paquet doit être qualifié sur PC et sur le Pi principal, avec contrôle visuel des PDF. Le retour arrière conserve les rapports et les écritures postérieures à la sauvegarde ; RTM Cloud garde sa livraison indépendante.

4.6.0-0126

La correction d'heure applique exactement la valeur confirmée, avec ses secondes et millisecondes. La confirmation distingue heure locale et UTC et indique « transpondeur inconnu » lorsque son identifiant est absent ; les identifiants présents restent affichés tels quels.
La publication vérifie les prérequis avant de modifier les résultats. Une publication refusée ne laisse pas de classement final partiel ; les pénalités ne sont comptées qu'une fois après publication et relecture.
Timing rend le roulage ciblé, ses états, ses prérequis et ses résultats plus visibles. Les commandes répétées sont regroupées ; les noms des pilotes et sessions remplacent les identifiants dans les résultats combinés.
Les imports Timing disposent d'un aperçu et d'un bilan. Les formats inconnus et erreurs de feuilles ou colonnes sont expliqués avant l'application ; le serveur conserve ses contrôles de droits et de références.
Les huit exemples du modèle Timing restent ignorés sans créer de données. Le bilan effectif présente les paramètres appliqués une seule fois ; les causes d'erreur répétées sont dédupliquées sans perdre leurs emplacements ni les autres erreurs.
Les imports du simulateur conservent les identifiants alphanumériques des transpondeurs. Leurs annexes de simulation sont vérifiées puis ignorées et signalées, sans créer de passages réels.
Une reprise de publication vérifie l'intégrité du classement enregistré. Les CSV ambigus sont refusés ; le bilan compte chaque ligne ignorée une seule fois et les historiques importés conservent leurs références aux groupes.
Les vues publiques, formulaires et dialogues améliorent contraste, libellés et navigation au clavier. Le véhicule engagé affiche son verrouillage ; les pages refusées permettent de revenir à l'espace autorisé.
Les alertes de chronométrage Speaker gardent un texte sombre lisible sur leur fond clair, avec les thèmes clairs comme sombres.
Tab et Maj+Tab restent dans les dialogues de confirmation, saisie et information. Les contrôles masqués ou désactivés sont exclus ; Échap annule et la fermeture rend le focus au déclencheur.
Les états publics usuels sont traduits. Les Meilleurs tours précisent que leurs temps ne comprennent pas les pénalités du classement. Les liens Public et Speaker expliquent un contexte Organisateur Piste incompatible sans le changer automatiquement.
Les PDF Timing corrigent les accents et les caractères Windows ANSI usuels, répartissent les classements sur plusieurs pages A4 et passent les noms longs à la ligne sans troncature. Les caractères hors Windows ANSI restent une limite du générateur.
Les exports de configuration et les étapes de restauration sont explicités. Un outil prépare une démo locale cohérente, sans panneau ni service Internet, dans un dossier neuf.
Le choix Piste affiche le nom et la durée retenus et précise son application immédiate. Le bouton Fermer conserve cette sélection sans démarrer la session.
Les retours Organisateur restent attachés à leur compte, événement et onglet, sans masquer les alertes de sécurité ou de reprise. Les passages publics remplacent les codes techniques connus par leurs libellés métier, avec le code disponible en détail.
Sur petit écran, les cartes, champs et commandes Timing restent dans la largeur de la page. Le tableau conserve un défilement interne ; le profil passe sous le titre et le sélecteur lorsque la place manque.
Une correction d'heure ou une publication confirmée reste annoncée comme appliquée si la relecture échoue. Actualiser les données relit sans renvoyer l'action ; les refus et réponses ambiguës restent non confirmés. Les retours tardifs d'un autre compte ou contexte sont écartés.
Une mise à jour de dernière activité bloquée par une contention SQLite ne fait plus échouer une session déjà vérifiée. L'expiration, la révocation, l'état actif et les droits restent contrôlés ; les autres erreurs de stockage restent visibles.
Une sauvegarde des données et de la configuration accompagne le retour arrière. Les preuves de qualification restent liées au paquet exact ; RTM Cloud conserve sa livraison indépendante.

4.6.0-0125

Interfaces et projection opérationnelle : le circuit enregistre les dossiers projetés par le Cloud dans une table locale consultable (identité, véhicule, offre, statut, documents), par mise à jour idempotente.
Les suppressions sont appliquées via des pierres tombales : la copie locale est retirée sans jamais toucher aux données de chronométrage ni à l'historique des pilotes.

4.6.0-0124

Synchronisation métier Cloud↔circuit (côté RTM) : le circuit reçoit la projection limitée du Cloud (journées autorisées, dossiers), l'applique sans jamais rejouer une opération déjà reçue, et publie ses retours (présence, résultats) à travers une file locale durable.
Le connecteur central n'autorise que les trois routes de synchronisation, avec le même jeton privé et le même transport borné que les autres services. Un type ou une version de schéma inconnu reste en attente, jamais appliqué à moitié.

4.6.0-0123

Confidentialité : un compte organisateur ne lit plus, dans l'historique d'un pilote, les tours des événements qui ne sont pas attachés à son organisation. La requête de l'historique est désormais bornée à ses propres événements.
La direction du circuit conserve l'historique complet de sa base locale ; le pilote conserve son historique personnel complet et ne peut pas lire celui d'un tiers.
Les autres lectures de temps (tours, classements, exports, passages, flux et audits) étaient déjà limitées à leur périmètre et restent inchangées.

4.6.0-0122

Le serveur RTM Cloud dispose de son propre projet de développement, avec ses consignes et sa documentation. Les services Cloud restent accessibles depuis RTM avec leurs droits et contrats existants.
Les sources et vérifications RTM sont autonomes. La vue Piste, les profils, les API et les fonctions d'exploitation sont conservés.
Les anciennes recettes qui démarraient un serveur Cloud sont conservées dans les archives du projet Cloud et retirées du paquet RTM.
Cette organisation des sources ne modifie aucune installation en service ; la qualification reste liée à chaque paquet exact.

4.6.0-0121

Après un enregistrement réussi dans Général, le test d'email de récupération redevient disponible lorsque la configuration et les droits permettent l'envoi. Un échec d'enregistrement ou une perte de droits maintient les protections nécessaires.
Cette version conserve les améliorations des menus, des miniatures, des fichiers, de la connexion et de la maintenance de 0120. Piste garde sa présentation et son fonctionnement.
Le résultat du test confirme l'acceptation par le serveur de messagerie ; vérifiez la réception dans la boîte du destinataire.

4.6.0-0120

Général réunit l'identité du circuit, les documents, l'email de récupération et Cloud et licence. Les formulaires sont regroupés, les menus placés à gauche des titres et la recherche mène aux sous-rubriques. Les modifications en attente sont signalées.
Créez une miniature depuis le profil de circuit, choisissez son fond et son format, puis utilisez-la dans Timing ou téléchargez-la en PNG. L'aperçu automatique suit le profil actif. Logos et images disposent de fonds adaptés à leur lisibilité.
La page intermédiaire Occupation de piste disparaît ; le comptage, les limites et les alertes restent disponibles. Les portails s'ouvrent directement depuis les Paramètres.
La connexion présente clairement le circuit et ses accès locaux. Le mot de passe peut être affiché, la récupération utilise un identifiant ou un email et le lien reçu ouvre directement le choix du nouveau mot de passe.
Maintenance et assistance rassemble l'état RTM, les diagnostics et les outils serveur configurés. Cockpit garde sa connexion système distincte. La santé DATA tient compte de la base réellement configurée ; un service réseau non utilisé n'est plus assimilé à une panne. Un accès impossible aux fichiers Kea est signalé sans interrompre la page.
Les dialogues et textes des parcours concernés sont harmonisés. Piste conserve sa présentation et son fonctionnement. Le test d'email confirme l'acceptation par le serveur de messagerie ; vérifiez sa réception dans la boîte du destinataire.

4.6.0-0119

Les paramètres se chargent sans erreur lorsque la connexion est confirmée avant le premier statut RTM. Le panneau Modules attend les données disponibles ; les brouillons restent protégés lors d'une actualisation du même compte et sont effacés lors d'un changement de compte ou de droits.
Cette correction conserve les menus d'exploitation, le gestionnaire de fichiers, les thèmes et le test d'email de 0118. La vue Piste conserve sa présentation et son fonctionnement.

4.6.0-0118

Les paramètres sont organisés par installation, exploitation, équipements, interfaces et maintenance. Général distingue l'identité, les documents et la messagerie. Les modules disposent de leur propre page et de leur propre enregistrement ; la rubrique « à coder » disparaît de l'interface d'exploitation.
Le test d'email utilise la configuration SMTP enregistrée et un destinataire explicite. Le résultat est daté et distingue l'acceptation par le serveur de la réception en boîte. Les modifications non enregistrées bloquent le test ; les droits et une limite de fréquence encadrent l'envoi.
Le gestionnaire de fichiers et les sélecteurs proposent un fil d'Ariane, une recherche dans le dossier courant, un tri et des métadonnées. Les actions conservent leurs droits et les formats attendus. La suppression reste définitive avec confirmation.
Les fenêtres, panneaux et champs suivent les palettes choisies. Les thèmes principaux sont mis en avant ; les autres thèmes et la personnalisation restent disponibles. Un contrôle du contraste des textes précède l'enregistrement d'un thème personnalisé.
Les autres menus et les aides utilisent des formulations orientées exploitation et maintenance. La vue Piste conserve sa présentation et son fonctionnement. Les cartes, profils, données métier et restrictions d'accès sont préservés.

4.6.0-0116

Une mise à jour live pouvait remplacer un contrôle Track pendant l'appui et perdre le clic sur une case, un nom, Fiche ou une pastille. Le candidat 0115 est rejeté pour cette régression ; 0116 conserve les contrôles pendant leur interaction native au pointeur, au clavier, dans un sélecteur ou pendant une composition de texte.
Les données continuent d'être fusionnées pendant l'interaction. Le rendu reprend après activation ou fin de l'interaction, sans clic artificiel. Changement de compte, retrait de droits et désactivation du module restent prioritaires. Les gestes caméra, le focus et les choix d'affichage conservent leur comportement.
La consultation héritée conserve liste cochable, carte centrale et fiche repliable, affichage indépendant de la consultation, groupes Timing par identifiants via la vraie API autorisée, fraîcheur GNSS UI de cinq secondes, caméra et suivi explicite. Groupes sélectionnés et contexte indisponible donnent zéro résultat avec choix conservés ; seul un nouvel événement disponible les réinitialise. Les fonds et leurs droits, l'historique à la demande et la configuration autorisée sont conservés.
Le rapport associé à l'artefact exact porte la qualification ; ces notes ne sont pas un rapport de recette et les résultats de 0115 ne qualifient pas 0116. Aucun débit de 800 captures/s, délai inférieur à deux secondes ou stockage trois jours n'est qualifié par ce correctif. Python reste en 3.12 et Tracker Android en 0.5.0 ; aucune commande matérielle automatique ni nouveau firmware radio.

4.6.0-0115

Track propose une liste cochable, une carte centrale et une fiche compacte repliable. Afficher un tracker et consulter sa fiche sont deux choix indépendants ; une recherche sans résultat ne ramène plus toute la liste. Les filtres Auto/Moto répétés sont remplacés par groupes Timing, GPS, mouvement et recherche.
Les groupes proviennent uniquement de la session Timing liée à la session Track active, sous les droits Track et Timing. Les identifiants tracker/groupe font foi, sans rapprochement par nom. Sans groupe reste distinct d'un contexte indisponible : les groupes sélectionnés et leurs pastilles restent conservés, avec zéro résultat explicite jusqu'au retour d'un contexte valide. Aucun élargissement silencieux ; seul un nouvel événement disponible réinitialise ces choix.
La lecture INTERNAL de session encadre un snapshot DATA unique pour contexte, groupes et affectations. Un changement visible refuse le contexte ; ce contrôle ne constitue pas une transaction distribuée entre les deux bases.
La fiche expose vitesse, cap, précision, batterie et âge GNSS ; les valeurs anciennes ne sont pas présentées comme une vitesse actuelle. La règle d'affichage récent est de cinq secondes. En mouvement exige un tracker en ligne, une position récente et une vitesse supérieure à 1 km/h, sans changement du délai de contact serveur ou des critères d'incident.
Zoom, déplacement, cadrage et suivi explicite conservent les fonds existants et leurs droits. Le suivi se met en pause après un geste manuel et signale l'attente d'un point frais ; les marqueurs proches restent consultables. Focus, saisie et choix d'affichage survivent aux mises à jour. Historique et configuration autorisée restent dans les détails secondaires.
La qualification est portée par le rapport associé à l'artefact exact ; ces notes ne constituent pas un rapport de recette. Aucun résultat d'une version antérieure ne qualifie ce build. Aucun débit de 800 captures/s, délai inférieur à deux secondes ou stockage trois jours n'est qualifié par cette évolution d'interface. Python reste en 3.12 et Tracker Android en 0.5.0 ; aucune commande matérielle automatique ni nouveau firmware radio.

4.6.0-0114

Piste charge et dessine les objets du profil actif associé à son fond géographique : surface de piste, stands, paddock, limites, accès, secteurs et lignes de chronométrage. Le chargement ne dépend plus des contrôles de l'atelier.
Track affiche également les surfaces, contours et accès auparavant exclus de son rendu, y compris les repères Point. Les trous restent transparents et les trois zones gardent leurs couleurs fixes.
OpenStreetMap et Plan RTM utilisent les mêmes coordonnées opérationnelles. Les objets restent superposés au fond après zoom et déplacement ; l'absence de lien secteur/feu ne masque pas le circuit.
La consultation conserve les géométries, identités et l'état actif. La vue GPS indépendante de Track ne reçoit pas les objets du circuit. Aucune modification ou commande de récepteur GNSS, tracker, base radio ou feu.
Les vérifications ciblées et navigateur utilisent des réponses isolées. La recette visuelle du profil réel sur le Pi doit identifier ce nouvel artefact ; une simulation ne qualifie ni l'implantation réelle ni les performances du flux trackers.

4.6.0-0113

Les ouvertures de la base interne évitent la création répétée des répertoires usuels. Configuration et chemin restent lus à chaque ouverture ; un nouveau parent est préparé avant connexion et les erreurs d'accès restent visibles.
Le préchargement PostgreSQL natif réunit les préfixes directs et historiques en une commande paramétrée. Capacités, ordre capture puis identifiant, référence UTC et identifiants BIGINT restent conservés ; les autres connexions gardent leur voie compatible sans replay après erreur SQL.
Quantum de seize candidats, budget souple de cent millisecondes, quotas, fraîcheur, critères d'incident, accusés après commit et archivage restent conservés. Les alertes proposent un drapeau à demander puis confirmer.
Les contrôles PC ciblés préparatoires de 0113 ont réussi : 15 tests des chemins internes, 107 tests d'analyse dont 10 nouveaux contrôles des préfixes, et 9 contrôles de l'outil de qualification. Sources inchangées pendant chaque suite et gardes à zéro ; l'adaptateur SQLite des préfixes ne constitue pas une preuve PostgreSQL native. L'outil de recette exige le build 0113 et son manifeste vérifié.
Les suites complètes PC et Pi de 0112 ont réussi avec 1 743 tests chacune. Sa charge conserve les 48 000 captures uniques mais échoue, avec 9/40 incidents cibles et un retard d'analyse important. Ces résultats ne qualifient pas le nouveau paquet 0113, qui exige ses propres contrôles et mesures.
La conservation de trois jours garde les traitements et incidents ouverts. Python reste en 3.12, Tracker Android en 0.5.0 et le firmware radio 2,4 GHz reste à développer. Le débit de 800 captures/s, la détection en moins de deux secondes et la capacité réelle de trois jours restent à démontrer.

4.6.0-0112

La vérification réussie d'une clé tracker inchangée est mémorisée sans expiration, avec 1 024 succès au plus et 64 verrous fixes. Seules deux empreintes sont retenues ; Track, la ligne DATA, le statut, le hash et la révocation restent vérifiés à chaque requête, puis la preuve au commit. Aucun droit ou secret n'est mis en cache.
La recherche des reçus existants et l'insertion PostgreSQL utilisent deux puis onze tableaux paramétrés avec psycopg. L'ordre des premières admissions est explicite, les IDs des captures égales restent cohérents et les doublons gardent le même reçu et le premier brut.
Le lookup d'ACK ne recharge plus les grands résultats dérivés inutiles. L'analyse, l'archive et l'audit gardent leurs lectures ; anciens ACK, réponses compactes, session, contexte et commit restent conservés.
Les tableaux builtin adaptés utilisent le codec binaire psycopg. Paramètres scalaires, valeurs personnalisées et autres connexions gardent leur voie compatible choisie avant SQL. Une erreur du pilote annule la transaction sans seconde exécution ; les identifiants BIGINT restent exacts.
Le comptage des effets évite le parcours d'une fenêtre GPS connue uniquement lorsqu'une majoration prouve le même maximum. Capacité réelle, aliases, formes legacy, cycles et fallback complet sont conservés ; la borne de 16 Mio, les checkpoints, GPS/ACC et rollback ne changent pas.
Les 71 tests PC ciblés préparatoires ont réussi avec source inchangée et gardes à zéro. Six petites fixtures TEMP PostgreSQL ont aussi réussi avec fermeture réelle et données permanentes inchangées ; elles combinent fonctions SOURCE17 et propriétaire Frozen16, sans qualifier un paquet complet ni une charge.
La charge SOURCE16 a échoué avec 0/40 couples tracker/incident attendus, capture→ACK P50 de 67,975 s et P99 de 119,614 s. FULLPC et charge 0112 demandent leurs rapports du nouveau gel. Le Pi est inaccessible ; un ZIP PC préparatoire ne vaut ni qualification de production ni promotion. Aucun débit de 800/s, délai inférieur à deux secondes ou stockage trois jours n'est acquis.
Quotas et seuils, rétention avec holds et demande puis approbation humaines des propositions restent conservés. Aucune nouvelle migration ou commande matérielle automatique. Python reste en 3.12, Tracker Android en 0.5.0 et le firmware radio 2,4 GHz reste à développer.

4.6.0-0111

Les identifiants et références durables Track/GNSS utilisent BIGINT sur PostgreSQL. La conservation de trois jours ne remet pas les séquences à zéro ; la limite des anciens entiers 32 bits pouvait être atteinte en environ 31 jours à 800 captures/s.
Les séquences existantes sont élargies sans redémarrage ni changement de position, propriétaire, incrément, cache, cycle ou bornes personnalisées. Les contraintes et anciennes références NOT VALID restent conservées ; les autres colonnes entières ne sont pas élargies.
Initialisation, schéma du flux, copie autorisée et restaurations DATA/GNSS appliquent le même contrat. Une cible de copie déjà remplie sans remplacement est refusée avant ce nouvel élargissement. SQLite conserve INTEGER PRIMARY KEY et l'autoincrément.
La migration conserve la transaction propriétaire et les limites plus strictes ; son helper borne locks à une seconde et statements à 60 secondes. Une grande table peut être réécrite ou provoquer un timeout : sauvegarde, arrêt coordonné et recette restent nécessaires, sans promesse de démarrage instantané.
Le watchdog ne transfère plus un état inutilisé et évite la lecture du contexte avant une demi-seconde d'absence. À cette frontière, le seuil courant et les preuves de silence restent contrôlés.
Les notifications réussies sont marquées ensemble avec psycopg, par tableaux d'identifiants exacts et d'heures UTC individuelles. Les refus gardent leurs retries, les erreurs SQL annulent le lot et les autres connexions gardent leur voie compatible. Livraison au moins une fois, identifiants stables et borne de 512 restent conservés.
Les 19 tests PC ciblés et huit petites fixtures natives BigInt ont réussi. Ils ne remplacent pas FULLPC, FULLPi ni la charge SOURCE16, encore non exécutées. Les charges V6 de 0110 ont échoué avec 10/40 puis 14/40 incidents attendus dans l'essai profilé, malgré les 48 001 bruts intacts et la bijection entre archives retenues et positions GNSS. Aucun débit 800/s ou délai inférieur à deux secondes n'est qualifié.
La conservation de trois jours garde ses holds pour travaux et incidents ouverts. Les propositions jaunes exigent demande puis approbation explicites, sans commande matérielle automatique. Python reste en 3.12, Tracker Android en 0.5.0 et le firmware radio 2,4 GHz reste à développer.

4.6.0-0110

La file PostgreSQL accepte jusqu'à 4 096 admissions en attente ou actives, sous un budget comptabilisé de 64 Mio. Cela limite les refus lors de rafales simultanées ; le budget ne représente pas toute la mémoire du processus et ne prouve pas un débit soutenu.
Les lots restent bornés et chaque accusé individuel attend son commit. Les captures, leurs identités, sessions et contextes sont conservés ; une file pleine renvoie un refus sans effacer les mesures de l'émetteur.
Après 128 notifications diffusées avec succès, le relais rend la main sans ajouter sa pause de 100 ms. Chaque lot reprend le contrôle de maintenance ; les lots partiels et erreurs conservent leur attente.
Une annulation attend la fin réelle du thread déjà lancé avant de libérer la garde de restauration, même si l'annulation se répète. Elle ne relance pas l'opération et ne rend pas remplaçables des ressources encore utilisées.
Les quatre incidents et leurs confirmations restent conservés. La conservation de trois jours garde ses exceptions ; une proposition de drapeau exige toujours une demande et une approbation autorisées, sans commande matérielle automatique.
Python reste en 3.12 et Tracker Android en 0.5.0. Le firmware radio 2,4 GHz reste à développer.
Les 1 677 tests PC complets réussis appartiennent à 0109, dont la charge PC V5 a échoué avec 15 couples tracker/incident attendus sur 40 et dont la suite Pi n'a pas été exécutée après une erreur de préparation. Les 53 tests PC ciblés de ce lot ne qualifient pas le nouveau paquet 0110 : débit de 800 captures/s, délais inférieurs à deux secondes et capacité sur trois jours restent à mesurer.

4.6.0-0109

Le comptage de la mémoire des contextes et des effets d'analyse parcourt les objets de façon itérative. Il conserve le même calcul des octets retenus et compte une seule fois les objets partagés.
L'analyse copie directement les formes d'état qu'elle connaît, avec leurs fenêtres GPS et leurs preuves d'incident. Une forme inhabituelle ou des objets mutables partagés déclenchent une copie générale de l'état entier pour préserver leurs liens et les preuves.
Les cinq écritures groupées de l'analyse PostgreSQL transmettent un tableau par colonne au pilote psycopg. Les valeurs nulles restent prises en charge, les colonnes de mesure normalisent les entiers en nombres à virgule et les identifiants BIGINT restent exacts. Les autres connexions et valeurs inhabituelles conservent le chemin compatible.
Ces changements conservent les captures brutes, les accusés après commit, l'ordre des traitements, les états direct et historique, les confirmations d'incident et la diffusion après commit. La conservation de trois jours garde ses exceptions pour les traitements et incidents ouverts ; un drapeau proposé exige toujours la confirmation de l'opérateur.
Aucune nouvelle migration ni dépendance n'est ajoutée. Python reste en 3.12 et Tracker Android en 0.5.0.
Les suites de 0108 ont réussi sur PC et Pi, mais sa charge PC de quarante trackers à vingt captures par seconde a échoué. Les essais SQL isolés préparatoires ne prouvent pas le débit du flux. Le nouvel artefact 0109 exige sa propre qualification ; le délai inférieur à deux secondes et la capacité de stockage sur trois jours restent à mesurer.

4.6.0-0108

La sélection d'un petit lot historique pouvait parcourir et trier tout le journal en attente. Un index partiel ordonné par capture et identifiant couvre les champs nécessaires et conserve les données existantes.
L'analyse PostgreSQL borne désormais sa sélection à seize candidats avant les requêtes. Les autres captures restent durables, avec le même partage direct/historique, les mêmes retries, la même fraîcheur et les mêmes commits.
SQLite conserve la taille de lot demandée et reçoit un index couvrant équivalent. Les contrôles vérifient les voies déséquilibrées, l'ordre des effets, les prédécesseurs en retry et les initialisations répétées.
La création de l'index intervient lors de l'initialisation du schéma et peut allonger la mise à jour d'un journal volumineux. Sauvegarde et arrêt coordonné restent nécessaires.
Les gains d'une requête ne qualifient pas le débit global. Ce paquet exige sa propre recette PC et Pi, des mesures pour quarante trackers à vingt captures par seconde et des délais d'incident inférieurs à deux secondes. Python reste en 3.12 et le firmware radio 2,4 GHz reste à développer.

4.6.0-0107

La refonte trackers conserve son journal durable commun USB/Android, ses deux processus Python 3.12, ses quatre incidents prioritaires, ses propositions de drapeau à confirmer et sa conservation serveur de trois jours. Tracker Android reste en version 0.5.0.
Le catalogue complet des drapeaux pouvait dépasser la taille acceptée du statut initial et fermer la connexion de supervision. Le direct utilise une projection bornée ; le catalogue complet se charge séparément en arrière-plan, sans retarder les alertes.
L'édition conserve toutes les définitions, y compris les drapeaux masqués et personnalisés. Le catalogue se renouvelle après une modification, un import ou une restauration. Les transferts inchangés utilisent un ETag.
Le cache du navigateur appartient au compte courant et à la révision reçue. Déconnexion et perte du droit de lecture retirent le catalogue ; une réponse tardive d'un autre compte ou d'une ancienne révision est écartée. Une erreur de chargement reste visible.
Le statut reste borné lorsque de nombreux drapeaux sont visibles ou qu'une image personnalisée est volumineuse. Les commandes de panneau et les programmes VSN conservent leur fonctionnement.
La vue Tracker ne réaffiche plus une ancienne précision GPS lorsqu'une capture plus récente la déclare absente dans l'ancien format de statut. Le format courant conserve la précision du fix analysé ; une mesure d'accéléromètre ne la remplace pas. Les contrôles d'interface vérifient les valeurs absentes, les zéros et les palettes avec les helpers et identités de capture courants.
Ce nouvel artefact exige sa propre recette PC et Pi. Le délai de deux secondes pour 40 trackers à 20 Hz, le stockage sur trois jours et les transmissions matérielles restent soumis à mesure. Le firmware radio 2,4 GHz n'est pas livré.

4.6.0-0106

Conservation commune de trois jours pour le brut, les positions et les incidents clôturés. La maintenance conserve les traitements inachevés, incidents ouverts et demandes de drapeau en attente ; les quotas ne raccourcissent plus les preuves.
L'état du flux présente la politique actuelle et le dernier bilan de conservation. Une erreur conserve les suppressions confirmées et signale les compteurs incomplets. Les sauvegardes qui référencent un contexte absent sont refusées avant restauration.
Les quatre incidents prioritaires proposent un drapeau jaune à examiner, puis à demander et approuver. Ces actions vérifient que le même épisode GNSS est encore actuel. La détection ne commande aucun panneau.
Les copies d'un broadcast reçues par plusieurs bases retrouvent le même reçu. Une identité réutilisée avec un contenu de capture différent est refusée avec 409 et préserve le premier brut.
Le firmware radio 2,4 GHz est à développer. Le parcours attendu distingue capture et réception, avec identité de démarrage, séquence, heure du fix et précision. Le format radio, son adaptateur et la transmission réelle restent à qualifier ensemble.
Le journal dérivé référence les réglages partagés ; les alarmes conservent leurs preuves complètes. L'analyse préverrouille au plus seize candidats, et l'entrée utilise aussi les paramètres natifs psycopg. Les gains de débit doivent être mesurés sur ce paquet.
Le traitement réduit les décodages et copies temporaires répétés des points. La vérification du module demandé évite de reconstruire tous les modules à chaque réception, avec les mêmes contrôles de licence à chaque appel.
USB et Android enregistrent leurs points dans un journal durable commun avant accusé de réception. Deux processus Python 3.12 distincts analysent et archivent, avec reprise après arrêt et identifiants stables.
PostgreSQL regroupe les réceptions dans un writer borné ; chaque accusé attend son commit, avec session et contexte capturés avant l'attente. Le drain USB règle chaque reçu séparément et conserve les enveloppes non confirmées, sans acquittement par son cache mémoire.
Les traitements utilisent le même ordre de verrous et réévaluent désactivations, révocations et rotations de clés avant leurs effets. Une restauration est refusée tant que le writer ou le drain USB reste actif. Le provider DATA est conservé pendant chaque transaction.
L'analyse PostgreSQL groupe les échanges SQL en conservant l'état de chaque point pour le suivant et les preuves de dépassement des autres trackers. Les historiques dépassant le préchargement borné gardent leur contrôle SQL. Le watchdog groupe ses lectures sans modifier la preuve du silence.
L'archive PostGIS valide ses points par lot, avec un réglage commun visible jusqu'au lot suivant et reconnaissance des doublons avant les filtres. Un point défectueux ne fait pas acquitter les insertions annulées ; les décisions terminées restent conservées après une confirmation de commit perdue.
Les baux de workers sont acquis par une décision SQL atomique et les paramètres des requêtes groupées sont préparés sans parcours répétés. L'archive exige sa propre transaction DATA pour ne pas enregistrer un reçu encore annulable.
Avec le pilote PostgreSQL psycopg, l'analyse et l'archive préparent moins d'objets SQL pour leurs lots. Les transactions, identifiants et contrôles de doublons restent conservés ; le gain doit être mesuré par la recette.
La vitesse déclarée et la vitesse calculée restent identifiées. Les sauts GPS, horloges et vitesses incohérentes interrompent les preuves sans modifier le point brut ; contexte cartographique et réglages sont conservés.
Une fenêtre bornée fournit une vitesse moyenne avec durée et incertitude lorsque les fixes successifs sont insuffisants. Les mesures ACC intercalées conservent la preuve GPS. Cette moyenne ne prouve pas un arrêt brutal.
Arrêt brutal, immobilisation sur piste ou près du bord, contresens et sortie de piste demandent plusieurs points cohérents. Pitlane et paddock excluent les arrêts. Le sens et la précision doivent être connus. Les règles restent modifiables et aucune commande automatique des feux n'est ajoutée.
La reprise historique utilise un état séparé et ne remplace pas le direct. Les preuves de dépassement suspect sont durables. Les positions sont regroupées sur 100 ms par tracker ; une alerte déclenche sa lecture autorisée immédiatement.
Le silence du flux est surveillé sans nouveau point ; heartbeat et historique ne le masquent pas. Une règle retirée ne déclenche plus d'alarme depuis un ancien contexte. Le repli SSE relaie les alertes avec contrôle du compte et de la session.
Un GPS répété avec un nouvel identifiant et les paquets hors ordre restent enregistrés, sans repousser le silence ni remplacer l'état d'analyse. Une erreur après un commit terminé ne rouvre pas les effets déjà enregistrés.
Heartbeat et réenregistrement actualisent le contact sans rétablir online après un silence confirmé ; une nouvelle observation live éligible rétablit cet état. Les notifications reflètent l'état enregistré.
Les notifications WebSocket et SSE conservent l'identifiant de l'incident enregistré, pour retrouver la même alerte après une reprise.
Le tampon USB conserve les points jusqu'à l'accusé durable. Sauvegardes et restaurations préservent les nouveaux états et identifiants ; la sauvegarde complète suspend les deux processus. Un point est limité à 64 Ko ; l'audit HTTP redondant des points acceptés est supprimé.
Les tampons hors connexion restent bornés : USB à 250 000 événements ou 512 Mio, Android à 50 000 mesures ou 24 heures. Une saturation USB suspend la lecture ; la radio actuelle ne reprend pas les trames jamais reçues. Les pertes Android restent affichées. Ces tampons ne garantissent pas une journée complète sans serveur.
Tracker Android 0.5.0 conserve 5 Hz par défaut et propose 1, 5, 10 ou 20 Hz. La capture continue pendant les requêtes ; les lots privilégient les mesures fraîches, avec un quota de rattrapage. La cadence GNSS réelle et le délai d'alerte restent à mesurer.
L'envoi Android par lots conserve le même corps lors des retries et attend chaque accusé durable avant retrait. Un lot peut confirmer certains points et en refuser d'autres ; une réponse malformée n'efface rien. Le repli vers l'ancienne API intervient à la tentative suivante.
Le drain USB réduit les lectures répétées par trame. Les refus de statut, de révocation ou de type conservent leurs enveloppes bloquées, sans faux accusé. Le cache de configuration détecte les remplacements de fichier et les changements pendant une lecture.
La conservation serveur reste de trois jours. Le tampon Android de 50 000 mesures représente au plus 41 min 40 s sans accusé à 20 Hz ; ses pertes restent comptées et visibles.
Android transmet le cap fourni par le fix GNSS courant. Un cap absent ou périmé reste absent ; l'ancien cap et un calcul entre deux positions ne sont plus présentés comme une mesure native.
Les vrais fixes GPS frais gardent leur priorité sur ACC et le rattrapage. Un point devenu ancien rejoint l'historique avec sa session d'audit. L'affichage et la reconnexion conservent le fix et les métadonnées de vitesse.
Le sens attendu se règle dans l'éditeur de secteurs et zones de piste. Le cap GNSS est contrôlé par un déplacement significatif ; des caps contradictoires suspendent la preuve de contresens.
Une panne DATA conserve le démarrage des comptes et réglages ; le moteur réessaie sa préparation au retour de la base, sans acquitter de point non enregistré.
Une DATA revenue sans migrations est initialisée avant reprise des consommateurs. Une ancienne archive initialise les nouvelles règles ; une archive 0106 conserve les suppressions décidées par l'opérateur.
La création du journal sur PostgreSQL conserve ses contraintes SQL ; l'ancienne traduction qui empêchait cette migration est corrigée.
Les migrations traduisent les identifiants SQLite AUTOINCREMENT vers PostgreSQL et refusent de lancer les consommateurs si DATA reste incomplète.
Le traitement des trackers retire les lectures d'identifiant inutiles, tout en conservant les identités stables des reçus et des alertes.
La mise à jour du direct utilise des conditions SQL portables sur PostgreSQL, y compris pour ACC seul et une précision absente. Une erreur pouvait faire vieillir les positions avant validation des alertes.
Des caches mémoire bornés réutilisent les contextes décodés et les contours préparés. Chaque lot vérifie sa source durable ; une restauration renouvelle les caches. La cartographie conserve ses contours et les mêmes critères de zones et de distance au bord.
La lecture du contexte regroupe les métadonnées internes dans un snapshot SQLite cohérent en lecture seule. Les chemins de base et d'archive copient les seules sections utiles de configuration, avec les mêmes contrôles de fraîcheur et la compatibilité des anciens réglages GNSS.
La recette de sauvegarde vérifie le même journal sur PC et Pi, avec les mêmes contrôles de restauration et de sécurité.
Un refus d'arrêt du writer conserve l'erreur initiale et les références actives. La fermeture des processus d'analyse et d'archive ne tente plus cet arrêt une seconde fois ; la restauration reste refusée.
Le banc de charge prépare son propre circuit et sa carte après vérification de DATA, pour qualifier les trackers sans dépendre du circuit livré par défaut.
Le débit de 40 trackers et le délai de deux secondes restent soumis à la recette mesurée. Les trames USB anciennes sans précision ou heure fiable limitent les alertes ; le firmware enrichi externe et les transmissions matérielles doivent encore être qualifiés.

4.6.0-0105

Le champ « N° » disparaît des palettes Piste et Secteurs. Les commandes de ces palettes n'ajoutent plus de numéro. La saisie du drapeau texte T, les programmes et les anciennes commandes API restent compatibles.
L'état piste réutilise les panneaux dans la même requête et transforme les événements de comptage déjà lus, sans les relire individuellement. Les droits et filtres restent conservés, sans cache partagé entre comptes.
La recette reprend les contrôles manquants de 0104 avec un nouveau paquet identifié. Les limites fournisseur, restauration et délais sont consignées dans le bilan de recette ; ces notes ne présument pas de leur réussite.

4.6.0-0104

BUG-000032 : cliquer sur le fond de la carte Piste conserve le drapeau sélectionné et le texte déjà validé. Le prochain clic sur un panneau utilise cette sélection. Le clic sur le fond ne commande aucun feu.
Échap hors fenêtre ouverte et Annuler dans la saisie texte gardent leur rôle. Le changement de palette, les contrôles de droits et la protection contre les clics sous le bandeau restent conservés.
Sur un écran de hauteur inférieure ou égale à 600 pixels, notamment en paysage 844 × 390, le menu de la barre supérieure utilise aussi son affichage compact en haut de l'écran, avec hauteur limitée et défilement interne.
Ce nouveau candidat suit le bilan 0103 clos avec une qualification fonctionnelle incomplète. Ses corrections exigent leurs propres validations ; aucun succès Pi, publication ni rendu matériel n'est présumé.

4.6.0-0103

Les sauvegardes Cloud, locales, la restauration et la récupération après sinistre sont regroupées dans Configuration → Sauvegardes. La tuile Cloud et sa fenêtre disparaissent de Piste. L'ancien lien #restore ouvre les archives.
Le catalogue d'archives Cloud est chargé seulement dans son onglet. La programmation locale reste accessible lorsque le Cloud est lent ; les requêtes simultanées sont regroupées. Les droits, l'option payante et les confirmations de restauration restent conservés.
Le chargement des cartes ne bloque plus tous les autres chargements derrière un verrou réseau unique. Le nombre d'acquisitions est limité ; les erreurs DNS, HTTPS, réseau, fournisseur et les délais dépassés sont distingués. Les images sont vérifiées avant affichage et mise en cache.
Dans Configuration → Cartes, préparez un cache IGN sur les limites de la carte ou autour de son centre, avec un rayon de 0,1 à 5 km. La zone est un carré couvrant ce rayon. Une estimation présente les images présentes et manquantes, leur volume réel ou estimé, puis la progression et l'annulation du téléchargement.
Le téléchargement est borné à 100 km² et 5 000 images, soumis au quota réel. OpenStreetMap autorise la consultation et son cache habituel, mais pas le préchargement de zones ; son fournisseur public n'est pas proposé pour ce téléchargement.
Les indicateurs Piste réservent la place des contrôles Calques et défilent sous ceux-ci lorsque la hauteur manque. Les positions enregistrées sont conservées, y compris lors des déplacements au clavier ou à la souris des rangées sous la zone visible. La fenêtre de création OSM suit les couleurs du thème.
L'horloge met à jour les seuls contrôles de session. Les logos inchangés ne sont plus recréés et les lectures simultanées du journal sont regroupées ; une réponse d'un ancien organisateur est écartée.
Les liens de la fenêtre À propos précisent leur portée de traduction. Les contrôles d'aide portent aussi sur Configuration avec son panneau Sauvegardes intégré ; les échecs de déplacement conservent leurs diagnostics et captures. Les tests de concurrence identifient le thread qui possède le verrou et la fixture de restauration utilise une horloge maîtrisée, sans changer le comportement du produit.
La qualification est confiée à Hermès et son Codex. Les images synthétiques ne prouvent pas l'accès réel OSM/IGN ni la charge du Pi ; aucun succès Pi, publication ou changement Cloud n'est présumé. Compte+IP, D1 et l'offre 2026 restent prévus pour 0104 et suivants.

4.6.0-0102

Sauvegardes mène explicitement à la programmation Cloud. Le même formulaire est disponible dans Cloud et restauration et depuis l'accueil ; résultat lisible près du formulaire, bouton occupé jusqu'à la réponse et réglages accessibles même si le catalogue est indisponible.
Le créateur OpenStreetMap affiche la cause d'une carte indisponible : session, droits, abonnement, images hors ligne, fournisseur ou image illisible. Réessayer et réouverture actualisent les calques ; les couches retirées ne continuent plus leurs téléchargements.
Sur mobile, les bulles Piste enregistrées sur ordinateur se réorganisent si elles se chevauchent, sans effacer les positions de bureau. Les indicateurs restent accessibles lorsque la hauteur manque et les liens au clavier sont conservés.
Les contrôles d'abonnement cartographique et de sauvegarde payante restent applicables. Aucun prestataire réel, DNS, proxy, serveur Cloud ou installation de production n'est modifié par ce lot.
Tests, recette Pi et livraison sont confiés à Hermès et/ou son Codex, sur l'artefact figé. Compte+IP, D1 et l'offre 2026 restent prévus à partir de 0103.
La recette cartographique corrige sa simulation du passage hors ligne et vérifie l'erreur HTTP 404 et l'état indisponible lors de la réouverture.
Le créateur OSM annule son redimensionnement différé lorsque sa carte est détruite et vérifie que la fenêtre est visible. La recette conserve la destruction immédiate et les erreurs JavaScript complètes. Le fond de la fenêtre météo reste dans ses marges sur mobile.
La fenêtre météo reste aussi dans la hauteur de l'écran. Son contenu défile et le bouton Fermer reste visible ; la recette vérifie l'accès au dernier contenu.
La météo Cloud reprend les prévisions AROME/ARPEGE, la vigilance datée et le radar national avec son intensité au circuit en mm/h. Les données anciennes ou absentes restent identifiées, les jours affichés suivent les données disponibles et aucune animation locale ni absence d'alerte n'est inventée.
Le radar associe chaque image à son échéance, actualise les données à l'ouverture de l'onglet et retire les mesures périmées dans une fenêtre laissée ouverte. La vigilance perd sa couleur à l'expiration du bulletin ou lors d'une transition de période. Les images restent privées. Demain suit l'heure de Paris ; la fenêtre météo tient sur mobile.
Les journées de prévision peuvent être partielles. La sélection de station dans RTM et les sources PIAF/AROME PI restent hors de ce correctif ; les simulations ne qualifient pas les fournisseurs réels.

4.6.0-0101

La tuile Sauvegarde Cloud de la page principale ouvre une fenêtre, comme la météo : copie immédiate ou quotidienne, restauration d’archive et récupération après sinistre.
Dernier résultat réel actualisé chaque minute, droits et confirmations conservés. Le même panneau est utilisé dans Configuration, sur mobile et au clavier.
La restauration ferme maintenant le flux permanent Track avant de remplacer les données ; les écritures et téléchargements ordinaires ne sont pas interrompus.
Option payante, compte Cloud indépendant après sinistre, copie de sécurité et équipements suspendus. Même version RTM et PostgreSQL/PostGIS nécessaires ; système et code exclus.
0100 reste un candidat historique bloqué. Les améliorations compte+IP, D1 et l’offre 2026 passent aux builds 0102 et suivants.

4.6.0-0100

Consolidation des protections 0099 : licence signée conservée hors ligne, retrait de sécurité différé pendant les sessions, récupération protégée, état en direct filtré et blocage temporaire de connexion.
Option payante Sauvegarde Cloud complète, immédiate ou quotidienne : configuration, comptes, secrets applicatifs, bases et fichiers, intégrité contrôlée, rétention et suivi des erreurs.
Après sinistre, le compte Cloud retrouve les archives sans l’ancien jeton. Sur un RTM préparé de même version, choisir l’archive et confirmer restaure configuration et données. Sauvegarde de sécurité préalable, accès système de la cible préservés et équipements à remettre en service explicitement.
Le mini-site intégré est retiré. Les logos et anciennes pages de présentation dirigent vers les rubriques maer.fr ; les écrans métier restent locaux. Internet est requis pour les présentations commerciales.
Client permanent de test sur le Pi principal, distinct de Mirecourt en production. Chaque publication exige la qualification de ce nouvel artefact ; les candidats historiques 0097/0098 ne sont pas réutilisés.
Limites : pas de sauvegarde du système ou du code, 256 Mio par archive, 20 archives et 2 Gio par installation. PostgreSQL/PostGIS et la même version RTM doivent être préparés avant restauration. Les améliorations compte+IP et D1 restent au lot suivant.

4.6.0-0099

Une panne du Cloud, un refus HTTP ou une rotation de jeton conserve la dernière licence signée. Un retrait signé des modules Flags ou Track attend l’arrêt des sessions et est journalisé.
Les liens de récupération de mot de passe utilisent une adresse configurée ou celle du serveur. Les en-têtes de proxy ne sont acceptés que depuis un proxy explicitement déclaré.
Le flux en direct filtre les données par compte. Pilotes et organisateurs ne reçoivent plus les panneaux, secteurs, autres organisateurs ni la télémétrie piste.
Les échecs de connexion et demandes de récupération sont limités temporairement par compte et IP. Le blocage dure 15 minutes par défaut et ne désactive jamais définitivement un compte. Mot de passe limité à 256 caractères.
Base Git 0096 : les travaux locaux 0097/0098 non commités restent séparés. Aucun changement Cloud ni déploiement en production.
Les programmes de drapeaux retrouvent exactement les octets du catalogue de référence, sans changement de leurs images ni de leur comportement. L’aide de Restauration et des notes de version rejoint le manuel existant. Les pages Mises à jour et Test de couverture reçoivent leur aide contextuelle ; le manuel dérivé de l’assistant est régénéré.

4.6.0-0098 — candidat historique, consolidé dans 0100

Le mini-site commercial intégré est retiré du paquet RTM. Les logos RTM, Track, Timing, Flags et MAER Engineering ouvrent directement leurs rubriques sur maer.fr dans un nouvel onglet.
Les anciennes adresses des pages de présentation conduisent à maer.fr, y compris via le relais Cloud. Un lien reste disponible si la navigation automatique est bloquée ; les anciennes images et chemins inconnus renvoient une erreur 404.
Les présentations nécessitent Internet. Les écrans métier, logos locaux et résultats de chronométrage restent disponibles dans RTM. Les adresses privées et paramètres de RTM ne sont pas transmis au site public.

4.6.0-0097 — candidat historique, consolidé dans 0100

Programmes VSN rétablis à leurs octets originaux vérifiés par le catalogue ; dépendances des tests d'API déclarées et vérifiées avant la qualification.
Archives ZIP compatibles Windows et Linux, fermeture des connexions SQLite après transaction et attente de fin d'instantané en cas d'annulation avant la reprise des acquisitions.
Option payante Sauvegarde Cloud : copie complète immédiate ou quotidienne de la configuration, des comptes, secrets applicatifs, bases et fichiers du client, avec vérification d'intégrité, rétention et suivi des échecs.
Après perte du serveur : récupération depuis le compte Cloud avec un code temporaire, sans ancien jeton ni sauvegarde locale. Sur un RTM préparé de même version, choisissez une archive et confirmez la reprise complète. Les anciennes copies restent disponibles après expiration de l'abonnement.
Sauvegarde de sécurité, redémarrage via le worker local disponible ou Cockpit, traitement explicite des erreurs et mise en attente des acquisitions. Les comptes et réglages du client sont récupérés ; les connexions système de la cible restent en place. Les équipements nécessitent une remise en service explicite.
Les archives portables anciennes conservent leur fonctionnement. La sauvegarde complète exclut le système, code, caches, fichiers de logs et anciennes archives. GNSS configurée inaccessible, chemin externe non pris en charge ou dépassement de quota : refus explicite. Cloud : 256 Mio par archive, 20 archives et 2 Gio par installation.
Livraison associée à RTM Cloud 0.1.0-test.21, avec recette Pi identifiée par les empreintes des paquets avant toute promotion.

4.6.0-0096

La mise à jour depuis 4.6.0-0094 par le bouton client fonctionne de nouveau : des fins de ligne différentes dans la liste des dépendances ne sont plus prises pour un changement de dépendances.
Aucun autre changement : fonctions, écrans, réglages et données restent ceux de la version précédente.

4.6.0-0095

Réorganisation interne des sources par produit, sans changement fonctionnel : fonctions, écrans, réglages, données et adresses restent identiques à la version 4.6.0-0094.
Le paquet installé conserve la même organisation. La mise à jour ne demande aucune migration ni action particulière ; le retour à 4.6.0-0094 reste possible par réinstallation.

4.6.0-0094

Météo Cloud enrichie : Météo-France AROME reste prioritaire. Les prochaines heures disponibles et un complément OpenWeather configuré par MAER alimentent les prévisions à cinq jours par pas de trois heures, la pluie, les nuages, la visibilité, la pression et le ressenti selon les données reçues. Les clés restent au Cloud ; la configuration manuelle est conservée.
Les sources, les dates et la résolution des prévisions sont indiquées. Les minima/maxima quotidiens sont ceux des échantillons disponibles. Les informations absentes, dont radar, UV, vigilance ou sept jours complets, restent signalées indisponibles. Aucun abonnement OpenWeather One Call n’est souscrit.
Nouveau menu Restauration : choix d’une archive locale, import d’un ZIP depuis le PC ou récupération d’une copie Cloud, puis aperçu du contenu et confirmation de son empreinte. Une archive importée n’est jamais restaurée automatiquement.
Avant restauration, RTM refuse les sessions actives, crée une sauvegarde de sécurité et passe en maintenance en attendant la fin des opérations. Les comptes, secrets, identité du circuit, connexions, adresses et identifiants des panneaux, liaisons USB et réglages météo de la cible sont conservés. Un matériel de remplacement doit être raccordé explicitement. Le journal de l’assistant reste sur la cible et les demandes en attente ou approuvées sont invalidées ; les anciennes intentions d’affichage dynamique ne sont pas rejouées. Un redémarrage explicite du service depuis Cockpit est requis. Une erreur partielle garde la maintenance fermée pour une reprise contrôlée depuis la sauvegarde de sécurité.
Sauvegarde privée dans RTM Cloud : envoi, liste, récupération et suppression confirmée, avec abonnement Maintenance et droits RTM. Les archives sont chiffrées et séparées par installation, dans la limite de 256 Mio chacune, 20 archives et 2 Gio par installation. Aucune suppression automatique pour libérer de la place.
Les terminaux Android TV restaurés restent désactivés et révoqués : chaque écran doit être réappairé avant de reprendre son affichage.
Livraison associée au Cloud 0.1.0-test.16 et préparation du central sur un serveur Ubuntu dédié. La qualification reste faite sur le Pi et la mise à jour utilise le même paquet privé. Une restauration applicative couvre les données incluses dans l’archive, pas le système Linux complet.

4.6.0-0093

Piste : le titre « Palette » reste entier. Le numéro et la nouvelle liste des palettes se trouvent côte à côte sous le titre. La palette « Principale » reste le choix initial et conserve ses drapeaux, leur visibilité et leur ordre existants.
Les palettes Flèches, Sécurité, Pluie, Glissant et Autres montrent les drapeaux classés dans les réglages. Chaque drapeau possède un nouveau champ « Palette spécialisée », distinct de sa visibilité dans la principale ; la liste indique ces deux états. Les programmes usuels actifs du catalogue sont préclassés une fois et les doublons archivés restent masqués. Un drapeau ne peut être classé que dans une palette spécialisée. « Extinction » est toujours disponible. Changer de palette annule la sélection en cours sans commander de feu.
L'historique ci-dessous regroupe les évolutions retrouvées dans les notes et documents antérieurs. Les attributions ou publications incertaines sont indiquées au lieu d'être présentées comme acquises.
Premier lot du chantier Assistant IA : le manuel RTM versionné devient consultable avec le seul abonnement IA. Les états du site, diagnostics et propositions de réglage exigent toujours l'abonnement Maintenance et les droits RTM. Aucun accès au terminal, aux fichiers ou aux commandes de feux n'est ajouté. Le serveur RTM Cloud correspondant porte la version technique 0.1.0-test.15 ; un fournisseur et un modèle IA doivent être configurés.
La base interne reçoit un champ additif de classement, sans effacer les drapeaux personnalisés ni les préférences existantes. L'installation en un clic conserve le dispositif de sauvegarde et de retour arrière ; une restauration intégrale repose sur la sauvegarde des données et de la configuration de l'installation.

4.6.0-0092

Sur le Pi de test, le superviseur de la base USB distante attend 30 secondes entre deux recherches lorsque la base est absente, et 10 secondes après une erreur. Cela évite que les recherches USB/IP répétées monopolisent le processeur.
La reconnexion automatique reste active : dès que la base distante réapparaît, elle est reprise au prochain contrôle. Une reconnexion peut donc prendre jusqu'à environ 30 secondes de plus. Aucune commande de feu ni modification des données de circuit n'est effectuée.
Maintenance du banc de test : anciennes sauvegardes NAS déplacées sur la clé USB après vérification, cache de construction supprimé et anciennes piles Docker arrêtées. Ces actions ne concernent pas l'installation de Mirecourt.

4.6.0-0091

La zone d'information du drapeau prend la place restante après les secteurs. La limite de largeur qui imposait un défilement des secteurs est supprimée.
Les boutons de secteurs gardent leur nom et le nombre de panneaux lisibles, sans ascenseur interne. Si la fenêtre est trop étroite, la barre répartit les éléments sur plusieurs lignes et adapte sa hauteur, sans masquer la carte ni la palette.
L'encart reste dans la barre du bas avec sa couleur, son aperçu et ses instructions. Les boutons « Bugs et suivi » et Aide restent accessibles. Les droits, les commandes et la sortie par Échap sont conservés ; sélectionner un drapeau n'envoie aucune commande.
Correction du défaut observé sur le Pi en 0090 avec les barres de défilement classiques. Aucun changement du moteur serveur, du schéma de données ou des dépendances.

4.6.0-0090

L'encart du drapeau sélectionné est replacé dans la barre inférieure des secteurs. Sa présentation horizontale compacte utilise l'espace disponible à côté des secteurs, au lieu d'un panneau séparé au-dessus de la barre.
La couleur de fond, l'aperçu du drapeau et les instructions contrastées sont conservés. Les boutons « Bugs et suivi » et Aide restent accessibles à droite sans recouvrir le message ; la disposition s'adapte aux petites fenêtres. Si la barre des secteurs est masquée dans les préférences, l'encart seul apparaît temporairement en bas pendant la sélection.
Échap et le clic hors zone quittent la sélection. Les droits et les commandes restent inchangés ; sélectionner ou prévisualiser un drapeau n'envoie aucune commande. Aucun changement de données ni de dépendances.
Consigne permanente de recette : utiliser en priorité l'installation principale du Pi avec sauvegarde et retour arrière utiles, pour rendre le candidat visible et éviter les installations parallèles superflues, tout en conservant l'isolation des tests et du matériel de production.

4.6.0-0089

L'encart de sélection des drapeaux dispose d'un espace réservé sous la carte et la palette, au-dessus de la barre des secteurs. Si l'écran manque de hauteur, la page défile et l'encart reste accessible après la palette, sans recouvrir ses choix. Les couleurs, textes et aperçus contrastés de 0088 sont conservés.
L'encart laisse utiliser la palette, y compris le choix Texte sur petit écran. Un clic sur l'encart ne commande pas un feu ou un secteur masqué dessous ; les commandes au clavier restent disponibles. Il disparaît à la sortie de sélection, à la désactivation de Flags ou au retrait des droits d'action sur les drapeaux. Le droit de commander suffit à conserver la sélection. La sélection et l'aperçu seuls n'envoient aucune commande.
Consigne permanente de l'utilisateur : chaque changement livré, même mineur, doit incrémenter la version et être expliqué dans les notes de version.

4.6.0-0088

À propos : numéro complet mis en évidence et actualisé à chaque ouverture, accès au catalogue par « Vérifier les mises à jour » et à ces notes par « Liste des changements ». Consulter le catalogue ne lance aucune installation. En cas d'échec du chargement, la version est indiquée indisponible.
BUG-000029 « Couleur souris » : l'encart de sélection montre le drapeau choisi pour limiter les confusions. Son fond reprend la couleur, avec une vignette de la palette pour les motifs, images et textes. Le numéro ou le texte choisi reste indiqué dans l'action.
Texte contrasté, aperçu fixe sans clignotement ni curseur personnalisé, encart placé au-dessus de la barre de commandes et des boutons Bugs et suivi/Aide. Les instructions restent visibles même si une image ne se charge pas.
La touche Échap permet de quitter la sélection lorsqu'aucune fenêtre de dialogue n'est ouverte. Le clic hors zone reste disponible. La sortie efface l'aperçu et ses couleurs ; les commandes et permissions restent identiques.

Fonctions disponibles en 4.6.0-0087

Mises à jour privées : catalogue RTM Cloud, version installée et notes des publications. L'installation nécessite une action explicite et un service local préparé par MAER. Le parcours vérifie les publications signées et prévoit sauvegarde, contrôle du service et restauration en cas d'échec.
Météo : affichage des conditions et de la température, vent et direction, prévisions et alertes selon les données disponibles et le fournisseur configuré.
Connexion Cloud : réglages du raccordement privé, test de connexion et vérification des informations de licence. La disponibilité des services connectés dépend du raccordement et des droits correspondants.

Repères des versions antérieures reconstituées

Cette chronologie résume les documents conservés. Une fonction « présente en » une version n'y a pas nécessairement été créée ; les dates des documents ne prouvent pas une mise en production.

0062 : base de référence avec catalogue Colorlight, palette configurable, affichage texte court et adaptations du journal et des PDF.
0064–0066 : parcours Tracker Android, édition contrôlée des fonds de carte et configuration des trackers et QR codes.
0070–0072 : suivi des signalements et corrections de parcours ; le détail de chaque build n'a pas pu être établi.
0075 : améliorations Timing/organisateur et compagnon Commissaires Android, initialement désactivé.
0063, 0067–0069, 0071, 0073–0074 et 0076–0086 : des candidats ou travaux sont attestés, mais leur contenu précis et leur statut de publication ne sont pas suffisamment établis pour leur attribuer une liste de nouveautés.

Pour installer une version publiée par MAER, ouvrez « Vérifier les mises à jour » depuis la fenêtre À propos.