Pourquoi construire un tableau de bord personnalisé OpenAPS ?

La gestion du diabète de type 1 avec une configuration OpenAPS (Open Artificial Pancreas System) produit un flux constant de données – valeurs de glucose sanguin, insuline à bord, niveaux de réservoir, état de batterie et alarmes système. Les applications de diabète hors-sol manquent souvent de flexibilité pour présenter ces informations exactement comme vous en avez besoin, surtout lorsque vous voulez corréler plusieurs mesures dans une seule vue. La construction d'un tableau de bord en temps réel personnalisé vous permet de contrôler complètement la mise en page, la fréquence de mise à jour, les seuils d'alerte et la persistance des données. Ce guide vous aide à accéder à l'ensemble du processus, de l'accès aux données brutes OpenAPS au déploiement d'une interface de surveillance prête à la production que vous pouvez faire confiance pour une utilisation quotidienne.

De nombreux outils existants comme Nightscout offrent une base de fonctionnalités, mais ils peuvent ne pas exposer tous les points de données brutes que vous aimez, ou ils vous forcent à un design visuel particulier. Un tableau de bord personnalisé vous permet de retirer des éléments inutiles et de vous concentrer sur ce qui compte le plus pour vous. Par exemple, vous pouvez mettre en évidence les flèches de tendance et les numéros IOB dans de grandes polices pour des regards rapides, tout en fournissant des graphiques d'historique détaillés pour une analyse plus approfondie.

Comprendre les sources de données OpenAPS

Avant d'écrire un code, vous devez savoir où vivent vos données OpenAPS. Le système fonctionne sur un Raspberry Pi (ou un ordinateur de bord similaire) exécutant un algorithme en boucle fermée qui communique avec un moniteur de glucose continu (CGM) et une pompe à insuline. Les points de données clés comprennent:

  • Le glucose de sang (BG) est une mesure – généralement toutes les 5 minutes de la MMC (p. ex., Dexcom, Medtronic).
  • Antécédents d'administration d'insuline – taux de base de la température, bolus et calculs d'insuline embarquée (IOB).
  • État du système – état de boucle (facile/désactivé), batterie de pompe, volume du réservoir et âge du capteur.
  • Alertes et erreurs – BG hors gamme, batterie basse, défaillances de communication.

OpenAPS stocke ces données localement dans des fichiers JSON (par exemple, , ) et les expose également via une API REST intégrée sur le réseau local de rig. L'API est la méthode préférée pour les tableaux de bord en temps réel car elle permet un accès sécurisé et basé sur les requêtes sans toucher directement le système de fichiers. Se reporter à la documentation officielle OpenAPS API pour les détails des paramètres et les options d'authentification.

Une erreur courante est de supposer que les données seront toujours disponibles en temps réel. Dans la pratique, l'émetteur CGM peut temporairement perdre la connexion, la pompe peut ne pas reconnaître une commande, ou le Raspberry Pi pourrait manquer de mémoire. Votre tableau de bord doit gérer tous ces cas de bord gracieusement. Validez toujours les horodatages et refusez les lectures statiques.

Aperçu de la pile technologique

Votre tableau de bord sera une application web fonctionnant sur un serveur ou une plate-forme cloud. La pile typique comprend:

  • Backend – un serveur léger (Node.js, Python Flask, ou Go) qui demande à la plate-forme OpenAPS et cache en option les données.
  • Frontend – une application d'une page construite avec React, Vue.js ou un JavaScript simple.
  • Visualisation des données – une bibliothèque comme Chart.js, D3.js ou ApexCharts pour le graphique des tendances de la BG et de l'administration d'insuline.
  • – Mises à jour en temps réel – obtenues par sondage périodique (setInterval) ou par des connexions WebSocket persistantes.
  • Hosting – une plate-forme VPS, Raspberry Pi (locale) ou sans serveur (par exemple Vercel, Netlify) avec support WebSocket.

