RPCB – HEMLo : Cours TRIIIP / TRIZ
Comment alerter sans les moyens classiques de communication ?
- Dead-man switch: implémenté dans les pages webs de a.rpcb.be et dans l'API (à corréler aux données météo)
- MESH ZigBee: en cours d'implémentation (TDD)
Concept : Dead-man Switch
Le Dead-man switch est un mécanisme de sécurité passif appliqué via le protocole Heartbeat :
- L'absence de données est traitée comme critique.
- Référence : Chandra & Toueg (1996), "Unreliable Failure Detectors".
Historique
- 1872 – George Westinghouse : premiers systèmes de freinage automatique
- Début XXᵉ : Dead-man’s handle dans locomotives
- Années 1980-2000 : systèmes industriels (SCADA)
- Années 2010 : systèmes distribués (cloud, Kubernetes, Raft)
Matrice de Liveness
| Badge | Condition (TTL) |
|---|---|
| OK | Signal récent (< 1h) |
| STALE | Signal dégradé (> 1h) |
| DANGER | Signal perdu (> 24h) |
Statut des dispositifs (Live API)
Concept : MESH ZigBee
Le réseau MESH ZigBee est un maillage de dispositifs IoT permettant la communication redondante et la propagation des messages via des routeurs et capteurs. La communication se fait via MQTT pour remonter les signaux vers le serveur.
- Coordonnateur : Gère l’association et la topologie.
- Routeurs : Répètent les messages pour assurer couverture et résilience.
- Capteurs : Mesurent les événements (fuite d’eau, heartbeat) et publient sur MQTT.
Historique
- Années 2000 : adoption de ZigBee pour l’automatisation et les capteurs domestiques.
- Années 2010 : intégration de réseaux MESH IoT pour les systèmes critiques.
- 2020+ : standardisation de MQTT pour la communication fiable des capteurs et Heartbeats.
Références bibliographiques et normes
- ZigBee : CSA Zigbee Specification R23 / Document 05-3474-23
- MQTT : OASIS MQTT v3.1.1
- Zigbee2MQTT : topics
bridge/event,bridge/networkmap, device payloads - Topologie MESH représentée via Graphviz DOT (child → parent)
Méthodologie
Processus suivi :
- Définition de l'idée et des besoins
- Implémentation KISS (Keep It Simple, Stupid)
- Écriture de tests TDD (bash, Playwright)
- PoC puis amélioration continue avec IA
- Dev itératif basé sur les tests et retours
Statut du Développement (TDD) - MESH ZigBee / UI
| Test | Description | Référence | Statut |
|---|---|---|---|
| 0_zigbee_MESH_nonreg_WaterLeak.sh | Vérifie que le capteur WaterSensorMock remonte un événement water_leak | RPCB MQTT / Zigbee2MQTT | ✅ |
| 1_zigbee_MESH_water_leak_detection_test.sh | /api/state → waterPresent=true pour WaterSensorMock | RPCB API | ✅ |
| 2_zigbee_MESH_device_announce.sh | /api/state → sensors.zigbeeDevices[ieee], annonce d’un device IEEE | ZigBee / RPCB API | ✅ |
| 3_zigbee_MESH_device_leave.sh | /api/state → sensors.zigbeeDevices[ieee].online=false, device leave | ZigBee / RPCB API | ✅ |
| 4_zigbee_MESH_linkquality.sh | /api/state → linkquality=55 pour le capteur | ZigBee / RPCB API | ✅ |
| 5_zigbee_MESH_route_change.sh | /api/state → sensors.meshTopology, vérifie parent → enfant / topologie | Graphviz DOT / ZigBee / RPCB API | ✅ |
| ui.mesh.summary_section | UI doit contenir la section Mesh | RPCB UI | ⚪️ |
| ui.mesh.devices_list | UI doit afficher au moins un ZigBee device | RPCB UI | ⚪️ |
| ui.mesh.device_status | UI doit afficher le status online/offline des devices | RPCB UI | ⚪️ |
| ui.mesh.linkquality | UI doit afficher la valeur linkquality des devices | RPCB UI | ⚪️ |
| ui.mesh.topology | UI doit afficher les devices et la topologie Mesh | Graphviz DOT / RPCB UI | ⚪️ |