Amélioration avec des fonctions d'un vrai dashboard automotive et containerisation du projet pour faciliter le déploiement

README.md

@@ -1,6 +1,18 @@
 # CARIA Automotive · Cockpit
 
-Première version de l’interface intérieure : accueil multimédia et instrumentation automobile, indépendants du matériel. Le projet scolaire original reste dans `WebControl/` ; le cockpit utilise `ui/` et `server/`.
+Version 0.3 de l’interface intérieure : accueil multimédia, instrumentation automobile, thèmes, météo, navigation et catalogue d’applications, indépendants du matériel. Référence d’affichage : **10 pouces tactile, paysage, 1200 × 1080 pixels** (dimensions fournies comme 1080 × 1200 puis orientation horizontale). Le projet scolaire original reste dans `WebControl/` ; le cockpit utilise `ui/` et `server/`.
+
+**Mise à jour d’une installation existante** : récupérer les fichiers modifiés puis exécuter `docker compose up -d --build` et recharger la page (Ctrl+F5). La version 0.1 a été construite et démarrée avec succès par l’utilisateur ; la nouvelle image 0.3 reste à construire sur son serveur.
+
+## Nouveautés 0.3
+
+- Bouton hamburger pour masquer/afficher les favoris, préférence mémorisée ; en-tête intégré au contenu et pied de page conservé pour les tests. Titres de page visuellement masqués quand les commandes suffisent.
+- Quatre favoris personnalisables et catalogue : Accueil, Conduite, Navigation, Musique locale, Jellyfin, Spotify, YouTube, **YouTube Music**, Waze. Afficher/masquer, ordre et mode d’ouverture réglables via Applications → Personnaliser ou Réglages → Personnaliser les applications.
+- Conduite : compteurs agrandis, base aplatie sous leurs libellés, quatre mesures rapides et page de détails (`#vehicle-details`). Lien dédié `/?display=drive#drive` ouvrant Conduite avec la barre repliée. Le favori Conduite reste présent par défaut pour les essais.
+- Musique : bibliothèque conservée et seconde vue `#now-playing`, accessible via « Vue lecture immersive ». Progression en arc, titre, durée, lecture/pause, précédent/suivant, ±15 s, déplacement dans la piste, volume, silence et répétition. Les deux vues partagent le même élément audio.
+- Services externes : nouvel onglet, même onglet, ou lecteur intégré pour les contenus compatibles. Waze peut recevoir la destination choisie dans CARIA.
+
+Voir [le guide applications et affichage tactile](docs/applications.md) pour les limites des intégrations Spotify, YouTube Music et Jellyfin.
 
 ## Démarrage avec Docker
 
@@ -20,7 +32,7 @@ docker compose down
 
 Le port est configurable avec `CARIA_PORT` dans un fichier `.env` à la racine (exemple : `CARIA_PORT=8090`). Deux services : Nginx sert l’interface et relaie `/api/` vers le simulateur Node.js. Seul le port de l’interface est publié. Aucun périphérique ni privilège matériel n’est demandé.
 
-Les images de base ne forcent pas l’architecture. La construction sur l’ODroid utilisera les variantes disponibles pour son système. **Le modèle, l’OS et l’architecture de l’ODroid restent à confirmer avant de garantir la compatibilité**, notamment si son OS est en 32 bits. Le déploiement Docker n’a pas pu être exécuté sur le poste de développement, où Docker est absent.
+Les images de base ne forcent pas l’architecture. La construction sur l’ODroid utilisera les variantes disponibles pour son système. **Le modèle, l’OS et l’architecture de l’ODroid restent à confirmer avant de garantir la compatibilité**, notamment si son OS est en 32 bits. Docker est absent du poste de développement.
 
 ## Démarrage sans Docker
 
@@ -34,18 +46,23 @@ Le serveur local sert également les trois fichiers de l’interface, sur le mê
 
 ## Fonctions disponibles
 
-- **Accueil** : heure/date de l’appareil, météo de démonstration, carburant/autonomie et accès à la musique.
+- **Accueil** : heure/date de l’appareil, météo réelle Open-Meteo après localisation, carburant/autonomie simulés et accès à la musique.
 - **Conduite** : vitesse et régime moteur à aiguilles SVG, rapport, carburant, température moteur, tension batterie, consommation et trajet simulés.
 - **Musique** : sélection multiple de fichiers audio locaux, liste de lecture, lecture/pause, précédent/suivant, progression et volume via le lecteur natif. Les fichiers restent sur l’appareil qui affiche le navigateur ; ils ne sont pas transférés au serveur. La sélection doit être refaite après un rechargement. Une bibliothèque persistante sur disque/USB côté serveur pourra être ajoutée ensuite.
 - **Streaming** : lien Jellyfin préconfiguré vers `https://media.cunatbrule.fr/web/`, modifiable dans les réglages. Ouverture dans un autre onglet ; aucune intégration de compte ni lecteur vidéo Jellyfin embarqué à ce stade.
