AudioLevelsServer s'auto-attachait à l'événement 'upgrade' du serveur HTTP
via la lib ws (server + path), en plus du listener manuel du proxy LiveKit.
Pour toute connexion /livekit, les deux listeners s'exécutaient : le proxy
LiveKit aboutissait bien côté upstream, mais le listener ws (path
/audio-levels ne matchant pas) appelait abortHandshake(socket, 400) sur le
même socket juste après, cassant la connexion côté client en HTTPS prod.
AudioLevelsServer passe maintenant en noServer: true et expose
handleUpgrade(), appelée par un dispatcher 'upgrade' unique dans
server/index.js qui route explicitement par chemin (/livekit vs
/audio-levels).
Ajout de certs/ au .gitignore (clés privées SSL locales mkcert).
http-proxy-middleware ne gere pas correctement WebSocket upgrade avec HTTPS.
Utilisation de http-proxy natif pour proxy direct WSS vers WS.
Modifications:
- Remplacement createProxyMiddleware par httpProxy.createProxyServer
- Gestion native de l'upgrade WebSocket
- Reecriture URL /livekit -> / pour LiveKit
- Logs info niveau pour debug facilite
Permet au client PWA charge en HTTPS de se connecter a LiveKit via proxy WSS.
Modifications:
- server/index.js: ajout proxy http-proxy-middleware
- Route /livekit proxie vers http://localhost:7880
- Upgrade WebSocket active pour le proxy
- server/package.json: ajout dependance http-proxy-middleware
Fonctionnement:
- Client HTTPS se connecte a wss://localhost:3000/livekit
- Serveur Express proxie vers ws://localhost:7880
- Resout probleme mixed content (HTTPS ne peut pas WS)
Problème résolu : certificats self-signed bloqués par navigateurs
Solution : mkcert génère certificats automatiquement approuvés
- CA locale installée sur système
- Certificats signés par cette CA
- Navigateurs font confiance automatiquement
- Pas de warnings SSL
- 100% local, pas de cloud/domaine
Nouveau script : setup-certificates.sh
- Installe mkcert (Homebrew/apt)
- Installe CA locale (mkcert -install)
- Détecte IP réseau automatiquement
- Génère certificats localhost + IP + *.local
- Configure server/.env (SSL_CERT, SSL_KEY)
- Configure client/.env (VITE_SERVER_URL)
- Met à jour vite.config.js avec HTTPS
Serveur modifié : server/index.js
- Lit certificats depuis process.env.SSL_CERT/SSL_KEY
- Fallback : ../certs/localhost.pem
- Message erreur si certificats introuvables
Documentation :
- SSL-SETUP.md : guide complet installation manuelle/auto
- SSL-SOLUTION.md : résumé technique
- README.md : ajout étape setup-certificates.sh
Résultat :
- Cadenas vert sur desktop (Chrome/Safari/Firefox)
- WebRTC fonctionne en HTTPS
- Smartphones : accepter certificat une fois (normal)
- Valable 10 ans, pas de renouvellement
Usage : ./setup-certificates.sh (2 minutes)
Ensuite : ./start.sh --dev ou ./start-desktop.sh
Filtrage des logs :
- LIVEKIT_LOG_LEVEL=info au lieu de debug
- Suppression logs DEBUG, signal requests/responses
- Garde uniquement INFO, WARN, ERROR importants
Rend les logs bien plus lisibles pour le debug applicatif.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Linux : utilise server/bin/livekit-server (installé par install.sh)
- macOS : utilise livekit-server du PATH (Homebrew)
- Corrige erreur 'livekit-server: not found' sous Linux
- Création d'un apiRouter Express pour toutes les routes API
- Routes montées sous /api ET à la racine (rétrocompatibilité)
- QR code corrigé : HTTPS en mode production
- start.sh : affichage URL HTTPS corrigé
- Résout le problème de connexion en mode production
- Ajout support HTTPS au serveur Express avec certificats auto-signés
- Variable d'environnement ENABLE_HTTPS pour activer/désactiver HTTPS
- start.sh active automatiquement HTTPS en mode production (pas --dev)
- Messages d'aide clarifiés avec URLs HTTPS et avertissement certificat
- WebSocket Audio Levels supporte wss:// en mode HTTPS
Mode dev : HTTPS sur port 5173 (Vite) + HTTP API sur 3000
Mode prod : HTTPS sur port 3000 (Express sert client + API)
- Création show-qr.sh : génère et affiche QR code avant lancement serveur
- Détection auto mode dev/prod pour URL correcte
- start.sh appelle show-qr.sh puis lance serveur silencieusement
- Logs serveur uniquement dans server.log (terminal propre)
- Suppression génération QR dans server/index.js (plus nécessaire)
- Suppression dépendance qrcode-terminal dans server (utilisé via npx dans show-qr.sh)
1. Messages finaux install scripts
- Mise en avant de ./start.sh (recommandé)
- Méthode manuelle en alternatif
- Port production corrigé (3000 au lieu de 5173)
2. Serveur statique production (server/index.js)
- Sert client/dist/ si build existe
- Route / serve index.html en production
- Mode dev : retourne info API JSON
- Permet ./start.sh mode prod fonctionnel
Fix issues identifiés : messages obsolètes + production non fonctionnelle.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Corrections pour le routing audio carte son → LiveKit :
**Fixes audio backend**
- AudioBridgeManager : extraction des device IDs depuis config.audio.device
- AudioBridge : ajout résolution device ID → device name pour CoreAudio/sox
- CoreAudioBackend : correction index args sox capture (args[2] au lieu de args[1])
**Résultat**
- ✅ Sox capture fonctionne : lit depuis "Microphone MacBook Pro"
- ✅ Audio capturé et envoyé vers routing
- ❌ Sox playback se ferme après 0.2s (problème persistant à corriger)
**Autres modifications**
- Logging centralisé (Logger.js)
- IP corrigée : 192.168.0.146
- Suppression système channels[] legacy dans groupes
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Probleme: Client tentait de se connecter a ws://localhost:3001 mais serveur n'avait pas de WebSocket demarre
Solution:
- Ajout import AudioLevelsServer dans server/index.js
- Demarrage WebSocket sur meme port que l'API REST (3000)
- Correction port dans useAudioLevels.js (3000 au lieu de 3001)
Le WebSocket audio-levels fonctionne maintenant pour monitoring temps reel
- ConfigManager: gestionnaire centralisé config avec EventEmitter
- AudioBridgeManager: gestion bridge avec auto-reload sur changement config
- Intégration dans serveur principal (index.js)
- Événements 'audio-device-updated' et 'config-updated'
- Reload automatique du bridge sans redémarrer serveur
- Mode placeholder pour développement (vrai bridge Phase 3)
Simplification majeure de la configuration des groupes :
- Suppression des champs redondants 'id' et 'description'
- Le nom du groupe sert maintenant d'identifiant (converti en slug automatiquement)
- Génération automatique des IDs pour groupes et canaux via fonction slugify()
Backend (server/) :
- Ajout fonction slugify() pour génération d'IDs à partir des noms
- Génération automatique des IDs au chargement de la config (index.js)
- API admin adaptée : POST/PUT /admin/groups génèrent les IDs automatiquement
- Pas besoin de fournir l'ID lors de la création/modification
Frontend (client/src/Admin.jsx + Admin.css) :
- Suppression champs ID et description du formulaire
- Simplification interface : nom + bitrate + canaux
- Mise à jour layout CSS canal (4 colonnes au lieu de 5)
- Cartes de groupe épurées (plus d'affichage d'ID)
Configuration (config.yaml) :
- Format simplifié : groupes avec 'name', 'channels' et 'audioBitrate' optionnel
- Exemple : "Production" au lieu de id/name/description séparés
- Plus lisible et maintenable
Les IDs sont générés dynamiquement :
- Groupe "Production" → id: "production"
- Canal "Principal" → id: "production-principal"
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Implémentation complète de l'interface d'administration web :
Backend (server/api/admin.js) :
- Endpoints CRUD pour gestion des groupes (GET/POST/PUT/DELETE /admin/groups)
- Gestion utilisateurs connectés en temps réel (GET/DELETE /admin/users)
- Monitoring statistiques système (GET /admin/stats)
- Affichage logs serveur avec filtrage (GET /admin/logs)
- Configuration audio globale (PUT /admin/config/audio)
- Système de tracking des connexions/déconnexions
- Export fonctions registerUser, unregisterUser, addLog
Frontend (client/src/Admin.jsx + Admin.css) :
- Interface admin complète avec 4 onglets (Groupes, Utilisateurs, Stats, Logs)
- Gestion groupes : création, modification, suppression avec formulaires
- Gestion canaux audio par groupe (inputs/outputs)
- Liste utilisateurs connectés avec déconnexion forcée
- Dashboard statistiques temps réel (connexions, uptime, mémoire)
- Viewer logs avec code couleur par niveau (debug/info/warn/error)
- Rafraîchissement auto toutes les 3s
- Design responsive et mode sombre
Intégration système :
- Routes admin montées sous /admin dans index.js
- Enregistrement automatique des utilisateurs lors de la génération de token
- Logs serveur centralisés dans le système admin
- Routing simple frontend pour /admin (main.jsx)
🎛️ Interface accessible via https://localhost:5173/admin🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Ajout de 3 groupes dans config.yaml : Production, Technique, Sonorisation
- Nouvel endpoint API GET /groups pour lister les groupes disponibles
- Composant GroupSelector.jsx pour changer de groupe pendant la session
- Hook useLiveKit étendu avec fonction switchGroup() pour reconnexion
- Intégration dans App.jsx avec gestion du changement de groupe
- Chaque groupe = 1 room LiveKit distincte
- Qualité audio configurable par groupe (96-128 kbps)
Problème :
Le serveur retournait ws://localhost:7880 aux clients, empêchant
les connexions depuis d'autres appareils sur le réseau.
Solution :
- Ajout détection automatique IP réseau (WiFi/Ethernet)
- Variable LIVEKIT_URL=AUTO pour mode auto-détection
- Fonction getNetworkIP() avec priorité interfaces (en0, en1, eth0, wlan0)
- Affichage IP détectée au démarrage du serveur
- Fallback vers localhost si IP non détectée
Modifications :
- server/index.js : ajout getNetworkIP() et détection AUTO
- server/.env : LIVEKIT_URL=AUTO par défaut
- server/.env.example : documentation modes configuration
- NETWORK_SETUP.md : guide complet configuration réseau et dépannage
Les clients reçoivent maintenant ws://IP_RESEAU:7880 et peuvent
se connecter depuis n'importe quel appareil sur le même réseau WiFi.
Ports utilisés :
- 3000 : API REST
- 7880 : LiveKit WebSocket
- 7882 : LiveKit UDP (RTP)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Support variable PORT en environnement
- Gestion propre de l'erreur EADDRINUSE
- Message d'aide pour utiliser un port alternatif
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Implémentation du serveur Node.js avec intégration LiveKit et API REST complète :
- Serveur Express avec API REST (endpoints /config, /token, /health)
- Génération tokens JWT LiveKit pour authentification clients
- Configuration YAML pour groupes et canaux audio
- Support mode cloud LiveKit (pas de binaire requis pour Phase 1)
- Logging structuré avec niveaux configurables
- Gestion propre du lifecycle (SIGTERM, SIGINT)
Endpoints fonctionnels :
- GET /config : retourne configuration groupes/canaux
- POST /token : génère token LiveKit pour un utilisateur/groupe
- GET /health : health check du serveur
- GET / : informations serveur
Phase 1.2 complétée : Infrastructure serveur opérationnelle
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
benoit