L’objectif du présent cahier des charges est de définir la conception d’un pager d’alerte sur le réseau (Meshtastic) de Gaulix : à réception d’une commande d’activation sur le réseau, l’appareil signale l’alerte de façon sonore et visuelle, affiche le message sur écran, et confirme la bonne réception à l’émetteur. La solution est pensée pour un usage secours citoyen / Association Agrée de Sécurité Civile(AASC ) / Plan Communale de Sauvegarde (PCS), reproductible, sans dépendance à des outils tiers spécialisés et sans paramétrage radio hors standard Meshtastic.
Contexte
Dans un contexte de multiplication des aléas climatiques, de tensions sur les réseaux de télécommunication classiques et de montée en puissance des dispositifs de Secours, Secours citoyen, de PCS, la capacité à alerter rapidement des bénévoles, des Sapeurs pompiers, Agents du département, des référents communaux ou des membres d’une structure de type AASC devient un enjeu opérationnel majeur.
Les solutions habituelles — SMS, groupes de messagerie, applications propriétaires — présentent des limites connues : dépendance à l’internet et/ou réseau mobile, saturation en situation de crise, absence de couverture en zone isolée, ou manque de matériel dédié pour les personnes qui doivent être alertés (bip sonore, message).
Le réseau Gaulix, basé sur la technologie Meshtastic (communication LoRa maillée, décentralisée, longue portée, faible consommation), permet déjà l’échange de messages texte entre nœuds sans infrastructure centrale. Le firmware standard ne répond toutefois pas pleinement à ce type d’utilisation déclenchement fiable, signal sonore et visuel, acquittement du de la lecture du message par l’utilisateur.
L’objectif du présent cahier des charges est de définir la conception d’un bipeur/pager d’alerte Gaulix : à réception d’un,message dédié sur le réseau, l’appareil signale l’alerte de façon sonore et visuelle, affiche le message sur écran. La solution est pensée pour un usage secours citoyen / AASC / PCS/…, reproductible.
Schéma de principe
Seeed Wio Tracker L1 Pro : terminal retenu pour la V1 (écran OLED, buzzer, LEDs, trackball, GPS, LoRa SX1262).
Le terminal cible dispose nativement des éléments nécessaires à un bipeur/pager : buzzer pour l’alarme sonore, écran OLED pour l’affichage plein écran, LEDs pour un signal visuel complémentaire, trackball et bouton pour l’acquittement, et GPS pour enrichir l’accusé de réception. Le développement s’appuie sur le firmware officiel Meshtastic, avec un module logiciel dédié au mode pager, compilé pour la cible seeed wio tracker L1 voir sa version en lit avec écran E-Ink
L’émission des alertes se fait depuis l’application Meshtastic (Android /Client web), depuis le fork Gaulix_bipper (Android / Desktop KMP) ou depuis le client web Meshtastic-Bipper, en plus de tout client compatible. Aucune plateforme propriétaire n’est requise. Les coordinateurs AASC, référents PCS ou postes de coordination communaux peuvent ainsi déclencher une mise en alerte sur tout le réseau Gaulix ou en message direct vers un pager identifié.
Afin d’assurer la conception d’un bippeur d’alerte employable dans le cadre du réseau Gaulix, voici les points jugés prioritaires :
Alerte et signalisation
- L’envoi d’un message d’alerte est réalisé via une application dédiée. Ce message peut être individuel ou de groupe sur les canaux d’origine Gaulix ou tout autre canal dédié (créer par les utilisateurs)..
- Syntaxe de commande simple et mémorisable, par exemple :
#alerte <texte>ou#secours <texte>- #alerte : le mot après # sera considéré comme un message de type alerte
- #secours : type demande de secours
- #info : type information
- #vigi : type diffusion de vigilance (météo/feu de forêt,…)
- À la réception d’une alerte valide :
- signal sonore (buzzer) : séquence de bips par défaut (3 bips), avec possibilité de mode continu jusqu’à acquittement.
- affichage plein écran sur OLED/E-Ink : «Type d’alerte», texte du message,horodatage.
- signal visuel complémentaire (LED)
- Confirmation de la lecture du message par l’opérateur (via un appuis sur le joystick) : arrêt de l’alarme.
- Commande de fin d’alerte (
#fin+ id alerte) pour retour à l’état normal. - Compteur d’alertes reçues et écran d’accueil mode pager .
Voir mon Github
Réseau et usage opérationnel
- Compatibilité avec le réseau Gaulix (EU868, canaux habituels).
- Émission depuis l’application Meshtastic, Gaulix_bipper ou le client web Bippeur ; pas de dépendance à une plateforme propriétaire.
- Possibilité d’utiliser un canal Alerte/PCS / secours distinct du trafic courant du mesh.
- Option future : liste blanche des nœuds autorisés à déclencher une alerte (coordinateurs AASC, référents PCS).
Configuration à distance
- Réglage du nombre de bips (ex.
#b 5). - Réglage du mode alarme continue(ex.
#b 0). - Borne de sécurité : coupure automatique de l’alarme continue après délai maximal (30 min) si aucun acquittement.
Contraintes techniques et économiques
- Première cible matérielle : Seeed Wio Tracker L1 Pro.
- Livrable de flashage : fichier
.uf2(bootloader nRF52). - Module logiciel dédié isolé du reste du firmware pour faciliter la maintenance.
- Interface et messages en français, vocabulaire secours / AASC / PCS.
- Simplicité d’usage pour des bénévoles non techniciens.
- Coût matériel maîtrisé : terminal tout-en-un, pas de câblage externe obligatoire pour la V1.
- Reproductibilité : documentation de flashage et fiche réflexe « envoyer / tester une alerte ».
Options et évolution (hors périmètre V1 du projet)
- Niveaux de multiples alertes (info / alerte / urgence).
- Statuts bénévoles (« disponible », « en route », « sur place »).
- Centralisation des acquittements via interface web ou poste de supervision
- Pont MQTT (Local) vers une salle de crise ou un PC-Crise
- Mode exercice vs réel pour les entraînements communaux. À voir
Mise en œuvre
Déploiement technique — Phase 1
| Étape | Contenu | Livrable |
|---|---|---|
| 1 | Spécification détaillée des commandes et états | Présent document V0.0.1 |
| 2 | Développement du module pager sur firmware Meshtastic | Firmware .uf2 L1 Pro |
| 3 | Tests sur réseau Gaulix (alerte, acquittement, ACK) | Compte-rendu de test |
| 4 | Rédaction fiche réflexe opérateur | PDF 1 page |
| 5 | Déploiement pilote (2 à 5 pagers) | Retour terrain |
Promotion auprès des services concernés
Ce cas d’usage permettrait, d’une part, de justifier et valoriser le réseau Gaulix en proposant une solution concrète de mise en alerte décentralisée, et d’autre part de faciliter l’adhésion des communes, intervennt « d’urgence », structures AASC, citoyens et bénévoles en montrant un outil immédiatement utile en exercice comme en situation réelle.
Les communes, responsables de la mise en œuvre du PCS, pourraient équiper des référents ou points de coordination d’un pager Gaulix, tout en déployant des nœuds relais Meshtastic pour couvrir le territoire (mairie, salle polyvalente, points hauts).
La solution reste auto-hébergeable au sens mesh : aucun abonnement, aucun serveur obligatoire pour la V1. Un client web Meshtastic-Bipper (voir section Écosystème logiciel coordinateur ci-après) permet déjà l’envoi d’alertes et la gestion côté poste fixe ; une évolution ultérieure pourrait enrichir la supervision (acquittements agrégés, carte des bénévoles) depuis un PC-Crise ou une mairie dotée d’une liaison internet (fixe ou satellite).
Acteurs cibles
| Acteur | Rôle |
|---|---|
| toute structure intervenant en « urgence » | structure technique |
| Communes | Portage du PCS, financement relais, équipement référents |
| Structures AASC | Coordinateurs et bénévoles de secours citoyen |
| Réseau Gaulix | Déploiement, maintenance, formation |
| Bénévoles équipés | Réception, acquittement et mise en œuvre terrain |
| Citoyens | Utilisateur du réseau meshtastic au quotidien peuvent recevoir et envoyer de l’info par un canal dédié |
Critères de succès V1
- Une alerte
#alerteenvoyée depuis l’app Meshtastic déclenche bip + écran sur le pager en moins de deux minutes (selon topologie mesh). - L’opérateur peut acquitter et l’émetteur reçoit un ACK explicite, en directe sur l’éméteur de l’alerte.
- Un non-initié peut utiliser le pager après 15 minutes de formation.
- Le firmware se flashe et se reconfigure sans compétence développeur.
Annexes
A — Commandes prévues (V1)
| Commande | Description | Exemple |
|---|---|---|
#alerte <texte> | Déclenche une alerte secours | #alerte Rassemblement hall sportif |
#secours <texte> | Synonyme alerte | #secours Renforts secteur Nord |
#fin | Fin d’alerte, retour normal | #fin |
#b <n> | Nombre de bips (0 = continu) | #b 5 |
#status | État du pager | #status |
| #info <texte> | envoie d’information de suivi | #info besoin 10 secouristes en plus |
| #T1 | premier TAG (service utilisateur) | #T1 Commune |
| #T2 | Second TAG (service utilisateur) | #T2 SDIS68 |
| #T3 | Troisième TAG (service utilisateur) | #T3 CRF68 |
Exemple complet #alerte Vigi météo Rouge #b 0 UDIOM99
B — Matériel cible V1
| Élément | Spécification |
|---|---|
| Terminal | Seeed Wio Tracker L1 Pro |
| Processeur | nRF52840 |
| Radio | SX1262 (LoRa) |
| Affichage | OLED SSD1306 |
| Signalisation | Buzzer, 2 × LED, trackball |
| Géolocalisation | GPS L76K (optionnel dans ACK) |
| Flashage | Fichier .uf2 via bootloader USB |
C — Liste des status
| Numéro | Libellé |
|---|---|
| 1 | PARTI |
| 2 | SUR LES LIEUX |
| 3 | Alerte bien reçus et lu |
| 4 | |
| 5 | DEPART HOPITAL |
| 6 | ARRIVEE HOPITAL |
| 7 | DISPONIBLE |
| 8 | INDISPONIBLE |
| 9 | RENTRE |
| 22 | SMUR SSL |
| 25 | DISPO HORS SECTEUR |
| 30 | POLICE SSL |
| 31 | GENDARMERIE SSL |
| 32 | EDF SSL |
| 33 | GDF SSL |
| 34 | DDE(Dept) SSL |
| 35 | CG(Dept) SSL |
| 36 | POLICE MUNI. SSL |
| 37 | BRIG. VERTES SSL |
| 38 | MAIRE SSL |
| 39 | DIR (xx) SSL |
Et voilà, si le sujet vous intéresse, alors peut être bientôt la suite du POC Bippeur
Frédéric (F4EED)