-- **Réglages** : ambiance jour/nuit, adresse du streaming, raccourcis pour ouvrir deux écrans et bouton plein écran. Les réglages sont conservés dans le stockage local du navigateur.
+- **Réglages** : ambiance jour/nuit combinable avec bleu, rouge, vert ou couleur utilisateur ; la palette colore les commandes, aiguilles, graphiques et illustrations. Luminosité adaptée au contraste. Adresse du streaming, raccourcis multiécran et plein écran. Les réglages sont conservés dans le stockage local du navigateur.
+- **Navigation** : carte Leaflet/OpenStreetMap, recherche de départ/destination avec Photon, itinéraire automobile OSRM, étapes en français, suivi GPS et voix optionnelle. Recalcul manuel en cas de sortie de route. Pas de trafic temps réel ni de cartographie hors ligne.
+- **Alertes de zones** : import GeoJSON local, sélection du pays, approche GPS, signal visuel et bip optionnel. Aucune base de radars ni alerte communautaire n’est fournie. Le test d’alerte est explicitement fictif. Les alertes sont désactivées à chaque rechargement/changement de pays et suspendues si le GPS est ancien ou imprécis.
 
-Le menu à gauche contient les quatre applications : accueil, conduite, musique et streaming. Les réglages sont en bas. La météo est fictive et explicitement marquée « DÉMO » ; l’heure est réelle. L’interface et la musique sélectionnée fonctionnent sans Internet tant que le serveur local est accessible. Jellyfin dépend de l’accès à son serveur.
+Le menu à gauche contient jusqu’à quatre favoris, avec un accès Applications permanent et les réglages en bas. Le badge « Démonstration » concerne les données du véhicule, pas la météo. La météo utilise une estimation de modèle et ne remplace pas une sonde extérieure. L’interface et la musique sélectionnée fonctionnent sans Internet tant que le serveur local est accessible. Les services météo, carte, recherche et itinéraires nécessitent Internet avec la configuration par défaut.
+
+**GPS sur le réseau local** : les navigateurs demandent un contexte sécurisé, donc HTTPS avec certificat reconnu, ou localhost. Sur `http://IP_DU_SERVEUR:8080`, utilisez le départ manuel (recherche ou coordonnées) pour la météo et les aperçus d’itinéraire. Le GPS de l’ODroid devra être fourni à son navigateur ; cette version n’intègre pas encore gpsd ou un récepteur USB. Voir [le guide météo/navigation/alertes](docs/navigation.md).
 
 ## Un ou plusieurs écrans
 
-- Instrumentation : `http://ADRESSE_DU_SERVEUR:8080/#drive`
+- Instrumentation dédiée : `http://ADRESSE_DU_SERVEUR:8080/?display=drive#drive`
 - Multimédia : `http://ADRESSE_DU_SERVEUR:8080/#home`
+- Navigation : `http://ADRESSE_DU_SERVEUR:8080/#map`
 
 Chaque écran ouvre sa propre page. Les valeurs proviennent du même serveur. Le profil route/ville/arrêt se synchronise entre les onglets d’un même navigateur et d’une même origine ; sur deux appareils, sélectionner le même profil sur chacun. Les fichiers audio et réglages restent propres à chaque navigateur.
 
@@ -65,22 +82,27 @@ Navigateur ODroid / tablette / second écran
 Étape suivante : passerelle Raspberry Pi CAN → données normalisées → interface
 ```
 
-L’interface utilise HTML/CSS/JavaScript sans framework, sans CDN ni police distante. Les compteurs SVG s’adaptent à la résolution, avec une actualisation toutes les 500 ms et une transition d’aiguille. Le serveur utilise uniquement les modules standard de Node.js. Aucun gain de performance sur ODroid n’est encore mesuré.
+L’interface utilise HTML/CSS/JavaScript sans framework, sans CDN ni police distante. Leaflet 1.9.4 (BSD-2-Clause) est livré localement et chargé à l’ouverture de la carte. Les tuiles sont téléchargées auprès du fournisseur cartographique. Les compteurs SVG s’adaptent à la résolution, avec une actualisation toutes les 500 ms et une transition d’aiguille. Le serveur utilise uniquement les modules standard de Node.js. Aucun gain de performance sur ODroid n’est encore mesuré.
 
 La passerelle CAN est un futur composant : pas de décodage Mégane III, de SocketCAN ni de commande véhicule dans cette version. Elle pourra être écrite indépendamment en Python, Rust, C++ ou JavaScript. Le contrat proposé est décrit dans [docs/architecture.md](docs/architecture.md). Le passage à des données réelles nécessitera également une adaptation de leur validation et de leurs indicateurs dans l’interface.
 
-Navigation, météo réelle, alertes radar et bibliothèque audio sur le serveur sont des étapes ultérieures. Les composants techniques choisis sont open source ; le dépôt historique n’a pas de licence globale, à définir avant une distribution publique du projet complet en tenant compte des fichiers tiers.
+Restent notamment : source de zones autorisée et maintenue par pays, GPS matériel, cartographie hors ligne et bibliothèque audio persistante sur le serveur. Les composants techniques choisis sont open source ; le dépôt historique n’a pas de licence globale, à définir avant une distribution publique du projet complet en tenant compte des fichiers tiers.
 
 ## Validation
 
 ```sh
