Communication

Vue d’ensemble des protocoles

Protocole	Usage	Latence	Portée
ESP-NOW	Nodes ↔ Coordinateur / ESP32-S3 USB bridge	< 10 ms	~50 m intérieur
WebSocket natif	SimPilot ↔ SimServer	< 50 ms	WiFi
WebSocket	SimPilot ↔ Coordinateur (mode simple)	< 50 ms	WiFi AP
MQTT	Bus d’événements inter-services (Docker)	< 10 ms	Localhost / réseau
WebRTC	SimCam (smartphone) → SimServer	~100 ms	WiFi
RTSP	Caméras IP PoE → SimServer (go2rtc)	~200 ms	Ethernet
HLS	SimServer → Navigateur (débriefing)	2-6 s	WiFi / HTTP
USB série (JSON lines)	ESP32-S3 USB bridge → Machine hôte	< 5 ms	Câble USB-C
REST API	SimPilot / SimServer → SaaS (cloud)	Variable	Internet

Schéma des flux par mode

Mode Simple

Sans SimServer, le coordinateur ESP32-S3 est le hub central.

graph TB
    Coord["Coordinateur ESP32-S3"]
    Coord -->|WiFi AP<br/>192.168.4.1| SimPilot["Tablette (SimPilot)"]
    Coord <-->|ESP-NOW<br/>broadcast| Nodes["Nodes (DAE, Scope)"]
    Coord -->|WebSocket<br/>port 81| Debug["Page web debug"]

    style Coord fill:#9b59b6,color:#fff
    style SimPilot fill:#50b87a,color:#fff
    style Nodes fill:#d94a4a,color:#fff

Mode SimServer

SimServer (Docker) remplace le coordinateur comme hub. L’ESP32-S3 USB bridge branché en USB-C communique avec les nodes via ESP-NOW.

graph TB
    subgraph studio_box["SIMSERVER (Docker)"]
        API["SimServer API<br/>(FastAPI)"]
        MQTT["Mosquitto<br/>(MQTT)"]
        Caddy["Caddy<br/>(TLS)"]
        API <--> MQTT
        Caddy --> API
    end
    USB["ESP32-S3 USB bridge"] <-->|USB série<br/>JSON lines| API
    USB <-->|ESP-NOW| Nodes["Nodes"]
    Caddy <-->|WebSocket| SimPilot["SimPilot (Pad)"]
    API <--|RTSP / USB| Cam["Caméras IP / USB"]
    API <--|WebRTC| SimCam["SimCam (smartphone)"]

    style studio_box fill:#4a90d9,color:#fff
    style SimPilot fill:#50b87a,color:#fff
    style Nodes fill:#d94a4a,color:#fff
    style SimCam fill:#e8a838,color:#fff
    style USB fill:#9b59b6,color:#fff

ESP-NOW

Protocole principal entre les nodes et le coordinateur / ESP32-S3 USB bridge.

Caractéristiques

• Pair-à-pair, sans connexion WiFi requise
• Latence typique : < 10 ms
• Portée : ~50 m en intérieur
• Taille max : 250 octets par message
• Pas de garantie de livraison (best effort)

Isolation multi-kits

3 kits peuvent fonctionner simultanément dans la même salle :

Kit	Canal WiFi	Group ID
Kit 1	1	1
Kit 2	6	2
Kit 3	11	3

Format de message

[Magic 0x53][Version][Type][Group][Payload JSON max 246 bytes]

Voir SimComm pour le détail du protocole.

WebSocket (SimPilot ↔ SimServer)

Communication bidirectionnelle en temps réel entre le SimPilot et SimServer via WebSocket natif (pas de bibliothèque SocketIO). La connexion passe par Caddy (TLS) en production.

Événements SimServer → SimPilot

// Mise à jour des paramètres vitaux
{ "event": "vitals:update", "data": { "hr": 72, "spo2": 98, "nibp": "120/80", "rr": 16 } }

// État du scénario
{ "event": "scenario:state", "data": { "state": "running", "step": 3, "elapsed": 180 } }

// Liste des dispositifs connectés
{ "event": "devices:update", "data": { "devices": [...] } }

// État d'enregistrement
{ "event": "recording:state", "data": { "recording": true } }

// Liste des caméras
{ "event": "cameras:update", "data": { "cameras": [...] } }

Événements SimPilot → SimServer

// Démarrer un scénario
{ "event": "scenario:start", "data": { "scenarioId": "acr-fv-adulte" } }

// Modifier un paramètre vital
{ "event": "vitals:override", "data": { "param": "hr", "value": 120 } }

// Déclencher un événement
{ "event": "event:trigger", "data": { "type": "shock", "energy": 200 } }

// Poser un marqueur
{ "event": "marker:add", "data": { "label": "Intubation", "timestamp": 1234567890 } }

Note

Le format des messages JSON est identique à l’ancien protocole SocketIO, mais transporté sur WebSocket natif. Cela simplifie l’architecture (pas de dépendance SocketIO côté client et serveur) tout en conservant la compatibilité des structures de données.

