# SPECS APPAREILS CONNECTÉS — Senseurs portables pour EasyPhone

> **Document de référence (source de vérité)** pour le projet **EasyPhone** (projet id 17 sur projets.newappai.com)
> et plus largement pour tout appareil connecté destiné au suivi du senior.
>
> - **Fichier** : `/media/newappai/ssd512/specs-appareils-connectes/SPECS_APPAREILS_CONNECTES.md`
> - **Projet repos associés** : `/media/newappai/ssd512/appareils-connectes/` (14 repos clonés,
>   voir son README.md — bagues / bracelets-montres / brassards)
> - **Version** : 1.1 — **date** : 30/09/2026 (Europe/Paris)
> - **Rédigé par** : Hermes (session hermes-ant)
> - **Objet** : recenser, classer et documenter TOUTES les voies d'accès aux données d'accéléromètre
>   et de signes vitaux des appareils connectés envisagés pour EasyPhone (détection de chute,
>   FC/SpO2, sommeil), avec pour chacune : statut de confirmation, sources, code de référence,
>   limites et plan de test.
>
> **Toute session Hermes (ou outil) qui travaille sur ce sujet doit lire ce document AVANT
> d'agir, et le METTRE À JOUR ici (ne pas créer de doublon ailleurs).** Chaque session ajoute
> une ligne au Journal des mises à jour (§ 11) et incrémente la version.

---

## Légende des statuts