-node --test server/telemetry.test.mjs
+node --test server/telemetry.test.mjs server/journey.test.mjs server/applications.test.mjs
 node --check ui/app.js
+node --check ui/journey.js
 ```
 
-Tests exécutés : contrat HTTP, limites des données simulées, profil invalide, API en lecture seule et impossibilité d’accéder aux fichiers du projet historique via le nouveau serveur. Tests Chrome automatisés : quatre vues à 1280×800, 1024×600, 800×480 et 390×844, absence de débordement horizontal, réglages persistants, lien Jellyfin, lecture de deux WAV locaux, changement de piste et retour après coupure API. Les captures accueil et conduite ont été examinées. Défilement vertical possible sur petits écrans selon la vue.
+Tests exécutés : contrat HTTP, limites des données simulées, profil invalide, API en lecture seule et isolation des fichiers historiques ; cache des services, coordonnées invalides, limites de requêtes, erreurs fournisseur ; calcul géographique, progression et validation des zones, exclusion des données expirées ou du GPS imprécis/ancien ; couleurs extrêmes. Tests Chrome : cinq vues à 1280×800, 1024×600, 800×480 et 390×844, sans débordement horizontal ; persistance du thème, météo manuelle, recherche/itinéraire, GPS simulé, import et alerte de zone, pause à l’arrêt du GPS. Les fournisseurs sont simulés et les tuiles remplacées localement pendant ces tests automatiques. Les réponses météo, recherche et itinéraire ont aussi été vérifiées sur les services réels depuis Node.js avec des coordonnées de test à Paris. Les tests audio/Jellyfin/coupure API de la version précédente sont conservés comme validation de cette base. Défilement vertical possible sur petits écrans selon la vue.
 
-À valider sur la cible : Docker/Compose, architecture ARM exacte, résolution et densité de l’écran, tactile, sortie audio, démarrage kiosque, consommation CPU/RAM et lecture Jellyfin réelle avec le compte utilisateur. Le lien Jellyfin a été vérifié dans l’interface, sans connexion au service ni test de son contenu.
+Le scénario navigateur est dans `tests/browser.mjs`. Il demande Playwright et un Chromium installé dans l’environnement de test, et un serveur CARIA démarré. Exécuter `node tests/browser.mjs`. Variables optionnelles : `CARIA_URL`, `CHROME_PATH`, `PLAYWRIGHT_MODULE` (chemin de module sous forme d’URL `file:///...` si hors résolution npm). Playwright n’est pas une dépendance de production et n’est pas inclus dans Docker.
+
+Scénarios 0.3 également exécutés : `node tests/applications-browser.mjs` (catalogue, favoris, masquage, persistance, onglets et continuité audio) et `node tests/touch-browser.mjs` (1200×1080 tactile, hamburger, conduite dédiée, détails, lecture en arc, avance/volume/répétition, intégration à la demande et arrêt en quittant la vue). Les services externes sont interceptés dans ces tests : aucune connexion à un compte ni lecture commerciale réelle n’y est effectuée. Les vues sont vérifiées sans débordement horizontal à plusieurs tailles, et les captures de Conduite et de la lecture immersive ont été examinées.
+
+À valider sur la cible : construction Docker 0.3, architecture ARM exacte, densité tactile, sortie audio, démarrage kiosque, consommation CPU/RAM, GPS réel et lectures externes avec les comptes utilisateur. Le guidage n’a pas été testé sur route. Un contrôle HEAD public de Jellyfin a répondu HTTP 200 sans `X-Frame-Options` ni `Content-Security-Policy` ; cela ne constitue pas un test de connexion ou de lecture intégrée.
 
 Voir [l’audit du dossier historique](docs/audit-initial.md).