WebSocket (SimPilot ↔ Coordinateur)

En mode simple (sans SimServer), le SimPilot communique avec le coordinateur ESP32-S3 via WebSocket natif.

Endpoint

ws://192.168.4.1:81

Messages JSON

// SimPilot → Coordinateur
{ "cmd": "start", "scenario": "acr-fv-adulte" }
{ "cmd": "trigger", "event": "shock" }
{ "cmd": "override", "param": "hr", "value": 120 }

// Coordinateur → SimPilot
{ "type": "vitals", "hr": 72, "spo2": 98, "rr": 16 }
{ "type": "device", "id": "dae-01", "state": "ANALYZING" }
{ "type": "event", "name": "shock_delivered", "energy": 200 }

USB série (ESP32-S3 ↔ SimServer)

Communication entre l’ESP32-S3 USB bridge et la machine hôte via câble USB-C. Le bridge est un petit PCB 2 couches (~40x25 mm, ~5 EUR) qui fait le pont entre le réseau ESP-NOW et SimServer.

Caractéristiques

• Interface : USB-C (USB CDC-ACM, apparaît comme /dev/ttyACM0)
• Débit : 115200 baud
• Format : JSON lines (une ligne JSON par message, terminée par \n)
• Direction : bidirectionnel

Format des messages

// ESP32-S3 → SimServer (paramètres vitaux reçus d'un node)
{"type":"vitals","device":"dinamap-01","hr":72,"spo2":98,"nibp":"120/80","rr":16}

// ESP32-S3 → SimServer (annonce d'un dispositif)
{"type":"announce","device":"dae-01","deviceType":"dae","capabilities":["shock","analyze"]}

// ESP32-S3 → SimServer (événement d'un node)
{"type":"event","device":"dae-01","name":"shock_delivered","energy":200}

// SimServer → ESP32-S3 (commande à relayer via ESP-NOW)
{"cmd":"start","scenario":"acr-fv-adulte","group":1}
{"cmd":"override","param":"hr","value":120,"group":1}
{"cmd":"stop","group":1}

Astuce

Le format JSON lines simplifie le parsing : chaque ligne est un message JSON complet. Pas de framing binaire, pas de longueur préfixée — juste du texte ligne par ligne.

MQTT (Bus d’événements inter-services)

Le broker Eclipse Mosquitto assure la communication entre les services Docker de SimServer. Il sert de bus d’événements interne.

Rôle

• Découplage entre les services (API, enregistrement, vidéo, bridge USB)
• Publication/souscription pour les événements de simulation
• Persistance des messages QoS 1 pour la fiabilité

Topics principaux

Topic	Éditeur	Description
sim/vitals/{deviceId}	USB bridge service	Paramètres vitaux en temps réel
sim/devices	USB bridge service	Annonces et état des dispositifs
sim/scenario/state	API	État du scénario (running, paused, stopped)
sim/recording/state	API	État d’enregistrement
sim/commands/{group}	API	Commandes à relayer aux nodes via ESP-NOW
sim/cameras/{cameraId}	go2rtc / API	État des flux caméras

Note

MQTT est utilisé uniquement en interne entre les conteneurs Docker. Les clients externes (SimPilot, SimCam) communiquent via WebSocket avec l’API FastAPI, qui publie/souscrit sur MQTT en interne.

WebRTC (SimCam → SimServer)

Les smartphones envoient leur flux vidéo à SimServer via WebRTC (préféré).

Signalisation WebSocket

// SimCam → SimServer (enregistrement)
{ "event": "camera:register", "data": { "deviceId": "phone-01", "capabilities": {...} } }

// SimServer → SimCam (configuration)
{ "event": "camera:config", "data": { "resolution": "720p", "framerate": 30 } }

// SimCam → SimServer (état)
{ "event": "camera:status", "data": { "battery": 85, "streaming": true } }

La signalisation WebRTC (offre SDP, réponse SDP, candidats ICE) passe par la connexion WebSocket entre SimCam et SimServer.

API REST du coordinateur

En mode simple, le coordinateur expose une API REST minimale :

Endpoint	Méthode	Description
/api/state	GET	État courant de la simulation
/api/devices	GET	Liste des dispositifs connectés
/api/scenarios	GET	Scénarios disponibles
/api/scenario/start	POST	Démarrer un scénario
/api/scenario/stop	POST	Arrêter la simulation

Auto-découverte

Astuce

Tous les appareils s’annoncent automatiquement sur le réseau. Aucune configuration manuelle n’est nécessaire.

Appareil	Mécanisme de découverte
Nodes ESP32	Broadcast ESP-NOW ANNOUNCE à intervalles réguliers
SimPilot	Connexion mDNS ou WiFi AP dédié
SimCam	Enregistrement WebSocket avec type camera
SimServer	Agrège toutes les découvertes, maintient le registre centralisé