Si vous préférez éviter de construire un moteur de bord complet, vous pouvez héberger le tableau de bord entièrement sur le banc lui-même en utilisant un générateur de site statique qui récupère les données directement de l'API de rig. Choisissez l'approche qui correspond le mieux à vos exigences de sécurité réseau et de confort personnel. De nombreux développeurs commencent par le sondage et passent ensuite à WebSockets pour réduire la latence.

Une tendance croissante est de combiner le tableau de bord avec une base de données de séries chronologiques comme InfluxDB ou TimescaleDB. Cela vous permet de zoomer de loin dans le temps (semaines ou mois) tout en offrant des mises à jour en direct. Le moteur peut écrire des points de données récents dans la base de données et servir des requêtes historiques à partir de celle-ci, réduisant la charge sur le système OpenAPS. Cette approche est particulièrement utile si vous voulez effectuer une analyse rétrospective ou partager des données agrégées avec votre endocrinologue.

Étape 1: Accès aux données OpenAPS via API

Pour récupérer les données de glucose, appelez . La réponse contient un tableau de lectures récentes de BG avec horodatage et direction de tendance. De même, retourne l'état de la boucle actuelle, IOB, niveau de batterie, et plus encore. Testez ces paramètres avec des outils comme ou Postman pour confirmer le format de données et la fréquence de mise à jour. Faites une attention particulière au format horodatage – OpenAPS utilise généralement l'epoch Unix en millisecondes ou secondes, de sorte que vous pouvez avoir besoin de convertir en objets JavaScript Date sur la façade.

Si votre appareil est derrière un pare-feu ou si vous avez besoin d'un accès à distance, envisagez d'utiliser un tunnel sécurisé (par exemple, ngrok) ou un VPN. N'exposez jamais l'API OpenAPS directement sur Internet public sans authentification. Pour les tableaux de bord de production, implémentez un serveur proxy qui ajoute une clé API, valide les requêtes et actionne le trafic pour éviter les abus. Vous pouvez également utiliser un serveur VPN sur le Raspberry Pi lui-même, permettant uniquement des connexions chiffrées au paramètre API.

Une autre considération est la vitesse à laquelle vous sondagez l'API. Le système OpenAPS peut gérer quelques requêtes par seconde, mais le marteautage constant peut interférer avec l'algorithme de boucle. Un intervalle de vote sûr est toutes les 5 à 10 secondes. Si vous avez besoin de mises à jour plus rapides, utilisez plutôt WebSockets, qui pousse les données seulement lorsque les mises à jour du système.

Étape 2: Conception de la disposition du tableau de bord

Commencez par une trame filaire qui place la métrique la plus critique — la glycémie actuelle — au sommet ou au centre.

  • Rang supérieur – Valeur BG (large), flèche de tendance, temps depuis la dernière lecture.
  • Deuxième ligne – IOB, taux basal actuel, niveau du réservoir.
  • Espace principal – un graphique BG de 3 heures ou 24 heures avec des zones codées en couleur (jaune pour prudence, rouge pour danger).
  • Side panel – alertes récentes et indicateurs de santé du système (batterie, âge du capteur).

Utilisez des cadres CSS réactifs comme Bootstrap ou Tailwind CSS pour s'assurer que le tableau de bord fonctionne sur les écrans mobiles – de nombreux utilisateurs veulent regarder à partir de leur téléphone. Envisagez d'utiliser une bibliothèque spécifique au tableau de bord comme GridStack.js pour permettre la personnalisation de la disposition des glisser-déposer, vous permettant de réarranger les widgets en tant que priorités. Par exemple, pendant l'exercice, vous pourriez vouloir agrandir le graphique BG et réduire l'affichage IOB. Un système de grille facilite également l'ajout de nouveaux widgets plus tard sans casser la disposition.

L'accessibilité est essentielle. Utilisez des schémas de couleurs à contraste élevé qui sont encore reconnaissables pour les utilisateurs de coloraved (éviter de dépendre du rouge/vert seulement). Ajoutez des étiquettes de texte à côté des indicateurs de couleur. Considérez l'utilisation d'un mode sombre pour la vision nocturne. Placez les informations les plus importantes où il attire l'œil en premier – généralement le haut gauche pour les langues de gauche à droite. Testez la mise en page sur différentes tailles d'écran, en particulier le téléphone que vous utilisez le plus souvent.