| Statut | Signification |
|---|---|
| ✅ **Confirmé** | Vérifié par au moins une source primaire (code source, doc RE, retour d'un testeur) — souvent 2+ sources indépendantes |
| 🟡 **Probable** | Déduit ou affiché par une seule source non vérifiée ici — à revérifier avant de l'en dépendre |
| ❓ **Inconnu** | Non documenté nulle part — mesurer / tester nous-mêmes |

**Convention de traçabilité (règle Antoine)** : toute tâche du board projets.newappai liée à ce
document porte en fin de description `[OUTIL: …]` (fait) ou `[OUTIL PRÉVU: …]` (à faire).

---

## Table des matières

1. [Synthèse décisionnelle](#1-synthèse-décisionnelle)
2. [Anneaux Colmi — famille R02 (principal candidat)](#2-anneaux-colmi--famille-r02)
   - 2.1 Modèles et compatibilité
   - 2.2 Protocole standard (UART, trames, CRC)
   - 2.3 Ce que lit le « client standard » (et ce qu'il ne lit pas)
   - 2.4 🔑 Flux brut accéléromètre — commande 0xA1 (LA voie principale)
   - 2.5 Canal « Big Data » (RingCLI Go) — historique traité
   - 2.6 Firmwares modifiés (débits élevés)
   - 2.7 Limites pour la détection de chute
3. [JCVital / Joint Chinese Ltd (bracelets)](#3-jcvital--joint-chinese-ltd)
4. [Autres candidats étudiés](#4-autres-candidats-étudiés)
5. [Algorithme de détection de chute — spec](#5-algorithme-de-détection-de-chute--spec)
6. [Architecture EasyPhone proposée](#6-architecture-easyphone-proposée)
7. [Plan de tests à réaliser](#7-plan-à-réaliser)
8. [Interdits mode Famille (à respecter impérativement)](#8-interdits-mode-famille)
9. [Glossaire](#9-glossaire)
10. [Sources & liens](#10-sources--liens)
11. [Journal des mises à jour](#11-journal-des-mises-à-jour)

---

## 1. Synthèse décisionnelle

**Question** : peut-on récupérer les données d'accéléromètre d'un anneau Colmi pour la
détection de chute dans EasyPhone ?

**Réponse : OUI — et sans flasher le firmware.**

| Voie | Ce qu'elle donne | Statut | Verdict EasyPhone |
|---|---|---|---|
| **A. Commande 0xA1 sur firmware d'origine** | Stream temps réel X/Y/Z ±4 g | ✅ Confirmé (3 implém. indépendantes, dont Dart/Flutter) | **✅ À retenir** — sans risque, réutilisable tel quel en Flutter |
| **B. Firmware mod (débit ×N)** | 352 Hz au lieu de ~25 Hz | ✅ Confirmé (mais risque de brick réel) | ❌ **Inutile pour la chute** (un événement 0,2–2 s se détecte à ~25 Hz) — réservé typing/gestes fins |
| **C. Canal Big Data (RingCLI)** | Hypnogramme, SpO2 24 h, FC horodatée, pas | ✅ Confirmé | ⚠️ **Pas d'accéléromètre** — utile pour FC/SpO2/sommeil offline uniquement |
| **D. JCVital V8/V6 (SDK BLE + Cloud REST)** | ECG, SpO2, FC, température, accel 3D (V6 : bouton SOS physique + GPS) | 🟡 Probable (site fabricant + échange email 28/09/2026, samples non encore reçus) | 🟡 Backup si l'anneau ne suffit pas — **V6 4G** = seul autonom hors portée Bluetooth |

**Limite dure à connaître (§ 2.7)** : l'anneau Colmi **ne stocke aucun historique
d'accéléromètre** → le téléphone EasyPhone doit être en portée BLE au moment de la chute.

---

## 2. Anneaux Colmi — famille R02

### 2.1 Modèles et compatibilité

| Modèle | Compat client open (tahnok) | Remarques |
|---|---|---|
| **Colmi R02** | ✅ Fully compatible | Cible principale des RE (20 $). Firmware variants : `R02_3.00.17_240903` (hw `R02_V3.0`) et `RY02_3.00.33_250117` (hw `RY02_V3.0`) — **les deux ne proposent pas les mêmes services GATT** (device info complet vs partiel + service inconnu en plus) |
| **Colmi R06** | ✅ Fully compatible | Repo Dart `colmi_r06_fbp` écrit dessus |
| **Colmi R10** | ✅ Fully compatible | |
| **R01/R03/R04/R05/R07** | 🟡 reconnus par les préfixes de scan | R03 testé par l'auteur de colmi-docs pour le canal Big Data |
| Clone/génériques (VK-5098, MERLIN, Hello Ring, RING1, boAtring, TR-R02, EVOLVEO, GL-SR2, Blaupunkt, KSIX RING, COLMI…) | 🟡 détectés par préfixe | Non testés pour le raw |

- **Pas de binding ni de clé BLE** pour parler au ring (mais portée très courte — c'est aussi
  une faiblesse sécurité : n'importe qui peut lire vos pas/FC à proximité).
- Toutes les trames font **16 octets**, écrites sur la characteristic RX, réponses sur la TX.
- Chaque trame : `octet0 = commandId (7 bits + 1 bit erreur)`, `octets 1..14 = payload`,
  `octet15 = CRC = somme(octets 0..14) & 0xFF`.

### 2.2 Protocole standard (UART-like)

```
Service : 6e40fff0-b5a3-f393-e0a9-e50e24dcca9e
  Write  (requests)  : 6e400002-b5a3-f393-e0a9-e50e24dcca9e
  Notify (responses) : 6e400003-b5a3-f393-e0a9-e50e24dcca9e

struct Command { uint8_t commandId; uint8_t data[14]; uint8_t crc; }
crc = (somme de commandId et des 14 octets de data, entier large) & 0xFF
```

Commandes connues du set « historique » (probablement le 1er characteristic ajouté) :
`01` set time, `02` caméra/gestes, `03` batterie, `04` nom téléphone, `16` intervalle FC,
`2c/2f/36` préférences monitoring, `50` greenLight, `69` heartSpo2Stress, `73` général,
**`a1` (161) raw sensors** (voir § 2.4), `44` (68) sleep data (nouveau, côté Big Data)…

### 2.3 Ce que lit le « client standard » (et ce qu'il ne lit pas)

Client officieux : **`tahnok/colmi_r02_client`** (Python, 100 % offline, MIT).
Statut de reverse-engineering déclaré :

- ✅ FC temps réel + SpO2 temps réel
- ✅ Logs de pas
- ✅ Logs FC (mesure périodique) + fréquence d'échantillonnage
- ✅ Réglage heure du ring
- ❌ Logs SpO2 (partiellement — RingCLI les lit, voir § 2.5)
- ❌ Suivi sommeil (idem — RingCLI 0.1.3+ le lit)
- ❌ Mesure « stress »
- ❌ **Accéléromètre** — NON parce que le hardware ne le donne pas, mais parce que **la
  commande n'est pas implémentée** dans ce client. Elle existe (§ 2.4).

Le client a une commande d'échappement `raw` (`colmi_r02_client --command N --subdata HEX`)
qui permet d'envoyer n'importe quelle commande brute → **utilisable immédiatement pour tester
la commande A1 sans attendre d'implémentation propre.**

### 2.4 🔑 Flux brut accéléromètre — commande 0xA1 (161)

**Statut : ✅ Confirmé — firmware d'origine AUCUNEMENT modifié.**

Preuve : dans la PR « Add RawSensors Command » du repo `Puxtril/colmi-docs`, le testeur
écrit mot pour mot : *« I haven't messed or touched the firmware on this ring at all since I
got it. It runs exactly the stock firmware »* — et le flux fonctionne. Recoupé par un
3ᵉ testeur (Kindle, C/Go) et par un 4ᵉ (script Python, issue #59 tahnok) et un 5ᵉ
(Dart/Flutter, repo R06).

#### Activation / désactivation

```python
# Trame 16 octets, CRC = sum(bytes[0..14]) & 0xFF, remplissage par zéros
START_RAW = bytes.fromhex("A10404")   # → trame [A1 04 04 00 ... 00, CRC]
STOP_RAW  = bytes.fromhex("A102")     # → trame [A1 02 00 ... 00, CRC]
```

1. Se connecter au service UART (aucun pairing requis au-delà du pairing OS basique)
2. `start_notify` sur `6e400003-…`
3. Écrire `A10404` (trammé) sur `6e400002-…`
4. Lire les notifs 16 octets et dispatcher selon `data[1]`

#### Format des notifications

```
data[0] = 0xA1 (echo commande)
data[1] = sous-type :
    0x01 = SpO2    (LED rouge + photodétecteur)  — statique/porté sans mouvement chez certains testeurs
    0x02 = PPG     (LED verte + photodétecteur)  — varie si on balance la main pendant le flash LED
    0x03 = ACCÉLÉROMÈTRE  ← ce qui nous intégrave
data[2..7] = valeurs accel (voir ci-dessous)
data[8..14] = réservé/autres
data[15] = CRC
```

**Pas de façon de ne s'abonner qu'à un sous-type** : on lit tout et on ignore les types 1/2.

#### Décodage accéléromètre (octets 2→7)

Ordre dans la trame : **Y, Z, X** (12 bits signés chacun, entrelacés high/low) :

```python
def int12(u):           # 12 bits signés
    return u - 4096 if u > 2047 else u

rawY = int12(((b[2] << 4) | (b[3] & 0x0F)) & 0x0FFF)
rawZ = int12(((b[4] << 4) | (b[5] & 0x0F)) & 0x0FFF)
rawX = int12(((b[6] << 4) | (b[7] & 0x0F)) & 0x0FFF)

# Plage ±4 g, 12 bits → 1 g = 512 units
g_x = rawX / 512.0     # = (raw/2048)*4
g_y = rawY / 512.0
g_z = rawZ / 512.0
```

**Axes physiques quand l'anneau est porté** (source : `colmi_r06_fbp/lib/colmi_ring.dart`) :
- **Z** = axe passant par le centre de l'anneau (≈ radial au doigt)
- **Y** = tangent à l'anneau
- **X** = vertical quand le doigt est pointé vers le bas
- À plat, repos : |Z| ≈ 1 g (512 units), sens selon face haute.

**Exemple de trame réelle** (repo Dart) :
`[161, 3, 0, 12, 31, 6, 251, 3, 0, 0, 0, 0, 0, 0, 0, 211]` → type 3, Y/Z/X décodés.

#### Comportements connus / pièges

| Piège | Détail | Contournement |
|---|---|---|
| **Flux qui se « bloque »** | Payload identique alors qu'on bouge (observé surtout Kindle/stack BLE exotique) | Unsubscribe → écrire `A102` → réécrire `A10404` → resubscribe. Corrige dans la quasi-totalité des retours |
| **SpO2/PPG figés** | Payloads identiques en permanence chez 1 testeur (valeurs manifestement mal parsées aussi : `Spo2:1605`…) | Normal pour nous : on ne lit QUE le type 0x03 |
| **LEDs qui restent allumées** | Les types 1/2 allument les LEDs → drain | Trame stop `A102` à la fin ; `0206` (disable camera feedback) en secours ; dernier recours reboot `08` |
| **Double-read** | Le même échantillon peut être livré 2 fois (leRE du 352 Hz s'est fait avoir 4 fois) | Dé-dupliquer / horodater côté app, ne jamais dériver le débit d'un simple compteur de callbacks |
| **Connexion déjà établie par l'app QRing** | Le ring n'accepte qu'une session central | Fermer l'app officielle avant (message d'Edge Impulse : « ring disconnected from previous connections ») |

#### Débit

- ❓ **Débit exact sur firmware stock : non mesuré de façon fiable à ce jour.**
  - L'auteur du patch 352 Hz affirme : *« the vendor protocol is a dead end for rate »*
    (le protocole d'origine est une impasse pour le débit).
  - Sa table de résultats mentionne une config de comparaison à **25 Hz** — ordre de
    grandeur plausible, mais ce n'est PAS une mesure publiée du stock.
  - L'outil communautaire `nosh118/colmi-ring-tools` affiche le **« Raw Rate » en Hz en
    direct** pendant le stream → **c'est l'instrument de mesure à utiliser** (§ 7, test T1).
- 🟡 **Suffisant pour la chute** : une chute se décompose en chute libre (200–600 ms),
  impact (<100 ms), immobilisation (>30 s). Même à 10–25 Hz, l'impact et la fenêtre de
  chute libre sont échantillonnés. Le 352 Hz n'est requis QUE pour du fine-motor
  (typing, gestes).

#### Références de code prêtes à l'emploi

| Langage | Repo | Élément | Réutilisable dans EasyPhone ? |
|---|---|---|---|
| **Dart / Flutter** | `CitizenOneX/colmi_r06_fbp` | `lib/colmi_ring.dart` : enum `RawSensorSubtype`, `parseRawAccelerometerSensorData(List<int>)` → `(rawX, rawY, rawZ)` | ✅ **OUI — quasi tel quel** (EasyPhone est en Flutter + flutter_blue_plus probable) |
| Python | `tahnok/colmi_r02_client` issue #59 (ZBZFirst) | Script complet : scan, framed_command, decode_type3_motion, taux en live, start/stop | ✅ Pour le banc d'essai PC/Mi 10T Lite (test T1) |
| Python | `edgeimpulse/example-data-collection-colmi-r02` | `ring.py` : logging accel+PPG+SpO2, resample, plot, upload Edge Impulse | ✅ Pour collecter un jeu d'entraînement de chutes |
| C / Go | PR `Puxtril/colmi-docs#2` | Structs RawSensors + test Kindle | Référence doc |
| Web JS | `nosh118.github.io/colmi-ring-tools` | Web Bluetooth live + mesure Raw Rate | ✅ Mesure du débit sans installer quoi que ce soit |
| Go | `smittytone/RingCLI` | Canal Big Data (§ 2.5) | Sync historique vitaux |

### 2.5 Canal « Big Data » (RingCLI Go) — historique traité

**Statut : ✅ Confirmé pour son contenu — ❌ aucun accéléromètre.**

- Deuxième characteristic séparée (docs : `colmi.puxtril.com/commands/` distingue le set
  « historique » — *« some commands here have newer versions in Big Data »* — et le set
  Big Data lui-même).
- **Contenu** : données **déjà agrégées par le firmware** :
  - 🆕 Hypnogramme / sommeil structuré (commande `68` / `0x44` `SleepDataRequest {dayOffset, …}`
    côté historique, version « newer request in Big Data »)
  - 🆕 SpO2 sur 24 h (RingCLI `data spo2 --full` = toutes les valeurs disponibles)
  - FC horodatée du jour (`data heartrate`), FC temps réel (`--realtime`), réglage
    périodicité FC (`utils heartrate --period 60 --enable`)
  - Pas, heure, batterie, binding
- **Utilité EasyPhone** : sync offline FC/SpO2/sommeil quand le téléphone revient à portée
  (dashboard Famille, tendances). **Ne sert PAS à la chute** : il n'existe AUCUNE commande
  d'historique d'accéléromètre dans toute la doc RE (vérifié sur colmi.puxtril.com) —
  le ring ne conserve pas les samples bruts.
- Avertissement firmware du README RingCLI : les R02 sortent avec des firmwares différents
  (3.00.17 vs 3.00.33) qui n'exposent **pas les mêmes services GATT** → tester avant de
  promettre une feature.

### 2.6 Firmwares modifiés (débits élevés)

**Statut : ✅ Confirmé que ça existe et que ça marche — ✅ confirmé que ça peut bricker.**

| Firmware | Source | Cible | Effet | Risque |
|---|---|---|---|---|
| `R02_3.00.06_FasterRawValuesMOD.bin` | repo `edgeimpulse/example-data-collection-colmi-r02` | R02 | Débits raw plus élevés — « highly recommended » par Edge Impulse pour le data collection | Flash Web Bluetooth (ATC_RF03 writer) — même ordre de risque que ci-dessous |
| `rt02r-low-latency.bin` | `nosh118.github.io/colmi-ring-tools` (catalogue) | **RT02R uniquement** | « Improves raw motion streaming for smoother MIDI control » | Outil officiel du catalogue = voie la plus sûre ; exige type exact + batterie ≥ 20 % |
| Images patchées **352 Hz** (`firmware/` : `build.py`, vérificateur, SHA auto-asserté) | `lachlanmcalpine/colmi-ring` | RT02CR / R02 (silicium RTL8762E) | **352 Hz non filtré / 270 Hz filtré** (mesurés via bit NEW-data reg 0x02 bit 0), 4 samples/notif ≈ 90 notifs/s, compteur de drop en `pkt[63]` | ⚠️ **Ring brické pendant le dev** (injection exécutée au boot avant connexion BLE → GATT corrompu, irrécupérable). Le repo documente la règle : *« an injection must never fire before a connection exists »*. Images = firmware COMPLET (pas des patches) → une mauvaise image = brick |
| — | atc1441 (mentionné par tahnok) | certains SoC | flasher historique | 🟡 « my SoC is not compatible with the atc html firmware flasher » (issue #59) → **compatibilité SoC à vérifier AVANT** |

**Détails techniques du patch 352 Hz** (utile si on y va un jour) :
- Capteur = **STK8BA50** (datasheet : ADC 2 kHz « non filtré », driver Linux STK8BA50 implique
  1792) — mais **mesuré sur la puce réelle : plafond 352 Hz**, la FIFO reste en bypass
  count=1 (tentatives d'accumulation : 4 échecs documentés). Deux documents d'usine
  d'accord ≠ une mesure sur la puce qu'on a en main.
- Registre `0x13` bit 7 (`DATA_SEL`) = chemin non filtré → +30 % (270 → 352). Bit 6
  (`PROTECT_DIS`) = MAUVAISE idée (211 Hz + reads déchirés), documenté pour ne pas retomber dedans.
- SoC = **RTL8762E, Cortex-M0 (ARMv6-M)** → aucune instr `movw/movt/add.w`, constantes
  construites en `movs/lsls/adds` (le builder `m0_scan` rejette automatiquement).
- Le ring RT12COL « qui ment sur son matos » = en réalité le **mêmes silicium RTL8762E**,
  étiquette cosmétique — testé par un flash direct d'image connue-good (retour `RT02CR_V3.1`
  byte-identique).

**Décision retenue pour EasyPhone** : ⛔ **ne pas flasher.** Le débit stock suffit à la
chute ; le gain 352 Hz ne concerne que le typing/gestes ; le risque de brick + la
perte de garantie + l'incompatibilité de variants ne se justifient pas.

### 2.7 Limites pour la détection de chute

1. **❌ Aucun historique accel dans l'anneau** (✅ confirmé : aucune commande de log accel
   documentée, ni dans le set historique, ni dans Big Data) → **le téléphone doit être en
   portée BLE (~ quelques mètres) au moment de la chute.** Chute hors portée = non détectée.
   - Portée : très courte (le client officiel la décrit comme « really tiny », ce qui est
     assumé comme trade-off sécurité). ❓ **à mesurer** (test T3).
2. **Autonomie vs streaming continu** : l'anneau est vendu pour ~5-7 j (R02). Un notify
   continu (même 10/s) peut impacter fortement l'autonomie. ❓ **à mesurer** (test T2).
3. **Pas de détection embarquée dans l'anneau** : aucun compute local chez Colmi (pas de
   « fall detection » firmware) → toute l'intelligence est côté EasyPhone (§ 5).
4. **Une session BLE à la fois** : impossible de streamer via EasyPhone ET garder l'app
   QRing connectée.
5. **Variants firmware** : le même modèle expose des services GATT différents (§ 2.1) →
   le code client doit **tolérer l'absence** de la commande A1 (fallback : dire
   « détection de chute indisponible sur cet anneau » et non planter).

---

## 3. JCVital / Joint Chinese Ltd

**Statut : 🟡 Probable** — specs et SDK annoncés sur le site fabricant + emails échangés
(28/09/2026, demande d'échantillons + partenariat envoyée à info@jointcorp.com,
+86-18680390477). **Aucun matériel reçu ni testé à ce jour** → ne rien promettre en interne
avant réception.

### 3.1 Gamme

| Modèle | Forme | Capteurs | SOS | GPS | Autonomie | Intérêt EasyPhone |
|---|---|---|---|---|---|---|
| **JCVital V8** | Bracelet **sans écran** (ECG smart band) | ECG, SpO2, FC/HRV, température, **accéléromètre 3D**, IP68, BT 5.4 | ❌ physique | ❌ (BLE only) | 15+ j (batt. 180 mAh) | ✅ Cible initiale — le plus discret pour un senior |
| **JCVital V6 4G** | Bracelet 4G autonome | idem + **4G standalone** | ✅ **bouton SOS physique** | ✅ **GPS + géorepères** | 7+ j | ✅ **Seul capable d'alerter hors portée Bluetooth** — si budget le permet |
| **J-Style 2025E** | Smartwatch 1,57" | ECG, SpO2, température, **GPS**, 5 ATM | 🟡 via app | ✅ | 10 j | Variante écran |
| **JCRing X1** | Anneau | SpO2, température, partage santé famille | ❌ | ❌ | 10 j, 5 ATM | Concurrent direct de Colmi mais **SDK fermé/fermé ?** → 🟡 à vérifier |
| **JCRing X3** | Anneau | SpO2 médical-grade, risque OSA | ❌ | ❌ | 7 j | Idem |
| **JCRing X6** | Anneau ultra-fin 2,2 mm | santé féminine | ❌ | ❌ | 7 j | Hors cible senior |

### 3.2 Points d'intégration annoncés (site `jointcorp.com/sdk-api/`)

- **SDK BLE** : Android / iOS / **Flutter** / Windows / macOS / Linux — streaming temps réel
- **Cloud REST API** : OAuth 2.0 + API Key — endpoints
  `/auth`, `/users/{userId}/devices`, `/devices/{deviceId}/ecg|hr|spo2|temp|sleep`
- **Webhook** : alertes push (→ pertinent pour l'alerte chute/ SOS côté serveur EasyPhone)
- **Raw PPG/ECG (mode ODM)** : pour traitement local avancé
- **⚠️ V8 sans détection de chute ni bouton SOS intégrés** (confirmé par le fabricant) →
  l'accéléromètre 3D brut doit être traité par EasyPhone (algo § 5), ou passer par le V6 4G.
- Contact : info@jointcorp.com — **demande d'échantillons en cours (email 28/09/2026)**.

---

## 4. Autres candidats étudiés

| Appareil | Accès capteurs brut | Prix | Statut | Verdict |
|---|---|---|---|---|
| **Hume Band 2.0** | ✅ Protocole **J2208 documenté**, client Python `brendangooden/j2208-band-tools`, **sans auth ni cloud** — HR, HRV, SpO2, température peau, accel (chute), sommeil, strain/recovery, « BP insights » | ~100–150 $ | ✅ Confirmé (repo public) | 🟡 **Meilleur bracelet « sans écran » documenté** — alternative sérieuse au V8 si le Colmi ne suffit pas ; 14 j de batterie |
| **Bangle.js 2** | ✅ Open source total (Espruino/JS) — accel brut, PPG brut, GPS, BLE,programmable | ~80–100 € | ✅ Confirmé | 🟡 Le plus ouvert (idéal R&D) mais forme montre + écran, moins discret, plus cher que le ring 20 $ |
| **Colmi R02/R06/R10** | ✅ voir § 2 | ~20 $ | ✅ Confirmé | ✅ **Retenu** — meilleur rapport discrétion/prix/données |
| **Colmi bands montres (P8/P71…)** | ❌ app fermée « Pubu Wear » | ~20–40 $ | ✅ Confirmé (à éviter) | ⛔ Éviter : protocole fermé, pas de source ouverte |
| **Colmi R02/R03 rings (ancien lien mémoire)** | ✅ client `tahnok/colmi_r02_client` (Python) + `robinojw/openring` (TS) | ~20 $ | ✅ | Couvert § 2 |
| **JCVital V8/V6** | 🟡 SDK annoncé | à négocier | 🟡 En attente échantillons | § 3 |
| **ESP32** | — | — | — | ⛔ Exclu par Antoine (contrainte projet : pas d'ESP32) |
| **Tensso / autres bracelets santé seniors** | ❓ | ❓ | ❓ | Non étudiés — à creuser si besoin |

---

## 5. Algorithme de détection de chute — spec

**Objectif** : détecter une chute du senior à partir du stream accéléromètre (X, Y, Z en g,
~10-25 Hz min / 352 Hz max) et lever une alerte EasyPhone.

### 5.1 États de l'algorithme (3 phases + confirmation)

| Phase | Condition | Fenêtre | Seuil initial 🟡 |
|---|---|---|---|
| **1. Chute libre** | `|a| = sqrt(x²+y²+z²) < 0.5 g` (apesanteur partielle) | ≥ 200 ms | accel totale sous 0,5 g |
| **2. Impact** | `|a| > 2.5 g` (pic de décélération) | dans les 2 s après la phase 1 | 2,5 g (communément 2–4 g selon altitude du lit/fauteuil) |
| **3. Immobilisation** | Variance de `|a|` < 0,1 g² **ET** orientation quasi-constante | ≥ 30 s | variance 0,1 g² |
| **Confirmation** | Phase 1 → 2 → 3 dans un ordre temporel coherent | total < ~35 s | déclenche alerte |

### 5.2 Anti-faux positifs (à implémenter)

- **Ignorer** les secousses isolées (impact sans chute libre = on tape du pied, on pose un
  objet) — l'enchaînement 1→2→3 est le filtre principal.
- **Seuil de durée** : chute libre > 200 ms évite les micro-tirs (le ring au doigt bouge
  beaucoup au quotidien : frapper un clavier, manger…).
- **Contexte sommeil** : pendant les heures de sommeil détectées (données Big Data § 2.5),
  baisser la sensibilité (chutes de lit ≠ activité) OU gérer séparément.
- **Window de grâce** : après une alerte, cooldown 5 min pour ne pas spammer.
- **Calibration terrain** : les seuils ci-dessus sont des points de départ — les affiner
  avec des données réelles collectées (Edge Impulse, § 2.4 « ring.py ») — Antoine a exigé
  des seuils quantifiés, d'où des valeurs chiffrées ici, toutes marquées 🟡 tant qu'elles
  ne sont pas mesurées sur terrain.

### 5.3 Chaîne de traitement côté EasyPhone (Flutter)

```
BLE notify (A1, type 03) → decode 12 bits → (gx, gy, gz) en g
  → magnitude |a| + variance glissante (fenêtre 1-2 s)
  → machine à états (free-fall → impact → immobile)
  → si confirmé : alerte
        ├─ consentement actif ? (cf. § 8) → alerte famille (data channel LiveKit / SMS)
        ├─ sinon : notification locale TTS + boutons OUI/NON (parcours consentement)
        └─ trace SQLite locale + remontée dashboard Famille (lecture API uniquement)
```

### 5.4 Ce qui existe déjà dans EasyPhone (à ne pas réécrire)

- **LiveKit service** : singleton déjà connecté en permanence → canal data channel pour
  les messages famille↔senior (spéc `SPECS_DELTA_CONTACTS_LIVEKIT_APPEL.md`).
- **Rôles + consentement** : `roles_service.dart` (responsible/member/senior,
  `needsSeniorConsent`), `consent_flow_service.dart` (TTS prénom+action → 2 boutons géants
  OUI/NON → expiration = **jamais d'activation**).
- **Check-in / SMS** : `checkin_service.dart` (max 1 SMS, défaut 112 à configurer).
- **Contacts importés** : 2 230 contacts déjà dans l'app (fichier Honor en lecture seule).
- **Règle** : la détection de chute s'ajoute EN PLUS, sans régression du kiosk mode Senior.

---

## 6. Architecture EasyPhone proposée

```
[ANNEAU Colmi R02]                          [TÉLÉPHONE EasyPhone senior]
  accel brut (cmd A1, stock) ──BLE ~25 Hz──▶ flutter_blue_plus
  FC/SpO2/sommeil historisés  ──sync───────▶  SQLite local
                                                 │
                                    algo chute (§ 5) — temps réel
                                                 │
                              ┌──────────────────┴──────────────────┐
                              ▼                                     ▼
                    consentement OK (§8)                  pas de consentement
                    alerte famille :                      → TTS + boutons OUI/NON
                    data channel LiveKit / SMS 112        (expiration = jamais d'activation)
                              │
                              ▼
                    [RESPONSABLE] dashboard Famille (affichage API — jamais de saisie santé
                                                 dans EasyPhone, source = Serinity)
```

**Choix d'architecture (à valider)** :
1. **Traitement 100 % local sur le téléphone** (pas de cloud) → pas de latence, pas de
   coût, respect de la contrainte « local interpretation » d'Antoine.
2. **Pas de nouveau serveur** (règle : pas d'outils dupliqués, zéro coût).
3. **Fallback** : si l'anneau n'est pas connecté → EasyPhone l'affiche honnêtement
   (« détection de chute inactive — anneau hors portée »), jamais de simulation.
4. **Feature générique multi-clients** (règle Antoine) : le service de détection de chute
   s'instancie par famille, rien de codé en dur pour un utilisateur.

---

## 7. Plan à réaliser

| ID | Test | Outils | Critère de succès | Statut |
|---|---|---|---|---|
| **T1** | Mesurer le **débit réel (Hz)** du stream A1 sur firmware stock | `nosh118/colmi-ring-tools` (affiche Raw Rate live) OU script issue #59 tahnok sur Mi 10T Lite / PC | Hz mesuré, consigné dans ce document (§ 2.4) | ⬜ À faire |
| **T2** | **Autonomie batterie** avec streaming continu (24 h) | R02 chargé à 100 %, stream A1 actif en continu, relevé horaire du % | Δ % / 24 h mesuré ; décision go/no-go sur le streaming permanent | ⬜ À faire |
| **T3** | **Portée BLE** réelle (mètres, murs) | R02 + téléphone, mesurer la distance de déconnexion | Portée en m indiquée ici (§ 2.7) | ⬜ À faire |
| **T4** | **Preuve de concept chute** : simuler 10 chutes (lit, fauteuil, marche) + 10 gestes quotidiens (marcher, taper, manger) → collecter via `ring.py` Edge Impulse → entraîner/valider les seuils § 5 | ring.py + Edge Impulse (gratuit) | Taux de détection ≥ 90 % et faux positifs ≤ 1/heure sur les gestes quotidiens | ⬜ À faire |
| **T5** | **Portage Dart** : intégrer `parseRawAccelerometerSensorData` dans un service Flutter EasyPhone (`accel_stream_service.dart`) | repo `colmi_r06_fbp` comme référence | `flutter analyze` = 0 erreur, stream affiché dans une page debug | ⬜ À faire |
| **T6** | **Sync Big Data** : FC/SpO2/sommeil 24 h via RingCLI → dashboard | RingCLI Go (`data spo2 --full`, `data heartrate`, sleep) | Données visibles dans le dashboard Famille | ⬜ À faire |
| **T7** | **Fallback JCVital V6 4G** (si T1-T4 révèlent une limite bloquante) | échantillons à réception (email 28/09/2026) | Décision : ring seul vs ring + V6 4G | ⬜ En attente fabricant |

---

## 8. Interdits mode Famille

**Cahier des charges de référence : `easyphone/docs/MODE_FAMILLE_OPTIONS.md`** (64 options,
P0 = 31) — **ne jamais le réécrire**, tout codage famille doit s'y référer. Ses 3 interdits,
applicables aussi à la détection de chute :

1. **Aucune action invasive** (vidéo/micro/son/position/SMS/appel) **sans parcours de
   consentement senior** : TTS prénom+action → 2 boutons géants OUI/NON sans rebours →
   **expiration = jamais d'activation**. → L'alerte chute qui envoie un SMS ou ouvre la
   caméra passe par ce parcours (le SMS au responsable dans `checkin_service` a déjà son
   propre cadre).
2. **Aucun champ de saisie santé/planning/médicament dans EasyPhone** (source = Serinity) →
   l'accel/FC affiché est en **lecture seule**.
3. **Aucune régression du kiosk mode Senior** → tout nouveau service est testé sur le
   parcours kiosk avant livraison.

Autres règles en vigueur : APK build `flutter build apk --release` (signé auto),
`/home/newappai/flutter/bin/flutter` (pas dans le PATH), tests `flutter test` : 2 fichiers
PRÉEXISTANTS en rouge (widget_test sans main, easyphone_test) — ne pas les attribuer à une
nouvelle mission sans vérifier.

---

## 9. Glossaire

- **PPG** : photopléthysmographie (LED verte + photodétecteur) → FC, SpO2.
- **ECG** : électrocardiogramme (électrodes peau) → rythme cardiaque précis, HRV.
- **HRV** : variabilité de la fréquence cardiaque.
- **FIFO** : tampon d'échantillons du capteur (ici toujours en bypass, count=1).
- **NEW-data bit** : bit registre 0x02.0 du STK8xxx = « nouvel échantillon dispo » — seule
  mesure de débit non falsifiable (un compte de paquets se trompe sur les doublons).
- **Big Data** : second set de commandes BLE Colmi (hypnogramme, SpO2 24 h agrégés).
- **RawSensors (0xA1)** : commande de stream brut accel+PPG+SpO2, § 2.4.
- **RTL8762E** : SoC Realtek des anneaux R02 (Cortex-M0).
- **Kiosk mode** : mode Senior verrouillé d'EasyPhone (interface réduite, pas de fuite).

---

## 10. Sources & liens

**Accéléromètre / protocole Colmi**
- Doc RE principale : https://colmi.puxtril.com/ (commands + Big Data) — repo
  https://github.com/Puxtril/colmi-docs — **PR #2 « Add RawSensors Command »** (preuve stock) :
  https://github.com/Puxtril/colmi-docs/pull/2
- Client Python standard : https://github.com/tahnok/colmi_r02_client —
  **issue #59 « Pulling Accelerometer Data via CLI »** (script complet A10404) :
  https://github.com/tahnok/colmi_r02_client/issues/59 —
  docs : https://tahnok.github.io/colmi_r02_client/
- **Dart/Flutter** (réutilisable EasyPhone) : https://github.com/CitizenOneX/colmi_r06_fbp
  → `lib/colmi_ring.dart`
- Edge Impulse data collection (Python + firmware FasterRawValuesMOD) :
  https://github.com/edgeimpulse/example-data-collection-colmi-r02
- Outils Web (flash catalogue + mesure Raw Rate live) :
  https://nosh118.github.io/colmi-ring-tools/
- Patch firmware 352 Hz (RE complète, risques documentés) :
  https://github.com/lachlanmcalpine/colmi-ring

**Historique / vitals**
- RingCLI (Go, canal Big Data) : https://github.com/smittytone/RingCLI

**Bracelets**
- JCVital / Joint Chinese Ltd : https://www.jointcorp.com/ — SDK :
  https://www.jointcorp.com/sdk-api/ — contact info@jointcorp.com, +86-18680390477
  (échantillons demandés le 28/09/2026)
- Hume Band 2.0 (protocole J2208) :
  https://github.com/brendangooden/j2208-band-tools
- Bangle.js 2 : https://www.espruino.com/Bangle.js2 —
  https://shop.espruino.com/banglejs2 — https://banglejs.com/apps/
- Colmi R02 aperçu produit : https://pypi.org/project/colmi-r02-client/

**Interne EasyPhone**
- Code : `/home/newappai/easyphone/` (pas de git)
- Cahier des charges mode Famille : `easyphone/docs/MODE_FAMILLE_OPTIONS.md`
- Spec delta LiveKit/contacts/appels : `easyphone/docs/SPECS_DELTA_CONTACTS_LIVEKIT_APPEL.md`
- Contacts source (LECTURE SEULE) : `/home/newappai/contacts-backup-honor400/`
- Board : projets.newappai.com → projet **EasyPhone (id 17)** —
  catégories : 12 LiveKit/Visio, 13 Mode Famille, 14 noyau senior, 15 Liaison Serinity
- Pièges build/test EasyPhone : voir mémoire session (§ EASYPHONE — état builds/devices)

---

## 11. Journal des mises à jour

| Version | Date | Auteur | Changements |
|---|---|---|---|
| 1.1 | 30/09/2026 | Hermes (hermes-ant) | Projet repos créé : `/media/newappai/ssd512/appareils-connectes/` — 14 repos clonés (9 bagues, 4 bracelets/montres, 1 brassard `antirez/bplog`), URLs pré-vérifiées par `git ls-remote`, index README. Vérifié : aucun projet équivalent n'existait avant. |
| 1.0 | 30/09/2026 | Hermes (hermes-ant) | Création. Consolidation des recherches : commande A1 stock (✅), firmwares mod (✅/risque brick), canal Big Data (pas d'accel), JCVital (🟡 échantillons en attente), spec algo chute, plan T1-T7. |

<!-- FIN DU DOCUMENT — les sessions suivantes ajoutent leurs entrées ci-dessus et incrémentent la version en tête de fichier. -->