Étape 3 : Construire le mandataire de l'arrière-plan (facultatif mais recommandé)

Un serveur de backend ajoute une couche de sécurité et de cache. Par exemple, un serveur Node.js Express peut :

  • Obtenez les données OpenAPS toutes les 5 secondes (ou aussi vite que le gréement se met à jour).
  • Conservez le dernier état en mémoire pour réduire la charge sur le gréement et fournir des réponses instantanées à la façade.
  • Exposer les paramètres comme et à la façade.
  • Ajouter les en-têtes du CORS et limiter le taux.

Voici un extrait de noeud.js minimal utilisant :

const express = require('express');
const fetch = require('node-fetch');
const app = express();

let cache = {};

setInterval(async () => {
 const res = await fetch('http://openaps-rig:8080/api/v1/status.json');
 cache.status = await res.json();
}, 5000);

app.get('/api/status', (req, res) => res.json(cache.status));
app.listen(3000);

Cette approche vous permet également d'agréger des données de plusieurs plates-formes si vous avez un système de secours ou si vous surveillez une autre boucle de personne. Pour une sécurité supplémentaire, implémentez l'authentification JWT sur les paramètres proxy. Vous pouvez également intégrer un cache simple en mémoire qui stocke les dernières 24 heures de données afin que le frontend puisse demander des plages historiques sans frapper la plate-forme à plusieurs reprises.

Si le système est inaccessible, le mandataire doit retourner une version en cache (ou une 503) plutôt que de se planter. Enregistrez toutes les erreurs dans un fichier ou un service de surveillance. Vous pouvez aussi exposer un paramètre de contrôle de santé que d'autres outils de surveillance (comme UptimeRobot) peuvent ping pour vérifier que le système mandataire et le système sont tous deux vivants.

Étape 4 : Mise en œuvre de la Frontend avec les mises à jour en temps réel

Utilisez une bibliothèque d'interface utilisateur JavaScript moderne pour gérer efficacement les composants d'état et de rendu. Réagir est un choix populaire en raison de ses méthodes de cycle de vie et de ses crochets. Créer un composant qui appelle votre backend toutes les 5 secondes (] avec ) et mettre à jour l'état. Pour de vraies expériences en temps réel, remplacer le vote par une connexion WebSocket – les deux Node.js et Python supportent ce facilement en utilisant des bibliothèques comme ou . WebSockets réduisent la bande passante et la la latence, ce qui est important lorsque vous avez besoin d'alertes immédiates pour l'hypoglycémie.

Pour le graphique, installez Chart.js (avec l'enveloppeur Réact ] ou ApexCharts pour les animations plus douces. Placez des valeurs BG sur un graphique linéaire avec une axe X et un axe Y du temps. Surlignez l'injection d'insuline comme un diagramme à barres ou une zone pour montrer les corrélations. Colorez chaque point de données en fonction de la direction de la flèche de tendance (plate, haut, bas). Vous pouvez également ajouter une région ombragée pour la plage cible (p. ex. 70-180 mg/dL) afin de la rendre immédiatement évidente lorsque l'utilisateur est hors de portée.

N'oubliez pas de gérer les données manquantes gracieusement – montrez un avertissement --stale de données - si la dernière lecture est plus ancienne que 10 minutes. Implémentez la logique de reconnection si WebSocket tombe, et affichez toujours l'horodatage de la dernière mise à jour réussie. Utilisez un spinner de chargement pendant la première récupération, et affichez un message d'erreur clair si le moteur de recherche est inaccessible.

Étape 5 : Options de déploiement et d'hébergement

Vous avez plusieurs cibles de déploiement viables:

  • Raspberry Pi local – exécutez le serveur de tableau de bord sur le même Pi qu'OpenAPS. Ceci est le plus simple et le plus privé. Accédez-le via une IP locale comme . Soyez conscient que l'exécution d'OpenAPS et d'un serveur de tableau de bord sur le même Pi peut forcer le matériel si vous ajoutez trop de fonctionnalités.
  • Cloud VPS (DigitalOcean, AWS, Linode) – utilisez un droplet Ubuntu minimal, installez Node.js ou Python, et exécutez l'application derrière un proxy inverse (Nginx) avec SSL. Cela vous permet de visualiser le tableau de bord de n'importe où, mais nécessite un durcissement de sécurité (firewall, fail2ban, HTTPS). Utilisez un outil comme Let's Encrypt pour obtenir des certificats SSL gratuits.
  • Les plateformes sans serveur (Vercel, Netlify, Cloudflare Workers) – bonnes pour les frontends statiques, mais elles luttent avec les connexions persistantes de WebSocket. Vous devriez compter sur le sondage et un moteur séparé pour l'agrégation des données. Vous pouvez également utiliser Cloudflare Workers avec des objets durables pour le support WebSocket, mais cela ajoute complexité et coût.

Pour un accès à distance sans IP publique, envisagez d'utiliser ngrok pour créer un tunnel sécurisé à votre tableau de bord local. Combinez-le avec une couche d'authentification (HTTP basic auth ou token-based) pour empêcher une visualisation non autorisée. Configurez également un VPN WireGuard sur votre réseau d'origine. WireGuard est léger et sécurisé, et il peut être configuré sur un périphérique de faible puissance comme un Raspberry Pi. Cela vous donne un accès chiffré à votre tableau de bord local à partir de n'importe quel appareil tout en gardant les données hors des serveurs publics.

Si vous choisissez d'héberger dans le cloud, soyez attentif aux règles HIPAA ou RGPD si vous manipulez des données de santé. Au minimum, chiffrez les données en transit (TLS) et au repos (base de données chiffrée). Considérez les politiques de conservation des données : vous n'aurez peut-être pas besoin de stocker plus de quelques semaines de lectures historiques sur un serveur cloud.

Pratiques exemplaires de surveillance des données sur le diabète

Votre tableau de bord sera utilisé pour les décisions critiques de la vie, donc la fiabilité et la précision sont essentielles.

  • Redundancy – Si le tableau de bord échoue, l'utilisateur devrait toujours recevoir des alertes de son récepteur ou pompe CGM. Ne jamais se fier uniquement à un tableau de bord personnalisé pour les alarmes. Le tableau de bord devrait servir d'outil complémentaire, et non pas de système d'alerte primaire.
  • Validation des données[ – Rejeter les lectures avec des valeurs impossibles (p. ex. BG < 20 mg/dL ou > 600 mg/dL). Affichez un avertissement si les données semblent corrompues.
  • Manipulation des fuseaux horaires – utilisez UTC pour le stockage et convertissez l'heure locale de l'utilisateur sur la façade. Les horodatages OpenAPS sont typiquement UTC. Soyez prudents avec les transitions d'heure d'été; conservez et traitez toujours les horodatages en UTC pour éviter toute ambiguïté.
  • Accessibilité – utiliser des couleurs contrastantes élevées, des polices de grande taille et des alertes sonores optionnelles (via l'API Web Audio) pour les basses critiques.
  • Loging – enregistrer des données historiques pour un examen ultérieur (p. ex., exportations CSV). Une base de données série chronologique comme InfluxDB peut être connectée pour l'analyse à long terme et l'analyse des tendances.

Testez votre tableau de bord dans des conditions réelles : que se passe-t-il lorsque la pompe est à court d'insuline ? Simulez ces scénarios pour assurer la récupération du tableau de bord sans intervention manuelle. Implémentez des paramètres de contrôle de santé qui peuvent être surveillés à l'extérieur. Exécutez le tableau de bord pendant une semaine avant de lui faire confiance pour une utilisation critique.

Caractéristiques avancées à considérer

Une fois que vous avez un tableau de bord de base en cours d'exécution, envisagez d'ajouter ces améliorations:

  • Lignes prédictives – utilisez une régression linéaire simple sur les lectures BG passées pour projeter les 30 prochaines minutes. Les utilisateurs plus avancés peuvent intégrer des modèles d'apprentissage automatique via un microservice séparé. Étiquetez clairement les prédictions en tant que telles pour éviter toute confusion avec les lectures réelles.
  • – intégrer la synthèse de la parole du navigateur pour lire le BG et le BIO toutes les 10 minutes, ce qui est utile pendant l'activité physique.
  • Remote control – avec une extrême prudence, vous pouvez ajouter des boutons pour déclencher des alarmes temporaires basales ou des ronflements à travers l'API OpenAPS. Cela nécessite une authentification rigoureuse et une boîte de dialogue de confirmation pour éviter des changements accidentels.
  • – permettre aux aidants de visualiser le tableau de bord à partir de leurs propres appareils avec différentes permissions (p. ex., en lecture seule pour les parents, contrôle complet pour l'utilisateur principal). Mettre en œuvre le contrôle d'accès basé sur le rôle (RBAC) sur le moteur de recherche.

Chacune de ces fonctionnalités ajoute de la complexité et des risques potentiels. Toujours tester dans un environnement sûr (par exemple, en utilisant des données historiques ou un gréement en mode -enacted-), avant de compter sur eux pour une utilisation quotidienne. Envisager d'utiliser des drapeaux de fonctionnalité pour déployer progressivement de nouvelles capacités. Par exemple, vous pourriez activer des lignes prédictives pour un sous-ensemble d'utilisateurs d'abord et recueillir des commentaires avant de permettre à tout le monde.

Dépannage de problèmes communs

Pendant le développement, vous pouvez rencontrer plusieurs problèmes communs. Voici les solutions:

  • – Vérifiez la connectivité réseau entre le serveur de tableau de bord et le système. Vérifiez que l'API OpenAPS répond en enrouleant directement le paramètre. Assurez-vous que les en-têtes du système CORS sont définis si vous faites des demandes croisées. Vérifiez les règles du pare-feu et que le port 8080 du système est accessible.
  • Stale data avertissements – Si les relevés sont plus longs que prévu, augmentez l'intervalle de vote ou réduisez le cache TTL. Vérifiez également que le dispositif CGM transmet correctement.
  • WebSocket déconnecte – Implémenter la reconnection automatique avec une rétro-démarrage exponentielle. Vérifiez les paramètres de proxy ou les règles de pare-feu qui peuvent faire tomber les connexions au ralenti.
  • Charts non rendus – Valider la structure de données JSON. Utilisez les journaux de console pour inspecter les données avant de les transmettre à la bibliothèque de cartographie. Assurez-vous que les horodatages sont dans un format auquel la bibliothèque s'attend (p. ex. millisecondes pour Chart.js). Vérifiez que votre composant graphique est de nouveau rendu sur les changements d'état.

Ajoutez la connexion au moteur et à la façade pour saisir les conditions d'erreur. Considérez la possibilité de mettre en place un service de surveillance comme UptimeRobot pour le tableau de bord lui-même. Créez une page simple -Health- , qui liste tous les états connus (rige accessible, dernière mise à jour des données, statut WebSocket) afin que vous puissiez rapidement diagnostiquer les problèmes.

Conclusion

Un tableau de bord OpenAPS personnalisé est plus qu'un exercice technique, c'est un outil qui peut améliorer votre confiance et votre qualité de vie en mettant des données actionnables à portée de main. Commencez petit : récupérer un point de départ et afficher un seul graphique. Puis itérer en ajoutant plus de mesures, alertes et raffinements visuels. La combinaison de données ouvertes OpenAPS et de technologies Web modernes vous donne une flexibilité inégalée pour créer exactement l'expérience de surveillance dont vous avez besoin. Avec une conception soignée et des tests rigoureux, votre tableau de bord peut devenir un compagnon fiable pour gérer le diabète en temps réel. Rappelez-vous que l'objectif ultime n'est pas seulement d'afficher des chiffres, mais de vous aider à prendre des décisions éclairées rapidement et en toute confiance.